Boost logo

Boost :

Subject: Re: [boost] GIL io_new review
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2011-01-16 08:31:10

"Phil Endecott" <spam_from_boost_dev_at_[hidden]> wrote in message
>> why can't you just read individual 5k input tiles and chop each of those
>> into the smaller output PNGs and then move on...yes the 5000%256!=0 issue
>> might require reading up to 4 input tiles and/or remembering some of the
>> edge data for the cross-border input tiles and/or maybe of the input tile
>> which in turn would require a (much) more complex code...but I do not
>> really see the issue with that
> I prefer fast and simple code to either fast-and-complex or
> slow-and-simple.

Khm...I must say I still doubt that that/your approach, considering the
inherent RAM and disk thrashing (and the consequential virtually zero
locality of reference) can be even nearly as fast as the 'complex code'

>>> So I just want the library to provide the simple
>>> open/read-row/write-row/close functionality for the image files, and to
>>> supply types that I can use for pixel_t, etc.
>> Independent of the rest of the discussion/issues, yes I would agree that
>> explicit read/write row would be a valuable part of the interface...
> Great.

As mentioned in a recent reply to Mateusz, I've finally cleaned up the code
to compile on GCC and Clang as well as added a 'low level interface' (to all
backends) that might satisfy your needs:
 - pixel_size()
 - row_size()
 - format()
 - image_format_id()
 - can_do_row_access()
 - can_do_tile_access()
 - can_do_roi_access()
 - can_do_vertical_roi_access()
 - begin_sequential_row_access()
 - get_native_format<>
 - global formatted_image_traits<>::supported_pixel_formats_t
+ libtiff_image specific:
 - tile_size()
 - tile_row_size()
 - tile_dimensions()
 - begin_sequential_tile_access()

Most of these are probably obvious (or will be from examples/code), except
maybe for format() - it will return a 'value' that is a backend's internal
representation of the loaded image's pixel format and can be used in two
ways: whether it matches a format of your target image (whose, backend's
internal, format value you retrieve with the get_native_format<> member
metafunction) or to convert it to the index in the backend's MPL typelist of
supported formats (e.g.
formatted_image_traits<libjpeg_image>::supported_pixel_formats_t) by passing
it to the image_format_id() static member function...

You can find a link with example code in the recent reply to Mateusz: ... hope you find
it useful...

"What Huxley teaches is that in the age of advanced technology, spiritual
devastation is more likely to come from an enemy with a smiling face than
from one whose countenance exudes suspicion and hate."
Neil Postman 

Boost list run by bdawes at, gregod at, cpdaniel at, john at