Re: [boost] [gil] New IO release

Subject: Re: [boost] [gil] New IO release
From: Christian Henning (chhenning_at_[hidden])
Date: 2010-10-25 10:48:12

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