- 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