Okay, I’ll now go out on a bit of a limb here attempting to describe things with which I’m only superficially familiar, and in the process I invite others who can “speak snake” about Planck, black-body and all that to straighten me out…
“Temp/tint” in raw processing is an attempt to tie the energy aspect of light to something that can be manipulated in post. While the RGB multipliers are the direct manipulation of the RGB=encoded values of a digital image, they can still be tied to the particular temperature of the captured light. The intuitive notions of “warmer” and “colder” with respect to the “color” of light is very mappable to a single slider and correspondingly to the effect upon the image. If you regard a chromaticity diagram with the white temperatures plotted, you’ll see an arc that can be somewhat readily translated into temp2whitbalance() and whitebalance2temp() functions.
“Tint”, if my understanding holds, is a manifestation of the rather obtuse characteristics of non-uniform light such as fluorescents. Their white is more a product of tricking the eye-brain with some combination of wavelengths rather than a continuous coverage of the spectrum like tungsten produces, and the white they produce doesn’t always fall on the temperature arc. I think of tint as a departure from the temp arc to accommodate such weird light…
Definitely “for what it’s worth”, probably not much…
Out of curiosity I ran above dcraw command.
I noticed that R6 CR3 doesn’t have Camera multipliers
What does it mean ?
Canon R6
Camera: Canon EOS R6
ISO speed: 500
Shutter: 1/83.0 sec
Aperture: f/6.4
Focal length: 60.0 mm
Embedded ICC profile: no
Number of raw images: 1
Thumb size: 5472 x 3648
Full size: 5472 x 3648
Image size: 5472 x 3648
Output size: 5472 x 3648
Raw colors: 3
Filter pattern: RG/GB
Daylight multipliers: 1.000000 1.000000 1.000000
Canon 7D
Camera: Canon EOS 7D
ISO speed: 6400
Shutter: 1/24.7 sec
Aperture: f/4.0
Focal length: 26.0 mm
Embedded ICC profile: no
Number of raw images: 1
Thumb size: 5184 x 3456
Full size: 5360 x 3516
Image size: 5202 x 3465
Output size: 5202 x 3465
Raw colors: 3
Filter pattern: RG/GB
Daylight multipliers: 2.184862 0.935831 1.256838
Camera multipliers: 1913.000000 1024.000000 2194.000000 1024.000000
Whitebalance annoys me to no end. Generally speaking I want the colours to look like what my brain saw. Proper white balance eliminates the colour of the light that was crucial at the time of capture. Because of the way your brain adapts setting the colour becomes a moving target.
The problem of course is that reproducing what your brain saw is kind of impossible and dependent on a lot of factors.
Like so many things in photography, the white balance setting to make white look white is the “technically correct”, basic setting. After that, nothing obliges you to stay there. In fact, it’s not at all unusual to e.g. push the white balance towards warmer colours for portraits. Perhaps to get a better starting point to getting what your brain saw, would be taking two shots: one at automatic WB and one at “daylight” balance. That should at least give you a hint of which direction to go in.
As for the technical aspects: setting the whitebalance requires a red/green and a blue/green ratio to be adjusted (or red/blue and green/blue, but as the bayer matrix has twice as many green sites…), so only two multipliers need to vary. that’s why we only have two variables to adjust…
@ggbutcher While the modern light sources are “famous” for their weird tints, the “tint” is also quite useful in some outdoor situations, e.g. under trees or on a lawn to get rid of a green cast (not niwe on skin). Basically, you need two variables to adjust white balance (as you can keep the green mulitplier fixed at 1.000), and (in my experience) colour temperature covers most of the needs for outdoor photography, tint is sometimes needed in specific situations.
Back in the old days, we illuminated with the sun and incandescent lighting, which are both black bodies, more or less. So Correlated Colour Temperature was a useful concept, and we knew which gel to put in front of lamps to balance indoor artificial with outside daylight, or which filter in front of the lens would record artificial light on daylight film, and we knew what mireds were.
For still digital photography, colour temperature is a good thing to know about, but isn’t a critical control. Yes, we can control with CT plus “tint” or whatever the other dimension is called, if we want. But personally, I prefer to multiply RGB channels.
We only need to tweak 2 of the 3 channels, but we may want to avoid clipping, so that involves a little juggling with the numbers.
That is a remarkable piece of insight! I had never thought about this, but it makes a lot of sense. In a world of mostly-incandescent light sources, the concept of a “color temperature” would be all you need to correct naturally-occurring color casts.
“Tint” is then a digital graft on existing analog techniques, and should probably be interpreted as “whatever color cast that is not temperature”, more than a sensible measure in its own right.
(The third axis of the tristimulus invariably being “lightness”, and being kept constant for color corrections.)
Which begs the question what other useful color axes there could be besides temperature/tint, and whether they might be useful for correcting color casts.
Those aren’t Tinted I requested non-tinted, but finetuned samples. Finetune meaning usually that the requested temp for temperature preset (eg sunny, cloudy, shade etc) moves along planckian locus in smaller increments than between each preset.
Or the current case in some RAW software - there’s support for reading image data (thanks to libraw), but not metadata (needed for the multipliers) due to the exiv2 team worrying about patents.
That too, RT uses a heavily modified derivative and I assumed you were talking about that. I missed that he outright ran dcraw, I’m kind of surprised he got that much information out of it. I would have expected it to completely choke on ISOBMFF-based CR3 and not display any of the information he found…
I’m wondering if some distro is installing a symlink from libraw’s dcraw-emu to dcraw…
I’d surmise that as long as a raw format continues to use the same file organization with respect to the image data, that can be extracted with current logic. It seems to be the metadata that is tripping things up, and that becomes more important as other information is needed to process current raws, such as lens distortion data…
The thing is that CR3 has a (standard but documented) container format that was not in use when dcraw was last updated - ISOBMFF should be alien to any implementation of dcraw unless it’s a very hacked-up fork or libraw’s dcraw-emu
The biggest challenge of CR3 initially was that it had a (nonstandard and undocumented) codec used to store image data. In theory, once this hurdle was crossed, support for the rest should have been easy, but certain exiv2 developers have been highly unreasonable (citing fears of unspecified patents, even though the patent issues with MPEG-4 lie with the codecs and not the container formats, with AOM selecting ISOBMFF as the container format for AVIF being clear evidence there are no known patent concerns, even to organizations with piles of IP lawyers, for exiv2’s use case.)
The current official dcraw is version 1.478 dated 2018.06.01
However, the package on my system (Arch Linux) is called version 9.28.0, last updated 2020-05-19. It claims to get dcraw from the official origin: Decoding raw digital photos in Linux
Official development ended a long time ago. Dave may have added patches in the latter years but the more recent versions circulating have been modified and built by others. You may have 9.28s that are different from one another.
Ok, maybe. All I know is what I can see. The revision info is from Dave’s site, and the Arch repository says it is pulled from that same site. If someone else is handling it now, I don’t know.
There is an infinite number of useful color axes. Well, nearly infinite. For example, think of Lab, with one lightness channel and two colour channels, and the choice of colour channels is fairly arbitrary. From an image encoded in Lab, we could convert to LCH, then rotate the hue, and convert back to Lab, so the axes would be different. We could have chosen to make one axis significant: a colour we want to desaturate or whatever. After tweaking, we have to convert to LCH, rotate the hue in the opposite direction, and convert to whatever colorspace we need for viewing.
I requested non-tinted, but finetuned samples. Finetune meaning usually that the requested temp for temperature preset (eg sunny, cloudy, shade etc) moves along planckian locus in smaller increments than between each preset.