Profile application after opening file

Well, the input profile does have an influence on the matching, although for luminance only (what is done here) it’s probably not big. However, I see your point, so I’ll think about how to put it in the exposure tool.

Do you expect this to work in interactive mode only, or should this be something that goes into a pp3 or which can be applied in batch mode? If the latter, we would have to think about how to do it properly, to avoid having the same usability issues that the current “auto levels” has (i.e. if you have a tone curve set, the results are way off).

Users surely would like to be able to batch-apply it, though even if they can’t there is a workaround: I presume the generated curve will be very similar between two photos from the same camera with the same in-camera settings, so even if this tool has no proper batch mode, they can still open one photo, generate the curve, and then apply this PP3 to all other photos.

Please see Ideas for a default profile to produce predictable "camera-like" output · Issue #2055 · Beep6581/RawTherapee · GitHub

The matching is luminance only. Could a second pass calculate a color saturation curve as well. I am thinking of those photographers who set their camera mode to vivid.

I was just thinking the same thing, but it may be that the individual channels are matched… ?

We also have to think about auto vignetting-corrected ooc jpegs especially when shot wide open. That may lead to wrong results in the histogram-matching process.

yes, you can match the individual channels and produce individual rgb curves. if people are interested, I can post a modified version of the script. in my (limited) tests however this is less robust – it works well for the original image but not so much if you try applying the same curves to other images…

that’s something I haven’t tested – I didn’t even think about it to be honest :slight_smile: I would be surprised if the impact turned out to be big, but it definitely needs to be checked

I have been experimenting with the histogram-matching script by agriggio and the colour tone.
In the example below I have loaded the raw image, set the Profile to neutral, and loaded the pp3 file with the tone curve produced by the histogram-matching script. This produced a very good luminance match to the camera jpeg, but the skin tones were reddish and a bit over saturated.

I always set my Nikon D7000 to the the neutral picture setting (as opposed to Portrait or Vivid ect.)
So I tried setting the RT Color management Input Profile to “Nikon D7000 camera Neutral.dcp” and turned Look-up table on, Tone Curve off. The only other setting change is the Lens Distortion profile is set to auto.

This produced a very close color match. Previously I have not found the Nikon sourced .dcp files useful, however with the correct luminance curve, they seem add the required color corrective. The image on the left is the camera jpeg embedded in the raw file displayed using gThumb, on Ubuntu Linux.

Here is an example-

@David_Wilson I haven’t checked @agriggio’s script but I am pretty sure that histogram matching is a global operation. Skin tone is likely the first thing people would notice that is off. The skin needs to be masked away and edited separately for the time being, until @agriggio does some more wizardry.

@afre the original script matches on (srgb) luminance only. here is a version that can work also on individual channels:
histogram-matching.py (7.2 KB)
use -m RGB for that.
as I wrote previously, the results I got were far from spectacular though…
also, if you have scipy installed the new version can take advantage of that to (try to) produce better curves

Afre,
I think you misunderstood my point. The histogram-matching did the global operation with the luminous tone curve. I was trying to say that that I only needed to apply the ’ Nikon D7000 camera Neutral.dcp’ adjustment to the skin colour to get a very close match to the original camera jpeg. My point was that this required only two simple operations.

@David_Wilson Just thinking aloud that histogram matching can shift colors in an undesirable fashion, which can make skin color unpleasant.

@agriggio I think changes in luminance can still mess up skin but in more subtle ways. Thanks for exploring people’s ideas from time to time :+1:.

absolutely. just change the tone curve type in RT and you will see (quite big, sometimes) changes in hues as well
tbh, this was just an experiment on my side and I was very surprised by how well it worked for me. I expected much worse given the simplicity of the approach. but sometimes simple is enough :slight_smile:

Yes, keep it simple :sunglasses:. Reminds me of how people have to apply special makeup to look good on TV (or on stage), especially back in the black and white days.

gThumb isn’t color managed image viewer => the same image will look different if you’re using color management in RT.

Does it work also on the RGB channels, meaning on the luminance also?
Or does it just work on the RGB channels?

It will produce 3 tone curves for the R, G and B channels respectively, i.e. the output pp3 will have the “RGB curves” activated, without changing the tone curve in the exposure tool.

Awesome thank you!! :slight_smile:
It is exactly what I asked for here:

I wasn’t aware of that, but you’re welcome :slight_smile:
Honestly though, the results aren’t that great most of the time… but maybe you’ll have better luck.

Very, very interesting thread. I’ve already put ‘histogram’ and ‘cdf’ operations in my img program to get data to play with in a spreadsheet, but I’ll not have more time for a bit until we get past a house crisis (remember, having a house is having a hobby… :slight_smile: )

I don’t know how Nikon, for instance, packages all the operations in their profiles. Luminance is pretty straightforward, tone curve. Saturation is another thing, may not be capture-able in the histogram difference. Sharpening is obvious, that won’t show up well in the histogram.

I’d surmise you can probably find all of the OOC JPEG settings somewhere in most cameras’ raw files, and their corresponding PP software assembles all them and applies them with an operation equivalent with the in-camera firmware. Luminance is probably the only one of these that can be reliably reconstructed with histogram matching.

That said, what I’m considering (you really do need something to think about when you’re crawling around under your house…) is a separate mode of my ‘blackwhitepoint’ tool in rawproc that, instead of contrast-stretching, applies histogram matching using whatever JPEG I can pull out of the raw file. This would allow using histogram matching to not only adjust the difference in luminance from a ‘neutral’ to camera setting, but also to scale the linear image, do both in one operation.

@agriggio, right now I subscribe to GPL V2 for rawproc, but I’d encapsulate the algorithm and ascribe it to GPL3 or later, per your declaration.

Okay, back to the dirt…

feel free to use GPL2 if you prefer, no problem on my side – I’m not very picky about that :slight_smile: