Inefficient code - Solutions
Generic Email
generic.email.30022 at gmail.com
Tue Jun 30 15:08:49 EDT 2009
Bill, this is phenomenal. I added the progress bar BECAUSE it was
taking so long.
Your code is much faster. I tried adding the revision below to you
stack, but I keep botching something and it is recognizing 0 changes.
Once you are happy with it, I think it would be great to see it in
Revolution Online. Until then, could you post your final?
Thanks
Bert
On Jun 29, 2009, at 2:30 PM, 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
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
More information about the use-livecode
mailing list