Hi Domagoj,
Finally, as far as I remember, in all discussions so far, of the few user arguments/'wishes' that touched the issue of the interface of GIL.IO all wished for an interface change exactly in the direction where IO2 went...
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.
ps. placing a function inside a namespace does not make it non-global...
It's not global either. ;-)
(AFAICT) You can reuse the low level file object but not the backend library object, which is what I was talking about and what is prerequisite for, for example, efficient 'moving ROI'/sequential-in-blocks image reading...
Are you talking about FILE* only or does that include std::ifstream as well?
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.
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?
Again, I don't see how can you do that with free functions except by allowing users to pass in low-level-object-modifier-functors to your global interface functions...which IMO would pretty much defeat your original argument of a 'simple and easy to use interface'...
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.
Cool, I would love to know more. Can you point where in your code you do that?
In libjpeg_image.hpp search for "void skip_rows("...
Thanks, I will have a look.
Yep, working on a fix. Tiff is very flexible and reading files without conversion works fine. But when reading with conversion I get into a problem with template member overloading. Basically I have a switch statement that would overload the read_data member with the on-file pixel format as template parameter. Now this pixel parameter can be anything for gray1 to rgb23_55_12, etc. Which makes the switch statement approach not feasible. I'm inclined to only allow read_and_convert_image/view for the most common channel sizes.
I use Steven Watanabe's switch_ for this. And yes, when it comes to LibTIFF (and WIC) and the most generic case of runtime pixel format detection and conversion, this approach can cause generation of an uber huge amount of code of which the user may actually want to support/allow only a small subset... For this reason I planned to allow the user to specify compile-time filters for allowed pixel formats so that the code for other pixel formats does not get generated even if the backend supports them...
I went down the same alley for now. The user can only use read_and_convert_image for TIFFs for common formats like, gray1, rgb8, etc..
No, simply revert your change and use char const * where they are enough...unlike some think, a char const * is a perfectly valid C++ construct...
Yep, will do.
Also consider making friends with the disassembly window in release builds...
Any good tutorial on this somewhere? Regards, Christian