Which Input Profile to choose?

Sorry for the long text, but I would like to describe my request as clear as possible, to avoid missunderstandings.
I’m relatively new to RawTherapee and a little bit confused about it’s Input Profiles. But at first some infos about my working methods, for a better understanding.
I know very well about color management for about 4 years. When I was working with Lightroom in the past (until 2017) I even created my own camera profiles (DCPs) with Xrite stuff. For each shooting or given light condition a seperate one. But over time I stopped doing so, because it wasn’t worth the effort in relation to the benefits…
Since last year I’m working with a custom UniWB setting and ETTR method, which increased the quality of my photos a lot. Together with the UniWB setting I put a custom Picture-Control setting to the camera, with every value set to zero and a custom “anti-tone-curve” to neutralize (or linearize) the camera’s internal used “RAW to Preview-JPG curve”. (To have a close as possible matching RAW-Histogram at the camera’s LCD.) And while I was working with Nikons Capture NX-D the last 2 years, I didn’t had to mind about Input Profiles, because there was nothing like that. So far so good.
But now, with RawTherapee, it’s a diffent story. I could choose whatever I want as a Input Profile. Which makes things not easier…
As I would like to have a starting point in RAW-conversion, which is neutral or flat or linear as possible, I’m trying to find a fitting profile now. At first I tried RawTherapee’s internal camera-specific profile without any other options activated below it. Result was a clipped red channel, which wasn’t clipped in the source file (as RawDigger told me).
Then I fiddled around with the additional options (base exposure, base table, “look”) but the red channel still kept clipped, even more. Then I tried the matching camera profile from Adobe’s DNG-Converter. At first with no additional options activated too. Result was better (Histogramm more neutral) but red channel also a little bit clipped. Then I activated base exposure below and so the red channel stopped clipping while Histogram went even more neutral.
So I was stumbling around, tried “no profile”, “dcraw only”, this and that… With just more and more confusion. Photo looked once more green or blue, once darker or brighter, once more or less saturated, once clipped or not…
(Btw. I still kept the tone curve option within the profiles deactivated, because of neutral as possible starting point.)
So now my questions are:

  1. Which Profile to choose? None? Dcraw only? RT’s internal one? Adobe’s?
  2. Which additional option to choose? And maybe why.
  3. What effect has this “Look”-Table?

I hope that someone around here can lighten my dark a little bit.
Thanks for commenting.

Regarding question #1, the most important thing the camera profile needs to do is to completely encompass the camera’s spectral response. Profiles have the information to work on two distinct things: 1) color, and 2) tone. Color is what I’m referring to in “encompass the spectral response”; tone is about what it would take to push the pixels’ energy level measurements around to be different than what the camera measured. So, to be complete, you want a camera profile that encompasses the camera’s ability to measure light with respect to representing color, and does NOT modify tone.

To not modify tone, depending on the profile type, you may be able to just not put in the tone curve or LUT. In ICC profiles, both must be present, but one can specify a gamut tone curve of 1.0 to nullify the operation.

In my simple mind, that’s all I want from my camera profiles, because I want to mess with tone separately to my own whims, and let the display or output transforms to do the tone thing the specific medium requires. But there’s a lot written and practiced about “look” camera profiles, which incorporate a non-linear tone curve. This to me is mixing metaphors, and I think it confuses things greatly.

I’ve come to think of the camera profile as additional metadata for the raw image, as essential as the width and height dimensions to the interpretation of the stream of bits the camera belches. So, for color, it’s those nine numbers that represent the reddest-red, greenest-green, and bluest-blue the camera data can represent, and for tone, NOTHING, because we consider the camera measurements as linear in magnitude, the starting point for any subsequent tone transform.

To your second question, bear-of-little-brain here says, None. Stick to the color part.

To your third question, this is another of the confusing aspects of profiles. With respect to color, in some profiling schemes the nine numbers can be replaced with a lookup table that does the same thing. But now, the table allows one to change individual values to “scooch” around the color characterization. This can be a powerful way to work with extreme colors that don’t translate well to smaller color gamuts, but if you change them too far from the surrounding lookups, the discontinuities can begin to show themselves to detriment. A lookup table can also incorporate tone transforming, so it’s a very powerful way of working with the camera image. But again, it confuses bear-of-little-brain, so I don’t spend much time working with such.

Your questions resonate with me, as I’ve been picking about this topic for about a year now. What I’ve wrote should be taken with a grain of salt; I hope others more knowledgeable will chip in…


Thanks a lot for your detailed explanations! And expanding my knowledge :+1:
So it would be better to assign any profile than no profile. But without activating any additional option(s), which influences the tone (tone curve, base table, “look”-table). But what about baseline exposure? Would this be “safe to use”? Or does it also affect the tone? In my opinion baseline exposure does the same like the exposure compensation slider. Just to match the brightness of camera’s JPG. Or am I wrong assuming this?
Furthermore I still don’t know which profile to choose. I would prefer the most accurate one, of course. But how will I know which one this should be? The RT’s internal one (auto-matched)? Or the one extracted from Adobe’s DNG-converter? I already compared them both with a given landscape photo - blue and green channels have exactly the same shape, size and position in working- or output histogram. But the red channel is more “boosted” in RT’s profile - so that it already clips. Not so with Adobe’s profile or within RawDigger… :dizzy:

If the profile has a base table, you definitely want to use that. That is the LUT that does the actual color correction, i.e. it’s supposed to give you the most accurate colours. If you don’t want any custom look that might be baked in the profile, then simply disable the tone curve and the look table.


Actually, a camera profile of some sort is needed to get to colors you will enjoy. For instance, the conversion to sRGB for saving to a JPEG requires the camera profile as the input. For grins, I saved a recent image with all my standard processing, except I just assigned a “no-tone” (that is, linear gamma, 1.0) sRGB profile to it. Looks like this:


So, what the raw processor thought the camera’s spectral response is, is sRGB, which only has a fraction of the range the camera really had. So, all those extreme colors were lost when the sRGB JPEG was made. Here’s what it should look like:

This image used the regular old dcraw-style color primaries from the RawTherapee camconst.json file.

I’ve found the simple dcraw/camconst.json color information works fine for the majority of images. Where you start to see problems is with really extreme colors that are the predominant component of the image, where you might want to see finer gradations. This is because the conversion from camera color space to, say, sRGB with appropriate rendering intent leaves most of the “smaller” colors alone and saves its attention for out-of-gamut colors. There, the transform gonkulator has to make rather hard decisions about how to translate them to within the limits of sRGB, and the really extreme colors can get lost in that translation.

I’ve particularly played with ways to handle the extreme blues I experienced with a particular local performance venue’s LED lighting. Making profiles with dcamprof shows promise, and from what little I’ve read about how folks are using the new color balance module in darktable, that might also have promise.

Thing is, you want to start in the raw processor with an internal image that still has the camera’s best effort, and the simple dcraw-style primaries should be sufficient for that. IMHO, YMMV, and all that…

1 Like

Thanks for your comment. Good to know that.
Reffering to RawPedia:
“DCP Base Table: This enables the DCP “HueSatMap” lookup table which is used to add non-linear corrections on top of the basic matrix. This is an advanced user setting and unless you want only the pure matrix result should leave it on.”
Hmm, do I want pure matrix result? I don’t know now.
So I will do some additional comparisons between RT’s and Adobe’s profile with nothing else activated than base table in both… (And further comparisons against RawDigger’s interpredation.)

Thanks again for your examples! Now I understand the connections between these profiles :+1:
I will include that dcraw profile in future comparisons…

After all it seems like another kind of “Many ways lead to Rome.” and personal taste (just like with the sharpening theme)… Previously I thought this matter would be more specific, not just like “You can do what you want, don’t mind about profiles, as long as you are happy with your results…” 🙋

1 Like

Hello again.
After some further experiments with input profiles, I finally understood the dependencies and effects of them, so far! In the beginning I didn’t realized that there’s an permanently conversion-connection from input- over working- to output profile, which misleaded my mind in wrong directions. Thought that the conversion to (output)sRGB takes place during export to JPG, not already before. So it was entirely logical that in my given example-photo the red channel got clipped by assigning an input profile, respectively the base table of such one. As this channel was fitting completely in sensors RAW table and ProPhoto profile, but simply not in sRGB output profile. Means that source data is still existing, but just doesn’t fit within the sRGB color space?!
So am I right supposing the process, with NO input profile assigned, looks like this:
open RAW file in Editor → translation from pure RAW data to working profile (ProPhoto) → translation from working profile to output profile (sRGB) → translation from output profile to monitor profile → display output… (with maybe “wrong” colors)
And the process with ACTIVATED input profile (and base table) like this:
open RAW file in Editor → translation from pure RAW data to input profile (correcting colors) → translation to working profile → translation to output profile → translation to monitor profile → display output… (with “right” colors) ???

Some confirmation or correction of my assumptions would be nice.
Thank you!

The pure matrix result may have errors for some colors. The HueSatMap (this is the DNG/DCP terminology, I think RT calls it the base table, I’d need to recheck tonight) attempts to correct for these errors.

The tone curve is “baked in” but in many cases you may want to use RT’s own tone curves. I usually do, and hence disable the tone curve.

The look table attempts to correct for certain hue shifts that may occur with Adobe’s standard tone curves, so if you use it with an alternative tone curve you may cause issues. DCamProf


Not quite. If you select “No profile”, then the data is already assumed to be in the selected working space. In other words, there’s no “translation from pure raw data to prophoto”, the input is simply assumed to be already in (say) prophoto. Usually, not what you want…

The input profile is what enables the translation from “pure raw data” to the working profile.



It is converted, while you’re processing, to be displayed. Internally, the software works on a high-bit-depth image that has gamut corresponding to the chosen working profile. But when that image is to be displayed, its converted to whatever bit-depth is handled by the display, and the colors are crunched down from the working profile gamut to the display gamut. This happens (mostly) every time you make a change: add a tool, or change its paramters. Otherwise, you’d be looking at colors that look like the first image I posted previously.

There’s a diagram in this article that might be helpful:

Thanks for your hints. I don’t wanna use Adobe’s profiles in future, used them only for testing. So I’m gonna stay with RT’s profiles + base table, nothing else. Seems most accurate to me.

Ahh, okay. So I was not that wrong at all.

Thanks again for further explanations and useful Article!
Too bad that the output device will still be the limiting factor. So you can have very fine 16bit-HDR-super-trooper-detailed-ultra-quality-mega-image as input, but only will see a downscaled excerpt of it at your 98,9% sRGB 8bit display, fed from your 8bit graphics-adapter. Even less with your consumer printer. Hahaha :clap: :raised_hands: :sweat_smile:

And thanks to all of you for given me enlightenment and expanding my knowledge! :+1:

May I add some thoughts? I think I’m a bit dense now, and some ideas got mixed in my brain, so I’m going to explain how I understand RT works, and if I’m wrong, please, somebody enlighten me too :smiley:

To begin with, you need to set your input camera profile (the Input Profile) to essentially tell RT which primary colors your sensor uses. You can let RT decide the proper primaries to use (with Auto-matched camera profile), or you can tell which profile to use with Custom, and pointing to the appropriate profile archive.

That input camera profile information is used to convert your image colors into the working color space in use by RT (the Working Profile). That working profile is always linear (that is, with gamma=1.0). Some say that a big enough color space (like REC2020) is better than a huge one (like Prophoto or ACES), unless you have a really good reason to choose the later. Nevertheless, that is a subject of endless discussions, so choose whichever you like the most.

Now you start editing your image, and RT updates the changes on your screen by converting the working image into an image suitable to show within the capabilities or your display: you can think about it as making a copy of the internal image, converting it to (typically) sRGB and showing it in your display. The internal image is never converted at that stage.

When you finish your editing and you’re happy with the results, after you hit the export button RT starts to finally making the necessary changes to the internal image, and one of the last steps is permanently converting the image to the output profile.

And you may say: Wait! Wait a moment! Where does RT has any setting to know which profile to use when converting the working image into a display image? Yes, that’s not set in the Color Management tool… It is set in Preferences>Color Management>Monitor>Default color profile. It’s the 4th color profile that you will need for a color managed workflow.

Is all of this correct? If so, does it clarify how the color management works (at a user level)?

Pretty good; let me offer a couple of clarifications:

“Auto-matched camera profile” I think is really “Auto-Matched Tone Curve”, if what I think you’re referring to is correct. If so, that’s a separate tool that compares the raw image to the embedded JPEG to make a tone curve to match the camera’s tone processing. It’s about tone, not color…

RT will automatically use a dcraw/camconst.json primary set if available, otherwise your statement about “Custom” applies.

Conceivably, one could use a non-linear working profile, and call that the “tone curve”, not use filmic or the other more-appropriate tools. Bear-of-little-brain (me, if not already apparent :smiley: ) would rather use the best tool for the job, currently for my use, filmic. So I go along with your assertion, use a linear working profile.

That said, I haven’t experienced any downsides doing all my raw processing in the camera space, and only doing the conversion for display/file output. I guess my camera profile is well-behaved…

I think you’ve pretty well got it. Do some playing around with it, see how things are affected. To do this, you’ll find a large selection of good ICC profiles here:

When I want to use a working profile, I use @Elle’s Rec2020-elle-v4-g10.icc profile (g10 means ‘gamma 1.0’ or ‘linear’). I also use her sRGB profiles for my file exports.

1 Like

FWIW for Nikon D610 and Z6 I got best colors and tone using Adobe .dcp profiles. Caveat: I don’t like to spend much time and efforts editing photos. I need something simple and reliable to get natural and good looking results.

1 Like


I would like to know why you are doing so?! Are RT’s profiles (ProPhoto as working profile and RTv4_sRGB as output profile) not “good” enough? Are Elle’s profiles more “precise”? Or what are the advantages? :v:

Thanks for your answer Glenn :smiley:

I was referring to Auto-matched camera profile:


where RT selects the appropriate primaries for your camera.

As seen the screenshot, there’s another setting (Custom) where you set the precise profile to use. But now I don’t know what is the fallback if you select Custom but doesn’t choose any profile or the profile is broken. I guess it would fallback to Camera standard, instead of Auto-matched.


Hi :v:

That made me confused too :wink: But you can find it out by comparison - with switching to “No profile” or “Camera standard” while watching the Working Profile Histogram and/or the Preview Picture at the same time.

It’s not just appropriate primaries. Auto-Match Camera Profile is where the DCP profile in your data/dcpprofiles directory has a manufacturer and model that matches the manufacturer/model in the file’s metadata. Nearly every DCP profile has a HueSatMap (aka base table), not just color primaries for dual illuminants.

I believe Camera Standard is what happens if there is no DCP profile but there is color matrix data in camconst.json - effectively the same as a single-illuminant matrix-only profile.

Use Embedded, if possible, is seen for DNGs - I’m not sure if any other raw format has embedded profile data. Be warned - a LOT of DNGs have very broken embedded profiles.

I don’t think you can choose “nothing” and have the radio button stay on Custom? And if you choose a broken or inappropriate file, you get garbage colors.

1 Like

I haven’t looked, but I’d bet RT and Elle used the same numbers, or close.

A working profile is less about being ‘precise’, and more about being ‘big enough’ , and ‘well-behaved’. @Elle has a good article on that:

Articles and tutorials on Color management, scroll down to C.3

Converting the working space data to sRGB AND saving it to JPEG WITH the sRGB profile does two things: 1) it gives color managed viewers the information to convert the image colors to the display profile, and 2) for non-color-managed viewers, prays that the display is something close to sRGB.

The word ‘precise’ in this endeavor really is only pertinent to the characterization of the input and output devices. And, (Mister Grammar Fairy here) the better word to use might be ‘accurate’… :smiley:


Too many things inside a profile, to my taste. When I’m working with my own camera images, I always use a custom icc input profile I made myself. And judging by comparison between the real subject and the colors on my display, it works quite nicely.

When working with Playraw images…, well, that’s another story :wink:

1 Like