Re: [boost] GIL io_new review

Subject: Re: [boost] GIL io_new review
From: Domagoj Saric (domagoj.saric_at_[hidden])
Date: 2010-12-14 11:10:08

"Christian Henning" <chhenning_at_[hidden]> wrote in message
news:AANLkTimUnOcdfEZfUsyHQ8oGxCE5r-JTgcnaYHLp9a4L_at_mail.gmail.com...

Hi, Christian...allow me to only touch/answer a few points until I get more 
time...

> Though you have  libpng_image::read( ... ) and libtiff_image::write(
> ... ) but would you have a lodepng::read( ... ) as well or is that png
> backend somehow plugged into the reader class differently?

Yes(1st question)/no(2nd question), as said, this is (automatically)
provided for all backends in a single place (by the base class)...nothing
special to it actually...probably similar to your read_image()
function...step into it and it will be clear...

> One of the good things we have with io_new is that the header files
> let you define what to include quite well. Only reading jpeg then just
> include jpeg_read.hpp. No writing part of jpeg or any other backend is
> included.

This (source code inclusion) is not what I was referring to (I'd expect any
half decent compiler to handle this) but to using things like STL containers
where you do not actually need them under the excuse that the overhead will
be shadowed by something else in the code path (e.g. backend or OS call)
that cannot be avoided anyway...

>> ps. Ideally, in most cases there should be no 'inner-loop' in GIL.IO
>> (other
>> than those within the backend library itself)...
>
> ??? How do you read progressive png then? Meaning you have to read an
> image a couple of times to actual get the final result. I rather
> relieve the user from doing that.

That's why I said 'most' cases...and I didn't 'count'/consider the loop that
reads scanlines/tiles, that is necessary with some backends, as an inner but
an outer loop...

> In case you don't like all streams what would be a better way of
> supporting in-memory images. Please remember a common interface is
> needed for flexibility.

I already recommended and explained the approach with
boost::iterator_range<> (the way io2 does it) ... which is probably also
what Phil and Roland proposed...

e.g.:

using namespace boost;
using namespace boost::gil;

unsigned char const my_in_memory_jpeg[] = {....};

typedef libjpeg_image::reader_for<memory_chunk_t>::type
in_memory_libjpeg_reader_t;

in_memory_libjpeg_reader_t my_reader( my_in_memory_jpeg );

my_reader.copy_to( ... );

 > I think I read somewhere you're becoming a father soon. Congratulations!

Thanks ;)

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