Boost logo

Boost :

Subject: Re: [boost] GIL io_new review
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2010-12-08 07:27:12

Christian Henning wrote:

>> Ideally, this extension would have separated
>> out the wrapping of the libraries from the actual GIL image integration,
>> with the GIL image integration just being a layer on top of the image
>> library wrappers.
> Mhmm, what would the first wrapper do, apart from error handling and
> providing a c++ interface for callbacks?

Not much more.

> What kind of buffer type would you use?

For the decoded data? Probably just raw memory.

> I'm intrigued by your idea. But need more information.

Haven't we discussed this about 3 times before? Anyway, here's an online:

class ReadJpegImage {
   ReadJpegImage(std::string filename);
   ReadJpegImage(const char* filename);
   ReadJpegImage(const char* begin, const char* end);

   size_t width() const;
   size_t height() const;

   pixel_format_t pixel_format() const;

   template <typename pixel_t>
   void read_rows(T* data, size_t n_rows);

   enum dct_e { dct_float, dct_int, dct_fastint };
   dct_e dct_method() const;
   void dct_method(dct_e d);

void read_jpeg_image(const char* filename, boost::gil::any_image& image)
   ReadJpegImage i(filename);
   // from i into image...

>> In addition to my comments above, I note that it's necessary to jump through
>> hoops (using Boost.IOStreams) just to read an image from memory. ?Surely
>> this should be a fundamental operation; it would be much better to have a
>> ctor that takes begin and end pointers for the encoded image data.
> Do you think io_new should provide in-memory streams, as well? So
> many other libs do that already? I mean there is std::stringstream,
> boost::iostreams, Fast Format ( ), and
> more.

No no, that's precisely what it shouldn't do. I don't want all the
extra layers of code that that involves. I just want a ctor that takes
begin and end pointers for the encoded image data.

>> I have some concerns about the likely performance of the code due to
>> excessive copying of the data both in and out of the image library.
>> ?Although I've not measured the performance impact, I feel it would be very
>> desirable (and is certainly possible) for this library to have zero copying.
> You're right there are cases when zero copying is possible but there
> might be fewer cases than you think. For instance, reading a
> rgb8_image_t from a bmp still requires some channel shuffling since
> bmp stores the image as bgr8_image_t.

Well I've never needed to read an rgb8 image from a BMP file. Channel
shuffling is exactly the case when copying is necessary. But I find
it's more common to not need copying - and in particular, copying the
encoded data should not be necessary.

Regards, Phil.

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