Jose wrote:
It would be great news if the GIL authors and yourself can manage to integrate both libraries.
I haven't sent my GIL review, but while GIL provides a sound design it would benefit most by combining with the more mature VIGRA library.
We would be happy to see GIL's image abstraction combined with VIGRA's algorithms. That would be the best of both worlds! However, what we don't want to see is the review of GIL postponed to the indefinite future or the current GIL submission rejected because of the lack of VIGRA's algorithms. GIL core is a library with a very specific goal - to provide efficient and representation-independent access to the pixels of an image. Providing an extensive set of image processing algorithms has never been the design goal of GIL core. While no library can ever be complete, we believe GIL provides a comprehensive solution to the stated goal. Here is why we believe GIL is ready for boost submission as-is: 1. The set of image algorithms is fundamentally open-ended. Vigra has a good set of them, but so do other libraries, like Intel's IPP, and ITK. Why stop with VIGRA, why not take advantage of all of them? And why stop at imaging algorithms; why not include computer vision algorithms like the ones in OpenCV? And why not add vector graphics algorithms, like the ones in AGG and Cairo? And when would we be ever done? 2. A library with multiple goals that could logically and easily be separated should be broken down into multiple libraries. Notably, image processing algorithms (like the ones in VIGRA) constitute a separate goal and deserve a separate library. Vector graphics (AGG) is another separate goal and deserves a separate library. Of course, it makes sense for both of them to make heavy use of a core library (like GIL) that abstracts away the image representation. 3. As Matt Gruenke states, the goal that GIL addresses is sufficiently important in itself to justify it constituting a separate submission. There are many cases where you deal with images in which you don't need to deal with image processing algorithms. By providing GIL in boost today, we will address the needs of this set of people that would otherwise have to wait for an unspecified amount of time for something they don't need. 4. GIL is a large library. Adding an extensive set of algorithms to it will make it really huge. This will put a big burden on the boost review process and it will be hard to ensure high quality for a very large library. We believe it is better for boost to consume large libraries as a set of smaller, solid and self-contained component libraries. 5. One argument I heard mentioned is, before writing lots of algorithms, how do you know that your core is solid? It seems more appropriate to start with algorithms and derive the data structures from them. While we think this is generally the right approach, we are confident that GIL can handle any imaging algorithm. This is because all GIL does is provide an efficient and representation-independent access to the pixels of an image, and this is all you need to be able to write any imaging algorithm. We have certainly provided a proof of concept by providing fully generic algorithms for convolution, resampling and generating the gradient. We are not saying that the core is complete, in a sense that it provides you with all the tools you need in designing image processing algorithms. In writing GIL image processing algorithms you may discover useful abstractions, like, for example, the need for promotion traits. Some of these abstractions may logically remain in the numeric extension, but the best place for others may be GIL core. So adding imaging algorithms will likely be associated with updating the core with some new functionality, and maybe some minimal interface changes, and this is a natural evolution for any library. However, we don't believe that big changes to the current interfaces and large redesign of GIL core will be necessary. Some people say that GIL is a new library, so its design is unproven in the long run. While GIL has a shorter life compared to mature libraries like Vigra, we have been working on GIL for more than three years, designing, implementing, throwing away and redesigning it from scratch many times until we reach a design that we are confident with. In designing GIL we have examined and taken advantage of the ideas behind many mature imaging libraries, including Vigra. We have also drawn from the expertise of many people at Adobe, and imaging is one of Adobe's core businesses. Finally, we are using GIL to solve real problems. Lubomir & Hailin