Re: [boost] [gil] New IO release

Subject: Re: [boost] [gil] New IO release
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2010-11-22 17:27:20

Hi...sorry for the delay...had to do some context switching :)

"Christian Henning" <chhenning_at_[hidden]> wrote in message 
news:AANLkTimcmYfUXD=tXZLibfuMqdgmtg6X-p-Em81Th+83_at_mail.gmail.com...
> In any event, you need to make sure you offer at the very least a way
> to simulate the old gil::io interface to avoid breaking code.

Of course, this is trivial to provide...

>> 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 ;)

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

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

>> Also consider making friends with the disassembly window in release
>> builds...
>
> Any good tutorial on this somewhere?

You don't need one actually...you can pretty much google any unknown 
instructions and/or compiler/optimizer idiom you see ;)

-- 
"What Huxley teaches is that in the age of advanced technology, spiritual
devastation is more likely to come from an enemy with a smiling face than
from one whose countenance exudes suspicion and hate."
Neil Postman