Re: [boost] GIL io_new review

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
>> else.

> 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:

rgb8_image_t img;

jpeg_image_file_reader j(jpeg_filename);  // <----- here

image_read_settings< jpeg_tag > settings( point_t(  0,  0 )
                                        , point_t( 10, 10 )
                                        , jpeg_dct_method::slow
                                        );

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.)

Phil.