So far, the three rejections I've seen all cite GIL's scope as a major/primary fault. Interestingly, the desired scope of each reviewer is different and possibly incompatible with the others: one desires a higher-level and far more general approach, one desires additional functionality, and one desires further decomposition. So, I'm beginning to wonder whether consensus on this matter is actually possible. I'd like to use some points made in this particular review to offer my understanding of GIL's scope, and my case that it encompasses a problem worthy of a solution in the form of a Boost library. I will provide my own review, separately. rasmus ekman wrote:
I vote that GIL is rejected this time.
This is not because I doubt the usefulness or quality of implementation, more due to the fact that there is at least one other generic library (Vigra), which covers much of the same field, that has been around longer, and supplies many more algorithms.
Since this seems to be the primary reason for your rejection of GIL, I'm curious whether your concern is that: a) it doesn't solve enough problems to be useful or b) it doesn't solve as many problems as it could My take on 'a' is that GIL absolutely does address problems concerning those who endeavor to write graphics and image processing routines that aren't tied to a specific image representation. If you're not interested in this problem, why do you use that as a basis for rejecting the library? Imagine you were writing fairly generic image manipulation routines - wouldn't you like a unified and efficient interface for accessing images of various precision and layout? 'b' is fundamentally open-ended and applies to a great number of libraries and problem domains. As it doesn't directly relate to the value of a solution, I think it doesn't warrant further discussion. I believe the core questions should be whether it solves a worth-while problem, and whether it does this in a way that meets Boost standards.
Vigra provides interface to FFTW, filters and convolution.
FYI, the FFTW library is fundamentally incompatible with boost's license requirements. For commercial applications, FFTW makes it non-free, and thus not directly comparable. Of course, you can compile it without FFTW support. Anyhow, I see GIL as an image access library - not an image algorithms library. My case for simply having a good solution to the image access problem follows. Suppose an algorithm provided by a given library didn't meet your requirements for speed, precision, supported image formats, or memory footprint. Perhaps you don't want to drag in a whole new library, just for one or two algorithms. Maybe you have a novel algorithm or implementation approach. For whatever reason, you can't or don't want to use the implementation provided by an existing library. In practice, these issues are quite common. Such cases would be less likely, if the library were written on top of a GIL-style image model. However, even if GIL did include a collection of algorithms - and had the very one you wanted - there's no guarantee that it would make an optimal or even acceptable performance vs. accuracy tradeoff, for your needs. When you're stuck writing your own implementation, it's helpful to have some routines that facilitate efficient image access. It'd be even better, if you could subsequently revisit decisions about your image representation, or reuse the same code for different types of images. For these reasons, even those who are simply consumers of image synthesis, manipulation, and transformation algorithms should see some value in GIL and the problem it solves. In summary, generic image access is instrumental in facilitating generic image algorithms. Since even the most generic and comprehensive collection of image algorithms will not suit all needs and uses, it's important to have a fallback solution for efficient & flexible image access. As you can see by the amount of work that went into GIL, this is not an easy problem to solve. IMO, it can and should be solved independently from the implementation of algorithms that use it. Matt Gruenke