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