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
