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: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2010-03-22 19:35:19

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.