Image resizing.

[Doobrey]

Does anyone have any good ideas for resizing a 24bit image that doesn't take ages on a 68k CPU ?
Basically I'm trying to resize a cover image from an ID3 tag to fit a 132*132 12 bit screen (Nokia LCD  currently on the parallel port :-D ).
I've currently tried 3 methods, but have problems with each of them.

1. graphics.library's BitMapScale is damn quick, but gives really crappy results( will it even handle 24bit bitmaps on Amigas without cybergfx or p96?)
2. My own scaling, sampling every pixel of the original image and then creating an average RGB value for each pixel of the resized image, best image but slower than treacle.
3. Another routine I did, just sampling the every nth pixel of the original and plotting that to the new image, (where n = orgsize/newsize ), quick but gives results comparable to BitMapScale

I also looked at the scaling provided by v45 datatype.library, but I don't want to limit it to OS3.9

Really I'm looking for an method that meets 1/2 way, trading a bit more CPU time for a better image quality

[Doobrey]

I did some tests last week with raw image data converted with Photoshop and just did a hacky conversion to 12bit  (r/2,g/2,b/2) and it looked suprisingly good.
 The LCD also has a 256 colour mode in which you could set 8 levels of red and green, and 4 levels of blue. The LCD controller can take a 12bit value and map it to the nearest rgb levels, I had to look really hard to spot any difference between 256 and 4096 mode, so I might end up using 256 col mode just cos it takes 1/2 the time to send the data( Still approx 1 sec to fill the screen!)..but I'm waffling now :roll:

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:

(ham caveats apply)

 Yup, always remember to set the Use_Pineapple_Rings flag  :-)

[Doobrey]

Karlos wrote:

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.

 Ta for the pointers (no pun intended)
 I just did some tests of an asm version, got it down to 1/2 a second to resample a 600x600 image to 132x132(although that was on WinUAE with JIT enabled :roll: but still waaaaaaay faster than the tests I did with Windows last night!) although that was reading a pixel as a 32bit RGB, I'll have to see what difference it'll make doing it as 3 byte reads..and also how fast it'll work on a real miggy.


Edit:
  Didn't really see any improvement switching to 3x Move.b (ax)+,dx . I just tested it out on my A4000 (040/40)and the same 600x600 ->132x132 resample only takes 0.75 secs..I was expecting something like at least 2-3 secs!
 The only problem now is the time it takes to load with datatypes, guess I'll have to spend an evening testing which ones are quickest... damn I need a life :-P