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.