Hi Domagoj, Domagoj Saric wrote:
Unlike io and io_new it uses objects that represent on-disk images ("formatted images" in io2-speak). This has several advantages: - you do not have to open an image twice in order to first query its properties (if you need to do so for whatever reason) and then to actually read it...which is both cumbersome and inefficient... - you do not have to open an image many times (and seek thru it over and over again) when reading an image in smaller pieces/ROIs... - an object based design allowed for a CRTP based design where most of the shared boiler plate code could have been extracted into a single base class which in turn allows for greater maintainability as well as easier extensibility - it provides access to the underlying backend to the user for maximum flexibility.
This sounds great. It's much closer to what I was trying to suggest back in March when we last had this discussion. I've had a quick look at your libjpeg interface. Two features that I often use are dct_method=JDCT_IFAST and scaling down 2x or 4x using scale_num and scale_denom. It would be interesting to know whether (a) your existing code lets me use these via a "native handle", or (b) they could be added easily. My preference would still be to have a thinner library-wrapping layer, i.e. just a C++ification of the C library interface (see e.g. http://chezphil.org/tmp/LibJpeg.hh for an incomplete example), underneath the gil interface. But what you're proposing sounds much closer to this than Christian's proposal. Regards, Phil.