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