Image scaling

[mskala at ansuz dot sooke dot bc dot ca]

Okay, I had planned to go get a SourceForge account today, but that didn't
happen; it's likely to be Sunday or Monday before I do, but whenever I do
manage it, I'd like to go ahead with the making-a-CVS-branch idea.

I've been through the scaling code, and it seems to me that it'll need a
fair bit of rewriting just to get into a state where I can do things with
the map terrain ideas.  The basic idea is that you're supposed to be able
to specify one or more images of varying resolutions, and the system will
automatically choose the one that matches its requirements, or scale one
of the specified ones to match any needed resolution you didn't
specify.  The "cut an image into hexes and apply it to the terrain" idea
pretty much requires that this behaviour work correctly, because the image
can only be at one resolution - trying to coordinate several versions at
different resolutions would be a nightmare for the game designer and
really break the convenience that was supposed to be the point of the
exercise.

There are some problems with the existing code, though.  For one thing, it
can only ever scale an image by a factor of two up or down - so if it
needs two resolutions that are separated by a factor other than two,
there's trouble.  And in fact, the resolutions it does need are 1, 2, 4,
13 (!= 4*2), 26, 48 (!= 26*2), 96, 192 (so the code claims... I've never
seen a 192-pixel hex)... and so there's trouble.  If all you specify is
one image and it's bigger than 16 pixels, then the smallest sizes will
just appear as black, because the scaling cuts out when the result is
below 8 pixels.  And if you attempt to fix that by specifying a default
flat colour, then *no* scaling will be done at all, and the default flat
colour will be used for all unspecified sizes, which explains the annoying
behaviour I've seen of everything going to flat colour at the highest
magnification in some games.  There is also weirdness in the handling of
"subimages", so scaling probably doesn't work even now with border and
connection terrain (may explain some other misbehaviour I've seen), and it
certainly won't work for my contemplated hexgrid image patches.

The actual scaling algorithm used is somewhat weird, and there are
comments in the code suggesting that the previous implementor wasn't
satisfied with it but was treating it as "good enough for now".

I think the best way to deal with the scaling situation is to just remove
the existing scaling code altogether and replace it with a new scaler that
would be closer to really right, and would work by picking the closest
match (maybe some preference given to bigger images) among the
designer-specified images, and then scaling it to *exactly* the desired
size, not just the nearest power-of-two step up or down.

What kind of resampling algorithm to use is a tricky question because
we're pretty firmly limited to 8-bit colour; I would be happier if we
weren't, but don't want to do the (much larger amount of) coding to change
it.  I think the thing to do is use a mode filter, that is, let the colour
of each output pixel be the most commonly-occurring colour among the input
pixels that map onto that output pixel.  That seems to be what the person
who wrote the comments in the existing code thought was the right thing to
do, but left to later to implement.  I don't think I want to attempt the
*really* really right thing to do, which would be to convert to RGB, do a
Lanczos-filtered scaling, and then convert back to indexed colour -
probably better to leave that at least until such time as we're ready to
make the whole works RGB, because the lossage from the simpler algorithm
is less than the lossage from using indexed colour anyway.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/