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)
/* ... */
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.