Help needed with a very silly idea...

[Karlos]

You know, it's an interesting in point.

I know a few people who write the most atrocious code imaginable, simply because they are spoiled by the performance of their hardware. People who should not be let anywhere near a compiler, for that matter. Their only skill is in the application of brute force to solve any problem. Then they use some convenience-oriented, high-level language/design tools with which to write their ill thought out code.

I worry that the arts of problem analysis, algorithm design and implementation efficiency are fast dying.

[odin]

You...you.....geek!  :-P

[bloodline]

Karlos wrote:
You know, it's an interesting in point.

I know a few people who write the most atrocious code imaginable, simply because they are spoiled by the performance of their hardware. People who should not be let anywhere near a compiler, for that matter. Their only skill is in the application of brute force to solve any problem. Then they use some convenience-oriented, high-level language/design tools with which to write their ill thought out code.

I would fit probably into that category. I loved the Amiga because I could program stuff in any sloppy way and get great results, much better than my Speccie/Amstrad/C64 friends :-D

I worry that the arts of problem analysis, algorithm design and implementation efficiency are a fast dying.

Well, I would suggest the shift is from a problem oriented view of program design to a solution one.
Err... We don't need to worry about the implementation of the problem, and instead worry more abotu the outcome of the solution... or something...

[Karlos]

bloodline wrote:

Well, I would suggest the shift is from a problem oriented view of program design to a solution one.
Err... We don't need to worry about the implementation of the problem, and instead worry more abotu the outcome of the solution... or something...

Which is a completely bollox approach for this situation. And indeed most of the things I work on.

I guess I like the mental challenges of actually doing something well.

[bloodline]

Karlos wrote:

bloodline wrote:

Well, I would suggest the shift is from a problem oriented view of program design to a solution one.
Err... We don't need to worry about the implementation of the problem, and instead worry more abotu the outcome of the solution... or something...

Which is a completely bollox approach for this situation. And indeed most of the things I work on.

I guess I like the mental challenges of actually doing something well.

Yeah, well I suppose when it's a computer problem... hmmm. Anyay, there is a reason why DSPs have been developed... and that's for this type of task... so get yourself a DSP or more horsepower :-D

[23JUL]

You may try lookup 'Simple border tracing' in your favourite search engine.

Or try: http://ct.radiology.uiowa.edu/~jiangm/courses/dip/html/node126.html

To get a box around it, you have to get the max x,y and min x,y, of the list of coords.

[Karlos]

@ 23JUL/JULES :-)

Thanks for the link. The mechanism there reminds me of a trick used to speed up a mandelbrot generator I tried once. It had a  mask to define already calculated pixels and used this border tracing to determine the region that had reached the iteration limit, bound it off and 'flood fill' the area as being already rendered.

[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..

[Karlos]

@Jose

Stay away from 24-bit packed pixel format (3 bytes per pixel). It is surely not of God's pixel representation ;-)

If you need to compare true colour data, have your code load it as 32-bit by expanding with an alpha channel. Even if you don't use the alpha for anything (which increases your datasize by 25%), the benefits of sensible alignment and longword accesses to the data more than make up for it.

I don't know how exactly you are handling your images but it is realtively straightforward to have datatypes load it and then use the DTM_READPIXELARRAY method to extract a 32-bit truecolour (ARGB) representation, even if the source data is not 32-bit.

[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...

[Cymric]

Karlos wrote:
@ 23JUL/JULES :-)
Thanks for the link. The mechanism there reminds me of a trick used to speed up a mandelbrot generator I tried once. It had a  mask to define already calculated pixels and used this border tracing to determine the region that had reached the iteration limit, bound it off and 'flood fill' the area as being already rendered.

Ah damn. Beaten to it. I came up with the same algorithm after staring at the blue/gray picture for a while. I have the nagging feeling you could do something clever with edge detection algorithms followed by a fast byte/word scanner to get a rough idea where the outlines of the blobs are. Then you can let loose the above algorithm. Finally wrap up with a box-within-box algorithm and merge them as necessary. But you're looking at an O(N^high integer) algorithm at the very least.

By the way, if you can locate Nico François' TurboMandel (or MandelVroom, forgot the exact name) you can witness a fractal flood fill in action. It was quite a sight to see fractals rendered in seconds rather than hours on a lowly 68000 :-).