Bruno Martínez wrote:

Is there a comparison with Anti-Grain? IIRC it also was representation independent.

No, I only learned about Anti-Grain recently. To do a library justice requires studying it in depth to make a good comparison. There are many libraries out there, and they keep evolving, so doing comparisons can be difficult and time consuming. If Anti-Grain is truly representation-independent, then it should be easier to adapt its algorithms into fully generic GIL algorithms. Lubomir

Is there a comparison with Anti-Grain? IIRC it also was representation independent.

Bruno

Question for Bruno (or anyone familiar with Anti-Grain): 1. How does Anti-Grain deal with planar images? Let's take the simplest possible example: Fill an image with the color red. Here is a possible code in GIL to do that: template <typename View, typename Pixel> void fill_pixels(const View& view, const Pixel& color) { typename View::pixel_t value; color_convert(color, value); for (typename View::iterator it=view.begin(); it!=view.end(); ++it) *it = value; }; Here is how to call it: rgb8_pixel_t red(255,0,0); // Channel ordering: RGBRGBRGBRGB... rgb8_image_t interleaved_image(100,100); fill_pixels(view(interleaved_image), red); // Channel ordering: RRR... GGG... BBB... rgb8_planar_image_t planar_image(100,100); fill_pixels(view(planar_image), red); How would this example look with Anti-Grain? __________________ Second question, how does AGG deal with images whose type is instantiated at run-time? (For example, suppose you read the image from a file and want to keep it in native form). Here is the extra GIL code to do this: template <typename Pixel> struct fill_pixels_op { typedef void result_type; Pixel _color; fill_pixels_op(const Pixel& color) : _color(color) {} template <typename View> void operator()(const View& view) const { fill_pixels(view, _color); } }; template <typename ViewTypes, typename Pixel> void fill_pixels(const any_image_view<ViewTypes>& view, const Pixel& color) { apply_operation(view, fill_pixels_op<Pixel>(color)); } Here is how to call it: typedef mpl::vector<rgb8_view_t, rgb8_planar_view_t> my_views_t; any_image_view<my_views_t> runtime_view; runtime_view = view(interleaved_image); fill_pixels(runtime_view, red); runtime_view = view(planar_image); fill_pixels(runtime_view, red); Again, my question is, how would this look in Anti-Grain? For the Vigra fans out there... How would the above two examples look in Vigra? For the Cairo fans... same question. Thanks, Lubomir

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov Sent: Thursday, October 12, 2006 2:52 PM To: boost@lists.boost.org Subject: Re: [boost] GIL Review - Integration with other graphics libraries,such as Cairo.

Lubomir Bourdev wrote:

...

template <typename View, typename Pixel> void fill_pixels(const View& view, const Pixel& color) { typename View::pixel_t value; color_convert(color, value); for (typename View::iterator it=view.begin(); it!=view.end(); ++it) *it = value; };

Here is how to call it:

rgb8_pixel_t red(255,0,0);

// Channel ordering: RGBRGBRGBRGB... rgb8_image_t interleaved_image(100,100); fill_pixels(view(interleaved_image), red);

// Channel ordering: RRR... GGG... BBB... rgb8_planar_image_t planar_image(100,100); fill_pixels(view(planar_image), red);

Hi Lubomir, sorry for asking this in the wrong thread, but: is it possible to write fill_pixels so that it produces the equivalent of three memset calls in the planar case, one per channel?

Absolutely! GIL already has similar performance specializations for some STL algorithms. For example, here is a simple way to write copy_pixels: template <typename SrcView, typename DstView> void copy_pixels(const SrcView& src, const DstView& dst) { assert(get_dimensions(src)==get_dimensions(dst)); for (typename SrcView::iterator it=src.begin(); it!=src.end(); ++it) { *dst++ = *src++; } } Here is a slightly faster version: template <typename SrcView, typename DstView> void copy_pixels(const SrcView& src, const DstView& dst) { for (int y=0; y<dst.height(); ++y) { typename SrcView::x_iterator srcIt=src.row_begin(y); typename DstView::x_iterator dstIt=dst.row_begin(y); for (int x=0; x<src.width(); ++x) dstIt[x]=srcIt[x]; } } (It is faster because operator++ for x_iterator does less work, as it doesn't have to deal with skipping potential padding at the end of each row. In fact, x_iterator is often a raw C pointer) But GIL doesn't use any of these. It uses performance specializations as follows: 1. If both images are interleaved and have no padding at the end of rows, invokes a single memmove 2. If both images are planar and have no padding at the end of rows, invokes a memmove for each channel 3. If they are of the same type but have padding at the end of rows, invokes memmove for each row (or K-memmoves per row in the case of K-channel planar images) Only in the worst-case scenario where they have a different layout or one/both are virtual, it will fallback to an explicit loop (the second version above). See the end of the video presentation for this. That allows for writing GIL algorithms that are both fully generic and down to the metal efficient. GIL provides metafunctions to query the properties of its constructs. For example, view_is_planar<View> is an MPL predicate that you can use to help write performance specializations. Lubomir

Joel de Guzman wrote:

Lubomir Bourdev wrote:

...

...

Is there a comparison with Anti-Grain? IIRC it also was representation independent.

Bruno

Question for Bruno (or anyone familiar with Anti-Grain):

IMO, Anti-grain and GIL serves different purposes. Anti-grain (http://www.antigrain.com/) is more about vector graphics while GIL is about Image manipulation and pixel data representations. While there is some overlap, of course, I think it's unwise to compare apples and oranges. IMO, these libraries complement each other rather than compete with each other.

Joel: We totally agree with you. We looked again at AGG. It is very, very nice, and in many ways complementary to GIL. However, I felt obliged to respond because people are asking for comparison and one reviewer already voted for rejecting GIL, in part because "Anti-Grain is richer". It would be really nice if you (or another AGG fan?), being familiar with AGG, look into and perhaps post an example showing how GIL could work with AGG. For example, how do we draw a line directly inside a GIL view. It doesn't have to be a fully-generic view. Let's start with something simple like: void draw_line(const rgb8_view_t& view, int x0, int y0, int x1, int y1) { // AGG magic here. } You can get the dimensions, stride and pointer to pixels of a GIL view. Can you make a shallow AGG rendering buffer from them and draw a line into it? The next question is, can we make draw_line more generic, and how much more generic (i.e. what kinds of images are possible) Thanks, Lubomir

Christian Henning said: (by the date of Sat, 14 Oct 2006 21:39:41 -0400)

...

The next question is, can we make draw_line more generic, and how much more generic (i.e. what kinds of images are possible)

I'm suggesting an iterator since one might to some extra work at each line's pixel. Think about antialiased lines.

Hi, some time ago I have written a small graphical library for simple use under X, I needed to draw a line. But in X libraries I only found drawing a line on the screen, while I wanted to draw it in the memory. I was too lazy to dig manuals for more. Instead I started searching for a nice line drawing algorithm. I have found some benchmarks, etc.. So Here I copy/paste the algorithm that according to those benchmarks is the fastest one.. // screw this, I'm too lazy to dig xlib manual to find line // drawing function different than // XDrawLine(display, d, gc, x1, y1, x2, y2) // which draws on the Display when I *need* to draw on XImage. // // Xaolin Wu's (public domain) algorithm void lix::line(int x0, int y0, int x1, int y1, int color) { // cout << "Xaolin Wu's alghoritm\n"; int dy = y1 - y0; int dx = x1 - x0; int stepx, stepy; if (dy < 0) { dy = -dy; stepy = -1; } else { stepy = 1; } if (dx < 0) { dx = -dx; stepx = -1; } else { stepx = 1; } putpixel( x0, y0, color); putpixel( x1, y1, color); if (dx > dy) { int length = (dx - 1) >> 2; int extras = (dx - 1) & 3; int incr2 = (dy << 2) - (dx << 1); if (incr2 < 0) { int c = dy << 1; int incr1 = c << 1; int d = incr1 - dx; for (int i = 0; i < length; i++) { x0 += stepx; x1 -= stepx; if (d < 0) { // Pattern: putpixel( x0, y0, color); // putpixel( x0 += stepx, y0, color); // x o o putpixel( x1, y1, color); // putpixel( x1 -= stepx, y1, color); d += incr1; } else { if (d < c) { // Pattern: putpixel( x0, y0, color); // o putpixel( x0 += stepx, y0 += stepy, color);// x o putpixel( x1, y1, color); // putpixel( x1 -= stepx, y1 -= stepy, color); } else { putpixel( x0, y0 += stepy, color); // Pattern: putpixel( x0 += stepx, y0, color); // o o putpixel( x1, y1 -= stepy, color); // x putpixel( x1 -= stepx, y1, color); // } d += incr2; } } if (extras > 0) { if (d < 0) { putpixel( x0 += stepx, y0, color); if (extras > 1) putpixel( x0 += stepx, y0, color); if (extras > 2) putpixel( x1 -= stepx, y1, color); } else if (d < c) { putpixel( x0 += stepx, y0, color); if (extras > 1) putpixel( x0 += stepx, y0 += stepy, color); if (extras > 2) putpixel( x1 -= stepx, y1, color); } else { putpixel( x0 += stepx, y0 += stepy, color); if (extras > 1) putpixel( x0 += stepx, y0, color); if (extras > 2) putpixel( x1 -= stepx, y1 -= stepy, color); } } } else { int c = (dy - dx) << 1; int incr1 = c << 1; int d = incr1 + dx; for (int i = 0; i < length; i++) { x0 += stepx; x1 -= stepx; if (d > 0) { putpixel( x0, y0 += stepy, color); // Pattern: putpixel( x0 += stepx, y0 += stepy, color); // o putpixel( x1, y1 -= stepy, color); // o putpixel( x1 -= stepx, y1 -= stepy, color); // x d += incr1; } else { if (d < c) { putpixel( x0, y0, color); // Pattern: putpixel( x0 += stepx, y0 += stepy, color); // o putpixel( x1, y1, color); // x o putpixel( x1 -= stepx, y1 -= stepy, color); // } else { putpixel( x0, y0 += stepy, color); // Pattern: putpixel( x0 += stepx, y0, color); // o o putpixel( x1, y1 -= stepy, color); // x putpixel( x1 -= stepx, y1, color); // } d += incr2; } } if (extras > 0) { if (d > 0) { putpixel( x0 += stepx, y0 += stepy, color); if (extras > 1) putpixel( x0 += stepx, y0 += stepy, color); if (extras > 2) putpixel( x1 -= stepx, y1 -= stepy, color); } else if (d < c) { putpixel( x0 += stepx, y0, color); if (extras > 1) putpixel( x0 += stepx, y0 += stepy, color); if (extras > 2) putpixel( x1 -= stepx, y1, color); } else { putpixel( x0 += stepx, y0 += stepy, color); if (extras > 1) putpixel( x0 += stepx, y0, color); if (extras > 2) { if (d > c) putpixel( x1 -= stepx, y1 -= stepy, color); else putpixel( x1 -= stepx, y1, color); } } } } } else { int length = (dy - 1) >> 2; int extras = (dy - 1) & 3; int incr2 = (dx << 2) - (dy << 1); if (incr2 < 0) { int c = dx << 1; int incr1 = c << 1; int d = incr1 - dy; for (int i = 0; i < length; i++) { y0 += stepy; y1 -= stepy; if (d < 0) { putpixel( x0, y0, color); putpixel( x0, y0 += stepy, color); putpixel( x1, y1, color); putpixel( x1, y1 -= stepy, color); d += incr1; } else { if (d < c) { putpixel( x0, y0, color); putpixel( x0 += stepx, y0 += stepy, color); putpixel( x1, y1, color); putpixel( x1 -= stepx, y1 -= stepy, color); } else { putpixel( x0 += stepx, y0, color); putpixel( x0, y0 += stepy, color); putpixel( x1 -= stepx, y1, color); putpixel( x1, y1 -= stepy, color); } d += incr2; } } if (extras > 0) { if (d < 0) { putpixel( x0, y0 += stepy, color); if (extras > 1) putpixel( x0, y0 += stepy, color); if (extras > 2) putpixel( x1, y1 -= stepy, color); } else if (d < c) { putpixel( stepx, y0 += stepy, color); if (extras > 1) putpixel( x0 += stepx, y0 += stepy, color); if (extras > 2) putpixel( x1, y1 -= stepy, color); } else { putpixel( x0 += stepx, y0 += stepy, color); if (extras > 1) putpixel( x0, y0 += stepy, color); if (extras > 2) putpixel( x1 -= stepx, y1 -= stepy, color); } } } else { int c = (dx - dy) << 1; int incr1 = c << 1; int d = incr1 + dy; for (int i = 0; i < length; i++) { y0 += stepy; y1 -= stepy; if (d > 0) { putpixel( x0 += stepx, y0, color); putpixel( x0 += stepx, y0 += stepy, color); putpixel( x1 -= stepx, y1, color); putpixel( x1 -= stepx, y1 -= stepy, color); d += incr1; } else { if (d < c) { putpixel( x0, y0, color); putpixel( x0 += stepx, y0 += stepy, color); putpixel( x1, y1, color); putpixel( x1 -= stepx, y1 -= stepy, color); } else { putpixel( x0 += stepx, y0, color); putpixel( x0, y0 += stepy, color); putpixel( x1 -= stepx, y1, color); putpixel( x1, y1 -= stepy, color); } d += incr2; } } if (extras > 0) { if (d > 0) { putpixel( x0 += stepx, y0 += stepy, color); if (extras > 1) putpixel( x0 += stepx, y0 += stepy, color); if (extras > 2) putpixel( x1 -= stepx, y1 -= stepy, color); } else if (d < c) { putpixel( x0, y0 += stepy, color); if (extras > 1) putpixel( x0 += stepx, y0 += stepy, color); if (extras > 2) putpixel( x1, y1 -= stepy, color); } else { putpixel( x0 += stepx, y0 += stepy, color); if (extras > 1) putpixel( x0, y0 += stepy, color); if (extras > 2) { if (d > c) putpixel( x1 -= stepx, y1 -= stepy, color); else putpixel( x1, y1 -= stepy, color); } } } } } } -- Janek Kozicki |

Christian Henning said: (by the date of Sun, 15 Oct 2006 13:29:50 -0400)

Even more interesting is that you can not only combine single pixels into a run of pixels, you can even combine runs of pixel into runs of runs of pixels, and so forth. I did that during my thesis. If you're interested I can send you a paper of where this algorithm is being described. Cool stuff.

Please send it offlist to me. I'm curious to see that :) Thanks in advance! -- Janek Kozicki |

To demonstrate how GIL can be integrated with other imaging libraries, we decided to create two wrappers of imaging algorithms of another library and invoke them from GIL. We picked Vigra as a test case. Here is the full sample file: http://opensource.adobe.com/gil/vigra_integration.cpp Synopsis: The first step is to provide metafunctions that map GIL view types to Vigra view types, as much as compatibility allows. Then provide functions that create Vigra views from GIL views: template <typename View> . .. vigra_src_view(const View& view) {...} template <typename View> ... vigra_dst_view(const View& view) {...} Then provide wrappers of Vigra algorithms: //////////////////////////////////////////// /// Vigra Algorithm wrappers //////////////////////////////////////////// template <typename SrcView, typename DstView, typename GradValue, typename DestValue> void canny_edge(const SrcView& src_view, const DstView& dst_view, double scale, GradValue gradient_threshold, DestValue edge_marker) { vigra::cannyEdgeImage(vigra_src_view(src_view), vigra_dst_view(dst_view), scale, gradient_threshold, edge_marker); } template <typename SrcView, typename DstView> void gaussian_convolve_x(const SrcView& src_view, const DstView& dst_view, double std_dev) { vigra::Kernel1D<double> gauss; gauss.initGaussian(std_dev); separableConvolveX(vigra_src_view(src_view), vigra_dst_view(dst_view), kernel1d(gauss)); } Finally this is how to invoke Vigra from GIL: //////////////////////////////////////////// /// main //////////////////////////////////////////// using namespace gil; typedef gray8_image_t image_t; int main() { image_t im_gray; jpeg_read_and_convert_image("test.jpg",im_gray); image_t result(get_dimensions(im_gray)); image_t::pixel_t gray(channel_convert<image_t::view_t::channel_t>(0.5f)); fill_pixels(view(result),gray); canny_edge(const_view(im_gray), view(result), 3.0, 5.0, 0); gaussian_convolve_x(const_view(result), view(result), 10); jpeg_write_view("test_out.jpg",color_converted_view<gray8_pixel_t>(view(result))); return 0; } ///////////////////////////////////////// Things work well only for 8-bit grayscale values. 16-bit gray sort of works ok, perhaps the only difference is the need to use different settings. If I use RGB values, however, canny_edge does not compile, and the Gaussian convolution returns the result in grayscale. Other color spaces, channel depths and planar images I am not sure how to set up. Perhaps I am not using Vigra properly. Prof. Köthe could you take a look at my source file (link above) and let me know if it looks OK? Thanks, Lubomir

Lubomir Bourdev wrote:

To demonstrate how GIL can be integrated with other imaging libraries, we decided to create two wrappers of imaging algorithms of another library and invoke them from GIL. We picked Vigra as a test case.

Things work well only for 8-bit grayscale values. 16-bit gray sort of works ok, perhaps the only difference is the need to use different settings. If I use RGB values, however, canny_edge does not compile, and the Gaussian convolution returns the result in grayscale. Other color spaces, channel depths and planar images I am not sure how to set up.

Perhaps I am not using Vigra properly. Prof. Köthe could you take a look at my source file (link above) and let me know if it looks OK?

I got your program to work. The 8-bit grayscale case does indeed give the correct result. In case of 16-bit grayscale, I found that the input grayvalues were shifted by 8 bit. I.e. instead of the value 188, the input image contained 48316 == 188 << 8 (the input file was the same). The edges changed accordingly. This is perhaps a byte order problem, or a bad reinterpret_cast? It failes to compile with 8-bit RGB because cannyEdgelList() is only applicable to scalar images at the moment (the docu says "SrcAccessor::value_type must be convertible to float"). But the convolution example works just fine. Compilation with 16-bit signed int also failes, because GIL doesn't define a conversion from gray8 to gray16s (it should). So VIGRA and GIL seem to be fairly interoperable. You should have contributed to VIGRA instead of starting your own library ;-) Regards Ulli -- ________________________________________________________________ | | | Ullrich Koethe Universitaet Hamburg / University of Hamburg | | FB Informatik / Dept. of Informatics | | AB Kognitive Systeme / Cognitive Systems Group | | | | Phone: +49 (0)40 42883-2573 Vogt-Koelln-Str. 30 | | Fax: +49 (0)40 42883-2572 D - 22527 Hamburg | | Email: u.koethe@computer.org Germany | | koethe@informatik.uni-hamburg.de | | WWW: http://kogs-www.informatik.uni-hamburg.de/~koethe/ | |________________________________________________________________|