Subject: [boost] Half-baked GIL IO extension review
From: Edd Dawson (lists_at_[hidden])
Date: 2010-12-06 18:10:22
- How much effort did you put into your evaluation?
A quick glance. I am interested in perhaps using the GIL in future and so keep
half an eye on it, but I haven't yet had time to really sink my teeth in to it.
I currently maintain a couple of C++ libraries for PNG and JPEG I/O  and
wouldn't mind being released of the burden ;) So I'm really looking at the code
to see whether it solves *my* problems. Hope that's ok.
- What is your evaluation of the design?
I think it's fine on the whole. But I'm left with some questions, some arising
from real-world uses:
1. is there explicit support for reading images from files with Unicode file
names? Or do I have to prepare a stream myself? I ask because there seem to be a
lot of overloads for reading from files whose paths are specified by char*s and
std::strings. IMO, in anything other than a toy application, these would be
useless for writing portable code. And for toy code I'd probably use the PIL
(Python) instead. So for *me*, these functions are redundant. I'm aware of this
redundancy because it exists in my code too :)
2. is it wise to drag the stuff from e.g. the IJG JPEG library's public headers
in to client scope? I ask because I've had clashes with the "boolean" macro
before and this would outright prevent me from using the library. The
implication of addressing this would probably mean that the GIL would no longer
be header-only. That's fine by me, but perhaps it's a design goal of the GIL for
3. Is there support for things like performing lossless JPEG rotations? Not a
big deal to me right now, but potentially I would like to use such a facility in
4. Is there support for obtaining the real-world dimensions of a loaded raster
in millimetres, say? I work on CAD/graphics applications which need this
functionality in order to generate reasonable texture coordinates.
- What is your evaluation of the implementation?
Looking again at the JPEG code here. As far as I can tell setjmp/longjmp have
been used with appropriate care, but I worry what will happen if a method on a
Device throws an exception, for example. I've had both Visual C++ 2008 and
Apple's g++ 4.0.1 crash on me in this kind of situation.
In my code, I attempt to store an exception by doing something akin to
boost::current_exception(), then longjmp out to a safe point before re-throwing it.
The IJG JPEG library can be compiled as C++ code and there's some new stuff in
Version 7 to control whether or not extern "C" blocks are used (look for
DONT_USE_EXTERN_C in the IJG source). It would be desirable in my opinion to
allow the user of the library the ability to use a build of libjpeg that was
compiled as C++. If compiled in such a manner, with a little care it is possible
to entirely replace setjmp/longjmp with exceptions. The same is true of libpng
and possibly of libtiff.
- What is your evaluation of the documentation?
Couldn't find a lot. Either my eyes are poor, or the documentation is :)
- What is your evaluation of the potential usefulness of the extensions?
Potentially very useful.
- Are you knowledgeable about the problem domain?
I know little about the inner workings of the file formats and compression
schemes involved, but have written my own C++ wrappers for libpng and the IJG
JPEG library ('libjpeg').
- Do you think the extensions should be accepted as a part of Boost.GIL
I personally couldn't use it until some of my concerns/requests were addressed.
But I certainly think it could be of value to others as-is.
However, I would say that there has to be more documentation, assuming I haven't
simply missed it... For this reason, my answer at the moment is regrettably 'no'.
I hope this was useful and my lack of general GIL knowledge doesn't invalidate
too much of my evaluation.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk