Boost logo

Boost :

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.

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