Battlezone Forums

I stumbled upon an interesting upscaling algorithm. This one is like HQx but much better for scaling art that contains antialiased lines and doesnt seem to produce as much jagged edges. Compare:

Original Image


HQX Scaling (Left) / XBR Scaling (Right)



The XBR upscaler is a part of a Paint.NET plugin, part of an upscaler program, as well as available for some SNES emulators.

The Paint.NET plugin is a DLL file that is to be copied to C:\Program Files\Paint.NET\Effects and can be found here:
http://code.google.com/p/2dimagefilter/downloads/list

The imageresizer program in that download site can also be used to upscale an image without having to open paint.NET. It would be nice if there was some way to do this as well as a batch operation.

XnView has a tool that allows all sorts of edits in batches from a script or direct input, perhaps this can be used in it as well (probably not though ..).
I once used it to digitalize all incoming invoices for a company, who's scanners had very limited abilities. Pretty neat bit of freeware (only for personal use!) software
http://www.xnview.com/

And when I check the link I notice this:
http://www.xnconvert.com/

Looks extremely useful.
However, the essential problem remains, that many of the original skins contain what you might call "implicated detail" that no doubt actually existed in the original artwork (sadly unavailable) It is the upscaling of this non-detail that often makes upscaled skins actually look worse than the original 256x256 skins, an implied detail becomes an obviously ugly blob when viewed up close.
The difficult bit is carefully working the blob back into the detail that the original only implied was there and then adding a subtle pixel level "material" type texture detail over that.
No clever programming is going to be able to recognise what that blob was intended to be and make it right, the most obvious example of this is the lettering/insignia on ISDf vehicles, I searched in vain for a an IDSf font to make the job easier, so not only do they need to be redone "by hand" but you also have to guess at what they were actually supposed to be spelling out on some of the vehicles.

This impresses me. Source code too? Nice. DLL? Even better considering upgrades.

This should work well in most cases and in only a few require human touch-ups.

Alright, some experiences doing some resizing.

Paint.NET plugin is better than the standalone resizer. Why? Paint.net can handle transparencies rather well.

So my further experiences with XBR. It's pretty smooth, the lines are smooth but it likes to round corners and angles quite a bit which may make it unsuitable for things that contain lines which consist primarily of hard 45 or 90 degree turns.

Keep in mind that running a x4 resize will baloon the filesize of your output dxtbz2 a whopping 16 times over the original whereas resizing any image by x2 will increase its size only by a factor of 4. Consider whether your texture details will be worth the massive filesize of a x4 resize.

== IMAGE SCALING AND SHELL BACKGROUNDS ==

One downside to the dxtbz2 format is that DXT is a lossy format and if you look closely the quality of custom shell backgrounds you may notice a some 4x4 pixel blocks that look a lot like JPEG block artifacts. DXT achieves good compression rates by dividing an image into a bunch of 4x4 (16 pixel) chunks, then paletting each chunk down to 4 distinct colors.

Therefore you would do well to see if the conversion to DXTBZ2 format introduces any artifacts or loss of color fidelity. In the case of things like custom buttons and interface elements, rescaling these can be beneficial if you want to reduce visual artifacts and maintain sharpness when the shell is autoscaled

If you simply want to maintain perfect color reproduction then you would want to upscale your source image by 2x lengthwise by 2x heightwise; this leads to increasing your DXT's filesize by 4x however it allows you to have more accurate color reproduction and reduces artifacting (use nearest neighbor, if you want 100% accurate color reproduction and zero artifacting but have some pixilation visible, use a 'sharp' upscaling method like XBR or maybe HQX if you want to reduce the appearance of pixilation, at the cost of a small amount of artifacting).

Some comparison shots:

XBR (2x resolution, then autoscaled by shell) its good if you don't mind smoothly rounded edges


HQX (2x resolution, then autoscaled by shell) some edges were cleaned up manually in paint.NET


Source to DXT Autoscaled (autoscaled by shell)


Source to DXT Autoscaled :: Close Up dxtbz2 compression artifacts are more visible when you pay attention


Actual Source Image (not autoscaled by the shell) Clean edges but low resolution

ADDENDUM
Proper upscales should get around artifacts introduced by DXT compression.

Since DXT compression is a requirement, the trick is to keep an eye out to make sure that DXT compression is not harming your image quality, particularly gradients and angled edges. Observe:

Without DXT compression:
http://zeroangel.overminddl1.com/misc_i ... loseup.png

With DXT compression:
http://zeroangel.overminddl1.com/misc_i ... loseup.png

DXT compresses every 4 pixels into 1. So, double your texture size to counter DXT lossyness.

Well, if you use nearest neighbor resizing you'll have no compression artifacts but poor texture smoothing since the smoothing blends from pixel to pixel. I would personally go for a 2x resize with XBR since it would keep angled edges fairly sharp looking without jaggedness and while the DXT artifacts would be present, they would be reduced by at least 1/2

For some reason DXT compression really kills the fidelity of Hadean textures. I'm guessing that it has to do with their mediocre resolution and maybe their color scheme just doesnt really take well to DXT. I need to add this to my list of things to do (resize the textures to 512x512).

I've found a slightly improved implementation of xBR called xBRZ

http://www.vogons.org/viewtopic.php?f=4 ... 25#p287379

This should get around my problem textures with a lot of angular elements having their angles rounded a bit too much when they are upscaled as well as it fixes some small artifacts with normal xBR.

Anyways, see the opening post in that topic for the ScalerTest application which can save files

BZ2's textures are pretty small by modern standards so texture compression doesn't provide much benefit. DXTC reduces textures by a factor of 4 but uncompressed 16-bit textures should fit into video memory of even older graphics cards. That's my opinion, at least.

If I had to choose, I'd leave user interface and effects textures uncompressed. (Shell background images would be okay compressed since they aren't as important and they're generally a lot larger.)

The Scaler Test thingy puts a big square of XBRZ on the top center of the output image. Is there a version that doesn't?

General BlackDragon wrote:The Scaler Test thingy puts a big square of XBRZ on the top center of the output image. Is there a version that doesn't?

In the version I have, there's an option to disable the XBRZ logo.