Blender AgX in darktable (proof of concept)

[kofa (István Kovács)]

Also, if your colours are oversaturated, the sRGB conversion at the end will probably clip them.

[hatsnp (Nuno Paulino)]

@kofa

Human vision itself does not preserve hue; there are all kinds of shifts. Just search the forum for salmon fire.

Oh wow… I always thought the salmon fire and the supposedly associated “rat piss yellow” was an artifact of those tone mapping methods and not because our vision itself doesn’t preserve hue, so when a software does we see it as wrong.

[kofa (István Kovács)]

The ‘rat piss yellow’ is a consequence of per-channel application of tone curves (all colours converging to secondaries). Try disabling insetting and rotation (and hue preservation) in the agx module (or in sigmoid), or use rgb curves, or filmic in v4 (?) and earlier without chroma preservation (I think those will also show the issue).

The ‘salmon fire’ is caused by preserving hue where human vision would introduce a shift, if I understand correctly.

[cjhemmer]

The theory here is very interesting to me and brings to mind a question that may or may not be relevant, at least in use of the module. Modeling the hue shift to match human perception makes sense in the context of a 3D modeling environment (e.g., Blender where the AgX model is pulled from) but does it also make sense with respect to a camera sensor which is, in my mind, recording the actual color light values of the source? Should we be defaulting to 100% hue preservation and adjusting for look from there or do the same theories apply to a camera sensor and it’s all about converting digital (sensor) to analog (human eye)?

[kofa (István Kovács)]

This has been raised before, see Blender AgX in darktable (proof of concept) - #1377 by Eary_Chow and Blender AgX in darktable (proof of concept) - #1282 by Eary_Chow (@Eary_Chow is one of the original developers of Blender’s AgX; my code is just a port).

[rvietor]

@cjhemmer

does it also make sense with respect to a camera sensor which is, in my mind, recording the actual color light values of the source?

Keep in mind that in both cases, the hue preservation (or non-) comes in at the stage where we prepare for display, so it doesn’t really matter where the signal comes from. Up until we start preparing for output, we want to avoid perceptual adaptations (which this is all about) …

[Eary_Chow]

@kofa

Human vision itself does not preserve hue

I would be cautious when talking about hue in this fashion. The term Hue in the HSV etc. models are quite abused to refer to chromaticity angles, while the term “hue” is inherently perceptual. Instead of saying that the human vision doesn’t preserve hue, I would say that none of the chromaticity based color models would be able to accurately represent the “hue” as percieved by human, which is highly context dependant. It’s much more accurate to just refer to them as chromaticity angles, instead of hue.

@hatsnp

Oh wow… I always thought the salmon fire and the supposedly associated “rat piss yellow” was an artifact of those tone mapping methods and not because our vision itself doesn’t preserve hue, so when a software does we see it as wrong.

The yellow shift can be undesirable if it’s too strong. If you tweak the attenuation higher, the shift can become less strong, you can play with that setting if you like. Basically, the lower the attenuation settings are, the stronger the hue flights are. And the rotation parameters can control the direction of the shift. The control of the shift is a key feature that AgX offers.

@kofa

The ‘salmon fire’ is caused by preserving hue where human vision would introduce a shift, if I understand correctly.

The “Salmon Fire” is when the chromaticities are attenuated to white via a straight line in the xyY plot. It has nothing to do with the “shifts” in human vision, it’s just the chromaticity. If you measure a real fire’s light spectra, convert it to chromaticity, and evaluate it in isolation, you won’t get a conventional sRGB yellow angle, it would be in the more orange angle.

But whether that looks good in a picture is a different matter. I personally don’t have a problem with it, but a lot of people do like fire to be more yellowish, as well as skin tones etc. To me it’s an aesthetic debate. Troy did mention there was a paper by MacAdam that suggest people prefer skin tone to be yellower, he mentioned the term MacAdam used to describe the salmon color, “beefy”.

And recently Chris Brejon wrote another article about picture formation, apparently he agrees it should be more yellowish.

What makes a good picture (formation) ? - Chris Brejon

[kofa (István Kovács)]

Thanks for correcting my sloppy wording, and for the interesting article.

[nosle]

@Eary_Chow

the term MacAdam used to describe the salmon color, “beefy”.

As someone who participated in the great salmon wars of pixls.us but has no theoretical knowledge what so ever it’s super interesting to see that these issues were known and have theoretical backing.

It’s also great to see the software solutions being developed.

[PD1 (PD)]

On a side note. Should we have a new build of AgX to align with the latest darktable master? Just a thought

[kofa (István Kovács)]

Blender AgX in darktable (proof of concept)

I’m off to vacation. I’ll probably work a bit on the docs towards the end, but will not have access to a proper coding environment (I’ll have a Raspberry Pi 4). I wouldn’t want to have one, anyway (‘too much of a good thing’ and all that).

[paperdigits (Mica)]

Also anyone can build master, have a stab at building it yourself if you never have.

[kofa (István Kovács)]

I’m back. I’ll sync the branch and let you know later this week.

[kofa (István Kovács)]

@kofa

We’ll leave them as they are, for now; in a few days, I’ll be on holiday. I’ll post a poll later, and I’ll update the UI according to the results, if needed.

So, here is the poll:

• revert to ‘pivot x shift’, ‘pivot y (linear)’
• keep ‘pivot input shift’, ‘pivot target output’

I’ll close the poll on Sunday evening my time, no earlier than 16:00 UTC.

[priort (Todd Prior)]

Is there room and would you get the best of both if you put (x) right after input and (y) after target?

[kofa (István Kovács)]

I cannot change the poll now.

All: keep in mind that what you change is not the actual pivot y coordinate, but the linear output. There’s a power function (using the ‘gamma’) connecting the two. For example, if gamma=2.2, a linear output of 0.18 (the value you set) is represented by pivot y = 0.46 (the pivot will be about ‘half way up’, calculated by the code).

[kofa (István Kovács)]

A new build. No new functionality, only some internal changes. Please test and let me know if I broke something.

Version info:

• The code has been rebased on the current master, and includes all changes up to and including:

commit 26f3237a1c711e0e3777028f6c9cf57a552c04ea (origin/master, origin/HEAD)
Author: Mario Zimmermann <mail@zisoft.de>
Date:   Sun Aug 17 17:29:55 2025 +0200

    [nightly macOS]: bump xcode to 16.2

(so has the same mainline changes as master build g26f3237a)

• tagged as agx-2025-08-20-18-05-00

The AppImage: https://tech.kovacs-telekes.org/dt-agx/Darktable-5.3.0%2B251~ga22c4eeb89-x86_64.AppImage

@priort , @Dave22152 , @MStraeten, please update your builds.

[Dave22152 (Dave Goldberg)]

I just created the build, but it shows 5.3.0+172~g1bfb368296. I just want to make sure I’m in step before I post it to everyone.

[priort (Todd Prior)]

I’m home in a couple of hours I will see where I land with mine… I think I build the dev last night or the night before and it was at +215…

[Dave22152 (Dave Goldberg)]

@priort - it looks like I got it squared away. I’m now at 5.3.0+251~ga22c4eeb89, but I’d be interested to see what you land with.