Welcome, Guest. Please login or register.

Author Topic: Image resizing.  (Read 2019 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline Karlos

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16879
  • Country: gb
  • Thanked: 5 times
    • Show all replies
Re: Image resizing.
« on: November 26, 2005, 08:06:15 PM »
Basically what you are looking for is a bininear resample. That in itself is fairly easy to code but as you have discovered, it is slow. If you need to convert to 12 bits also, you need an error diffusion method if you want to try and preserve the integrity of the image.

It will be quite slow if you use both.

Just for your own use, for 12 bits you might try the following (assuming you have pgs)

Load the 24 bit image into photogenics. Resize it and then save as HAM6 (with dithering). This will basically reduce the colour to 12 bit (ham caveats apply).

Reload and save the data in some sensible format.
int p; // A
 

Offline Karlos

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16879
  • Country: gb
  • Thanked: 5 times
    • Show all replies
Re: Image resizing.
« Reply #1 on: November 27, 2005, 12:29:02 AM »
Quote

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.
int p; // A