Thorsten wrote:
On Fri, Oct 13, 2006 at 01:43:50PM -0700, Lubomir Bourdev wrote:
A related question: Which one is easier - building new functionality on top of a solid design, or extending the design of a library with lots of existing algorithms that are built on top of the old design?
What if you need to revert your design, because certain functionality is not (or not easily) implementable - and you only find out while doing that one, specific algorithm? So, seeing a lib with lots of (algorithmic) functionality kind of increases my confidence that the basic design is sound...
Your argument is generally true, but not in the case of GIL. GIL's goal is simple - to provide consistent, fast and representation-independent access to the pixels of an image. I claim that navigating the image and being able to get/set the values of the pixels is sufficient interface to build any imaging algorithm. Can you provide a counterexample?
Merging between GIL/Vigra or especially GIL/AGG would be interesting.
To repeat: I'd at least like to have Vigra's concept of pixel accessors and promotion traits merged/applied in GIL.
Promotion traits, as I stated in another thread, are handy and there is definitely a value in providing them. But I think they are an integral part of the imaging algorithms and therefore belong in the numeric extension. So stay tuned! As for Vigra's pixel accessors... I read the documentation and I am still struggling to understand the difference between using them and using a PixelDereferenceAdaptor. If they indeed serve the same purpose, that would be an argument against including them in GIL. Can you post a simple example that illustrates how pixel accessors in Vigra are used? Thanks, Lubomir