Boost logo

Boost :

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.


> 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,
Charter Member of OSGeo,
Member of ACCU,

Boost list run by bdawes at, gregod at, cpdaniel at, john at