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.