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-21 20:00:50

Christian Henning wrote:
>> I was hoping that there would be a proper review of this, but I understand
>> and sympathise with why that hasn't happened. ?Nonetheless, if you consider
>> it's now finished and ready for general release, can I encourage you to
>> encourage others to post their "not review but review-like comments"?
>
> Ups, I think I misunderstood. The new test.jpg is going to be in 1.43.
> My submission is still waiting in the review loop. I have a review
> manager but he is still evaluating what he is getting into. ;-)

Ooops, sorry.

> Nonetheless, I remember you made some comments a few years back (
> 4/27/2008 ). I consider them mostly minor updates and have focussed my
> effort more on high-level features. But they aren't forgotten. Here is
> a list what you were suggesting for jpeg format:
>
> - DCT type: You can specify the type when reading an image.

That's good.  And writing?

> - 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.

> - MMX/SSE - Not necessarily this extensions problem. A user can use
> whatever libjpeg.

OK.

> - Rotation: Same state as Scaled Decoding.

I agree that this is not well described anywhere, but the program 
jpegtran can do it.

> - 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.

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.

Anyway, I am glad to hear that you still plan to have a conventional 
review for this work.

Regards,  Phil.