Hi Christian, I've just had to remind myself what this was all about. I may have forgotten or mis-remembered something. Christian Henning wrote:
- DCT type: You can specify the type when reading an image.
That's good. ?And writing?
Just added it. Good idea!
- Scaled Decoding: Todo - Never figured out how to do that. Couldn't find anything on the net. - Partial Image Decoding - Same as Scaled Decoding
Well, I think both of those things are described in the libjpeg documentation. ?If you can't find it and are interested in implementing it, please let me know.
I would be interested in a pointer to details of Partial Image Decoding. Depending on the amount of effort I'll either add it now or after the review. My time frame is kinda small right now.
I think the situation was that you were decoding and discarding the stuff after the area of interest, which was obviously wasteful and fixable. The more difficult issue was whether it is possible to reduce the work done prior to the area of interest. I don't have a good enough understanding of libjpeg to know the answer to that. Presumably there are similar issues with the other formats.
- Rotation: Same state as Scaled Decoding.
I agree that this is not well described anywhere, but the program jpegtran can do it.
I consider this a "nice to have". This extension is about IO but again if it's easy to integrate I'll do it.
Unfortunately it's not always possible to respect partitioning like "this bit is IO" when that breaks the performance. But again, I still don't know how to do this rotation. I have a feeling that there really aren't many people around who actually understand libjpeg properly...
- In-memory jpeg: This is done. Please see unit tests.
The last time that I looked at your code - about a year ago - my problem was to take a very large TIFF and to chop it up into 256x256 PNG tiles. ? ?I wanted to do this without having to keep all of the image data in memory simultaneously. ?This seemed to be beyond what you could offer. ?I'm unsure whether or not it's fundamentally possible with gil or not; I had hoped that its idea of "views" would make it possible if the views could lazily obtain the data from the source image. ?Even if gil can't do this, it would be good if your libtiff/png/jpeg wrappers were usable for general C++-ing of those libraries.
You can read subimages from a tiff image. At least in theory, I just noticed a bug when trying to do that. This bug is only with tiff images. All other formats work fine.
Once that's done you have a gil image which you make into a png
So for my problem of chopping up the TIFF into lots of tiles, I think I have two choices: (1) Decode the whole TIFF into one gil image. For each tile, create a gil view and create and save a PNG. (2) For each tile, partially decode the TIFF into a gil image, and create and save a PNG. The first choice uses lots of RAM. The second choice uses lots of time because the partial decoding has to decode and discard all of the content that precedes the area of interest. Is that true?
I also recall some concerns about how you were handling errors from one of the libraries. ?I think you had a setjmp() that was bound to fail, or something like that.
I'm using setjmp in the jpeg and png specific code.
In jpeg/read.hpp you have a namespace-scope static jmp_buf. I immediately worry about thread-safety. Even in a single-threaded app I can't see how this works if you have more than one jpeg file open. Then you setjmp() in the constructor. The jmp_buf is invalid as soon as that scope returns, so if libjpeg calls your error_exit() from after the ctor has finished (e.g. in jpeg_read_scanlines()) it will crash. (Have I grossly misunderstood how this works?) I haven't looked at your other uses. Regards, Phil.
