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…
@agriggio
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.)
@ggbutcher
Thanks again for your examples! Now I understand the connections between these profiles
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…” 🙋
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:
@Entropy512
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.
@agriggio
Ahh, okay. So I was not that wrong at all.
@ggbutcher
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
And thanks to all of you for given me enlightenment and expanding my knowledge!
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
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 ) 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.
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.
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?
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.
That made me confused too 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.
Regards
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.
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’…
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
Gosh, this topic is still very dense, to me. I believe I have several misunderstandings and many questions.
I think the Rawpedia section about Color Management deserves some review with the elements discussed here (and your valuable articles @ggbutcher),
same goes for the tooltips in RT.
Apart from that, I primarily use RT to edit photos taken with a Nikon D750. And I have two use case scenarii:
scan and invert colour negative (and some positive) film, backlit with an LED panel, in the film negative module
take normal photos and process them
And recently, I’ve been trying to make some HaldCLUT files for the film simulation module.
So for each case, I need to carefully think about the Color Management section.
Negative film: since I’ve made a camera profile (with an embedded tone curve) with dcamprof for my LED light source, cf. how to create a dcp for an artificial light source I tick all checkboxes (tone curve, base table, look table)
Normal photos: I’m kind of confused by the tone curve and look table options. I’m not sure what I’m allowing to be baked in, honestly — for instance, the “tone curve”, I’d love to understand from whence it comes, whatever it is. Does the .dcp for my camera contain one?
Now, say I take a picture of a colorchecker in D50-like conditions. What are the Color Management settings in RT that should be applied to get the expected gradation on the grey scale (other than initially doing the WB)?
Sorry for reviving this thread and thanks for reading me.
EDIT:
2023-05-24:
(1). colour negatives were not discussed, yet.
(2). simple answer: for a neutral basis (proper gradation and colours), only use the base table of the profile that’s shipped with RT. The Look Table and Tone Curve options can have obscure origins, depending on how the .dcp was made in the first place, so you don’t really know what you’re applying.
hey, @Claes, hi!
thanks for these pointers, I had not seen that hefty add-on article to the Color Management section.
I can only sigh when I see there’s so much to read and actually understand, to be able to answer to my questions xD
Do you believe there’s enough material there to answer to my last point about neutral tone reproduction?
Thanks again, for being so responsive.
Do you believe there’s enough material there to answer to my last point about neutral tone reproduction?
Non :-(((((
It depends on how the .dcp for your camera has been made,
I have managed to find two .dcps for my camera (X-T4) – one
includes a tone curve, the other does not. If you have an X-T4
camera, I can gladly send you my .dcp :-)))).
) 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.
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.