- What is your evaluation of the design? I believe that the various Concepts namely treating a data sequence as a view on a matrix or grid, iterating a matrix or Grid , and Color have not been adequately thought about in their own right. I do like the locator concept, though AFAICS this has a lot of similarities to an iterator over a 2D or 3D grid, but again these could Concepts (e.g step iterator) could be abstracted out and then more generally useful - What is your evaluation of the implementation? I didnt look in detail. It appeared that some typedefs were only there to meet GIL Concept requirements and appeared to be unused. This is an indication that the implementation probably has unneccessary dependencies. - What is your evaluation of the documentation? Links to the Concepts don't work (they point to local files on my system). This makes it tedious to wade through. It would be preferable to have local HTML documentataion in full. The use of ConceptC++ style concepts is problematic. My suggestion is that if one wishes to use this style in the Docs then you should also follow through and actually put the Concepts into code and compile them on ConceptGCC. You could then verify that the documentation is correct. I suspect that the current GIL docs would require a lot of work to pass that test. In fact I would make that a requirement for any Docs that wish to use the ConceptGCC format. This would be an interesting discipline and I suspect would result in design changes to the library itself. Overall the docs seems patchy. I would suggest looking at other boost docs and seeing the difference in format. For one thing separating code tutorial and docs into separate dwnloads is confusing and time wasting. Look at librraies in the boost vault to see somethng of a common format. - What is your evaluation of the potential usefulness of the library? I see the usefulness in terms of separating the above Concepts. This would be more useful as various separate libraries. Each of the above Concepts is complex enough to deserve its own library. - Did you try to use the library? With what compiler? Did you have any problems? There is a format (official or unofficial) for library reviews, which has not been followed. The code is designed to be copied into the reviewers boost distribution for evaluation. The installations section of the tutorial doesnt cover quite what you are meant to do to install the library. The lack of detailed information is a common theme. I get the impression I am meant to be an expert in the domain to use the library. This put me off sufficiently not to bother trying the code. Suggestions for a first example. Load an image, provide some means or suggestions so that you can view the image. Show code for a transform of the image. View the result. Proceed like that. This would make for a much more powerful and comprehensible tutorial and would certainly get me more interested. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I found the documentation hard to follow for the reasons given above, hence I didnt look in detail. - Are you knowledgeable about the problem domain? No. Overall this is the libraries problem . It is very domain specific and the domain is specialised. Some of The Concepts ( actual rather than documented) are interesting, but the library seems intended for experts in this particular domain, not fro average users like myself. I vote to reject GIL in its current state. I would suggest the most useful part of the library potentially is that dealing with Colour, but not from an experts point of view as currently implemented. I would suggest thinking about how to make an easy to use Colour interface, maybe looking at current "standards" such as VRML, SVG, HTML, MFC. These are written from a users rather than a hardware viewpoint and all have similarities and AFAICS there is no insurmountable problem to provide an interface for the general user in an image processing library. regards Andy Little