How Your Camera and Image Processor Determine Colors

Some time ago, Roger Cicala asked me if I'd contribute technical articles to the Lenrentals blog. It's taken me a while, but I got started a few weeks ago with a post about how in-camera focus bracketing systems work. They've just published one one color and raw files.

www.lensrentals.com/blog/2023/03/how-your-camera-and-image-processor-determine-colors/

While this is a technical article, I've tried to keep it at a level that most photographers can understand. It's certainly not the article I'd write for PS&T, and it's nowhere near as tough a slog as most of my blog articles on color. Still, I expect that there will be questions and comments. I'm not a fan of the comment system that Lensrentals has chosen, and am unable to respond to comments there. But I'd be happy to take questions and listen to comments in this thread.

Thanks,

Jim

the thing is that a lot of different people visit various sub-forums here including PS&T, so I will steal it for an unofficial FAQ over there w/ a note that it is intended for "entry-level to mid-level" audience ...

OK. More mid than entry. I'm sure I'll get some corrections in those areas where I've oversimplified.

Thanks Jim, looks like an interesting read but I've only had the chance to scan it quickly so far.
I didn't see anything in it on the Bayer matrix/Foveon sensors etc. Which is what I was expecting it to show, but IMO it actually proved more interesting for not getting bogged down in that.

I shoot with full spectrum converted cameras quite a bit & find it fascinating how the UV & IR sensitivity of the camera can drastically change some colours. Even having a replacement hot mirror that doesn't quite match the OEM version can introduce occasional colour shifts. :)

IR pollution has long been a real problem in color photography. I remember a Kodak engineer telling me about a photograph sent to the company by a wedding photographer. It had been shot on color negative film. The subject was the men in a wedding party. All were wearing black tuxes. In the photograph, none of the tuxes were black, and none of the tuxes were the same color. Aniline dyes tend to ge transparent in the IR region.

I mentioned both. The article is written in such a way that most of it applies to both.

Thanks a lot for writing and posting it, Jim. Your contributions are very informative and always a must-read!

"

"
Using libraw/dcraw_emu as a converter did not give me expected results when using the version included with Debian Bullseye. I built a newer version from source that knows how to read the metadata that my camera puts into the raw file and I like the results better.

/home/jrm/src/libraw2021dec18/LibRaw-master/bin/dcraw_emu -v -disinterp -T -6 IMG_3609d.CR3
gmic IMG_3609.CR3.tiff keep[0] display_histogram 800,600,65536,0,65535,0,"cut(i,0,65535)" normalize[-1] 0,255 output[-1] IMG_3609.CR3.hist.png ; echo "gmic histogram"
gm convert -verbose IMG_3609d.CR3.tiff IMG_3609d.CR3.png

/Users/jrm/src/libraw/LibRaw-0.20.2/bin/dcraw_emu -v -disinterp -T -6 -g 2.222 4.5 IMG_3718.CR3
/opt/local/bin/gmic IMG_3718.CR3.tiff keep[0] display_histogram 800,600,65536,0,65535,0,"cut(i,0,65535)" normalize[-1] 0,255 output[-1] IMG_3718b_hist.png ; echo "gmic histogram"

/home/jrm/src/libraw2021dec18/LibRaw-master/bin/dcraw_emu -v -T -6 IMG_3609.CR3

Canon DPP 4:

Have you tried
/home/jrm/src/libraw2021dec18/LibRaw-master/bin/dcraw_emu -w -T -6 IMG_3609.CR3

Thanks, I had guessed "-w" was default for dcraw_emu

This seems to illustrate my objection to "There is information in the raw file metadata that raw developers can use to convert the image data to color images, but good raw converters ignore that information" since a raw converter cannot know the camera white balance unless it is able to read it from the metadata.

Here is an example from an older version of dcraw_emu that does not know how to read the metadata. It also includes black borders from the top and left instead of clipping to what was seen in the viewfinder as it would if it could read the metadata.

ln -s IMG_3718.CR3 IMG_3718w.CR3
/Users/jrm/src/libraw/LibRaw-0.20.2/bin/dcraw_emu -v -w -T -6 IMG_3718w.CR3
Processing file IMG_3718w.CR3
Writing file IMG_3718w.CR3.tiff
/opt/local/bin/gm convert -verbose IMG_3718w.CR3.tiff -resize "25%" -unsharp 0x1 -define 'jpeg:dct-method=float,jpeg:optimize-coding=true' -interlace line -quality 94 IMG_3718ws2.JPG
IMG_3718w.CR3.tiff TIFF 8352x5586+0+0 DirectClass 8-bit 267.0Mi 0.210u 0m:0.204095s (218.0Mi pixels/s)
IMG_3718w.CR3.tiff TIFF 8352x5586=>2088x1397+0+0 DirectClass 8-bit 0.810u 0m:0.814386s (54.6Mi pixels/s)
IMG_3718w.CR3.tiff=>IMG_3718ws2.JPG JPG 8352x5586=>2088x1397+0+0 DirectClass 8-bit 2.0Mi 0.160u 0m:0.358679s (124.0Mi pixels/s)

It appears that I was wrong and that "-w" does more what I expect when I use a new enough version of dcraw_emu to read the metadata. Thanks again.
/home/jrm/src/libraw2021dec18/LibRaw-master/bin/dcraw_emu -v -w -T -6 IMG_3609w.CR3
Using 8 threads
Processing file IMG_3609w.CR3
Writing file IMG_3609w.CR3.tiff

default is the same as in the original dcraw, for the sake of compatibility, "Daylight WB". If CM is absent (the model isn't supported), this can be awfully off. For unsupported models, where -w isn't known too, -a may be a viable option.
For many unsupported cameras we still will be able to read white level, black level, and white balance table.

You are very welcome.