From: Hans Meine (meine_at_[hidden])
Date: 2006-11-02 12:35:45
Hi Lubomir,
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
> Boost.
> 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
> terrific.
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
languages.
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
different^H^H^H^H^H^H^H^H^Hadapted semantics.
> 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?)
Agreed.
I will try to catch up with the previous discussions and participate more
often during the next weeks.
Greetings,
Hans