View Single Post
Old 04-28-2012, 10:07 PM   #11
geekmaster
Всё гениальное просто.
geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.
 
geekmaster's Avatar
 
Posts: 5,070
Karma: 6789001
Join Date: Nov 2011
Location: Щедрость не имеет пределов.
Device: *.*
@kiri87: Regarding your images showing the kindle 3 comparison of color palettes between wb0 (raw color values), dithered 16-color, and dithered 2-color, I see a clear off-by-one error. In retrospect it is obvious that for "inverted color" devices I need to SUBTRACT the dither offset instead of adding it.

This happens because the "normal" method of 8-bit and higher graphics is 0=black and 255=white, and this is how the new mxcfb device driver for the Freescale iMX508 integrated eink controller behaves. But for the older einkfb device driver used in the K3 and earlier that use the external epson broadsheet eink controller chip, the einkfb device driver assumes that color value zero is white instead of black (inverted color). A complication is the K4. Because it comes with SSH factory-installed in diags, I was doing my initial testing in an UNMODIFIED K4 (factory partitions, and not registered). When booted from diags, the K4 uses the new mxcfb eink driver to get full speed and power from the integrated eink controller. BUT (and this is a HUGE) when booting the K4 from main (with cvm and desktop framework) it runs in K3 compatibility mode using the old einkfb device driver. Not only is this eink compatibility mode slower and a lot more limited, it also uses the old inverted color palette (even when using its 8-bit framebuffer).

When handling inverted color in my older code, I immediately inverted the color value (~color) and processed all pixels as black 0. But for this NEW demo, now that all my code uses ioctl() calls for all eink updates, I instead use the "inverted color update" for the inverted color devices.

Now that I had a chance to sleep on what I thought looked like an "off by one" error at the top/bottom palette transition in the cosmegg demo, and taking the above information into account, it is plain to see that the color inversion affects the dithering so that instead of ADDING one to the 16-color palette when the "unused" bottom bits are greater than the dither threshold (in order to make the color MORE WHITE), we need to SUBTRACT one to make the color MORE WHITE on an inverted color palette. The inversion is now done at the last possible moment by the eink device drivers using the "inverted color update".

So the dithers need to ADD only for the normal color dithers but need to SUBTRACT for the inverted color dithers. I may have already compensated for this in the 2-color dithering... I will compare the two methods and fix it.

Thanks for giving me this feedback that helps me examine this from new directions.

UPDATE: I see while inspecting this code that the "right thing to do" is not to make the code conditional on white zero or black zero (like for K4main and K4diags), but to use dither tables that contain positive or negative values. One thing I realized while writing this is that 256-color mode requires that the bottom half-byte become zero, but the previous content dithers the bottom bit of the top half-byte. Dithering 4-bits can be done with a smaller 4x4 dither table with values 0-15.


Last edited by geekmaster; 04-29-2012 at 12:02 PM.
geekmaster is offline   Reply With Quote