I have nothing to contribute to this thread other than to say thanks.
It's these types of discussions that make this list so valuable, in
which all of us get a change to explore different algorithms and learn a
lot along the way.
I've been expecting Alex Tweedly to jump in with some clever use of
arrays for an order-of-magnitude speed increase, as he's done so many
times before. :)
Great stuff, guys. Thanks for this thread.
--
Richard Gaskin
Fourth World
Revolution training and consulting: http://www.fourthworld.com
Webzine for Rev developers: http://www.revjournal.com
Bill Marriott wrote:
Bernd,
Thanks for the pointer... I believe I've corrected the error. Here's the key
part of the loop with friendly variable names and comments:
-- starting with the whole image, check a range of pixels for
differences
-- keep slicing the range in half until we find a block of unchanged
pixels
repeat while char currPixel+1 to currPixel+rangeToCheck of ImageA <> \
char currPixel+1 to currPixel+rangeToCheck of ImageB
-- aha, the range we're testing has changes
if rangeToCheck >= 8 then
-- eight bytes is at least two pixels... it's still too big;
slice it in half
put rangeToCheck div 4 div 2 * 4 into rangeToCheck
else
-- we're down to a single changed pixel now
-- record which pixel has changed (offset within the imageData)
put 1 into bytesChanged[currPixel+1]
-- move to the next pixel; assume that changed pixels are near
each other
add 4 to currPixel
end if
end repeat
-- we found one or more unchanged pixels; skip this section of data
add rangeToCheck to currPixel
-- and update the range to encompass the remainder of the image
put dataLength - currPixel into rangeToCheck
end repeat
My routine will be optimal the fewer changes there are in the image, and the
less distributed (more localized) those changes are. It took about 680 ms on
my 2.66 GHz Core i7 Vista system, so I took the progress bar out. :) Can
anyone improve on it?
"BNig" <niggemann at uni-wh.de> wrote in message
news:24255723.post at talk.nabble.com...
I like the ideas to speed up the analysis of differences among 2 images.
My
impression is that your approach with div 2 is leading to erroneous
resutls
because by dividing by 2 you break the 4 byte blocks of imagedata. 150 div
2
= 75, 75 div 2 = 37, 37 div 2 = 18. You get the idea. You eventually
compare
blocks of 4 that belong to 2 pixels. That can be alright but not in all
[...]
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
