Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The article doesn't mention the void and cluster[0][1] ordered dithering (and modernized variants) which have the advantage of ordered dithering that they are highly parallelization, e.g. via GPU shaders but do not leave the easily spottable patterns of ordered dithering.

For example the madVR[2] video renderer uses it for realtime video dithering to avoid banding shallow color gradients from 10bit sources or debanded internal 16bit representation on <= 8bit displays.

[0] http://cv.ulichney.com/papers/1993-void-cluster.pdf [1] http://www.hpl.hp.com/research/isl/halftoning/publications/1... [2] http://madvr.com/



I find it amusing that someone would have a dedicated GPU, yet cannot fully render color images. I mean, I'm sure there's actually plenty of use-cases, but it's still funny.


"Fully render" is a strange way of putting it - most consumer hardware has only 8-bit colour depth, and lots of video compression algorithms will turn smooth gradients into blocky messes that would benefit from dithering.

If you're processing the decode at 10 or 16 bits and need to render at 8 bits, it's much better to dither than truncate.


> and lots of video compression algorithms will turn smooth gradients into blocky messes that would benefit from dithering.

More accurately: Either you have a 10bit-per-channel video (or better) which has smooth gradients which will need dithering when rendering to an 8bit-per-channel display.

Or you have 8bit video (more common) which will have to be passed through a debanding filter first. But then how do you get the debanded result onto the screen without reintroducing the banding? By dithering it.


Fair enough. I don't think I've ever actually programmed a GPU with the purpose of making images, so my terminology might not be the most precise.


One technique I've experimented with is iteratively diffusing errors not just towards un-visited neighbors below and to the right, but also into the future. We are all interested in the future, for that is where you and I are going to spend the rest of our lives. [1]

It works nicely with video, and it makes still images (and images you're slowly panning and zooming with the Ken Burns effect [2]) look alive and detailed, as if they were live video.

Another variation of the serpentine scanning (aka boustrophedon transform [3]) you can apply when iteratively dithering an image is to rotate the scan direction 90 degrees each frame, so even frames scan horizontally, odd frames scan vertically, and the vertical and horizontal scan directions rotate round every four frames. That results in a completely uniform diffusion, even when each scan frame only diffuses errors to the next cell.

It spreads the error out over time, as well as space, which has a pleasing effect on the eyes, I think. Any one frame has artifacts, but they tend to cancel each other out over time, break up the log jams, and dance around local minima and without getting stuck at fixed points.

I've implemented some 8 bit anisotropic heat diffusion cellular automata, that exhibited a subtle drift because of the scan order. But rotating the scan order 90 degrees each frame completely eliminated the subtle drifting effect I was getting when using a fixed scan order. Here's a discussion about it I had with Rudy Rucker [4] who inspired some of the rules and pointed out the problem, and a demo [5], and source [6].

Here's one of my favorite spooky Heizenbugs:

>The original version of this code written in C running on a Sun did have an interesting bug: I was not initializing the "error" accumulator that carried the leftover of the average from cell to cell, so when different kinds of background activities were happening on the Sun, the error accumulator got initialized from the stack frame with a random undefined value! I noticed it when every time I typed to a terminal window, the dithering shivered! It was really spooky until I figured out what was going on!

[1] https://www.youtube.com/watch?v=jb6H14gVWjM

[2] https://en.wikipedia.org/wiki/Ken_Burns_effect

[3] https://en.wikipedia.org/wiki/Boustrophedon_transform

[4] http://donhopkins.com/mediawiki/index.php/CAM6_Simulator

[5] https://github.com/SimHacker/CAM6/blob/master/javascript/CAM...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: