Request for a 2.2/2.4 gamma wide gamut working profile

from here

1 Like

Because there is no gamma outside of output display. Every internal data massaging relying on that is pure madness.

In the input profile module itā€™s possible to select rec.709 profile linear or with gamma as working profile.
Do you understand what is a working profile?
The working profile has gamma if rec.709 with gamma or srgb are selected.

However RGB curves with a Lab trc is ā€œmadnessā€, so please remove the Lab trc in the tone curve module and use something like srgb gamma.

What @anon41087856 means is that the original reason for a gamma construct was to make linear-recorded images look right on CRT displays, which have non-linear response. I havenā€™t seen it for myself yet, but I am told that LCD displays natively have linear response, but are made to approximate the behavior of CRTs for compatibility reasons. This was the essence of the painful discussions about a year ago on scene- vs. display-referred workflow.

What I have seen for myself is that working the image data in its original ā€œenergy relationshipā€ keeps from introducing artifacts longer than if the data is ā€œcurvedā€ in any way, then worked. Multiplication (exposure compensation) doesnā€™t count: while the magnitudes change, their energy relationship stays the same.

Converting to a non-linear working profile, then swinging the data around may be easier with the available tools, but it introduces artifacts and color shifts. And yes, the traditional tools are harder to work in linear space, but that doesnā€™t mean they canā€™t be re-organized to accommodate. Right now, Iā€™ve abrogated my use of spline curves in favor of a filmic curve that I control by modifying its coefficients. It works rather well, especially in providing clarity in the darkest cornersā€¦

WRT working profiles, Iā€™ve stopped using them for the time being, finding joy in simply working in camera space, then converting to sRGB at the time I write the file.

1 Like

Yes letā€™s not go that route again please!

Civility is a requirement to participate here. Letā€™s keep it above board.

2 Likes

I promiseā€¦ :smile:

Certainly not directed at you, it was a general comment.

Yes, filmic curves works very well for underexposed photos and they should be used in the early stage of a raw file development.
When you use filmic curves you are just raising the exposure and then fitting the new values in the 0-1 range plus a little contrast in the shadows.

After this point thereā€™s no reason to not use standard curves or adopting a display referred workflow.

Why and when use the cdl tool ?
ā€œTo facilitate the transfer of colour intent from the production to the post-production worldā€

https://knowledge.autodesk.com/search-result/caas/CloudHelp/cloudhelp/2016/ENU/Flame/files/GUID-85A9A2B3-FD5D-4A60-975D-5289BE9B33D0-htm.html

So not really usefull.

The sigmoidal contrast used in imagemagick is probably a better choice

http://www.imagemagick.org/Usage/color_mods/#sigmoidal

Ruminating on this some more, I went back and picked apart what Iā€™m doing in rawproc to see if there is ā€œroom to maneuverā€ with the curve tool in linear. To the extent that I added a ā€œcopy tone curve to the clipboardā€ button on the tone tool, with the intent to support spreadsheet analysis, and then later to actually copy to a curve tool command. Hereā€™s the outcome:

What youā€™re looking at are two overlapped instances of rawproc on my desktop, both with the same image open, same processing except for the curve at the end. The ā€˜behindā€™ one has a filmic curve, for which you can regard its parameters and plot in the parameters pane. With that processing, I copied the curve as a curve tool command and pasted it into the curve tool of the ā€˜forwardā€™ one, its curve tool prominent in the parameters pane.

The images are a bit different in tone; Iā€™m attributing that to precision error in the 0-255 integer based curve tool. If you look closely, youā€™ll see I selected the bottom-left control point; actually, this one is the second point, covering the anchor point at 0,0. That is where the filmic ā€˜toeā€™ is captured, and indeed, you can scooch that point around just a teeny bit and influence the darkest tones almost like messing with the B coefficient in filmic.

I selected an interval of 10 for the control point collection, which actually gives room for making minor changes along the curve. Itā€™s easy to introduce unattractive discontinuities, but one can make beneficial changes to specific local tonality if one is carefulā€¦

Note that the histogram is not of the display output; my monitor profile is about a 2.2 gamma, so thereā€™s the display reference. This histogram reflects the application of the filmic curve to the linear data. Oh, and at this point in the processing, Iā€™m still working on the camera data, no conversion to a working profile.

Iā€™m going to continue to use just a filmic curve for my tone transform, but I see room to use a curve tool, especially if the dominant transform has to be ā€œnegativeā€, that is, a convex curve.

Ruminations on a Saturday before the holiday breakā€¦

2 Likes

With the filmic curve equation is possible to recover data outside the 0-1 range and this is impossible with the standard curve tool.

If you want to roll-off the highlights with values > 1 and add contrast in the shadows, yes filmic is the faster way to go.

But in the end every filmic curves are just exposure compensation + s-curve for contrast.

I guess in darktable the tone curve module use Lab trc because backward compatibility with the old Lab curve.

The new rgb curve module use Lab trc when the ā€œcompensateā€ option is checked.
It would be great to add the srgb trc in this module too

I think AurĆ©lienā€™s point was that using sRGB as your working profile will not restrict your gamut because darktable doesnā€™t clip out-of-gamut colors (those where one or two of R, G or B are negative).

You can try it out yourself with transicc from lcms2:

$ transicc -i /usr/share/argyllcms/ref/Rec2020.icm -o '*sRGB'
LittleCMS ColorSpace conversion calculator - 4.3 [LittleCMS 2.09]

Enter values, 'q' to quit
R? 255
G? 0
B? 0

R=318.3001 G=-410.4162 B=-59.8131

Enter values, 'q' to quit
R? q
Done.
$ transicc -i '*sRGB' -o /usr/share/argyllcms/ref/Rec2020.icm
LittleCMS ColorSpace conversion calculator - 4.3 [LittleCMS 2.09]

Enter values, 'q' to quit
R? 318.3
G? -410.42
B? -59.81

R=255.0000 G=0.0000 B=0.0000

Enter values, 'q' to quit
R? q
Done.

As you can see, if no clipping is performed, then even colors outside of sRGBā€™s gamut can be converted to it and back with no issue.

Elle wrote an article about the limitations of such an editing workflow, though.

2 Likes