RAW developer and other modules

This is the standard “Adobe color matrix” profile derived from DCRAW (AFAIK). It should correspond to the “standard color matrix” option in Darktable

In the version of photoflow you are using, the color management is implemented in a way that “decouples” the gamut and gamma encoding of the colorspace in use. The gamut is defined by the RGB primaries, which specify the reddest, greenest and bluest color that a colorspace can represent. The gamma encoding is specified by the tone response curve used to represent the RGB values. Typical TRCs are gamma 2.2 used by the AdobeRGB1998 colorspace, gamma 1.8 used by ProPhotoRGB, and the one used by the sRGB colorspace.

A special case is the linear TRC, which does not apply any gamma-like encoding.
The L channel in the CIELab colorspace uses yet another gamma encoding, which is called perceptual because it tries to represent the values in equally-spaced intervals of perceived lightness. For example, mid-gray is represented in this case exactly by 50% lightness, while it corresponds to 18% lightness in a linear scale.

Although each colorspace specifies the associated TRC, there is nothing that prevents the user of a different one. For example, it is perfectly legitimate to edit an image using the sRGB primaries and a linear or perceptual encoding, and photoflow gives the freedom to do so in an easy way.

So, to answer your question:

  • standard means the TRC defined by the colorspace (for ex., gamma=2.2 in the AdobeRGB case)
  • perceptual means the TRC associated to the CIELab L channel
  • linear means no gamma encoding

I personally suggest to do most of the editing in linear colorspace, and only switch to perceptual encoding if you need to work with overlay-like blend modes. You can do this by adding a color profile conversion layer and setting the new encoding there.

Of course, you also need to add such a conversion layer at the top of your layer stack, to finally convert the image to the output colorspace. Here, chose sRGB with standard encoding if you are saving to Jpeg.
I am currently improving the interface for this, by implementing an “image export” dialog which will allow to set the size, post-resize sharpening and output colorspace for the images being exported to disk ans Jpeg or TIFF.

I would recommend to always clip negative values, because otherwise they might cause a lot of troubles in subsequent edits. Negative values are due to the presence of colors outside of the destination gamut, so better choose a wide-gamut colorspace like Rec.2020 or ACEScg and clip.

Overflow values are a different story. The version of photoflow you are using is designed to correctly handle high dynamic range images, in which the upper value is basically undefined (from the physical point of you, there is no theoretical limit in the intensity of light of the scene being recorded…). For example, if you push the exposure compensation upward, the brightest pixels are not lost of you do not clip, they are simply represented by values larger than 1. When editing the image further, you can compress the highlights back below 1 and recover the details for the final output image.

So my recommendation is to set the highlights reconstruction in the exposure tab to either clip or blend (in this case, the clipping happens before the exposure compensation is applied), and un-check the clip overflow values box in the Color tab.

I hope this answers all of your questions…

5 Likes