Christian Henning wrote:
On Thu, Dec 9, 2010 at 3:03 PM, Phil Endecott <spam_from_boost_dev@chezphil.org> 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.