Subject: Re: [boost] [gil] New IO release
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2010-10-11 09:46:47
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.