For a basic, simple and effective workflow this is a must.
Every tone manipulation operation like brightness,contrast and curves should be performed always with a 2.2 gamma ( srgb, rec.709, pure 2.2 and pure 2.4 trc), no linear and no lab perceptual trc.
Example with a simple workflow , rgb levels (gamma) and rgb tone curve
Photoflow, working profile rec.2020 with lab gamma
With a linear gamma it’s just impossible to fine tuning the shadows, same for lab trc because it lifts too much the shadows and with curves is not possible to add the right amount of contrast but only darkening the overall brightness
Yes, but it gives to the user a higher amount of precision in the tone manipulation.
The hue shift will be not perceived in the 99,9% of the cases and some times the hue shift looks just better over hue preserving
It is important that you look at the results using the representation that you like… with the gamma that works for you.
I can’t see that this has anything to do with the working space where the modifications are being applied, typically by some sort of matrix multiplication.
The whole principle of a non-destructive editor is that the image you are seeing at any moment is the end of a chain of modifications running from the RAW file and ending up being transformed by the ICC of your display and splashed on your screen. You can change the operation applied at any stage of that change, and see the results as everything subsequent recalculates. You need to ensure you have enough bit-depth to avoid loss of information to rounding etc errors… which is why dt uses 32-bit floating representations internally.
No, the curve tool for example is one of the most important tool in every photo or video editor but it simply doesn’t works well in linear or lab gamma (actually the log-linear view in the base curve darktable’s module does the trick but it is slow and not intuitive ).
For this reasons every commercial raw editor have a gamma close to srgb and in the video editing world is used some log color spaces (mid point raised to match 2.2 gamma and linear part in the shadows because a pure log transfer has the same issue of lab trc)
In the end is possibile to use a linear working space, but when curves, brightness and contrast sliders are used there’s need to a linear to gamma conversion before and a gamma to linear conversion after.
@Elle’s profile set has working-grade profiles in the various gammas:
I’m having decent success using a filmic tone operator to do the thing that vexes you. Yes, standard curve tools do not give you sufficient control at the low end, but that’s the original goal of filmic: shape the toe to manage the lowest values.
It would appear darktable and PhotoFlow have made decent progress in providing filmic tone operators with intuitive controls. I wouldn’t endorse my filmic operator in rawproc; it simply exposes the A, B, C, and D coefficients, manipulation of which is decidedly un-intuitive…
It may not have all the flexibility you desire (or the wide gamut support) but Filmulator does its “curve” operations at the end of the pipeline (controlled with sliders) in sRGB gamma.
Filmulator’s philosophy is that an appealing result is preferable to an “accurate” one.
@age PhotoFlow’s curve tool already allows nonlinear representation. Don’t know what the current backend is. Perhaps @Carmelo_DrRaw could give you more options (or you could set it up to work that way but then it would rob you of the convenience).
@Carmelo_DrRaw BTW, I loaded the curve module before the PFI was done loading and PF crashed. Can’t reproduce: it might have to do with the elusive bug that comes from doing things in rapid succession.
The UI of curves is built around the idea that middle grey = 50% and white = 100%, so grey ends up in the middle of the graph, which is convenient for ergonomics. Linear standard middle grey is 18%, so an exponent 1/2.44 puts it at this value and makes them usable. But nothing prevents you from using them knowing your fulcrum point is at 18%, and not 50%. Just roll your S curve around 20% instead of 50%. But even so, it still assumes white = 100% and that sucks.
Curves are a silly thing of the past. Hard assumptions like grey = 50% are wrong for large dynamic ranges and that’s why we need a special workflow (even special software) to handle HDR. The truth is, if you use a proper pipeline with proper algorithms, HDR is just like SDR and the workflow is the same (same tools, same software, same method, just different parameters).
Use the contrast in colour balance, it gives you a fulcrum value that let you enter whatever grey value you want as a reference. Use the tone equalizer while disabling the details preservation in masking tab, and you get a tone curve (which is actually just a parametric exposure compensation) with logarithmic controls, working in linear space and let you rescale the dynamic range as you like. Use exposure to set up your lightness and filmic to unclip the highlights, and you have a full pipeline that works the same no matter the dynamic range of your picture.
Hard-coded assumptions are so 1990. We need to break free from that nonsense.
Let me elaborate on this. I am speaking about the tool itself and not the working profile. As said above, I would leave the latter alone; everything would be managed and reinterpreted by the tool itself. Curve tools as I know them allow the widest range of motion at the centre. This makes it easy to adjust whatever is in the middle, depending on what the graph represents – more on this in the next paragraph; but less so as we approach the terminal points.
Now for a paradigm shift that may or may not gain traction. Perhaps this middle of the curve could be shifted along the xy-axes. Additionally, perhaps the xy ranges and scales could be user-controlled. I would love that amount of power and flexibility.
So if @age wants to target the shadows with his favourite tool the curve, then he(?–sorry, I forget) may centre the curve around the shadows. The tool would keep the values <0 from being used or made. If he wants to use x or xy nonlinear scales, or whatever linear combination of colour he may do so. Sure, now the curve tool would be a monster.
Same operations for both but they are different and the external profile has posterization
Thanks for the answer but no, the colour balance module isn’t different from the levels tool in gimp, it doesn’t clip but it should be not recommended for raw.
The contrast slider in the colour balance module push the white outside the 0-1 range, that value could be recovered but it required a lot of additional and unnecessary works.
Even working with hdr the white level should not be scaled with a contrast adjustment
Right. It’s not as if the formula went straight from the ACES.
1 doesn’t mean anything inside your pipeline, it’s just a value. It’s your display that needs mapping to [0,1] and means white when it sees. Let’s not mixup output and pipe, that’s the mistake that got us in trouble 25 years ago.
I think to understand your opinion but one misconception about aces is that is possible to do one single video grading in a scene referred space and then deliver that result for whatever hdr / sdr color space with of course the right color transform.
This is considered bad pratice.
Now, with Darktable it’s painful hard to use rgb curves without the srgb working profile (big limitation in the gamut).
At least take in consideration to modify the behaviour of the curve module so the user have a choice in which gamma the curve is applied.
I’m pretty sure everyone will love this feature and if someone doesn’t want to use curves because thery’re “obsolete” he could just not use this module
Yes, since I teased the display TRC out of my mainline processing, all works nicely.
I’ve had to really wrap my head around it, as in rawproc I can select any tool in the chain to be the displayed image, and that will get display-transformed. Needed to set my expectations such that it shouldn’t be considered unless i selected the last tool in the chain, which is usually a resize/sharpen group for the file output.
You can work in sRGB in darktable pipeline, just go to the input colour profile module and set the working colour profile to sRGB. But that has nothing to do with gamut, I think you are lost in colour management concepts. Small RGB spaces are better for some parts of the editing (for colour control from user perspective) provided the soft doesn’t clip out-of-gamut values (and darktable doesn’t). But nothing in there will change your output gamut, and gamma/TRC/OETF is an encoding, not a gamut mapping.
I’m not surprised things don’t work well for you in scene-linear if you don’t understand basic digital colour.
I think you probably meant “tone”, not “gamut”… ??
You make a good point, color and tone are two distinct things that get rolled up into a single entity in ICC and DCP profiles. Very much need to keep their consideration distinct, even when dealing with the combined needs of displays.
Yes I know it but i don’t want to work with srgb working space, i want to work with a wide gamut working space.
I want to use curves too.
Now try to open a raw file, set the working space “rec.2020 linear” and use the RGB levels module to raise the gamma.
After this, changes the working space to “srgb”.
See how the image is different? This is because that module is dependent from the gamma used in the working space.
The rgb curve module works always using the perceptual trc used in lab color space.
I found that a pure gamma 2.2 or srgb it would be a better choice, i use a lot the curve tool in every editor but the one in darktable is pretty much useless because the Lab trc.
Edit:
I wasn’t expecting different behaviours for RGB levels and RGB curves.
But the Lab trc used in curves is bad anyway.
Gamma belongs to output. The module is independant from the output. You get to decide what input, output and pipe colour spaces you want. That’s consistent. A good pipe is a pipe that doesn’t care about the output.
What you are asking for is for the module to adapt depending on the output TRC. So you want a display-referred pipe, but still wider gamut than your display. That makes no sense at all and will trigger a full load of problems you have no idea of.
If it is what you want (and, again, trust me, you will open a can of worms), then use the unbreak colour profile module to force an artificial “gamma-like” transformation.
My friendly advice here is to embrace the scene-linear workflow, learn it, try it, and when you will see by yourself that you no longer mess colours while adjusting luma, and the other way around, , even for dramatic edits, you will understand what is so great about it.
why are you talking about output?
RGB level are dependent from the gamma used in the WORKING PROFILE in darktable.
I was misleading to think rgb curves share the same behaviour.
middle gray 0.18 is mapped to 0.5 in rgb curves?is this correct?
is this because the lab trc?
