[Trac #1017] swizzle and other DCON-related display problems

[Zarro Boogs per Child]

#1017: swizzle and other DCON-related display problems
---------------------------+------------------------------------------------
 Reporter:  AlbertCahalan  |        Owner:  blizzard 
     Type:  defect         |       Status:  new      
 Priority:  normal         |    Milestone:  Untriaged
Component:  distro         |   Resolution:           
 Keywords:                 |  
---------------------------+------------------------------------------------
Comment (by AlbertCahalan):

 Replying to [comment:1 vmb]:
 > Replying to [ticket:1017 AlbertCahalan]:
 > > On a test pattern, I'm seeing aliasing errors which indicate that the
 RGB weight in the swizzle is not correct and which suggest that the
 swizzle is not operating on linear data.

 Here you go:

 http://wiki.laptop.org/go/Image:Zone_plate_boys.png

 Regarding the filter itself: The colored circles in the zone plate area
 are obviously bad. The bi-level noise patch shouldn't be showing any
 color. The bottom row of bi-level pattern patches should not be showing
 any color. The 3x2 group of patterned yellow and green color patches
 shouldn't be showing odd colors.

 Regarding the filter operating on wrong-gamma data: There are numerous
 extra aliasing circles in the zone plate area. The top row of bi-level
 pattern patches does not appear equally bright as the grey square to the
 left of them.

 > > First, the sRGB values need to become linear via a lookup table. If
 YCrCr were supported in the framebuffer (nice idea, just set the high bit)
 then that would get converted too.

 I forgot: this would be a good place to add temporal anti-aliasing against
 the quantization to 6:6:6, especially when the frame buffer is set to
 8:8:8. Each table lookup could provide a mask for a pseudo-random number
 generator, allowing gamma to be properly respected. (actually a pair of
 masks, equivalent to multiplication by a floating-point value with 1
 fraction bit)

 > As the person who originally designed the hardware filter kernel (which
 is 3x3, and in order to avoid having full multipliers in the ASIC needs to
 have all weights be fractional powers of 2), I'd be interested in seeing
 some of the images that give you aliasing problems.

 Multiplication is just adding weights that are fractional powers of 2. For
 a 3x3 filter labeled "a" through "i" in normal English reading order, this
 is better:

 (a + 2*b + 2*d + 2*e + 4*e + 2*f + 2*h + i)/16

 As you can see, the "e" term appears twice. The degree to which you can do
 this will greatly affect quality. I stuck with 3x3 and only increased the
 divider to 16, but higher is much better.

 I just tested the above in a screen simulator, with both broken and fixed
 gamma. It's better no matter what the gamma.

 On a real B2 OLPC XO, the test pattern looks far better if I tell my image
 viewer that the screen gamma is 1.0 rather than the standard sRGB gamma.
 I'm fairly sure this indicates that the filter is operating on raw pixel
 data, which would normally be in the sRGB color space. This is not a
 legitimate operation; the data must be linear. If the LCD itself is not
 linear, then you need a separate gamma lookup table for that.

 Got a diagram of the pipeline anywhere? It could go on the wiki. ASIC code
 would be useful too.

 Note: image link is above

-- 
Ticket URL: <http://dev.laptop.org/ticket/1017#comment:2>
One Laptop Per Child <http://laptop.org/>