Live data from Hacker News

Ditherpunk: The article I wish I had about monochrome image dithering

surma.dev

131–140 of 203 posts

Re: Ditherpunk: The article I wish I had about monochrome image dithering

#131

I just finished making an online dithering tool, doodad.dev/dither-me-this if anyone wants to play around with dithering. I'll be re-jigging it based on some info from that article, and definitely adding 'blue noise' as an option. Thanks for sharing.

Wow! I just want to recommend the dither-me-this and find you already here :) Also, the pattern-generator(https://doodad.dev/pattern-generator) is really amazing, applause!

Re: Ditherpunk: The article I wish I had about monochrome image dithering

#132
post #81

> However, sRGB is not linear, meaning that (0.5,0.5,0.5) in sRGB is not the color a human sees when you mix 50% of (0,0,0) and (1,1,1). Instead, it’s the color you get when you pump half the power of full white through your Cathod-Ray Tube (CRT). While true, to avoid confusion, it might be better rephrased without bringing human color perception or even colors into the mix. sRGB uses non-linear (gamma) values, which…

I always feel we have way too many historical burdens (which were good compromises at the time) in (digital) image/video field. In no particular order (and some are overlapping), I can immediately think of gamma, RGB/YCbCr/whatever color models, different (and often limited) color spaces, (low-)color depth and dithering, chroma subsampling, PAL/NTSC, 1001/1000 in fps (think 29.97), interlaced, TV/PC range, different…

I don't think of colorspaces as "historical burdens". I don't like that CRT monitors are brought up every time sRGB is mentioned though. I know it has historical relevance, but it's not relevant anymore, and it's not needed to understand the difference between linear and non-linear colorspaces.

Re: Ditherpunk: The article I wish I had about monochrome image dithering

#133

This is such a well-written article: it describes the impetus, it is researched, it has great examples both as code and as output, and it piques interest. In the late 1990's I contracted with an embedded software company to optimize a dithering algorithm for 8-bit MCUs that was used in most laser printers & copiers, and this paper is a really good overview.

This guys' articles are wonderful. I was experimenting with compiling C to WASM[0] and Surma's was really helpful.

[0]: https://surma.dev/things/c-to-webassembly/index.html

Re: Ditherpunk: The article I wish I had about monochrome image dithering

#134

What about dithering for the smallest possible images? I'm talking in the 300 byte - 2kb range here. Does anyone have any suggestions for what to do to really get file size down?

pngquant is a FOSS tool designed for that.

https://pngquant.org/

Re: Ditherpunk: The article I wish I had about monochrome image dithering

#136

Earlier quoted context omitted.

GIMP has it: Colors > Tone Mapping > Retinex

Ah thanks, just tried it out and it indeed produces quite a different result using that filter (default settings) before dithering. Here's a side-by-side comparison using an image from the front page of nytimes.com (be sure to click to zoom in for the full effect): https://imgur.com/a/mrHl7FW Without it (left), a photo remains "accurate" in terms of brightness levels. But with it (right), it becomes far more high-con…

Black and white images need more contrast to be pleasing. I think that's most of the effect you see here.

Maybe you'd want to start with a decent black and white photograph to get a better comparison.

No matter what you do you probably also don't want to end up with large patches of solid white or black in your source image (unless it's the background). The hair already feels like drowning in black. But to take care of that you need to use photoshop and be careful with the gradient curves :)

Re: Ditherpunk: The article I wish I had about monochrome image dithering

#137

Earlier quoted context omitted.

I always feel we have way too many historical burdens (which were good compromises at the time) in (digital) image/video field. In no particular order (and some are overlapping), I can immediately think of gamma, RGB/YCbCr/whatever color models, different (and often limited) color spaces, (low-)color depth and dithering, chroma subsampling, PAL/NTSC, 1001/1000 in fps (think 29.97), interlaced, TV/PC range, different…

I don't think of colorspaces as "historical burdens". I don't like that CRT monitors are brought up every time sRGB is mentioned though. I know it has historical relevance, but it's not relevant anymore, and it's not needed to understand the difference between linear and non-linear colorspaces.

I misunderstood what you mean. Please ignore. On a side note, by colorspace I mainly meant that we can just stick with one with ultra-wide gamut. There are indeed other reasons to have different color spaces.

(Below is my original comment for transparency.)

-------------

Gamma isn't really about CRT; or I should say, they're two different things. The fact CRT has a somewhat physical "gamma" (light intensity varies nonlinearly with the voltage) is likely just a coincidence with the gamma we're talking here.

The reason gamma is used in sRGB is because human eyes are more sensitive to changes in darker area, i.e. if the light intensity changes linearly, it feels more "jumpy" in darker end (which causes perceptible bandings). This is especially an issue with lower color depth. To solve this, we invented gamma space to give darker end more bits/intensity intervals to smooth the perceptive brightness.

>it's not needed to understand the difference between linear and non-linear colorspaces

It absolutely should, since any gamma space would have problem with "averaging", as explained by the GP. Actually, it's so bad that almost all the image editing/representing tasks we have today are doing it wrong (resizing, blurring, mixing..).

This topic has been discussed extensively on Internet, so I'm not going to go into detail too much. A good start point is [1][2].

[1] https://www.youtube.com/watch?v=LKnqECcg6Gw [2] http://blog.johnnovak.net/2016/09/21/what-every-coder-should...

Re: Ditherpunk: The article I wish I had about monochrome image dithering

#138

This article is missing a crucial pre-processing step to dithering algorithms: apply a Retinex-like filter to enhance the local contrast before doing the dithering. This gives a dramatic improvement of the final result. In fact, by exploring the scale parameter of the pre-processing step, you find a continuous family of binarisations that interpolates between global tresholding and local dithering.

That's fascinating -- do you have any links to examples? I'm searching online but can't find anything at all. I've never heard of using Retinex in the context of dithering, and wondering what specifically you mean by Retinex-"like"? I'm also really curious what contexts this has been most successful in. E.g. was it used for dithering in images or games back in the 1990's when we were limited to 16-bit or 256-bit colo…

> I'm also really curious what contexts this has been most successful in. E.g. was it used for dithering in images or games back in the 1990's when we were limited to 16-bit or 256-bit color? Or is this something more recently explored in academia or in some niche imaging applications?

No need to speak in the past tense! It is not a "niche" application, either. Think about it: gray ink is almost never used. All printing into paper is done by dithering black ink into white paper. This includes bank notes, passports, product labels, etc. Besides dithering being used everywhere, it is a very active area of research, both in academia and in industry. In my lab we have seen a few industrial projects concerning dithering. It's a vast and very beautiful subject.

> do you have any links to examples?

Take a look here for a couple of examples: http://gabarro.org/ccn/linear_dithering.html

Re: Ditherpunk: The article I wish I had about monochrome image dithering

#139

Earlier quoted context omitted.

I always feel we have way too many historical burdens (which were good compromises at the time) in (digital) image/video field. In no particular order (and some are overlapping), I can immediately think of gamma, RGB/YCbCr/whatever color models, different (and often limited) color spaces, (low-)color depth and dithering, chroma subsampling, PAL/NTSC, 1001/1000 in fps (think 29.97), interlaced, TV/PC range, different…

I don't think of colorspaces as "historical burdens". I don't like that CRT monitors are brought up every time sRGB is mentioned though. I know it has historical relevance, but it's not relevant anymore, and it's not needed to understand the difference between linear and non-linear colorspaces.

I don't see why you would avoid talking about it.

As far as I've understood, CRT monitor gamma has basically evolved to become the inverse of human eye gamma :

http://poynton.ca/PDFs/Rehabilitation_of_gamma.pdf

(With some changes for a less accurate, but more visually pleasing/exciting replication of brightness levels ?)

Now, with many modern, digital screens (LCD, LED, e-ink?), as far as I've understood the electro-optical hardware response is actually linear, so the hardware actually has to do a non-linear conversion ?

I'm still somewhat confused about this, as I expected to have to do gamma correction when making a gradient recently, but in the end it looked like I didn't have to (or maybe it's because I didn't do it properly : didn't do it two-way?).

Note that the blog author might be confused there too, as just after he says :

> With these conversions in place, dithering produces (more) accurate results:

– you can clearly see that the new dithered gradient doesn't correspond to the undithered one ! (Both undithered gradients seem to be the same.)

Re: Ditherpunk: The article I wish I had about monochrome image dithering

#140
Great article!

Frustrated that Firefox doesn't support "image-rendering: pixelated". FF supports "crisp-edges" and happens to implement that as nearest-neighbor filtering but the spec says that is not the meaning of "crisp-edges".

I don't understand why Firefox is dragging their feet on this. It seems like such an easy thing to add. In fact given their current implementation they could just make `pixelated` a synonym for `crisp-edges` and ship it

Here's the 8yr old issue

https://bugzilla.mozilla.org/show_bug.cgi?id=856337

Post reply on HN