Hi Brett,

Thanks. I've read the tutorial (or at least glanced over most of it), but I honestly can't find anything (besides possibly the transform_pixel_positions algorithm) that would do what I want to do. Also, all of the X/Y 2d loops seem to use a numeric loop for the outer loop (I was hoping to be able to use iterators for both, since it would be easier to go from left-to-right and top-to-bottom extents, where left isn't necessarily 0 and top isn't necessarily 0).

Sorry for getting back so late. Do you still have problems? If though, please send me some sample code that I can work with. Regards, Christian

Brett, For your first question, it's probable that using 1d iterators would not speed things, as they're less performant for 2d traversal. To gain some speed, you could try storing the results of 'src.height()' and 'src.row_end(y)' into variables, this would allow the compiler to know for sure that these values are constant. Also note that using numerical values are not really a problem for your algorithm reusability : you could feed it with, say, a view transformed with 'flipped_up_down_viewhttp://www.boost.org/doc/libs/1_42_0/libs/gil/doc/html/g_i_l_0163.html' so it could operate bottom-up, and so on. For your second question, I'd look at creating a 'subimage_view' from your source view, and then use 'copy_pixels' to copy it to your destination image. This should be pretty close to optimal gil usage. Cheers, Nicolas.

Brett,

glad I could help ! The only thing I'm confused about is that you say that using 1d iterators

wouldn't help much (and, btw, I was able to use the iterators correctly now that I didn't need to add to the x/y coordinates in the destination view). The documentation clearly says that v(x, y) is slower than iteration. Would you mind clarifying what you mean? What I'm doing now, and what a lot of the samples do, is something like this:

for(int x = 0; x < width, ++x) for(y_iterator y = src.y_begin(x); y != src.y_end(x); ++y) /* ... */

Actually, you're approach is the good one. I should not have said '1d iterators', its confusing. I only wanted to warn you that according to http://www.boost.org/doc/libs/1_42_0/libs/gil/doc/html/giltutorial.html#OneD...: *GIL image views provide **begin()** and **end()** methods that return one

dimensional pixel iterators which iterate over each pixel in the view, left to right and top to bottom. They do a proper "carriage return" - they skip any unused bytes at the end of a row. As such, they are slightly suboptimal, because they need to keep track of their current position with respect to the end of the row. Their increment operator performs one extra check (are we at the end of the row?), a check that is avoided if two nested loops are used instead.*

So, what I meant is to avoid using something like : for (iterator it = src.begin(); it != src.end(); ++it) /* ... */ which is often suboptimal to traverse the pixels of a view. Just one comment about your loop, as you mentioned a need for performance, be careful about the order of the loops, as the performance of your traversal may vary with the memory layout of the pixel data of your view. Most of the time, its recommended to iterate over 'y' in the outer loop : for(int y = 0; y < height, ++x) for(x_iterator x = src.row_begin(x), end = src.row_end(); x != end; ++x) /* ... */ This allows, considering a typical image memory layout, to traverse raw images in a cache coherent way. Note also that calling row_end() at every pixel may not be nicely optimized away by your compiler. Best regards, Nicolas.

On Fri, 2010-04-09 at 00:56 -0400, Brett Gmoser wrote:

The documentation clearly says that v(x, y) is slower than iteration.

Interestingly, I've just been benchmarking the various GIL image traversal methods, as I find the coordinate access method very convenient, but I wanted to get some idea of how much improvement I should realistically expect from converting code to use iterators. Results obtained on standard Debian Lenny on an Intel Core i7, compiled with -march=core2 -mfpmath=sse -msse4.1 -O3 -DNDEBUG ; the main bits of code appended to this email. GIL coord access 1120.9697 Megapixels/s GIL row iterator access 1293.0218 Megapixels/s GIL image iterator access 77.9477 Megapixels/s I was pretty surprised just how efficient the v(x,y) accessor is, and even more surprised by how inefficient the whole-image iterator is! Inspecting the assember, the inner loop of v(x,y) looks like: .L768: xorb (%rcx,%rdx), %sil movq %rax, %rdx incq %rax cmpq %r8, %rax jne .L768 which is very lean, but not quite as good as the inner loop of the row iterator: .L734: xorb (%rdx,%rax), %cl incq %rax cmpq %rax, %r8 jg .L734 However, the inner loop of the all-image iterator is: .L696: movzbl (%rcx), %eax incq %rdx leaq 1(%rcx,%rbp), %rcx xorl %eax, %r10d .L708: testq %rdx, %rdx jne .L696 cmpq %rcx, %rbx jne .L696 which is a bit more complicated, although it seems remarkable it runs ~15 times slower than the other methods. What I took away from this: - Avoid the all-image iterator like the plague (although I don't really understand how it manages to be quite so spectacularly slow). - You need to be pretty desperate for performance to convert working and basically fast enough coordinate-access based code to iterators. - Compilers can do a pretty nice job with GIL classes. I've used other image classes which leave far more to run-time (e.g virtual function calls) and you have to basically "unload" the class information to pointers and ints and do it all yourself to get performant inner loops. ----- BOOST_AUTO_TEST_CASE(coord_access_benchmark) { unsigned char hash=0; scoped_timer t("GIL coord access",images().size(),"Megapixels"); for (images_t::const_iterator it=images().begin();it!=images().end();++it) { const boost::gil::gray8c_view_t v=boost::gil::const_view(**it); for (int y=0;y