Help needed with a very silly idea...

[Jose]

@Karlos

Just another silly idea...
Could there be more than one object you're trying to identify in the same horizontal space? If not you could use some form of prediction about where the start of the object is based on the start of the previous line (after you detect the start of an horizontal line that is...).

[Jose]

Hey. Since the blobs can repeat themselves in a line I think all pixels have to be scanned. So the thing would be to opimize the detection routine. I know you more than know this, it's just that the program I'm doing has a similar routine;) Except that instead of trying to identify pixels that fall within a certain range it compares pixels of two successive images. I'll let y'all know what it does when I get a good, completed working version. I had a doubt that I think applies here too:
 When comparing two pixels and checking the difference is there a way to use LONGs instead of BYTES to access compare and infere about the diference of each color component between 2 pixels? That would probably acceleratte it by 3 times or so..
I want to use C for now to make it portable to AOS4 so no 68k assembler (just for now :-D ).

Sorry for hijacking the thread  :-D but I think this could be usefull for the code that makes the pixel comparisons used in your detection routine too, it's practically the same I think, except that you're using a range (two pixel comparisons probably for the higher and lower values ?).

[EDIT] I meant, in your case it could be two pixel comparsions(higher and lower range value checking) each for each color component.

[Jose]

@Karlos
"..if you need to know which pixels are different, there are a couple of ways of working it out. Probably the easiest is to take the result of the 32-bit xor operation and mask it with four succesive 32-bit masks that each isolate a byte in the long word. Anything coming up as non zero is a difference"

Slightly more complicated. I want to determine the color diference of each color component between two equivalent pixels (e.g. in the same position) in two images of the same size. I can't use LONGs for that because the results of a diference might pass the boudaries of each BYTE in a LONG.
I'm also scanning all pixels :-D so this is the critical part of the code..

[Jose]

@Karlos

Yes, but if I use the DTM_READPIXELARRAY to get an ARGB representation and the source file/memory region is in a different format, say 24bit-packed (isn't that and YUV what most Jpegs are in by the way?) won't things slow down the same cause the OS will have to do the conversion anyway ?  I though about doing a routine just for the 24bit-packed format wich uses LONGs, treating each LONG as, successively, RGBR, then GBRG and BRGB... but I haven't looked at the details to see if it's possible in my case...