Correcting for Chromatic Aberration

Because the true pixel lies somewhere between four adjacent neighbor pixels, it should be a sum of those neighbors. For increased accuracy, you need to take subpixel offset into account for the different color channels. The IPS panel used in the RiftDK actually has FOUR subpixel positions RGBS (where S = Screendoor subpixel). The Pixels are square, with each pixel the same width and height (including a quarter-pixel vertical "screendoor" subpixel).

By using correct subpixel interpolation, you should be able to compensate for CA (Chromatic Aberration) quite well. Remember that (from a software point of view) pixels do not need to start on a RED pixel (i.e. RBGS). A white pixel can also be represented as GBSR or BSRG. Both text and vector art look much better if all vertical lines are at least TWO pixels wide. Even the common IBM BIOS bitmap character set follows that rule.

What is extremely convenient for subpixel processing is that a 32-bit per pixel framebuffer can be represented as a byte array, where each byte represents a subpixel (and the alpha channel represents the black Screendoor subpixel). I do that in my framebuffer processing, and it is simple and fast.

Most popular lens distortion correction software uses a subset of "Brown's model", but usually neglects the tangential distortion correction. Brown himself called such popular (but over-simplified) software "degenerate".

instead of applying entirely different functions to each channel, couldnt you just use one function for all channels, and at the end apply a simple factor for each channel? is it correct that the CA error is a linear function of distance from the lens centre? if not I can understand the need for 3 different equations. but it would preferable to use 3 factors because then its easy to manually fine tune it with your eye.

i also have a question on sub pixel sampling. did you mean to say the shape of the sub pixels are square? or is the whole pixel square? if the latter is the case does that mean each R is a rectangle, 4 units high, 1 unit across? is there also a horizontal S sub pixel? if so that would make each R 3 units high and 1 unit across. just need clarification thanks.

which of the below makes 1 pixel? (assuming each letter is same size unit)

RGBS
RGBS
RGBS
RGBS

or

RGBS
RGBS
RGBS
SSSS

or

RGBS

or

RGBS
SSSS

edit: judging by this post http://www.mtbs3d.com/phpbb/viewtopic.php?f=140&t=15592#p85456 it is:

RGBS
RGBS
RGBS
SSSS

also, as far as downsampling, you have recommended box filter (averaged). I did some testing with box filter and it looks really nice. But there is the possibility of cubic filtering on fast cards. This is even higher quality. http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter20.html

"lukepoga" wrote:
instead of applying entirely different functions to each channel, couldnt you just use one function for all channels, and at the end apply a simple factor for each channel? ...

No. Lens distortion correction uses a non-linear polynomial, and the difference between the color channel offsets is not a simple factor.

"lukepoga" wrote:
... is it correct that the CA error is a linear function of distance from the lens centre? ...

No. Most of the error is the difference in the K2 coefficient used in the "Brown's model" lens distortion correction formula, which is multiplied by the 4th-power of the radial distance from the lens center (optical axis). The differences in radius are (4th-power) exponential as the radius increases.

"lukepoga" wrote:
... i also have a question on sub pixel sampling. did you mean to say the shape of the sub pixels are square? or is the whole pixel square? if the latter is the case does that mean each R is a rectangle, 4 units high, 1 unit across? is there also a horizontal S sub pixel? if so that would make each R 3 units high and 1 unit across. just need clarification thanks.

which of the below makes 1 pixel? (assuming each letter is same size unit)
...

RGBS
RGBS
RGBS
SSSS

The pixels are square. The three visible subpixels within them are rectangular, and three times as tall as they are wide. There is a (virtual) "screendoor" pixel that is about the same width as a color subpixel, between each column of pixels.

It is convenient in software to think of the 'A' in an ARGB bitmap pixel as being the "screendoor" pixel, especially when treating a bitmap framebuffer as four interleaved 8-bit images. For "low-endian" hardware, the bitmap byte order is (B,G,R,S, B,G,R,S, ...). In your subpixel layout quoted above, that is what it LOOKS like when the RiftDK LCD is viewed under high magnification, but the extra rows of subpixels (and the "screendoor" pixel row) are not stored in memory.

EDIT: Correction to above: I see from a macrophoto of the actual Rift screen that the RGB subpixels are 1/3 pixel wide with NO border between pixels. That visible border is an illusion, because our eyes are less sensitive to blue and it appears quite dark (part of the screendoor effect) when viewing a white background. If you view a color that has equal luminance for each of Red, Green and Blue (a dark purplish color), there are no apparent vertical lines in the "screendoor". I was mistaken partly because of the diagram on a whiteboard behind Palmer Luckey in a photo taken at the OculusVR offices, and reinforced by the illusion caused by the much darker blue component in most scenes viewed in the Rift.

The latest SDK does an excellent job of correcting for Chromatic Aberration. I tested it by holding the Rift loosely against my face so I could look a little sideways throught the lenses to see the inner divider. Then I move in the latest Tuscany demo outside, with a white window shutter vertical edge right next to that black border. Although the display border clearly had very noticeable Chromatic aberration, the window shutter next to it had a nicely colored edge with no discernable Chromatic Aberration.

Job well done, Oculus team!
:D

Yes, the v0.2.1 SDK does a great job of correcting for chromatic aberration compared to the v0.1.5 SDK which did no correction :)

"geekmaster" wrote:
The latest SDK does an excellent job of correcting for Chromatic Aberration. I tested it by holding the Rift loosely against my face so I could look a little sideways throught the lenses to see the inner divider. Then I move in the latest Tuscany demo outside, with a white window shutter vertical edge right next to that black border. Although the display border clearly had very noticeable Chromatic aberration, the window shutter next to it had a nicely colored edge with no discernable Chromatic Aberration.

Job well done, Oculus team!
:D

hmm.. launched tuscany demo and still see aberrations. what am i do wrong or how can i apply changes from v0.2.5 SDK?