"Smart" texture filtering. Is this the future?

[marconelly!]

Take a look at this:

http://www.hiend3d.com/smartflt.html

The author offers a small executable file
http://www.hiend3d.com/bin/SmartFlt.zip
that shows his texture filtering method in realtime, compared to regular bilinear filtering, and old point sampling method. It looks really impressive, but I'm wondering if anisotropic filtering is making this obsolete before it had a chance to live?\

The same guy has a host of other, truly impressive image upscaling utilities:

 

[MfA]

He means this to be used for magnification ... so it doesnt really compete with anisotropic filtering.

 

[marconelly!]

Ah, I see.

I've just tested his magnification utilities on several photographic and illustration pictures, with limited results. Sometimes it would look better than plain bicubic interpolation in Photoshop, and sometimes it would look same or worse. I don't know if the same would apply to this texturing method he devised, but I think it might have limited use depending on the type of textures used.

 

[arjan de lumens]

Reminds me of the SuperEagle or 2xSal (or whatever their names were) framebuffer scaling methods available in the Snes9x super nintendo emulator, except that this one requires ~8 bits of extra per-texel information in addition to the color value; and its usefulness seems limited to drawn pictures/non-photorealistic rendering.

 

[malcolm]

Does anyone know what is planned to come next? Or are they planning to just keep using normal anisotropic filtering?

 

[MaxSt]

Reminds me of the SuperEagle or 2xSal (or whatever their names were) framebuffer scaling methods available in the Snes9x super nintendo emulator

hq2x/hq3x/hq4x filters (portrait picture above) are implemented in ZSNES emulator.

I'd also recommend reading these topics:
This Filtering Worthwhile?
Magnification Filters

MaxSt.

 

[arjan de lumens]

Does anyone know what is planned to come next? Or are they planning to just keep using normal anisotropic filtering?

Next natural step up would be bicubic filtering; the appropriate Direct3D caps and OpenGL extensions have been around for many years, but no one has stepped up and actually implemented it in hardware, and given the relative lack of demand for what is really a rather expensive feature, don't expect it anytime soon. (Technically, you can do bicubic in pixel shaders today if you feel like it, but it will cut down your performance by a factor of about 20-40 compared to standard bilinear/aniso.)

 

[malcolm]

thx, i agree a 20-40times performance cut doesnt seem worth it
how much would it be if implemented in the hardware?
I dont know what bicubic is actualy, does anyone have a link for a good explanation?

 

[malcolm]

The people at microsoft should take a look at those magnification methods for longhorn, look at what theyre doing:
http://www.winsupersite.com/images/showcase/longhorn_winhec_08.png
Theyre using a bilinear filter for high dpi! im not sure if this is only on the icons or also on the text, the text on top of the window is bilinear filtered tough, it is light blue instead of white.
For the text they might ask some advice on the acrobat reader team
I realy hope they dont mess up high dpi at microsoft, how can they think this is ok...
I think in the future they should switch to a mathematical(resolution independent) image format instead of pixel based.

 

[Guden Oden]

The GUI for Irix (SGI's flavor of Unix) was fully vectorized and scaleable way back in the mid-90s, maybe even earlier. Also, Steve Jobs' weird NextStation OS used Display Postscript, which was vectorized and scaleable too. That means there's plenty of earlier examples of fully scaleable GUIs that managed sharp text and icons...

Remember that Longhorn is a work in progress. I'm sure M$ won't bi-linear filter bitmaps in the final version.

 

[malcolm]

Im not so sure about that actualy...
I think this is one of the people working on it saying this:
"We're using 3D hardware to apply a stretch and bilinear filter to the display," Hammil said. "There's a bit of work to map the mouse coordinates from the scaled coordinate system to unscaled coordinate system so it still works."

This is from the road to longhorn article on winsupersite.com

If it would be some early low quality way of doing it i dont think they would explain it like this, realy seems like theyre saying this is the way they want to do it.
It sounds like this person knows very litle about graphics to me, i have very litle confidence in microsoft releasing longhorn with high quality high dpi.
Also that last sentence doesnt sound like a professional talking, it sounds like theyre making a real mess of it.
Im sure there are hundreds of people here on beyond3d that can do it the right way.

 

[Guden Oden]

Well Malcolm, I'm equally sure MS is not entirely populated by idiots, so I'm convinced they'll get it right in the end no matter what your concerns may be, based on this one interview with one single person from the company.

Remember, Longhorn is being betatested already by manymany thousands of people and even safe mode in XP has moved past the 16 color VGA stage; resolutions are going up both on CRTs and LCDs and will continue to do so. In 2006 when Longhorn is out, 1600 LCD screens will likely be the NORM rather than exception.

Of course the OS will look good on hi-res displays, that goes without saying.

 

[Dave Baumann]

If you want a play:

http://www.beyond3d.com/articles/shadercomp/results/index.php?p=2#7

2D Scaling by pixel shaders!

 

[MaxSt]

If you want a play:

http://www.beyond3d.com/articles/shadercomp/results/index.php?p=2#7

2D Scaling by pixel shaders!

That's nice, but 2xSaI and Scale2x can't really compete with hq2x:

.

.

.

...........point sampling..............................scale2x...................................2xsai.........................................hq2x


MaxSt.

 

[marconelly!]

I've seen more elaborate tests though (with actual game screenshots) and in some instances Scale 2x and 3X actually looks better than HQ2X and 3X. Some types of curvy lines are very poorly processed by HQ2X, but otherwise it's really good.

 

[_phil_]

marc :
in your example of smartfilter ,do you always need to sacrifice alpha channel to provide data ?

 

[MaxSt]

... in some instances Scale 2x and 3X actually looks better than HQ2X and 3X.

No way!

Some types of curvy lines are very poorly processed by HQ2X

No way again! HQ filters are very good with curvy lines. Look:

point sampling

scale3x

hq3x

MaxSt.

 

[I.S.T.]

Um, all I see is a grey square for the hq3x pic.

 

[MaxSt]

marc :
in your example of smartfilter ,do you always need to sacrifice alpha channel to provide data ?

No, it's just an additional information, so it can be stored separately.
It's kinda like MIP information is stored separately.

MaxSt.

 

[marconelly!]

No way again! HQ filters are very good with curvy lines. Look:

OK, if you don't trust me, here's the proof from the latest ZSNES:

Scale 3x:

HQ3x

Look at the circles at the ground, HQ3x clearly fails there. Clouds look better in HQ but eggs look better in Scale. Neither is perfect, though.

I saw even better sample of wavy lines from SMB3 where HQ3x completely failed compared to just about every other upscaler, but the bandwidth run out on the site that guy was hosting it.