News for hackers. Stuff that matters.
Re:Blur Radius Comparison by codeflo on Saturday January 13, 2024 @05:16AM (#38978617)
The point about gamma correction is important. Many effects like scaling and blurring should occur in what's called linear color space, otherwise you add or remove energy, which can look very wrong. Normal RGB isn't linear.

GPUs and most game engines get this correct, maybe because in animated 3D graphics, you'd notice this immediately. But browsers are ridiculously bad at understanding this -- there was an article a while back that demonstrated some pathological cases.

Re:Blur Radius Comparison by jiggawatts on Saturday January 13, 2024 @05:33AM (#38978724)
Browsers, chat apps, social media apps, Outlook and all other email clients, Teams, Zoom, Adobe Photoshop (really!), DaVinci Resolve (a colorist tool ffs)[2], and on, and on...

Developers assuming that RGB is a triplet of 8-bit numbers and that maths can be naively done to those numbers is one of my favourite examples of the Dunning Kruger effect.[1]

It's such a rarity to see a tool correctly implement color management or linear light for transforms by default that it always jumps out as far out of the norm.

> animated 3D graphics

You'd think so... but no. It's a persistent error in 3D games as well, as well as 3D renderers like Blender.

A common question posted in game-dev forums is "textures look brighter/lighter/faded in game compared to Photoshop". This is because most image editors use the sRGB non-linear gamma, but the game engine uses linear light because it's essentially a physical optics simulator. Beginner game developers load the sRGB 8-bit pixel values and then use them as-is without first undoing the gamma to bring them into the linear light space. This results in over-bright textures. The Quake engine and its derivatives were notorious for this kind of thing, made even worse by OpenGL accelerators like the 3dfs Voodoo card doing more incorrect things on top of that.

Similarly, "Cinematic" mode in Blender should be renamed to "not broken" or simply "correct" color management mode.

[1] I'm guilty of making all of the mistakes I've listed here, in a 3D engine, a ray tracer, and several other graphics utilities. We're all beginners at some point!

[2] The "best" video colorist tool on the planet is not color managed on Windows or Linux. It outputs "whatever" to the screen and ha-ha... good luck. On a HDR screen, with HDR on, if you enable HDR in Resolve you get a washed-out incorrect mess. That just blows my mind.

Re:Blur Radius Comparison by codeflo on Saturday January 13, 2024 @05:51AM (#38978828)
> You'd think so... but no.

Well, your first counter examples are beginner mistakes (obviously) and a graphics card that the younger half of HN readers have never heard of.

Blender getting it wrong would be inexcusable, though. Maybe I was overly optimistic.

Re:Blur Radius Comparison by david_for_you on Saturday January 13, 2024 @06:55AM (#38979168)
Blender is a tool that gives you a lot of options and some of those would be "wrong", so it is partly up to the user to know what is correct. The defaults have been "correct" for a long time already though, at least regarding linear vs gamma space.
Re:Blur Radius Comparison by MartijnBraam on Saturday January 13, 2024 @09:35AM (#38980280)
To be fair the solution in Resolve to get "correct" colors is with decklink cards bypassing the entire OS graphics stack to deal with this. It's only somewhat recently that Resolve started getting support for getting a fullscreen view on a second monitor that's not a decklink.
Re:Blur Radius Comparison by jiggawatts on Sunday January 14, 2024 @01:07AM (#38987946)
Blackmagic is a hardware company that also has some software they sell on the side, which is why they've steadfastly ignored fixing their software in any way that would eliminate the need to purchase their over-priced video output cards.

My laptop can output 8K HDR @ 60 fps, which no Decklink card can achieve, at any price. I can get a "clean feed" by simply ticking the "Override to reference mode" checkbox in the NVIDIA driver. Several people have confirmed that this produces bit-accurate output indistinguishable from what a Decklink card outputs.

> fullscreen view on a second monitor

Yes, but it's still not color managed or even enabled for HDR under anything but MacOS! It just outputs the values as-is and lets the OS deal with it, which will treat it as Rec 709 SDR.

Re:Blur Radius Comparison by Solvency on Saturday January 13, 2024 @09:51AM (#38980442)
I agree but...huh? Chat apps? When are they dealing with linear color space? With video messages?
Re:Blur Radius Comparison by kzrdude on Saturday January 13, 2024 @10:37AM (#38980876)
Skype for business is hopefully dead but they used to do nearest-neighbor-downscaling of profile images. Even chat apps can do stuff wrong with images if they try hard enough.
Re:Blur Radius Comparison by jiggawatts on Saturday January 13, 2024 @02:49PM (#38983815)
People send pictures to each other with chat apps. Think iMessage, WhatsApp, and Telegram. All of these will generate downscaled thumbnails. All of these have to deal with non-sRGB images from sources such as Apple devices that use Display P3 by default now. Etc…
Re:Blur Radius Comparison by marcedwards on Saturday January 13, 2024 @09:20PM (#38986791)
Pasting UI images into team chat apps is pretty common, and the apps I’ve used have some pretty serious and ongoing issues. Not fun when others are making decisions based on those images.
Re:Blur Radius Comparison by dahart on Saturday January 13, 2024 @11:04AM (#38981169)
You’re conflating the tools with user errors. Photoshop, Resolve, and Blender aren’t doing it wrong because some users do it wrong. Gamma correction workflows are just prone to error, and sometimes people don’t know how to do it right. It’s not in general possible for the tool do handle it for you, the user needs to know the image’s history and sometimes has to convert between gamma encodings explicitly.

I don’t even know what you mean about Outlook and Teams, are you saying the text gamma is wrong? Or they display images wrong?

> Developers assuming that RGB is a triplet of 8-bit numbers and that maths can be naively done to those numbers is one of my favourite examples of the Dunning Kruger effect. [1]

RGB is a triplet of numbers, and you can do naive math on them, to convert to another color space for example. RGB in fact is a naive color space in the first place, not well defined, and does not have a defined gamma, so all math on RGB is de facto naive. sRGB is not RGB.

BTW, please don’t invoke Dunning Kruger snidely to suggest someone’s wrong. It’s a bad meme because DK is widely misunderstood, and suggesting someone’s an example because they’re wrong, ironically, perpetuates the misunderstanding. People making assumptions, or doing something wrong, or even being incompetent, are not examples of Dunning Kruger. People being over-confident is also not an example of Dunning Kruger: they showed in the paper that there is a positive correlation between confidence and competence for the tasks they measure. Therefore, you cannot know when something is an example of DK or not. The paper has rather poor methodology, it is full of priming and leading questions, including the title, and it went viral not because it’s right but because people love to believe the mistaken idea that someone who’s very confident might be incompetent, even though that’s not what the paper demonstrated. Also the Dunning Kruger effect probably doesn’t even exist, plus replication attempts have shown the opposite effects for more difficult tasks, like, say, engineering.

https://talyarkoni.org/blog/2010/07/07/what-the-dunning-krug...

Re:Blur Radius Comparison by marcedwards on Saturday January 13, 2024 @07:44PM (#38986270)
>You’re conflating the tools with user errors. Photoshop, Resolve, and Blender aren’t doing it wrong because some users do it wrong.

I agree, but defaults also matter. I’d like our tools to not assume everyone’s an expert, which means the default should be to provide good results. Photoshop can definitely work with linear profiles, and the 32-bit mode is good when you need it.

Re:Blur Radius Comparison by dahart on Saturday January 13, 2024 @08:13PM (#38986435)
Yeah, totally agree, defaults absolutely matter. And a bunch of the software @jiggawatts claimed handles gamma badly does in fact have reasonable defaults. The hard problem with images is that you need metadata, not just pixel values, and the metadata isn’t guaranteed to be there or to be accurate. It’s getting better quickly, I think, but it’s not Photoshop’s fault if the image doesn’t specify a color space or gamma, and not Photoshop’s fault if someone applies gamma first and then does a blur or paints a mask and then the blending isn’t what they expected.
Re:Blur Radius Comparison by marcedwards on Saturday January 13, 2024 @09:18PM (#38986779)
Yep, yep, yep. Getting better quickly, but regressions are common, too.

(QuickLook on macOS hasn’t shown correct colours for a while now. FB12602125 and FB13475690 if anyone from Apple is reading this and wants to take a look!)

Re:Blur Radius Comparison by planckscnst on Saturday January 13, 2024 @05:29PM (#38985288)
I occasionally do creative work that involves color. I've previously tried to understand color science concepts, starting with gamma, but I just haven't been able to develop an internal understanding of how this all works. Is there any content about the subject that you would recommend for someone like me?
Re:Blur Radius Comparison by marcedwards on Saturday January 13, 2024 @07:23PM (#38986140)
I hope this article series helps. My goal was to cover colour management in a way that everyone can understand. If it doesn’t, please feel free to ask questions (I’d love to know where the article fails).

https://bjango.com/articles/colourmanagementgamut/

Re:Blur Radius Comparison by jiggawatts on Saturday January 13, 2024 @08:34PM (#38986540)
I like this page because it shows one of the common issues (ugly gradient fills), explains the cause, and provides a solution usable in any web project: https://bottosson.github.io/posts/oklab/

The main thing to remember is that mathematical operations like blur and resize ought to be done in a linear space, but everything else needs to be non-linear in some way.

- Nonlinear gamma improves storage efficiency because it allocates bits more effectively “where it matters”.

- CRT displays had a nonlinear response curve as well, and this has been baked into standards like sRGB and all video standards.

- The human perception of color is also nonlinear.

These gamma curves are all generally different now, especially with modern HDR display pipelines.

So a correct pipeline is:

1. Undo the source curve into a linear format. E.g.: camera raw formats are usually logarithmic.

2. Do special effects like blending, sharpen, resize, Etc… in linear format.

3. Show grading controls that use a perceptual space to the human user.

4. Encode the output with the appropriate gamut and gamma for the output format, such as sRGB, or some HDR format. Tag it correctly.

As an example of what not to do, the chap that recently invented the “quite okay” image format[1] just ignored all this and encodes RGB 8-bit triples as-is with no indication of color space.

This is simple, clear, and wrong.

In the case of 3D graphics the RGB triples are a direct measurement of luminosity, and go to infinity. The common sRGB format goes from zero to one and represents the input to a function that maps that to an actual intensity. They’re not compatible! This is why mixing these in a game engine results in faded colours. Similarly, the linear output of a ray tracer can’t be sent to a screen as-is, it’ll look wrong.

Similarly ask yourself: which red, green, and blue? Each format defines these with differently! The “red” of Display P3 used by most Apple devices and HDR cinema projectors is very visibly different to the “red” of lsRGB!

These aren’t platonic ideals but points in space that can be measured, defined, and mapped into other color spaces.

[1] https://en.m.wikipedia.org/wiki/QOI_(image_format)