Doobrey wrote:
I hit on an idea earlier on, if the org. pic is >= 2x new size, I could do a quick resize to 1/2 org size using a colour average on a 2x2 block, then apply the slower resampling on that. Results were as good as resample of the org. image, but the time taken was only slightly faster
Looks like it's time to revert to asm :crazy:
It all comes down to your inner loops. Chances are you can write a decent implementation in C for a simple 4 -> 1 point resample.
Obvious things you can do when processing an image when speed is important
Never, *ever*, even upon pain of death, use a nested loop for x, y that gives you expressions like "pixel[(y*width)+x]" or "pixel
- [y]" (which typically evaluates to the same thing).
Always use a single, constantly incrementing pointer for the current pixel. If you need the pixel above, below, left or right, just add (or index with) the appropriate offset. Skipping all the multiplications this type of thing can cause is usually a good speed up.
Always use shifts for multiplication and division when using any constant power of 2 (such as averaging the value of four pixels). A good compiler should do this automatically but it never hurts to do it explicitly.
Due to the effects of cache, on a 68040 or 68060 it can be faster (when your source data is in cacheable memory) to write code that manipulates the individual byte components of a pixel rather than trying to load a 32-bit pixel representation to an integer and muck about with it. Experimentation is the key.
Once you have gotten your C code as fast as you can make it, and it still isn't fast enough, then use asm.