|
Boost : |
Subject: Re: [boost] GIL io_new review
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2010-12-09 16:17:20
On 09/12/10 20:59, Christian Henning wrote:
> Hi Phil, only one comment.
>
> On Thu, Dec 9, 2010 at 3:03 PM, Phil Endecott
> <spam_from_boost_dev_at_[hidden]> 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.
>>
>>> 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.
>
>
> You can read row-by-row, pixel-by-pixel, tile-by-tile. It can be done
> in any rectangular shape. Now, is it done most efficiently? No. Can it
> be done better? Yes. But the interface allows for it. That's my point.
Thanks Christian for the clarification.
I've got confused myself as there have been mentioned some suggestions
and patches to the design which I have no idea about.
I took it as I got as there is some lack of functionality for some
non-whole I/O cases.
Best regards,
-- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk