Re: [boost] GIL io_new review

Subject: Re: [boost] GIL io_new review
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2010-12-09 15:03:28

Mateusz, I'm going to snip most of your message to focus on the 
important stuff.  I don't have time to answer everything in detail and 
somehow my central point doesn't seem to have been understood yet.

> Anyways, my understanding is that Boost.GIL IO takes all the access
> options provided by format libraries as they are specified and either
> allows to utilise some or all of them.

No, that's precisely what it doesn't do.  It supports exactly one 
access method, which is to read or write a complete file in one go, and 
nothing else.

No doubt reading or writing a complete file in one go will be the most 
common operation, but it is not the only one, and it's not the one that 
I need for any of my current applications including the example that 
I've posted.  I think that it's unfortunate that Christian's extension 
has not tried to support at least sequential row-by-row access to images.

> Thus, I don't think it's possible for Boost.GIL IO to address such
> specific and advanced problems like Phil's. However, I think Boost.GIL
> IO backends could be not only format but problem specific as well.
> Perhaps, Phil's problem qualifies to be solved with a new GIL IO backend
> solving efficient block-based access implementing some assumptions:
>
> - one file open at time
> - calculation of memory efficient size of block based on size of
> scanline and max number of scanline to not to open too much
> - merge read blocks to single 256x256 written in single file
> - blocks/scanlines caching strategy (see GDAL case above)
> - etc.
>
> I believe it would be feasible with Boost.GIL and the IO extensions,
> as a specialised IO driver.

No.  I don't want a special IO driver to manage my tiled images.  I 
simply want a wrapper around the image libraries that I can call that 
hides much of the legacy interface.  I just wish that the extension 
we're reviewing had been decomposed into a set of such wrappers and the 
whole-image read/write code, such that I could use the wrappers and not 
the rest.

Regards,  Phil.