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 :-)))).
My nikon D750 is the only “serious” digital camera I own. That said, since I’m playing with HaldCLUTs, I’d like to know, from a fuji raw converter perspective, and from an RT perspective, what settings must be applied for “truly” neutral tone reproduction.
in the raw converter (“powered by silkypix”), what’s the color setting you need to choose on the shots you used for your dcp to have the best “out of camera” neutrality?
in RT, same question. If you’ve selected an auto-matched camera profile, do you need to only tick the Base Table checkbox to get that neutrality?
EDIT:
2023-05-24:
(1). in Fuji raw converter (silkypix-based), to achieve neutrality (more or less)
a. Tone — can be set to “standard” instead of “average contrast”
b. Highlights controller — offers a “Dynamic range” section, which can be set to zero
c. then, you can play with the exposure bias slider.
d. Camera setting — choose faithful natural or faithful standard, they’re quite similar in this case.
Side note: I don’t have a procedure for Nikon NX Studio, yet (i.e. Nikon’s Neutral, Standard and Flat Picture Control profiles all have tone curves baked in them)
(2). For RT, use an auto-matched camera profile, with only the Base Table enabled. Simple.
Last time I had a running copy of RT, it had a Neutral processing profile which did just that… That’s not the same as the input profile; if you do nothing else, I think RT just defaults to the camconst.json color matrix for your camera.
I am sorry: I do not really understand what you are after
Words like “Natural”, and “Faithful” as used in the camera settings you
presented above are rather vague. (Not to talk about the “Faithful Standard” color,
which actually implies an “Unfaithful Standard”, as well.)
I wonder whether you mean something like “100% colour match”?
I.e. your object has a certain colour, let us call it XYZ. You take
a (RAW) photo of that object, and you would like to develop it so
that the object is presented on your monitor exactly as XYZ.
Is that a correct assumption?
(Then, perhaps, you would also like to distribute your image
and have it look exactly as XYZ on every monitor all over
France? And/or print the image in offset, litho, intaglio, screen,
&c &c &c — still looking like XYZ…?)
The closest I’ve come to something like that was: My first color management experiment
By all means not perfect, but pretty good for a non-professional set-up…
this is Fuji’s own take on colour, in the raw converter they provide. Do you happen to have this piece of software? else, what would be the in-camera profile you would choose in order to achieve neutrality (which I would define here as faithful greyscale gradation)?
I’m not sure I want to have such a firm constraint. Maybe my line of thought translates into this, but I don’t know.
The setup I’m thinking of: say I take a picture of a colorchecker in D50-like (or D65) conditions (essentially having it outdoors with natural light, without reflections, glare, etc.).
→ Provided the exposure and white balance are accounted for, 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), on screen?
So for the tone ramp a linear profile and good exposure would be faithful to that as you wouldn’t introduce any large or biased compression…color could be shitty or way off and still meet that criteria in the profile so you need a decent matrix for color. You could use the Adobe Profile editor to make a linear DCP for your camera and tweak color as well
after picking the WB on the grey card exposed to the sun, I adjusted the exposure so the brightest patch would get to L = 97% approximately.
The other grey patches fall pretty well where they’re expected to, in my opinion (not talking about the a and b values, though).
the processing profile is derived from neutral.
→ this seems to achieve neutrality in RT.
A few minutes before that, with a different lens and orientation, the sun was behind clouds. With a similar processing approach, I get some compression in the shadows (i.e. they appear lighter than they should, but that could be due to the hand-held and imperfect setup )
If I understand my D7200 correctly, when shooting in RAW you don’t need to set up anything in the camera. Everything you can switch on is used only for the in-camera development of the JPEGs. Therefore the input profile of RT is just used to map the values of all four sensor channels to the rgb values of the corresponding pixel.
Back to the optional Tone Curve and the Look Table: for my D750, I think I found something relative to its origin.
That does not clarify what these two options, in this case, are supposed to do. What “Look” are we talking about? What is that Tone Curve required for? (i.e. when is it applicable?)
Since this git + google groups discussion mentioned in my previous post is almost 10 years old, I doubt I’ll get an answer about the intent of the attached look table (for the D750). But there was some debate pertaining to the quality / usability of the provided color checker shots, back then (perhaps @jdc remembers?). This is getting off topic: should I provide my own shot so it can be turned into an RT-bundled .dcp profile?
@nonophuran
Yes, I remember, or at least approximately…
The problem of the calibration charts is of 2 types (at least)
these calibration targets are most often close to sRGB or even a little more, especially for greens, this is mainly due to the printing of these targets, which limits the gamut. Isn’t it paradoxical to have a “working profile” in Prophoto (or Rec2020) and use a target in sRGB. We extrapolate a lot and the errors are significant…
the second point is whatever we say, whatever we do the calibration system is good for an illuminant, the rest comes from empiricism. In this sense, ICC profiles are “finer” than DCPs, but more complex to develop, and even more constrained by the illuminant
Another point to be mentioned is the nature of the grays (for example on the Colorchecker24), putting Pick in the belief that it is a good balance of whites comes up against 2 false inferences.
the grays are not pure greys…so we do the WB on one color, certainly close to a gray…but
believing that the variation of the law of white balance is linear is probably wrong
And
the color matrix is in D65, and probably tainted with error… The illuminant is not pure, Observer it is tainted with doubt.
I remind you that it is possible to correct the colorimetry with “Abstract profile” (even if this module is controversial… that’s an understatement), by acting at the end of the process (see Rawpedia).
The tone curve has the same roll as any tone curve…to massage the data in to a way the manages contrast more the way we perceive it… the Look table can be applied as noted in the specifications for DCP profiles as noted here
"There is also a LookTable, which is exactly the same as a HueSatDelta Table, but is intended to be applied later in the processing pipe, “after any exposure compensation and/or fill light stages, but before any tone curve stage”
During creation the DCP spec is often used and abused as is evident from all the complaints about various DNG implementations…
There is a lot of good information around DCP files here which may clarify some of your queries including a text file that you can just read through…
I think I understand the problem the way you described it. It’s especially obvious in the realm of colour negative film inversion: one grey spot is never enough, however close to neutral it might be.
In your opinion, with all those limitations in mind, is a new attempt (with a 24 or 48-patch card) for the D750 required, or is the biggest achievable difference too small to even care, because of the nature of the targets and the realistically achievable shooting conditions?
Thanks again!
I think I get the Tone Curve concept. Thanks for the link, too.
My main point was, for the specific example of the Nikon D750 DCP currently shipped with RT, to understand from whence this look came, as this was far from obvious in the history of its making, cf. github discussion mentioned supra.
I can’t recall now without full review but you may have mentioned about starting points and JPG and that’s why you are using DCP as a preferred option?? Or that’s wrong. But I hacked this to work with my Spyder checker and It actually gives a pretty nice result. Maybe not color accurate as some but a pretty nice match to JPG… GitHub - pmjdebruijn/colormatch: ColorMatch
We have to stay very humble… I don’t know. Doing what you suggest is better than nothing, but you have to remain pragmatic by understanding the limitations.
The colorimetric system has more unknowns than equations and all the tools and concepts: ICC profiles, DCP profiles, notions of primaries, illuminants, etc. are approximate models.
For example, the white balance on which I work (temperature correlation) supposes a certain number of sidestepping of reality. To think that it could be otherwise is a utopia.
But there again, it is better that than nothing…provided you know the limits.
