Subject: Re: [boost] gil::io "non-review" (was: [gil] Can not open test.jpg)
From: Christian Henning (chhenning_at_[hidden])
Date: 2010-03-22 17:35:50
Hi Phil,
>> - 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.
>> - 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.
>
>> - 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
without writing it to a file. You can use std::stringstream instead.
Here is an example of doing this taking from my unit tests:
BOOST_AUTO_TEST_CASE( stream_test )
{
// 1. Read an image.
ifstream in( jpeg_filename.c_str(), ios::binary );
rgb8_image_t img;
read_image( in, img, tag_t() );
// 2. Write image to in-memory buffer.
stringstream out_buffer( ios_base::in | ios_base::out | ios_base::binary );
write_view( out_buffer, view( img ), tag_t() );
// 3. Copy in-memory buffer to another.
stringstream in_buffer( ios_base::in | ios_base::out | ios_base::binary );
in_buffer << out_buffer.rdbuf();
// 4. Read in-memory buffer to gil image
rgb8_image_t dst;
read_image( in_buffer, dst, tag_t() );
// 5. Write out image.
string filename( jpeg_out + "stream_test.jpg" );
ofstream out( filename.c_str(), ios_base::binary );
write_view( out, view( dst ), tag_t() );
}
I hope this gives you an imagination of what's possible with the new
io extension.
Is this what you have in mind?
>
> 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.
Regards,
Christian