Subject: Re: [boost] GIL io_new review
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2010-12-10 10:39:28
Christian Henning wrote:
> On Thu, Dec 9, 2010 at 3:03 PM, Phil Endecott
> <spam_from_boost_dev_at_[hidden]> wrote:
>> 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
> 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.
You can read row-by-row by repeatedly closing and re-opening the file
and skipping over all of the previously read lines. This is O(N^2).
Actually doing that in practice would be crazy, but yes you are right,
it can be done - for reading. But not for writing.
> Can it be done better? Yes. But the interface allows for it.
No, your interface does not allow for a better implementation.
> That's my point.
> Here one example:
> rgb8_image_t img;
> image_read_settings< jpeg_tag > settings( point_t( 0, 0 )
> , point_t( 10, 10 )
> , jpeg_dct_method::slow
> read_image( jpeg_filename, img, settings );
So how does that interface allow for an efficient implementation? It
doesn't. To function efficiently the image file needs to be kept open
from one call to the next. That can't be done with a free function
like read_image() that takes a filename. You need to decouple the
image file object from the reading and writing:
jpeg_image_file_reader j(jpeg_filename); // <----- here
image_read_settings< jpeg_tag > settings( point_t( 0, 0 )
, point_t( 10, 10 )
read_image( j, img, settings ); // Takes the file object, not the filename
Now, the file remains open while j is in scope, so you can read more
lines from it etc. with the possibility of doing so efficiently.
(If anyone is having difficulty following this, compare this will
reading and writing text files; imagine if the operations took
filenames, and there were no objects representing open files.)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk