Hello Dear Boost Developers, Users: I post my opinion about GIL and boost in this thread. I work in the research field of computer vision applied to robotics and other applications. The current discussion is going far beyond the scope of my actual knowledge about generic programming. I am following the thread and I feel that there is a lot to learn about the 'magic' that does a good library. There are really lots of CV libraries out there and as a user/developer, I find sometimes hard to choose the more comfortable representation for images(I know, the term comfortable refers to a subjective impression/valutation ...). Very often, I would say, I choose the 'good ol' unsigned char* (don't try this at home), weird uh? ... but not so much in the end. So .. here my two cents: Modern machine vision domain is not only about filtering and convolve and/transform. It is quite clear now that Statistical Learning, Knowledge representation, Pattern Recog and so on, are all strictly related to scene understanding. I'd like also to add that Neurophysiology/Neuroscience also is becoming more and more important to understand and (trying to) model a Visual Apparatus. So, it is hard to point out at this moment what is missing in the current version of GIL. It is simply not possible decide that a library is complete when dealing with computer vision. Obviously GIL doesn't want to cover all these aspects. But back to the point. What happens in the everyday work is that you have different sources for the images and different environments where processing occurs. Let me briefly describe: In our setup now we have 3d Stereo Cameras (Point Grey - Bumblebee). 1D Laser Scan on a tilt unit for a 3D map/image (let me call it an 'Image'). CMOS usb cameras (acquired through OpenCV highgui library). The processing environment is mainly based on matlab scripts/mex files/compiled .m files (really... all fashions). What happens is that we have really different formats, dimensions and 'nature' for what is commonly called an Image. Say, bumblebee has its format, Intel, matlab represents images as matrices (in a column major fashion etc ...). And I guess that this is what every researcher/user have in his work. I believe that having a boost library to handle a common/standard format would be very nice. I know also Vigra because I often use Hugin (really wonderful program that uses Vigra) to make panorama images. It is really fast! Some years ago (not so many, anyway) I started using OpenCV from Intel. I found it quite easy to use but then was discouraged by the disontinuos support and releases (and the documentation is still quite old). Then I considered other solutions and came up with ltilib from the University of aachen, a quite huge and well designed CV library with a broad selection of machine learning algorithms and I continue to keep it updated and it solved me some problem also on the hardware side (yes, it deals with many aspects). I can continue with Gandalf, vxl (really huge and interesting, cmake based) and so on and so on .. And the result is that now I am stuck to the above mentioned unsigned char* (float* as well) representation. When I accidentaly saw GIL I was amazed by the design. And it does no matter in my poit of view that it has not all the routines for stereo-matching, gabor wavelet or skin recognition or SIFT or DOG pyramids ... and so on.. The most important issue is that it is lightweight, does not cause runtime problem when compiling with other libraries (well this happened sometime when mixing various libs).... And that (I hope that..) it will be included in boost. Now I think that asio + interprocess + GIL will boost the Boost libraries!! Well, I stop here ... just wanted to express my appreciation to the GIL people for their valuable exposition of their work and all the contributions from the reviewer from which I am really learning a lot of interesting things. best, Andrea Atanassov Tervel-PT1672 wrote:
I work for a Motorola biometrics unit. Our core business is fingerprint images: extracting minutia, cleaning them up, etc. I work in the infrastructure part of things, so I don't interact with image processing on a regular basis. A few months back a colleague of mine was tasked with finding a good library to base our future image processing development. After some review of the available libraries, he recommended GIL. His main reasons was the very good idea of view/image separation; the establishing a lightweight bounds checker/accessor to the image's pixels. I decided to review the library myself and found it to be very intuitive. As I mentioned earlier I work more in the business process/infrastructure side of things, so this was my first serious interaction with image processing. As a learning project, I decided to implement a few functions to get acquainted with the concepts of both GIL and the image processing. Within a week and a half of reading wikipedia and looking at GIL, I ended up implementing a convolution view. I enjoyed working with and learning from GIL; it is definitely a well thought out library. We will be using it for our needs.
Tervel Atanassov
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost