Re: [boost] GIL - late review

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