From: Hans Meine (meine_at_[hidden])
Date: 2006-11-02 12:35:45
let me throw in some more thoughts about a future imaging solution from
another VIGRA developer, being out of scope of the review though.
(Sorry if I am repeating topics from previous discussions; I was too busy in
the last weeks to take part in them or even to read all messages carefully.)
On Thursday, 02. November 2006 03:48, Lubomir Bourdev wrote:
> As I already mentioned, we also would like very much to see image
> processing algorithms added to GIL, whether or not it is accepted in
> In particular, the Vigra algorithms provide a good starting point.
Actually, this sounds like a good idea from a users' POV, but as a VIGRA
developer, it brings the bitter taste of submitting precious work results to
a rival project... ;-}
In the process of creating an improved imaging library solution from all the
mentioned projects, would you be willing to consider a name change or sth.
like that? E.g. boost::imaging or similar?
I could imagine that more developers would be attracted to such a "neutral"
successor, compared to "giving up" their own libraries and working on GIL.
> We also are looking for volunteers to implement other algorithms, such
> as the ones in OpenCV. It would be great to also have a GIL-layer over
> Intel's IPP library. Also, providing interfaces to AGG would be
Maybe a look at the ITK can be inspiring, too.
OTOH, one wants to have compatibility with linear algebra libraries,
geometry/drawing libraries (AGG / cairo / freetype / ...) and scripting
In the last years, I have put quite some work into our VIGRA python bindings
(using boost::python), which already exist in their second main incarnation
(alas, not officially released yet) and I would like to work on
boost::imaging python bindings, too then. (Our latest idea for a major
overhaul would be to use NumPy arrays behind the scenes, providing even more
compatibility and re-usability of existing, clever solutions.) Just to
mention yet another important component of an imaging system.
> More I/O formats too.
Do you plan to bring the GIL io layer into boost, too?
While I do not see our "impex" (import-export) library as being perfect at
all, I really think it is far superior to the GIL one.
One major advantage (besides supporting more filetypes) is that we have a
system for pluggable readers/writers which are automatically chosen depending
on the file type (file header for reading, filename extension on writing).
> There is a function called resize_clobber_image. [...]
> It does not copy the pixels. This could be done manually with
> copy_pixels if needed.
> We are looking for a better name, but resize_image implies the pixels
> are copied (and truncated) as with vector resize.
I would prefer the simple, STL-compatible name resize(), accepting the
> We didn't add copying
> of the pixels because doing so is often not necessary, and it is unclear
> what the copy policy should be exactly. (copy into top left? Truncate?)
I will try to catch up with the previous discussions and participate more
often during the next weeks.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk