@anon41087856 - I followed the tutorial in this thread and tried to follow the logic:
It looks like the code linearizes “something” which I’m guessing is the LAB TRC, because the camera input profile is already linear.
- Is above correct? If not, what is linearized?
Then the code applies a log2 curve that takes parameters from the image, modified if the user wants by picking middle gray and etc. At this point it seems to me that the image is no longer encoded linearly. Edit: this question is meant rhetorically, in case anyone wonders.
- Is above correct? Is the image no longer encoded linearly?
The next step is to apply a tone curve, which happens in LAB space, but using automatic RGB to restore the otherwise lost saturation.
-
Is the tone curve itself applied in LAB space even though the saturation is added back in using “automatic RGB”?
-
And what is “automatic RGB”?
Question 2 above is meant rhetorically. This new darktable algorithm linearizes “something” (that’s question 1), applies a log2 (or gamma, user choice) curve, and then modifies the result in LAB space, but add saturation using RGB. The result is hardly “scene-referred”. The result also has hue shifts all over the place.
Whether the new darktable algorithms produce “pretty results” or an easier, quicker way to get to “pretty results” is a matter of aesthetic opinion, and personally I don’t care whether an operation is done on linear RGB or otherwise as long as the user is happy (and preferably also has a clue regarding what they are doing to their RGB data).
@gez - several times you’ve expressed a rather intense dislike of editing nonlinear RGB, often in connection with doing so using GIMP. Is there something about the darktable “unbreak profile” algorithm that makes it OK, acceptable, etc to operate on nonlinear RGB?