5 ms·

> Dithering a black-to-white gradient will be wrong without linearising first. TBH both look wrong to me. If I squint, neither dithering patterns match the ori

by kaoD 2y ago

> Dithering a black-to-white gradient will be wrong without linearising first. TBH both look wrong to me. If I squint, neither dithering patterns match the original gradient... but the non-linearized one looks the most similar. What could be causing this?

hagbard_c 2y ago
> What could be causing this? Hypercorrection, in this care over-linearisation.
badmintonbaseba 2y ago
Apart from implementing it incorrect, an uncalibrated display could also cause this. Check out http://www.lagom.nl/lcd-test/gamma_calibration.php http://www.lagom.nl/lcd-test/gamma_calibration.php with DPI scaling turned off, at 100% zoom level (how browsers scale images are also horrible, so you want to avoid that). edit: Reading back, viewing the gradients also not at 100% zoom level could also itself cause the mismatch, because browsers just suck at image scaling.
gus_massa 2y ago
Mac vs pc? They have a different default gamma and they may show a different gray level. (It bite me a long time ago. I made a gif that has the same RGB bacground than a webpage. In my pc it was fine, but in a mac they the border was very visible and the result horrible. My solution was to change the backgroung of the webpage from a RGB number to a 1 pixel gif with repetition or scale to fill the page.)
TinkersW 2y ago
I don't know where they got the idea you don't dither in srgb, the point of dithering is to map it to the nearest bit pattern with a random adjustment so that it could go either way(aside from artistic choice), you should dither in srgb if you are going to display it in srgb, which is probably why the "not linearized" version looks more accurate. See: Dithering should happen in sRGB https://www.shadertoy.com/view/NssBRX https://www.shadertoy.com/view/NssBRX
- robinsonb5 2y ago
  I'm far from convinced that shadertoy demonstration is correct: If you set the number of bits to 1, the dithered version is clearly far too light, which is exactly what happens if you dither in gamma-encoded space rather than linear space. It gets much worse if you uncomment the SHOW_CORRECT define since the data is then being transformed back to SRGB before being quantised, which quite heavily skews the probability of which code point will be selected in favour of the lighter colour. Increasing the number of bits hides the effect somewhat by making more code points available. But because they're distributed in gamma-encoded rather than linear-encoded space, it's still not correct to assume that a 50/50 pixel mix of two adjacent code points will appear the same as the colour numerically halfway between them, unless you're making that judgement in linear space. The mistake the shadertoy is making is transforming the data to sRGB before quantising. Both dithering and quantising should be done in linear space (which is non-trivial since in linear space the codepoints aren't linearly distributed any more) - otherwise the dither function's triangular distribution is skewed by the sRGB transform.
- bmandale 2y ago
  The OP example is clearly wrong, but this doesn't sound right either. The point of dithering is eg, if you have a pixel value of .5, to recreate the brightness of that with black and white pixels. The naive approach would do that with one black and one white pixel. But depending on how the display usually renders .5, then it might be better to replicate it with, say, 2 white pixels and 3 black pixels.
shiandow 2y ago
They seem to be using some kind of error diffusion. And getting error diffusion to play nice with linear colour space is nontrivial. I remember I had quite a bit of discussion with madshi when MadVR tried implementing it. You can do something that comes close by modifying the colour space into something that is gamma light in the integer part and linear light in the fractional part. If the value of a pixel is x you then get something like floor(x) + (l - ginv(x)) / (l - u) with l and u the the two shades corresponding to floor(x) and ceil(x) in linear light. Though technically error diffusion will still be incorrect, but it does handle constant shades correctly and most alternatives are worse somehow.
- obrhubr 2y ago
  Thank you for pointing that out. The Atkinson dithering I was using was indeed messing with the results. I'll be updating the post shortly :)
  - shiandow 2y ago
    Still looks a bit dark to me, though the main issue is that webbrowsers simply refuse to display the image in a 1-1 resolution. Edit: Oh and I see you suffer from the patterned runs of pixels that plagued madshi ;-) It's one of the reasons I prefer simple patterned dithers
Retr0id 2y ago
You're looking at a scaled version of the bitmap (potentially re-scaled multiple times) and some or all of those interpolations may not have been done in a linear colour space. But in this case I think it's just wrong. The entire first 40% of the bar is black, and I don't think it should be.

by kaoD 2y ago

hagbard_c 2y ago

> What could be causing this? Hypercorrection, in this care over-linearisation.

badmintonbaseba 2y ago

Apart from implementing it incorrect, an uncalibrated display could also cause this. Check out http://www.lagom.nl/lcd-test/gamma_calibration.php http://www.lagom.nl/lcd-test/gamma_calibration.php with DPI scaling turned off, at 100% zoom level (how browsers scale images are also horrible, so you want to avoid that). edit: Reading back, viewing the gradients also not at 100% zoom level could also itself cause the mismatch, because browsers just suck at image scaling.

gus_massa 2y ago

Mac vs pc? They have a different default gamma and they may show a different gray level. (It bite me a long time ago. I made a gif that has the same RGB bacground than a webpage. In my pc it was fine, but in a mac they the border was very visible and the result horrible. My solution was to change the backgroung of the webpage from a RGB number to a 1 pixel gif with repetition or scale to fill the page.)

TinkersW 2y ago

I don't know where they got the idea you don't dither in srgb, the point of dithering is to map it to the nearest bit pattern with a random adjustment so that it could go either way(aside from artistic choice), you should dither in srgb if you are going to display it in srgb, which is probably why the "not linearized" version looks more accurate. See: Dithering should happen in sRGB https://www.shadertoy.com/view/NssBRX https://www.shadertoy.com/view/NssBRX

robinsonb5 2y ago
I'm far from convinced that shadertoy demonstration is correct: If you set the number of bits to 1, the dithered version is clearly far too light, which is exactly what happens if you dither in gamma-encoded space rather than linear space. It gets much worse if you uncomment the SHOW_CORRECT define since the data is then being transformed back to SRGB before being quantised, which quite heavily skews the probability of which code point will be selected in favour of the lighter colour. Increasing the number of bits hides the effect somewhat by making more code points available. But because they're distributed in gamma-encoded rather than linear-encoded space, it's still not correct to assume that a 50/50 pixel mix of two adjacent code points will appear the same as the colour numerically halfway between them, unless you're making that judgement in linear space. The mistake the shadertoy is making is transforming the data to sRGB before quantising. Both dithering and quantising should be done in linear space (which is non-trivial since in linear space the codepoints aren't linearly distributed any more) - otherwise the dither function's triangular distribution is skewed by the sRGB transform.
bmandale 2y ago
The OP example is clearly wrong, but this doesn't sound right either. The point of dithering is eg, if you have a pixel value of .5, to recreate the brightness of that with black and white pixels. The naive approach would do that with one black and one white pixel. But depending on how the display usually renders .5, then it might be better to replicate it with, say, 2 white pixels and 3 black pixels.

shiandow 2y ago

They seem to be using some kind of error diffusion. And getting error diffusion to play nice with linear colour space is nontrivial. I remember I had quite a bit of discussion with madshi when MadVR tried implementing it. You can do something that comes close by modifying the colour space into something that is gamma light in the integer part and linear light in the fractional part. If the value of a pixel is x you then get something like floor(x) + (l - ginv(x)) / (l - u) with l and u the the two shades corresponding to floor(x) and ceil(x) in linear light. Though technically error diffusion will still be incorrect, but it does handle constant shades correctly and most alternatives are worse somehow.

obrhubr 2y ago
Thank you for pointing that out. The Atkinson dithering I was using was indeed messing with the results. I'll be updating the post shortly :)
- shiandow 2y ago
  Still looks a bit dark to me, though the main issue is that webbrowsers simply refuse to display the image in a 1-1 resolution. Edit: Oh and I see you suffer from the patterned runs of pixels that plagued madshi ;-) It's one of the reasons I prefer simple patterned dithers

Retr0id 2y ago

You're looking at a scaled version of the bitmap (potentially re-scaled multiple times) and some or all of those interpolations may not have been done in a linear colour space. But in this case I think it's just wrong. The entire first 40% of the bar is black, and I don't think it should be.