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