ethanshen wrote: Wed Oct 29, 2025 10:57 pm
What about white balance setting in the digital camera, does it matter?
For reproductive photos of color negatives, the white balance information stored as metadata by the camera is fully irrelevant. That is because we do not strive to create a color-correct version of the still-negative representation with the orange mask in place, but rather invert the frame and aim to achieve a natural rendition of the scene captured.
Of course, the light source makes a difference, and I’ve said before that at present I feel that anything more or less resembling daylight is going to be fine, whereas anything resembling tungsten lighting will require more processing. That’s not to say that it’s necessarily impossible; I just feel that the extra mile introduced by it is not one we must travel.
To clarify, I should also say that, of course, MakeTiff reads the white balance information included by cameras as metadata and transfers it into the TIFF file in a way that ColorPerfect can deal with, because in PerfectRAW mode — where the camera image represents the scene and is not an intermediate of a negative in turn representing the scene — camera white balance can indeed be used.
So the summary is: camera white balance recording for ColorNeg DC is irrelevant, while for PerfectRAW it can totally be used.
ethanshen wrote: Wed Oct 29, 2025 10:57 pm
Also, what about the choices of working color space in Photoshop?
I read somewhere else from Christoph that "the Pro Photo RGB color space is quite tricky"…
In the past, the whole RGB working space debate was something of a hold-up, let’s say. Folks wanted to use wide-gamut color spaces in ways that they weren’t really fit to be used. We tried to explain what they were, how they related to scenes captured on film, and why, particularly when working with scans, it made sense to use narrower gamut color spaces with ColorPerfect 2 instead.
All of that was one of the most difficult things for photographers to accept, and I suppose also to understand — to really get to the bottom of. Years ago, Dave said to me, “We’re not the color police, you know.” Meaning that while we hoped to make our users understand their choices, we didn’t want to orchestrate them. We weren’t trying to create some color dogma — and I’m not today either.
I thus decided to take this whole field out of the equation in ColorPerfect 3 by including suitable steps so that anybody can use any supported color space anywhere without it affecting the general operability of the plug-in. I also extended support a lot but not in MakeTiff yet.
For scans, that means a distinction between narrow-gamut and wide-gamut assignments still exists. In
ColorNeg SC mode, you can assign a wide-gamut color space such as
ProPhoto RGB to a scan, and ColorPerfect 3 will perform internal color processing so that the output becomes meaningful and consistent. When a narrow-gamut color space is assigned instead, the plug-in behaves just like ColorPerfect 2 did: the RGB primaries of the narrow-gamut color space directly form the final image’s RGB, as encoded in the negative itself — just as they would appear in a projection of that negative onto color photographic paper.
In contrast, when working from digital camera reproductions of color negatives — that is, in
ColorNeg DC mode — the situation is different. Here, considerable color processing is always required to take the digital camera out of the equation, so the distinction between narrow- and wide-gamut assignments that exists for scans no longer applies.
We are no longer using the
ProPhoto RGB primaries as stand-ins for the color photographic papers’ red, green, and blue dyes — which never would have made sense and is not something we ever suggested doing, but rather something that resulted from assigning ProPhoto RGB to images of linear origin and using ColorPerfect 2 on them. The challenges of
ProPhoto RGB follow downstream. It encompasses such a large color gamut that your screen will not be able to display it. And if you can’t display it, you may introduce colors that only show up in print — for example, certain cyan hues generated in computer graphics. That can be a good thing because you can print them and you don’t need to display them faithfully if you know what you want. So that’s something to look out for.
Furthermore, because
ProPhoto RGB encompasses what we can call hypothetical colors — that is, those lying outside of human vision — the portion of the container volume actually representing visible colors is smaller than it would be in narrower-gamut encodings. For 16-bit-per-channel images, that has no negative implications at all. But if anybody decides to convert to 8-bit in Photoshop without first converting to a narrower-gamut RGB working space, that would lead to problems. Suddenly we have a small container volume, and then only a portion of it is being used for actually visible colors.
As long as folks know what they’re doing, any color encoding will be fine — and even if they don’t, any detriments arising from such an RGB working space choice are outside of ColorPerfect itself. That said, for
ColorNeg DC, I think
Adobe RGB (1998) is a useful choice. But you can also experiment with wider settings and see whether the math then behaves in a way you like. Of course, you’ll need to convert the final result to something practical for downstream use.
