Re: [boost] [gil] New IO release

Subject: Re: [boost] [gil] New IO release
From: Christian Henning (chhenning_at_[hidden])
Date: 2010-11-22 19:24:54

Hi Domagoj, good to hear from you!

Not sure if you noticed, gil::io_new has scheduled a review starting
Dec, 1st. For this I wont make changes to the source until the review
starts.

>>> Um, to rewind things a little to make sure we are talking about the same
>>> thing. I was talking about reusing the backend library objects/instances
>>> (e.g. TIFF, jpeg_decompress_struct, ...), which IO2 supports and IO_new
>>> AFAICT does not.
>>
>> You can reuse a TIFF* but not reuse a jpeg_decompress_struct. It might
>> be a good idea to add these objects to the image_read_settings<
>> jpeg_tag > structures.
>
> Hmm...for this not to turn out akward/non-RAII-like you'd probably need to
> make your image_read_settings<> into a non-trivial class with proper
> initialisation and destruction...IOW your design would become more
> object-based (more io2-like)...which is what I'm proposing all along (and
> the way io2 is already designed ;)
>

io_new is also object-oriented but it also provides, as you know, the
free floating helper functions like read_image, etc. Even though, I
don't state it in the documentation but you could use the underlying
classes also. All image formats use the same reader class which is
hidden inside the detail namespace. For instance:

[taken from image_read.hpp]

detail::reader< Device
              , FormatTag
              , detail::read_and_no_convert
              > reader( file
                      , settings
                      );

reader.init_image( img
                 , reader.get_info()
                 );

reader.apply( view( img ));

This object can be reused at will. But I have a question for you. Are
you sure you can easily reuse a jpeg_decompress_struct object and jump
around a jpeg image without getting it confused? I mean, for instance,
imagine you read the last image line first and then try to read the
first line. Does that work?

>
>>> Simply reusing the low level source object (like a FILE) will make little
>>> difference if, for every ROI you read, you have to recreate the backend
>>> library object which in turn implies rereading the whole image up to the
>>> requested ROI instead of just continuing where you left off...
>>
>> Is this statement true when an std::ifstream object is used?
>
> Well yes, the type of the input/source object does not matter...the problem
> is in the fact that the backend object (e.g. jpeg_decompress_struct) is
> destroyed and recreated (e.g. for each call to read_image()) which in turn
> requires/makes the backend library code reread the image from the beginning
> (to read the header, dimensions, format etc...)...

See my question from above.

>
>> More advanced use cases might need such access to low level objects. I
>> agree with you that my current implementation lacks support for some
>> advanced use cases.
>
> The problem (in this particular case) is not (primarily) in the
> implementation but in the interface/design of io_new...
> If we can agree on this and that io2 solves these problems better would you
> agree to switch to (an) io2(-like) interface so we can merge and join our
> efforts? I can write some preliminary documentation on the base
> formatted_image (that forms the backbone of io2) and the requirements that
> each xxx_image implementation class (libpng_image, wic_image...) must fulfil
> according to which you can try and port for example your GIF reader and
> then, through this experience, say your objections/what you think needs to
> be changed/improved, how to accommodate/fit into/work with other parts of
> your work (the toolbox, the properties system...)...

I would love to work with you to create the best image reader/writer
possible for the boost community. Let's see what the review brings to
the table and afterwards we can start sorting out the major
differences. How does that sound?

Regards,
Christian