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-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 {
public:
   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);
   // ...read 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 ( http://www.fastformat.org/ ), 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.