"Pure and Correct AA"

[bloodbob]

Humus, between the anti-aliasing filter and the demosaicking with bayer pattern CCDs things don't quite work out like that. The PSF is more like a gaussian with a flattened top than a box AFAIR.

Okay pretend it one of those special CCD with the red,green,blue element stacked on top of each other.

 

[arjan de lumens]

I've got my fingers crossed some brave person will implement a 16x16 sinc in linear space to see how good it can work. But that's a bit OT...

Actually, I'd think that it would be perfectly on-topic:

 

[Bludd]

Actually, I'd think that it would be perfectly on-topic: Image

Is that from Joint Strike Fighter by Innerloop Studios?

 

[arjan de lumens]

Is that from Joint Strike Fighter by Innerloop Studios?

Dunno; I just took the image that Davros posted on the first page of this thread.

 

[Xmas]

With square pixels blending according to coverage of the corresponding square is correct IMHO. That's what you'll get if you take a picture with a camera (if we ignore scattering in the lens and other undesirable artifacts), the integral value of the incoming light behind that pixel (of course CCDs suffer from less than 100% coverage like pixels on a screen too though).

As I already said, it is correct coverage, but it doesn't give you perfect antialiasing. In fact, a box filter is pretty poor at avoiding aliasing.

I strongly disagree. Why do you think ATI introduced gamma-correct AA?

Because the framebuffer contains sRGB colors, not lRGB nor monitor color space. That's not an assumption, it's a definition (for Windows at least).

And linearly blending sRGB colors is wrong. But it has been done in the past because sRGB <-> lRGB conversion is expensive. IIRC R300 introduced sRGB downsampling and sRGB conversion after texture filtering. The latest DX10 hardware will finally do the conversion in all the proper places: before texture filtering, and for every read and write access to the framebuffer (alpha blending, AA resolve), if it is flagged as sRGB.

This is independent of the display hardware. Gamma correction in the pixel output pipeline is used (or rather: should be used, but most people never adjust it properly) to convert the sRGB colors from the framebuffer to the proper colors on screen. And that is the only place where you need to consider the monitor response curve.

Aliasing in computer graphics is a side effect of flexible programmability and developers are partly to blame? I'm sorry but can you repeat that or clarify?

We're obviously talking about "shader aliasing" here, not edge or texture aliasing. The latter two are pretty well covered (by fixed function units) in hardware, and even alpha test can be "fixed" now with transparency AA and alpha to coverage.

With flexible shaders it's much easier to get high frequency content that causes aliasing than with simple fixed function multitexturing. It's the responsibility of the shader writer to avoid that, IHVs simply can't do it. They can only provide the tools necessary (gradients, multisample aware shaders).

 

[Jawed]

Actually, I'd think that it would be perfectly on-topic:

Nice effort.

I see two problems:

1. the ringing - oh my eyes
2. the 1 pixel down and 1 pixel right offset - implies to me that the 4:1 reduction you performed was somehow offset from the resulting-pixel's centre

Jawed

 

[arjan de lumens]

Nice effort.

I see two problems:

1. the ringing - oh my eyes
2. the 1 pixel down and 1 pixel right offset - implies to me that the 4:1 reduction you performed was somehow offset from the resulting-pixel's centre

Jawed

That ringing is the main reason why a large-window sinc-filter is not usually accepted as the final, best-possible-looking solution to 3d graphics antialiasing.

The offset is actually 1/2 pixel down & right; I aligned the 16x16 sinc filter to pixel boundaries, which means that the filter is centered on a location 1/2 pixel away from the nearest actual pixel center.

 

[Jawed]

The offset is actually 1/2 pixel down & right; I aligned the 16x16 sinc filter to pixel boundaries, which means that the filter is centered on a location 1/2 pixel away from the nearest actual pixel center.

Hmm, but there shouldn't be any offset in the resulting image if your sinc is sampling equally in all directions around the destination pixel.

If I take the original image, and its duplicate:

1. then rotate the duplicate 180 degrees
2. size original and duplicate to 25%
3. rotate duplicate 180 degrees

there's no offset between them.

Additionally, your sinc seems to be asymmetric because the top and left 1-pixel "borders" are "dark" whilst the bottom and right borders are "light". So it seems to me that you've got some residual asymmetry in your sinc.

Jawed

 

[Jawed]

I found this page which is extremely useful as it provides a comprehensive comparison of filtering techniques:

http://www.xs4all.nl/~bvdwolf/main/foto/down_sample/down_sample.htm

It also provides a high-resolution test image with varying spatial frequencies which is useful for anyone who's playing with down-sampling.

Please note that the reference image must be used carefully. The reasons why are described on the page. Basically an indexed-colour image (i.e. GIF) cannot be re-sampled. You must first convert to RGB colour.

Jawed

 

[Nick]

Once again, when it comes to pure anti-aliasing, a sinc filter is theoretically the best solution. Like the IHV AA expert said: not opinion, just math and science.

It's the best reconstruction filter for a point sampled continuous frequency-limited signal (Nyquist rate). In fact it reconstructs the original signal perfectly under these conditions. If the continuous signal was not point sampled or contains frequencies higher than half the sampling frequency, sinc won't help reconstructing the original signal (but causes aliasing instead).

Furthermore, even if the signal can be perfectly reconstructed, it is again point sampled before displaying it on screen, which isn't optimal either.

Instead of point sampling you can also integrate regions (convolution with a box instead of dirac). A perfect camera would do this per pixel, which is what I believe Humus referred to. If the signal is frequency-limited I'm sure a perfect reconstruction filter exists, but I doubt it's sinc. And all we really need is a filter that gives us perfect re-sampling, which might be as simple as reconstructing with a box filter and integrating again.

All I'm trying to say is that sinc has some nice mathematical properties under several conditions, but it shouldn't be regarded as the filter to use in all situations (even if it was practical). "Just math and science" is the way to go, but sinc isn't the final answer.

Edit: I forgot to add that for sync to be the best filter the signal also has to be infinite...

 

[arjan de lumens]

I found this page which is extremely useful as it provides a comprehensive comparison of filtering techniques:

http://www.xs4all.nl/~bvdwolf/main/foto/down_sample/down_sample.htm

It also provides a high-resolution test image with varying spatial frequencies which is useful for anyone who's playing with down-sampling.

Please note that the reference image must be used carefully. The reasons why are described on the page. Basically an indexed-colour image (i.e. GIF) cannot be re-sampled. You must first convert to RGB colour.

Jawed

I get the impression that, as far as image antialiasing is concerned, that particular test image focuses too much on pure frequency content as opposed to spatial extent of frequency features. I have now fixed my 16x16-linear-sinc filter so that the 1/2-pixel offset is no longer present - this gives the following result with the downloadable test image on that page:

The plane image with the exact same filter gives:

 

[stepz]

Just in case anyone will find this comparison interesting, here are some of the filters of ImageMagic for the plane image:

Sinc

Lanczos

Box

Cubic, support 0.5

Cubic
Others:
Bessel, Blackman, Catrom,Gaussian,Hamming,Hanning, Hermite, Mitchell, Point, Quadratic, Triangle

PS: if anyone is willing to host it, I can whip up a script generating a comparison page for all of the filters with different support sizes.

 

[Jawed]

Woah! Nice. I'd just downloaded IM and was tripping up over it not being pathed for some reason, so you've saved me a lotta bother.

OK, so what's going on, the IM sinc isn't ringing like Arjan's implementation.

This page for the API:

http://www.imagemagick.org/api/resize.php

says that a Blackman filter is used to window the input image before applying the sinc. Hmm...

Jawed

 

[Jawed]

From this page:

http://www.imagemagick.org/Usage/resize/#filter

you can see that Blackman is "close" to a box filter. So this pre-filtering would appear to explain the lack of ringing in the sinc resampled image.

Jawed

 

[Jawed]

Arjan, looking at your sinc on the van der Wolf reference image I notice that the "mid grey" (purely blurred fine-detail) is too bright. It should (shouldn't it ) come out as R=G=B=127/128, but it's coming out as 161 (in gamma 2.2 space).

I hit a similar problem when I was playing with this image in Photoshop, having converted it to 16-bit linear space and resizing it. If I work in 8-bit gamma 2.2 space, the blurred area comes out as 127-128. I'm bemused as to what's happening here...

I have to admit I'm suspicious now if ImageMagick is actually working in linear space, but confused why linear space manipulations of this image (by Arjan and me) are seemingly producing the over-bright blur.

The reference image has an average of 127.81 in gamma 2.2 space...

Jawed

 

[Davros]

Is that from Joint Strike Fighter by Innerloop Studios?

No its Modern Air combat by Eagle Dynamics
http://www.lo-mac.com/

 

[arjan de lumens]

Arjan, looking at your sinc on the van der Wolf reference image I notice that the "mid grey" (purely blurred fine-detail) is too bright. It should (shouldn't it ) come out as R=G=B=127/128, but it's coming out as 161 (in gamma 2.2 space).

My filtering routine interprets the input image as standardized sRGB, converts it to linear-RGB, performs the 16x16-sinc downsampling in linear-RGB space and then converts the resulting image back to sRGB.

The input image, if interpreted as linear-RGB, has an average brightness of about 50%, however interpreting it as sRGB and converting it to linear-RGB results in a somewhat lower average brightness - about 36% or so. The filtering process then turns this average color into the actual color of the solid-gray region; the value of ~161 in 8-bit sRGB space corresponds to about 36% intensity in linear color space.

50% brightness linear-RGB, corresponding to a value of about 183 in 8-bit sRGB space, looks subjectively much brighter than the ring pattern if I try to draw such a solid color onto the pattern, whereas an sRGB value of 160 comes much closer.

 

[Jawed]

50% brightness linear-RGB, corresponding to a value of about 183 in 8-bit sRGB space, looks subjectively much brighter than the ring pattern if I try to draw such a solid color onto the pattern, whereas an sRGB value of 160 comes much closer.

Ah yes, I was forgetting about the mid-luminance in sRGB, argh thanks for going through it.

The reference image has an average of 91.45 in gamma 1 space and if I size it down to 1 pixel, it ends up as 91, or 162 in sRGB.

Hmm, so ImageMagick isn't working in linear space, which is rather disappointing.

I'm also wondering, now, if these "black+white" reference images have been constructed properly, they should be averaging to 183 in sRGB space, shouldn't they (if they're to act as "perceptual" measures of quality)? Argh.

Jawed

 

[arjan de lumens]

I'm also wondering, now, if these "black+white" reference images have been constructed properly, they should be averaging to 183 in sRGB space, shouldn't they (if they're to act as "perceptual" measures of quality)? Argh.

Given the way the de Wolf image is constructed, it is constructed "properly" for use as an input to linear-RGB calculations/devices, however it is not constructed properly for display in an sRGB-like color space (like the ones that most monitors actually display). Fascinatingly, on my monitor (an Apple LCD), the image even shows very noticeable aliasing (concentric rings in the corners) that disappear when I apply a 2.2 gamma to it.

 

[Jawed]

shame the target is "off" like this.

I've learnt a few useful things today, anyway, which if nothing else will help me when I'm trying to avoid some resizing nasties in my photos.

---

LOL at this thread:

http://forum.doom9.org/archive/index.php/t-112594.html

Still none the wiser for the best way of generating a good-enough reference image by resizing, though...

I'm beginning to think the error introduced by not using linear space is bigger than the error between linear space versions of bicubic, blackman-sinc and lanczos.

Hey, perhaps taking an average of all three would work?... (Off to reboot my PC, generating a single 1.8GB image in PS seems to have fatally wounded XP...)

Jawed