I agree that most image processing algorithms are not defined relative to the colorspace of the input data. The exceptions are things like:
-
Any algorithm that calculates relative luminance - which requires Y from XYZ, and so is dependent on the RGB color space primaries and also on the RGB color space TRC, because calculating relative luminance requires removing the color space companding curve in order to operate on linear RGB - otherwise you get Luma.
-
Any algorithm that uses luminance or luma as input also must take the RGB color space primaries and TRC into account, or else produces wrong results.
-
Of course algorithms that convert from RGB to XYZ and then perhaps to LAB or LCH must take the RGB color space primaries and also the color space TRC (the companding curve) into account, or else produce wrong results.
“How wrong” results of using the wrong primaries and TRC when converting to LAB of course depends on how far off the actual primaries and TRC are from the assumed primaries and TRC.Here are a couple of examples (one very wrong, one slightly wrong) from using the wrong TRC when converting from sRGB to LAB:
Well, I’m sure that you’ve read a lot more papers on image processing algorithms than I have. But from the ones that I’ve read, often there really is a conspicuous absence of any description whatsoever of what color space the input image is presumed to be in before the algorithm is applied. However, a failure on the author’s part to mention the RGB primaries and TRC does not in any way logically imply that the user’s choice of RGB primaries or channel encoding won’t make a visible and obvious difference in the result of applying the algorithm.
With respect to the channel encoding (TRC, companding curve), consider “gamma artifacts” from editing using perceptually uniform RGB instead of linear RGB. Default GIMP is built around the premises that:
- Gamma artifacts are important (I agree)
- Users should be able to edit their images without worrying too much about gamma artifacts (I agree, but users who know what they are doing should have the option to do other than what might be technically correct, and also there are a few operations for which “technically correct” is not really applicable, and recent default GIMP code does make it possible for users to choose to go against what’s technically correct)
Examples of gamma artifacts from painting in the regular sRGB color space with its more or less perceptually uniform TRC, compared to painting using linear sRGB:
The difference the RGB color space TRC (companding curve, channel encoding) makes when using “posterize” to make a step-wedge:
Adding noise to regular vs linear sRGB:
Auto-stretch-contrast:
For more examples of the difference the image’s RGB TRC (channel encoding, companding curve) makes, see:
Linear Gamma vs Higher Gamma RGB Color Spaces: Gaussian Blur and Normal Blend Mode
and
Is your image editor using an internal linear gamma color space? Should it?
OK, now let’s look at the notion that the RGB color space primaries don’t matter:
White-balancing an sRGB camera-saved jpeg (White balancing camera-saved sRGB jpegs) that was shot using the wrong white balance, using linear sRGB to pick the white point:
Same as above, except using linear Rec.2020:
Color correcting an image using a known neutral spot - for the second image, tyvek is very close to neutral white:
Following is a partial list of GIMP editing operations for which results are entirely independent of the color space RGB primaries, assuming the channel encoding (TRC, companding curve) is linear (all bets are off once you mix non-linear channel encodings into the mix):
Blend modes: Addition
Blend modes: Dissolve
Blend modes: Grain extract
Blend modes: Grain merge
Blend modes: Normal
Blend modes: Subtract
Colors: Brightness/Contrast
Colors: Desaturate luminosity
Colors: HDR Exposure, exposure and offset
Colors: Invert Colors
Colors: Levels Value Channel, upper/lower sliders
Colors: Mono Mixer, straight luminosity
Filters: Apply lens
Filters: Edge Detect difference of gaussians
Filters: Emboss
Filters: Gaussian Blur
Filters: Lens distortion
Filters: Noise Spread
Filters: Pixelize
Filters: Unsharp mask
Filters: Vignette - black, white, gray
Filters : Noise Pick
Filters : Noise Slur
Paint Tools: Normal, etc blend modes
Tools/gegl op: High Pass
Tools/gegl op: Mantuik06
Tools/gegl op: Mirror
Tools/gegl op: Radial Gradient
Tools/gegl op: Gaussian blur
Transforms: Crop
Transforms: Flip
Transforms: Rotate
Transforms: Scale
Transforms: Other transforms
Here’s a partial list of GIMP editing operations for which results are very dependent on the RGB primaries, even if the channel encoding is linear:
Blend modes: Burn
Blend modes: Color
Blend modes: Darken only
Blend modes: Difference
Blend modes: Divide
Blend modes: Dodge
Blend modes: Hard light
Blend modes: Hue
Blend modes: Lighten only
Blend modes: Multiply
Blend modes: Overlay
Blend modes: Saturation
Blend modes: Screen
Blend modes: Soft light
Blend modes: Value
Channel data: Using channel data as an editing layer
Channel data: Channel-based selections
Colors: Alien Map HSL or RGB
Colors: Auto strech contrast
Colors: Auto stretch contrast HSV
Colors: Channel Mixer
Colors: Color Balance
Colors: Colorize
Colors: Curves, RGB channels
Colors: Curves, Value channel
Colors: Desaturate average
Colors: Desaturate lightness
Colors: HDR Exposure, gamma
Colors: Hue-Lightness-Saturation
Colors: Levels RGB channels, upper/lower sliders (See Figure 2 below)
Colors: Levels gamma slider adjustments, RGB and Value channels (Also see Figure 1 below)
Colors: Mono Mixer, anything except straight luminosity (See Figure 3 below)
Colors: Threshold
Colors: Posterize
Colors: Value Invert
Filters: Artistic Cartoon
Filters: Artistic Soft glow
Filters: Edge Detect Laplace
Filters: Edge Detect Sobel
Filters: Noise RGB
Filters: Red Eye Removal
Filters: Tile Seamless
Filters: Vignette - color
Paint Tools: Multiply, etc blend modes
Tools/gegl op: Box Max
Tools/gegl op: Box Min
Tools/gegl op: Fattal2
For more information on the difference the RGB working space primaries make, and for links to example images, see the following article, which discusses why sRGB isn’t suitable as a universal color space for editing. Similar problems obtain regardless of what RGB color space one might choose as the one and only color space for editing, be that color space sRGB or ProPhotoRGB or ACES or whatever:
Limitations of unbounded sRGB as a universal color space for image editing:
Also see the following article, which discusses reasons why ACES isn’t a good universal RGB working space:
About Rendering Engines Colourspaces Agnosticism:
To summarize:
Addition and subtract are chromaticity-independent operations, but results do depend on the TRC.
Multiply and divide by any color other than gray are chromaticity-dependent operations, and results also depend on the TRC, not just “technically” but also visibly and obviously. So are operations that depend on retrieving individual channels for use in further editing steps.
“Gamma” adjustments and Curves also are chromaticity-dependent except when operating on all three channels by exactly the same amount, again, not just technically, but visibly. And results do depend on the TRC, not just technically but also visibly.
I will absolutely agree that sometimes the difference between sharpening on linear vs perceptually uniform RGB is subtle. But sometimes that subtle difference is visually important.