Hello everyone,
I would like to ask for clarification on working‑color‑space best practices for film digitization workflows, based on earlier discussions within this forum.
There appears to be a clear distinction between scanner‑sourced files and camera‑based negative reproductions:
When processing scanner scans in **SC‑Mode**:
Scanners capture film using narrow‑band R‑G‑B light sources. The signal they produce is natively RGB. Under these conditions, the sRGB gamut should be sufficient to contain all real‑world colour information from the scanned film.
When processing camera‑reproduced negatives in **DC‑Mode**:
DC‑Mode executes the camera‑sensor calibration matrix calculations. These computations generate intermediate colour values that may lie outside real‑world gamut boundaries. Consequently, a moderately wide‑gamut profile such as Adobe RGB 1998 — wide enough, yet not excessively large — is needed to provide sufficient headroom for those intermediate computed values.
Could the author please confirm whether this understanding is correct?
Color‑space selection: SC‑Mode for scanner, DC‑Mode for camera‑based negative repro
-
C.Oldendorf
- Developer
- Posts: 237
- Joined: Fri Sep 02, 2022 10:31 am
- Contact:
There is indeed an important distinction between scanner-based and digital-camera-based negative reproduction in ColorPerfect 3, but I would formulate it differently from the distinction proposed in the question.
The short answer first
The old ColorPerfect working-space documentation is here:
ColorPerfect 2: Working Spaces
Some of the ideas behind it go back further and are discussed in Dave’s older material:
Calibrating Digital Images – Profiling
Calibrating Digital Images – Pitfalls
That material predates PerfectRAW and parts of it no longer describe later ColorPerfect/PerfectRAW implementations, so it should be regarded as historical background rather than as a specification of current behavior.
For understanding ColorPerfect 2 ColorNeg, the useful analogy is traditional analog color-negative printing.
The spectral colors in the photographed scene are reduced by the spectral sensitivities of the film to three records, which are stored as varying densities in the negative’s dye layers.
When the negative is printed in an enlarger, those dye records act on the three sensitive layers of the photographic paper. The positive image is ultimately formed by the colorants of that paper.
ColorPerfect 2 ColorNeg followed an analogous model.
After conversion of the negative into positive RGB brightnesses, the primaries of the selected RGB working space effectively acted as stand-ins for the colorants of the photographic paper.
This worked very well with conventional RGB spaces whose primaries were suitable for that role.
Historically these included sRGB, Apple RGB, ColorMatch RGB and other similarly narrow spaces.
2. Why wide spaces were problematic, and why narrow did not mean “loss of gamut”
The same mechanism did not work well with decidedly wide-gamut RGB spaces.
If the calculated positive RGB values were interpreted directly using the very distant primaries of a space such as ProPhoto RGB, those primaries effectively became the “dyes” of the virtual photographic paper.
The result became excessively colorful and unnaturally saturated.
Even Adobe RGB 1998 was not necessarily ideal in this direct role because of its substantially extended green primary. On monitors capable of displaying roughly the Adobe RGB gamut this could become quite apparent, whereas an sRGB-limited display could conceal part of the problem.
This was the reason for the old recommendation to use a conventional, reasonably narrow RGB working space for ColorNeg.
It did not mean that ColorPerfect first created some independently defined large-gamut positive image and then squeezed it into sRGB.
The positive brightnesses were calculated and then interpreted using the selected RGB primaries. If sRGB primaries were assigned to those values, the resulting colors were defined by those primaries in the first place.
The assignment itself therefore cannot somehow produce another population of colors outside that RGB system and then clip them away.
That is fundamentally different from taking an already characterized wide-gamut RGB image and converting it into a smaller RGB color space.
This distinction was historically difficult to communicate because users were quite reasonably familiar with the general principle that converting an existing wide-gamut image into a narrower space may lose colors. That principle simply did not describe the ColorNeg operation above.
A related historical point concerns Apple RGB and ColorMatch RGB.
Their primaries remain perfectly usable for the traditional ColorNeg model. In a 16-bit/channel workflow their Gamma 1.8 encoding is also of little practical consequence.
However, once an image is reduced to 8 bits/channel, Gamma 1.8 is the inferior encoding choice. It belongs to an older workflow tradition, and the industry, including Apple, has long since moved away from Gamma 1.8 as the general-purpose choice.
For that reason I would no longer recommend Apple RGB or ColorMatch RGB for a new workflow even though they remain technically valid ColorPerfect working spaces.
3. What ColorPerfect 3 changed for SC
With ColorPerfect 3 I decided that users should no longer have to understand or agree with the old working-space model merely to obtain the result they expect.
For ColorNeg SC, ColorPerfect 3 therefore distinguishes internally between suitable conventional narrow RGB spaces and extended/wide RGB spaces.
For the conventional narrow case, the traditional mechanism remains: the RGB primaries can directly take the role of the virtual photographic-paper colorants.
For extended spaces such as Adobe RGB 1998, ProPhoto RGB, Wide Gamut RGB, ECI RGB variants, Display P3 and the other supported larger spaces, ColorPerfect 3 does something different.
It uses suitable internal virtual colorants for the relevant part of the negative-to-positive operation and then produces output appropriate to the selected RGB working profile.
The old excessive-saturation problem therefore no longer occurs merely because a user chooses a wide-gamut working space.
ColorPerfect 3 also recognizes a considerably larger range of working spaces than ColorPerfect 2, broadly including the established RGB spaces documented by Bruce Lindbloom together with additional more recent spaces in current use.
So if somebody asks me what to choose today for straightforward scanner-based ColorNeg work, my answer is sRGB.
It is simple, conventional, uses a modern tone-response encoding, and fits the traditional ColorNeg SC model very well.
But this is now a soft recommendation, not a restriction.
If your established workflow uses Adobe RGB 1998, ProPhoto RGB, Display P3 or another supported space, ColorPerfect 3 is designed to accommodate that choice correctly.
4. ColorNeg DC and PerfectRAW
DC, digital capture, is a different case from the traditional SC mechanism.
ColorNeg DC performs camera-related computational compensation in much the same general sense in which PerfectRAW has always compensated for properties of a digital camera.
I do not want to document the underlying mathematics or physics here.
The important practical fact is that ColorNeg DC performs processing directed toward the selected RGB target working space.
That remains true even when the selected target is sRGB.
There is therefore no simple sequence in which ColorPerfect calculates generic positive RGB values and merely assigns sRGB, Adobe RGB or ProPhoto primaries to those unchanged numbers.
Likewise, Adobe RGB 1998 is not required because the camera calculations supposedly need a wider “container” for intermediate values.
The selected working space is the intended RGB output space, not a scratch gamut into which ColorPerfect’s internal calculations must fit.
For digital-camera-derived images, however, there is a genuine practical working-space question which does not arise in quite the same way in the traditional SC model:
the required output gamut depends on the scene.
For that reason I regard Adobe RGB 1998 as a sensible general-purpose baseline for PerfectRAW and ColorNeg DC.
It provides appreciably more room than sRGB without immediately moving into the much larger working spaces which demand more care from the user and from the rest of the imaging workflow.
That does not mean that Adobe RGB 1998 will contain every color which can ever occur in a camera-derived image.
Nor does it mean that wider spaces are wrong.
If you know that your workflow can benefit from preserving colors beyond the range of Adobe RGB 1998, wider supported spaces are perfectly legitimate.
This becomes particularly relevant in specialist output workflows where a printer can reproduce colors which the monitor cannot display. In such a situation a wider working space can preserve printable colors even though they cannot all be judged directly on screen.
That is a valid reason to work wider.
It is very different from saying that ProPhoto RGB or another very large space is automatically better simply because it has a larger gamut.
PerfectRAW already followed this general principle in ColorPerfect 2: it computationally compensated for camera properties and generated output appropriate to the supported/detected RGB working space.
ColorNeg DC continues that general type of camera-related processing for negative reproduction.
5. Scanner input: assign, do not convert
Whether the intended working space is sRGB, Adobe RGB or ProPhoto is less important than what happens to the scanner data before ColorPerfect sees them.
Scanner acquisition should ordinarily be kept as free as practical from upstream color transformations and other automatic color-changing processing.
We want the scanner’s captured RGB data, not data which have already undergone some unwanted conversion before ColorPerfect gets to work.
However, “unprocessed” does not mean “untagged.”
Before invoking ColorPerfect, assign the intended RGB working profile.
For a grayscale scan, assign the intended gray working profile.
The distinction between assigning and converting is important.
Assigning associates the existing pixel values with the profile required by the ColorPerfect workflow.
Converting to another profile alters the pixel values.
Therefore:
Assign the intended profile before ColorPerfect. Do not convert the source image into another RGB or gray profile beforehand.
MakeTiff also has a TIFF-processing mode which can batch-assign profiles to scanner TIFFs, which is useful when dealing with large numbers of scans.
6. MakeTiff camera files and ColorPos RAW/RGB
The MakeTiff camera workflow looks unusual if viewed only from the standpoint of ordinary Photoshop RGB processing.
MakeTiff can create linear, demosaiced and otherwise deliberately unadulterated TIFF data from digital-camera RAW files.
A working-space profile is assigned to the TIFF, but the pixel data are still RAW workflow input intended for ColorPerfect. They are not yet ordinary finished RGB pixels encoded for that profile.
Photoshop does not know this.
It sees an RGB image with an assigned profile and naturally interprets the pixels as though they already belonged to that profile. The image may consequently look completely wrong before ColorPerfect is invoked.
That is expected.
ColorPerfect detects the assigned profile, treats the incoming data as RAW workflow data and produces the proper preview and final output for the selected working space.
ColorPerfect 3 also needs to make this distinction explicit in ColorPos.
A common workflow is to process an image in ColorNeg and subsequently invoke ColorPos. At that point ColorNeg may already have produced RGB data correctly encoded for the selected working profile.
ColorPos therefore distinguishes between:
RAW – the incoming pixels are still unprocessed workflow data and must be made appropriate for the assigned profile.
RGB – the incoming pixels are already encoded for that RGB working profile.
A ColorNeg → ColorPos workflow will normally reach ColorPos with RGB input.
7. The separate grayscale problem
The old ColorPerfect grayscale documentation is here:
Using ColorPerfect on grayscale images
The old recommendation to match the gray working profile and the default RGB working space did not arise from gamut considerations.
It arose from the way Photoshop supplies preview images to plugins.
The ColorPerfect preview is rendered through Photoshop, which is useful because Photoshop’s own display color management, including features such as soft proofing, remains involved.
However, Photoshop cannot provide the plugin with a grayscale proxy image. The proxy is always RGB.
If the actual document is grayscale, Photoshop therefore uses its configured default RGB working space when constructing the preview supplied to the plugin.
If the grayscale document and that RGB working space use different tone-response curves, the RGB proxy and the actual grayscale image consequently have different tone encodings.
ColorPerfect can return a correct final grayscale image while the preview shown during processing differs in brightness.
The old solution was therefore to match the tone-response characteristics of the default RGB and gray working profiles.
Typical examples are:
sRGB + sGray
Adobe RGB 1998 + Gray Gamma 2.2
or another suitable matching combination.
8. What ColorPerfect 3 changed for grayscale
This dependency on host configuration always bothered me.
ColorPerfect can detect the gray profile assigned to the actual document, but Photoshop does not directly tell a plugin which default RGB working space it is using to construct the RGB proxy.
ColorPerfect 3 now solves this in Photoshop and Photoshop Elements by means of an effective fingerprinting mechanism which can deduce the configured RGB working space.
There is no need to go into the implementation details here.
The result is that ColorPerfect can compensate its preview output appropriately.
In Photoshop and Photoshop Elements, preview and final grayscale output can therefore agree independently of the particular RGB/gray working-space configuration.
Matching the profiles remains sensible and uncomplicated. If your default RGB working space is Adobe RGB 1998, Gray Gamma 2.2 is a stable choice; if it is sRGB, sGray is the natural matching choice.
But in Photoshop and Photoshop Elements this is now a recommendation rather than a requirement for correct preview behavior.
The corresponding automatic compensation is not presently available in PhotoLine, Affinity Photo 1.x, Affinity Photo 2.x, or Affinity.
In those hosts, the old requirement to match the relevant tone-response characteristics remains.
9. Practical recommendations
Putting everything together:
The short answer first
- For ColorNeg SC, my practical recommendation today is simply sRGB.
That recommendation is not based on the idea that scanner colors somehow “fit inside” sRGB. It follows from the traditional ColorNeg model and the role played there by the RGB primaries. The historical reason, and why choosing sRGB in that context does not itself imply a loss of gamut, are explained in sections 1 and 2.
ColorPerfect 3 no longer requires this choice, however. Wider supported working spaces can now also be used correctly in SC mode; see section 3. - For ColorNeg DC, and likewise for PerfectRAW, Adobe RGB 1998 is a sensible general-purpose baseline.
The reason is not that ColorPerfect needs additional gamut as computational “headroom.” Rather, the gamut actually required by a digital-camera-derived image depends on the scene. Adobe RGB 1998 is a practical moderately wide choice which avoids unnecessarily restricting many photographic images while remaining comparatively easy to work with.
Wider spaces are also supported and can be useful where the workflow genuinely requires them. That is more specialist territory and is discussed in section 4. - For grayscale images, matching the gray working profile and the default RGB working space by tone-response curve remains sensible. In Photoshop and Photoshop Elements, ColorPerfect 3 can now compensate automatically if they do not match. In PhotoLine and the Affinity hosts, the old matching requirement remains relevant. See sections 7 and 8.
- Irrespective of working-space choice, source data intended for ColorPerfect should normally be kept free of prior color-space conversions. The intended RGB or gray profile should be assigned before ColorPerfect is invoked, not converted into beforehand. MakeTiff and the ColorPos RAW/RGB distinction are covered in sections 5 and 6.
The old ColorPerfect working-space documentation is here:
ColorPerfect 2: Working Spaces
Some of the ideas behind it go back further and are discussed in Dave’s older material:
Calibrating Digital Images – Profiling
Calibrating Digital Images – Pitfalls
That material predates PerfectRAW and parts of it no longer describe later ColorPerfect/PerfectRAW implementations, so it should be regarded as historical background rather than as a specification of current behavior.
For understanding ColorPerfect 2 ColorNeg, the useful analogy is traditional analog color-negative printing.
The spectral colors in the photographed scene are reduced by the spectral sensitivities of the film to three records, which are stored as varying densities in the negative’s dye layers.
When the negative is printed in an enlarger, those dye records act on the three sensitive layers of the photographic paper. The positive image is ultimately formed by the colorants of that paper.
ColorPerfect 2 ColorNeg followed an analogous model.
After conversion of the negative into positive RGB brightnesses, the primaries of the selected RGB working space effectively acted as stand-ins for the colorants of the photographic paper.
This worked very well with conventional RGB spaces whose primaries were suitable for that role.
Historically these included sRGB, Apple RGB, ColorMatch RGB and other similarly narrow spaces.
2. Why wide spaces were problematic, and why narrow did not mean “loss of gamut”
The same mechanism did not work well with decidedly wide-gamut RGB spaces.
If the calculated positive RGB values were interpreted directly using the very distant primaries of a space such as ProPhoto RGB, those primaries effectively became the “dyes” of the virtual photographic paper.
The result became excessively colorful and unnaturally saturated.
Even Adobe RGB 1998 was not necessarily ideal in this direct role because of its substantially extended green primary. On monitors capable of displaying roughly the Adobe RGB gamut this could become quite apparent, whereas an sRGB-limited display could conceal part of the problem.
This was the reason for the old recommendation to use a conventional, reasonably narrow RGB working space for ColorNeg.
It did not mean that ColorPerfect first created some independently defined large-gamut positive image and then squeezed it into sRGB.
The positive brightnesses were calculated and then interpreted using the selected RGB primaries. If sRGB primaries were assigned to those values, the resulting colors were defined by those primaries in the first place.
The assignment itself therefore cannot somehow produce another population of colors outside that RGB system and then clip them away.
That is fundamentally different from taking an already characterized wide-gamut RGB image and converting it into a smaller RGB color space.
This distinction was historically difficult to communicate because users were quite reasonably familiar with the general principle that converting an existing wide-gamut image into a narrower space may lose colors. That principle simply did not describe the ColorNeg operation above.
A related historical point concerns Apple RGB and ColorMatch RGB.
Their primaries remain perfectly usable for the traditional ColorNeg model. In a 16-bit/channel workflow their Gamma 1.8 encoding is also of little practical consequence.
However, once an image is reduced to 8 bits/channel, Gamma 1.8 is the inferior encoding choice. It belongs to an older workflow tradition, and the industry, including Apple, has long since moved away from Gamma 1.8 as the general-purpose choice.
For that reason I would no longer recommend Apple RGB or ColorMatch RGB for a new workflow even though they remain technically valid ColorPerfect working spaces.
3. What ColorPerfect 3 changed for SC
With ColorPerfect 3 I decided that users should no longer have to understand or agree with the old working-space model merely to obtain the result they expect.
For ColorNeg SC, ColorPerfect 3 therefore distinguishes internally between suitable conventional narrow RGB spaces and extended/wide RGB spaces.
For the conventional narrow case, the traditional mechanism remains: the RGB primaries can directly take the role of the virtual photographic-paper colorants.
For extended spaces such as Adobe RGB 1998, ProPhoto RGB, Wide Gamut RGB, ECI RGB variants, Display P3 and the other supported larger spaces, ColorPerfect 3 does something different.
It uses suitable internal virtual colorants for the relevant part of the negative-to-positive operation and then produces output appropriate to the selected RGB working profile.
The old excessive-saturation problem therefore no longer occurs merely because a user chooses a wide-gamut working space.
ColorPerfect 3 also recognizes a considerably larger range of working spaces than ColorPerfect 2, broadly including the established RGB spaces documented by Bruce Lindbloom together with additional more recent spaces in current use.
So if somebody asks me what to choose today for straightforward scanner-based ColorNeg work, my answer is sRGB.
It is simple, conventional, uses a modern tone-response encoding, and fits the traditional ColorNeg SC model very well.
But this is now a soft recommendation, not a restriction.
If your established workflow uses Adobe RGB 1998, ProPhoto RGB, Display P3 or another supported space, ColorPerfect 3 is designed to accommodate that choice correctly.
4. ColorNeg DC and PerfectRAW
DC, digital capture, is a different case from the traditional SC mechanism.
ColorNeg DC performs camera-related computational compensation in much the same general sense in which PerfectRAW has always compensated for properties of a digital camera.
I do not want to document the underlying mathematics or physics here.
The important practical fact is that ColorNeg DC performs processing directed toward the selected RGB target working space.
That remains true even when the selected target is sRGB.
There is therefore no simple sequence in which ColorPerfect calculates generic positive RGB values and merely assigns sRGB, Adobe RGB or ProPhoto primaries to those unchanged numbers.
Likewise, Adobe RGB 1998 is not required because the camera calculations supposedly need a wider “container” for intermediate values.
The selected working space is the intended RGB output space, not a scratch gamut into which ColorPerfect’s internal calculations must fit.
For digital-camera-derived images, however, there is a genuine practical working-space question which does not arise in quite the same way in the traditional SC model:
the required output gamut depends on the scene.
For that reason I regard Adobe RGB 1998 as a sensible general-purpose baseline for PerfectRAW and ColorNeg DC.
It provides appreciably more room than sRGB without immediately moving into the much larger working spaces which demand more care from the user and from the rest of the imaging workflow.
That does not mean that Adobe RGB 1998 will contain every color which can ever occur in a camera-derived image.
Nor does it mean that wider spaces are wrong.
If you know that your workflow can benefit from preserving colors beyond the range of Adobe RGB 1998, wider supported spaces are perfectly legitimate.
This becomes particularly relevant in specialist output workflows where a printer can reproduce colors which the monitor cannot display. In such a situation a wider working space can preserve printable colors even though they cannot all be judged directly on screen.
That is a valid reason to work wider.
It is very different from saying that ProPhoto RGB or another very large space is automatically better simply because it has a larger gamut.
PerfectRAW already followed this general principle in ColorPerfect 2: it computationally compensated for camera properties and generated output appropriate to the supported/detected RGB working space.
ColorNeg DC continues that general type of camera-related processing for negative reproduction.
5. Scanner input: assign, do not convert
Whether the intended working space is sRGB, Adobe RGB or ProPhoto is less important than what happens to the scanner data before ColorPerfect sees them.
Scanner acquisition should ordinarily be kept as free as practical from upstream color transformations and other automatic color-changing processing.
We want the scanner’s captured RGB data, not data which have already undergone some unwanted conversion before ColorPerfect gets to work.
However, “unprocessed” does not mean “untagged.”
Before invoking ColorPerfect, assign the intended RGB working profile.
For a grayscale scan, assign the intended gray working profile.
The distinction between assigning and converting is important.
Assigning associates the existing pixel values with the profile required by the ColorPerfect workflow.
Converting to another profile alters the pixel values.
Therefore:
Assign the intended profile before ColorPerfect. Do not convert the source image into another RGB or gray profile beforehand.
MakeTiff also has a TIFF-processing mode which can batch-assign profiles to scanner TIFFs, which is useful when dealing with large numbers of scans.
6. MakeTiff camera files and ColorPos RAW/RGB
The MakeTiff camera workflow looks unusual if viewed only from the standpoint of ordinary Photoshop RGB processing.
MakeTiff can create linear, demosaiced and otherwise deliberately unadulterated TIFF data from digital-camera RAW files.
A working-space profile is assigned to the TIFF, but the pixel data are still RAW workflow input intended for ColorPerfect. They are not yet ordinary finished RGB pixels encoded for that profile.
Photoshop does not know this.
It sees an RGB image with an assigned profile and naturally interprets the pixels as though they already belonged to that profile. The image may consequently look completely wrong before ColorPerfect is invoked.
That is expected.
ColorPerfect detects the assigned profile, treats the incoming data as RAW workflow data and produces the proper preview and final output for the selected working space.
ColorPerfect 3 also needs to make this distinction explicit in ColorPos.
A common workflow is to process an image in ColorNeg and subsequently invoke ColorPos. At that point ColorNeg may already have produced RGB data correctly encoded for the selected working profile.
ColorPos therefore distinguishes between:
RAW – the incoming pixels are still unprocessed workflow data and must be made appropriate for the assigned profile.
RGB – the incoming pixels are already encoded for that RGB working profile.
A ColorNeg → ColorPos workflow will normally reach ColorPos with RGB input.
7. The separate grayscale problem
The old ColorPerfect grayscale documentation is here:
Using ColorPerfect on grayscale images
The old recommendation to match the gray working profile and the default RGB working space did not arise from gamut considerations.
It arose from the way Photoshop supplies preview images to plugins.
The ColorPerfect preview is rendered through Photoshop, which is useful because Photoshop’s own display color management, including features such as soft proofing, remains involved.
However, Photoshop cannot provide the plugin with a grayscale proxy image. The proxy is always RGB.
If the actual document is grayscale, Photoshop therefore uses its configured default RGB working space when constructing the preview supplied to the plugin.
If the grayscale document and that RGB working space use different tone-response curves, the RGB proxy and the actual grayscale image consequently have different tone encodings.
ColorPerfect can return a correct final grayscale image while the preview shown during processing differs in brightness.
The old solution was therefore to match the tone-response characteristics of the default RGB and gray working profiles.
Typical examples are:
sRGB + sGray
Adobe RGB 1998 + Gray Gamma 2.2
or another suitable matching combination.
8. What ColorPerfect 3 changed for grayscale
This dependency on host configuration always bothered me.
ColorPerfect can detect the gray profile assigned to the actual document, but Photoshop does not directly tell a plugin which default RGB working space it is using to construct the RGB proxy.
ColorPerfect 3 now solves this in Photoshop and Photoshop Elements by means of an effective fingerprinting mechanism which can deduce the configured RGB working space.
There is no need to go into the implementation details here.
The result is that ColorPerfect can compensate its preview output appropriately.
In Photoshop and Photoshop Elements, preview and final grayscale output can therefore agree independently of the particular RGB/gray working-space configuration.
Matching the profiles remains sensible and uncomplicated. If your default RGB working space is Adobe RGB 1998, Gray Gamma 2.2 is a stable choice; if it is sRGB, sGray is the natural matching choice.
But in Photoshop and Photoshop Elements this is now a recommendation rather than a requirement for correct preview behavior.
The corresponding automatic compensation is not presently available in PhotoLine, Affinity Photo 1.x, Affinity Photo 2.x, or Affinity.
In those hosts, the old requirement to match the relevant tone-response characteristics remains.
9. Practical recommendations
Putting everything together:
- For ColorNeg SC scanner negatives, use sRGB unless you have a particular reason to choose something else. The recommendation follows from the traditional ColorNeg SC model, not from an assumption that a narrow gamut preserves or discards some fixed set of scanner colors.
- Apple RGB and ColorMatch RGB remain technically suitable for the traditional SC mechanism, especially in 16 bits/channel, but I would no longer recommend their Gamma 1.8 encoding for a modern workflow which may end up at 8 bits/channel.
- If your established SC workflow uses Adobe RGB 1998, ProPhoto RGB, Display P3 or another supported space, ColorPerfect 3 can accommodate that choice correctly.
- For ColorNeg DC and PerfectRAW, Adobe RGB 1998 is a sensible general-purpose baseline because the gamut required by a camera-derived image depends on the scene.
- Wider spaces can be appropriate where the workflow actually benefits from them, particularly in specialist output situations where printable colors extend beyond what the monitor can display.
- For grayscale work, matching the gray profile to the default RGB working space remains sensible. Photoshop and Photoshop Elements can now be compensated automatically; PhotoLine and the Affinity hosts still require the matching setup.
- For scanner acquisition, avoid unwanted upstream color processing, preserve the capture values and assign the intended RGB or gray profile before invoking ColorPerfect. Do not convert the source image into another profile first.
- For MakeTiff camera workflows, remember that the assigned profile identifies the intended ColorPerfect working/output context even though the TIFF pixels are still RAW workflow data.
- In ColorPos, RAW means input which still requires processing into the selected working-space representation; RGB means that this step has already been performed.
-
robyferrero
- ColorPerfect User
- Posts: 188
- Joined: Wed Aug 20, 2025 4:12 pm
- Location: Italia
I don't quite understand the last part of: 6. MakeTiff camera files and ColorPos RAW/RGB. Where you say: A ColorNeg → ColorPos workflow will normally achieve ColorPos with RGB input.
What does it mean to go from ColorNEG to ColorPOS?
That ColorNEG DC is used for conversion, and then the file is processed in ColorPOS?
What does it mean to go from ColorNEG to ColorPOS?
That ColorNEG DC is used for conversion, and then the file is processed in ColorPOS?
-
C.Oldendorf
- Developer
- Posts: 237
- Joined: Fri Sep 02, 2022 10:31 am
- Contact:
Yes. This refers to the somewhat niche possibility of first converting a negative to a positive in ColorNeg, using either SC or DC processing, and then using ColorPos on that already converted positive as a second processing step.robyferrero wrote: Sun Sep 06, 2026 12:34 pm What does it mean to go from ColorNEG to ColorPOS?
That ColorNEG DC is used for conversion, and then the file is processed in ColorPOS?
Normally, TouchUp is the mode intended for a second step on an image which already has color integrity and has already undergone Blackpoint/BPTails processing.
Some users nevertheless have reasons to use ColorPos instead. One example would be working with a selection, such as a luminance mask derived from the positive image.
Such a workflow might look like this:
- Convert the negative to a positive in ColorNeg.
- Turn off the BPoint system during that conversion.
- Make the positive sufficiently dark to avoid highlight clipping without causing the intended masking operation to behave strangely.
- Create the desired selection or luminance mask from that positive.
- Then process the image in ColorPos, making separate adjustments to the In and Out portions of the selection.
The important point in relation to the new RAW/RGB switch is this:
There is no way to turn off the relevant color processing in ColorNeg, nor should there normally be one. Likewise, when ColorPos receives genuinely RAW input, the corresponding color processing should take place there as well.
However, the workflow described above creates one possible exception: ColorPos can receive an image which has already undergone the necessary color processing in ColorNeg.
In that case, applying the same processing again would obviously be wrong.
That is why ColorPos now has the RAW/RGB toggle:
RAW means that ColorPos is receiving unprocessed input and must perform the appropriate processing for the assigned working profile.
RGB means that the input has already been processed into the assigned RGB working space, for example by a preceding ColorNeg operation, and that processing must therefore not be repeated.
I expect the RGB case to be relatively rare, but I did not want ColorPerfect 3 to close off a perfectly legitimate workflow simply because it is not the usual one. The toggle is essentially an escape route for exactly such cases.
-
robyferrero
- ColorPerfect User
- Posts: 188
- Joined: Wed Aug 20, 2025 4:12 pm
- Location: Italia
If I understand correctly, regardless of the luminance mask, if I want to process with the ColorNEG > ColorPOS method: I convert the negative file to a positive, excluding the BP and BPTails. Then I go to ColorPOS and process the image normally as I would without the ColorNEG step. What I don't understand is whether in this case, on ColorPOS, I should work in RAW (Adobe 1998 color space) or RGB (Gamma c 2.2). I mean, switching from ColorNEG, even excluding the two BPs, when I get to ColorPOS, the latter is receiving a pre-processed input, is that correct? So I switch from the RAW button to the RGB one? Also, it seems to me that this is a method to be used in exceptional cases: for example, if you need to work with luminance masks. With a standard workflow, it's not necessary.
-
C.Oldendorf
- Developer
- Posts: 237
- Joined: Fri Sep 02, 2022 10:31 am
- Contact:
Yes, with one important difference: the input is no longer unprocessed.robyferrero wrote: Mon Sep 07, 2026 11:54 am Then I go to ColorPOS and process the image normally as I would without the ColorNeg step.
Exactly.robyferrero wrote: Mon Sep 07, 2026 11:54 am What I don't understand is whether in this case, on ColorPOS, I should work in RAW (Adobe 1998 color space) or RGB (Gamma c 2.2). I mean, switching from ColorNEG, even excluding the two BPs, when I get to ColorPOS, the latter is receiving a pre-processed input, is that correct? So I switch from the RAW button to the RGB one?
In this situation you switch ColorPos to RGB.
RGB means that the incoming image data have already been encoded for the correct RGB primaries. In your example, ColorNeg has already produced data appropriate for Adobe RGB 1998.
ColorPos therefore does not need to perform that color processing again. It only needs to know the tone-response curve used to decode and subsequently re-encode the image.
For Adobe RGB 1998, that is Gamma 2.2.
So, in simplified terms:
RAW = ColorPos receives unprocessed input and must perform the necessary processing for the selected RGB working space.
RGB = ColorPos receives input which is already encoded for the correct RGB primaries, so only the corresponding tone-response encoding needs to be handled.
Yes, absolutely.robyferrero wrote: Mon Sep 07, 2026 11:54 am Also, it seems to me that this is a method to be used in exceptional cases: for example, if you need to work with luminance masks.
With a standard workflow, it's not necessary.
This is intended for users who specifically know why they want to process a ColorNeg result further in ColorPos, for example because they want to work with a luminance mask derived from the positive image. For a normal workflow, there is no need to do this.
There can also be practical reasons why setting up the same masking operation on the linear negative is inconvenient. Suppose, for example, that you want to retain the sprocket holes, automatic frame detection fails, and you therefore use a selection with the Shift key held when starting the plug-in to tell ColorPerfect where the actual frame is. At that point your available selection is already being used for that purpose.
Again, there are alternative ways of arranging the workflow. The point is simply that situations exist in which processing the positive further in ColorPos is useful, and the RGB option keeps that route open.
-
robyferrero
- ColorPerfect User
- Posts: 188
- Joined: Wed Aug 20, 2025 4:12 pm
- Location: Italia
Well, that's all clear. I did some tests a couple of days ago, and I wasn't entirely satisfied with the results using the RAW button. On the other hand, using the RGB button produces almost the same results as processing done only on ColorNEG. Thanks for the clarification.