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