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. ;-)
> 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.
> - 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk