Subject: Re: [boost] [gil] New IO release
From: Christian Henning (chhenning_at_[hidden])
Date: 2010-10-25 10:48:12
> 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
>>> object, which is what I was talking about and what is prerequisite for,
>>> example, efficient 'moving ROI'/sequential-in-blocks image reading...
>> Are you talking about FILE* only or does that include std::ifstream as
> 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
> 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
> 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,
> No, simply revert your change and use char const * where they are
> enough...unlike some think, a char const * is a perfectly valid C++
Yep, will do.
> Also consider making friends with the disassembly window in release
Any good tutorial on this somewhere?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk