[boost] Half-baked GIL IO extension review

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 [1][2] 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[3] 
(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 
some reason?

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 
future.

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
library?

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.

Kind regards,

Edd

[1] http://bitbucket.org/edd/pngxx
[2] http://bitbucket.org/edd/jpegxx
[3] http://www.pythonware.com/products/pil