Re: Image scaling

[Eric McDonald <mcdonald@phy.cmich.edu>]

mskala@ansuz.sooke.bc.ca wrote:
> 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.

Sure thing. I would prefer, however, to integrate any image-scaling or 
other low-level image-handling fixes directly into the mainline, as they 
become available. Once you are to the point of implementing your map 
terrain ideas, I will be quite willing to make a branch in CVS. Of 
course, if you feel you need the branch sooner (uncertain fixes, 
etc...), that is fine too.

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

Completely agreed.

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

I've seen both of the problems you describe. If you can fix them, (a) 
that would be really great, and (b) I would prefer to merge them into 
the mainline sooner rather than later.

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

Welcome to the Xconq sources! :-)
I've seen variations on that "slogan" in a few places myself.

> 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 share your sentiments here. I know there are several aspects to this 
problem, but one of the aspects, image files, could be dealt with fairly 
easily, I think.

We already require 'libpng' to build ParaGUI. If we made it a general 
dep for Xconq, I don't think it would be a big problem. It is pretty 
much ubiquitous in the Linux world, and I have already shown that it can 
be easily acquired and integrated into MinGW32 on Windows. And, with a 
little script, I could pass ImageMagick's 'convert' command over the 
entire 'images' directory, and all the GIF files could be converted to 
PNG. And, finally, some careful use of a script and 'sed' could batch 
change all of the ".gif" endings in the .imf files to ".png" endings; I 
suppose a Perl person could do it more efficiently than me, but it is 
not a difficult task in any case.

The only other thing that would need to be done, would be to set up the 
"imfhook" or whatever the image family loader function is called, to 
suck all the goodies out of the loaded PNG struct and image array 
(presumably decompressed by a library call). But, I suppose this last 
point leads to another aspect of the problem: internal color handling....

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

Seems reasonable.

Eric