Re: [boost] GIL io_new review

Subject: Re: [boost] GIL io_new review
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2010-12-09 15:40:10

On 09/12/10 20:03, Phil Endecott wrote:
> Mateusz, I'm going to snip most of your message to focus on the
> important stuff.

Sure.

> I don't have time to answer everything in detail and
> somehow my central point doesn't seem to have been understood yet.

Yes, I've realised it lately.

>> 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.

Right, understood. I've been looking too far in future I think.

> 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.

Yes, agreed.

> I think that it's unfortunate that Christian's extension
> has not tried to support at least sequential row-by-row access to images.

It would be useful indeed.

>> 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.

Yes, this has been clarified now.

Thanks for the detailed explanation.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org