Opening an image I was sure didn’t have clipping, I was surprised to see the clipping indicator (set to 255) displaying. The raw histogram confirmed there was no clipping of the raw data. So what caused the clipping? There followed a process of turning off every single module possible to find the culprit. It was an educational exercise, helping me understand more about what effected the histogram. It also raised a few questions.
The closest match I could get to the raw histogram came with everything either turned off or set to ‘none’, except demosaicing, working space and output space (the latter two of which can’t be turned off). This surprised me, as I thought raw histogram represented data pre-demosaic, so why would setting demosaic to ‘none’ be less accurate than setting it to anything else?
Rawpedia says, “…the working profile will only specify the red, green and blue primaries, gamma will not change as RawTherapee’s processing pipeline is floating point with no gamma encoding (that is gamma = 1.0).” Yet when I change Tone Response Curve from ‘none’ to ‘custom’ and set gamma = 1, the results vary - the image gets much darker. It behaved this way with every working space tested. If Rawtherapee always uses a gamma of 1, why does changing the TRC in working profile to gamma = 1 give a different result?
I set profile back to neutral. Given the raw data wasn’t clipping, it was easy to retain the ‘clipped’ highlights in a variety of ways. Either by a) Reducing exposure, b) Lowering white point of exposure tone curve, or c) Lowering raw white point. As a starting point, are all these methods as technically valid as each other, or is their one superior/inferior option? Further, as someone accustomed to the scene-linear workflow in darktable, am I better off bringing those highlights back with dynamic range compression, similar to how I would use filmic? (In other words, set exposure for the midtones, and not worry about the highlights?)
@Soupy The fact that you have no raw clipping only means that none of your sensor pixels have overloaded. The simple step of converting your raw values to another color space can create RGB values that have one or more channels clipped. This also explains your first question: the raw histogram shows raw values. Even when everything else is turned off, like you say, there is still a conversion step causing different RGB values.
As for your third point. It all depends on what type of highlight you want to recover. If there really is no raw clipping, I would start by reducing the exposure or increasing the highlight compression. Bringing down the tone curve basically does the same thing. By no means touch the raw white point slide.
@Soupy
your point 1- as @thanatomatic said, as soon as you process raw, you have to choose a working space and an output space. Thus You have the choice in RT either to use WS for clipping indicator and histogram or use Output space.
If the gamut of your output space is small like sRGB, considering the large camera space, without precautions, you will get clipping in output space.
Now you set demosaicing to none. Even in this case, you have the transformations
camera space> WS > output space.
so raw histogram (in camera space) will be different from histogram in WS and histogram in output space.
If you set inputprofile to no profile, the transformation from camera space to WS is identity. In this case, the two histogram should only differ by the wrong application of a gamma to WS data (see hereunder). But it is perhaps still more complicated.
Some remarks:
The WS histogram presented is wrong as a gamma=1.8 is applied to compute this histogram and values in WS. It is some bizarre hack to replace log scale.
when there are some clipping in output space, you can have a preview of your output file using soft-proofing.
you can toggle between WS histogram and output histogram
your point 2
In my opinion, this option to use TRC for WS is of no use. I confirm your observation and I think the right way to correct the bug is to suppress the option!
A bug means it does not work as intended. So this must mean TRC ‘custom’ gives wrong result (ie. gamma 1 <> gamma 1), whereas TRC ‘none’ gives correct result. According to RawPedia that means gamma = 1. Can anyone confirm this? Or does TRC ‘none’ use standard gamma of selected profile, which for Pro Photo RGB would be 1.8?
It is interesting you say the WS Histogram is wrong in applying gamma 1.8 to calculate values, as that would seemingly be correct for normal non-linear Pro Photo RGB. This matches what I observed. When going from TRC ‘custom’ gamma = 1, to TRC ‘none’ I saw brightness increase in both histogram and image, making me think it was all working as intended, with gamma 1.8…
Handy to know. Not a major issue, but wouldn’t it make more sense for the icon to be placed next to the histogram, under all the other little buttons there?
Actually, selecting ‘camera standard’ as input got nearly identical, even moreso than selecting ‘no profile’ - but they were only NEARLY identical when demosaic was not ‘none’, and TRC was set to ‘custom’ and gamma = 1. You tell me it’s wrong, and you may be right, but so far it seems to match in all the ways it should. I would guess at this point the reason the histograms are not perfectly identical is because of the Camera Space > Working Space transformation. But you and Thanatomanic have both focused on the effects of colour space on histogram, which I more or less understood already, and my first question was not that. My question was the effect of demosaicing - if raw is captured before demosaic (it is), then why should we only be able to mimic raw histogram with demosaic turned on?
My English is too bad to engage in a debate on the subject of TRC. For me it works as I expected (by connecting to the aspect of the output visualization gamma=2.4 slope=12.92, and not with the gamma in the process which is always 1).
Thanks for confirming. My question is simply, if gamma in process always = 1, then why does changing gamma of custom TRC to 1 make a difference? My current assumption is the custom TRC has no effect on editing operations, and is only there for correct visual display on our monitors? If so, why did gaaned say it has a bug? My current assumption, as much as I can understand from ganned’s answer, is that the histogram uses an incorrect gamma 1.8, which gets negated when you drop TRC custom to gamma = 1 (this is why it makes the histogram match the raw histogram). But with a correctly working histogram, you would not need to drop the TRC custom gamma to 1 in order to to match the raw histogram. In fact, doing so would unmatch the raw histogram. However, if TRC has no effect on editing operations, why does it effect the histogram? Is that the bug gaaned was talking about?
In other words, currently the histogram has a bug (applying gamma 1.8), and the TRC ‘custom’ has a bug (altering the histogram when it shouldn’t), and when custom is set to gamma = 1, the two bugs more or less cancel each other out on the histogram, thus giving the correct result, which is what I was seeing? Two wrongs making a right? Or am I completely barking up the wrong tree?
It has an influence not only on histogram but also on values displayed for instance in the pipette, also on the clipping indicator pehaps other tools.
The WS TRC must not be used to correct display. It is here to modulate the processing (you are no longer in linear processing).
Now, having different result between no TRC and gamma=1 seems clearly a bug to me.
I agree
It was by design I think but it can be puzzling inspecting histogram and color values as those values are said to come from WS and processing is said linear .
AA display of histogram in log scale seems better to me.
The WS values have also this 1.8 gamma applied
There was already some discussions about that but it was not corrected.
@jdc I really disagree with removing/hiding this feature without a proper commit message or having a discussion on GitHub first. If there is a bug, the correct way is to discuss and investigate, not simply remove. Could you please revert your commit for the time being?
@gaaned92 You seem to have brought up this issue before. Could you, or Jacques, start an issue in the tracker to get to the bottom of this? That would be much appreciated.
I don’t mind if the eventual conclusion is that we need to remove the custom TRC code, but the reasons why should be documented in the tracker at the very least.
