Quote:
Originally Posted by islewind
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
|
I can see that the pixels in the "a dither" are also anchored in place like the bayer dither, and the forumulas for computing them are effectively similar, differing by use "magic number" multiplication instead of bitwise shift and or. The magic number method may be faster on modern processors, and COULD be faster than a table lookup, depending on a number of factors (mostly RAM access penalty, cache layout, and algorithmic access ordering). Also, the linked page uses floating point instead of integer, which may also incur a speed penalty depending on CPU, and on choice of compiler and optimization settings. Of course for modern GPU shaders in a desktop graphics card, float may be better, but in lesser devices like the (ARM based) Raspberry Pi (and perhaps eink kindles), integer can be much faster, even in shaders.
In my case, I am supporting older kindles including the DX and DXG here, so relying on magic number multiplication and especially floating point may make it run slower. Of course, the only way to tell for sure is to code it both ways and MEASURE the speeds, in addition to examining the assembler language output from the compiler.
The Bayer dither has a lot of research behind it. Reordering the dither threshold elements may make some images (or video) look better, but may also have other image examples where it falls short.
A table lookup can be faster if it can all fit in CPU cache and remain resident, but that depends a lot on a number of other factors. A 64-byte 8x8 dither table is certainly small enough if it does not need to continuously keep getting reloaded (such as every time another byte is written to STDOUT with a function call).
But for the update rate that all eink kindle models support (about 7.7 FPS), the dither function optimization is not all that critical. I did it the way I did it mostly because I enjoyed doing it that way, which is all that really matters for recreational programming such as this. For others to choose one dither method over another makes no difference really, as long as they select one that does the job, and they enjoy doing it.