Inefficient code - Solutions
Bill Marriott
wjm at wjm.org
Mon Jun 29 15:30:12 EDT 2009
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
> [...]
More information about the use-livecode
mailing list