Re: [boost] gil::io "non-review" (was: [gil] Can not open test.jpg)

Subject: Re: [boost] gil::io "non-review" (was: [gil] Can not open test.jpg)
From: Christian Henning (chhenning_at_[hidden])
Date: 2010-03-25 15:51:51

Hi Phil,

>
> You can probably just declare the buffer before you call setjmp().
>
> However, I only have an intuitive idea of what happens.  It really needs
> someone who actually understands this stuff (i.e. the spec) to look at it.
>  For example, the GNU libc manual says:

For now, I'll do that. I also put a comment to keep a record of this
problem. Hopefully someone will get back to me on this issue. I don't
consider this a show-stopper.

>> When you C++-tified libjpeg for instance, in what container would you
>> store the data? You probably would use a template parameter to give
>> the user the option.
>
> No; if I were doing this, I'd first wrap libjpeg to hide all its nasty warts
> like this error handling, increase the type safety, and other "thin" changes
> - as above.
>
> class ReadJpegFile {
> public:
>  struct JpegDecodingError: std::exception {};
>  typedef uint8_t sample_t;
>  ReadJpegFile(std::string fn);
>  ~ReadJpegFile();
>  size_t read_scanlines(size_t n_lines, sample_t* data);
>  ....
> };

Understand what you mean. Quite a workload you are describing. ;-) It
might be nice GSOC project, though. In a future version of gil::io we
might just do that. My goal right now is to replace the current
gil::io with the new version and I'm running out of time. I'm in the
process of creating the final release candidate.

>> Also, how would a C++ wrapper help you with large images?
>
> My point is that your gil interface doesn't help me with large images in
> limited RAM, and your current design is "all or nothing".  Decomposing it
> into wrappers around the libraries that are independently useful would mean
> that I could use them directly and get the benefit of e.g. the error
> handling stuff, with my own row-at-a-time code on top.

Imagine for now libjpeg doesn't allow for partial image decoding. How
would you solve that problem? My solution might be to create a virtual
image container which only holds a certain amount of an image in
memory and the rest on the hard drive. Though, while reading a large
image this container will handle limit memory situation on the fly.

I have been glancing over libjepg documentation. One of the advanced
feature is called "Buffered-image mode". It goes like this:

"In buffered-image mode, the library stores the partially decoded image in a
coefficient buffer, from which it can be read out as many times as desired.
This mode is typically used for incremental display of progressive JPEG files,
but it can be used with any JPEG file.  Each scan of a progressive JPEG file
adds more data (more detail) to the buffered image.  The application can
display in lockstep with the source file (one display pass per input scan),
or it can allow input processing to outrun display processing.  By making
input and display processing run independently, it is possible for the
application to adapt progressive display to a wide range of data transmission
rates."

Do you think this feature can be used to read out sub-images?

Regards,
Christian