Quote:
Originally Posted by geekmaster
Thanks for the link, and it may indeed help people to understand dithering in a more visual manner.
But we are working with eink here, where an anchored dither has positive perceptual significance in how it interacts with the eink display hardware and device drivers, hence my choice of dither method.
EDIT: Ordered dither is also known as "Bayer dither", as it is called in the linked page above (which also shows that it provides best compression, due to fewer pixels changing between sequential video frames, besides being more "eink compatible" due to less "pulsating" temporal artifacts).
|
The linked page is about dither algorithm developed for use for video / gif animation / ui animations on eink devices; GIF animations shares similar constraints with dithering for eink - which is why the page focuses on that for its illustrations. My kobo mini easily runs such dithered full screen updates at ~10fps, using double buffering (with a full deph buffer backing the animation).
All the GIFs on that page; apart from the rightmost which is using error-diffusion are using ordered dithers. The "a dither" methods have a wider range of display'able colors, most of the code on the page is there to let people play around with the formulas; I expect coders to be able to lift the core of it out of the switch statement yielding something close to 6-7 instructions/pixel. (sadly though; on most archs; a LUT will still beat this procedural mask). For higher perceptual quality from an ordred dither; using "void and cluster" to generate the LUT would be among the best options; but that is computationally a _lot_ more complex than the simple pseudo-random patterns used in the methods summed up on my page.
/pippin