93 replies to this topic

[BQ Octantis]

G'day all,

 

Since embarking on my color science journey a year a go now, I've had a frequent nagging in the back of my mind about the perceptual difference between saturation-hammering stretches (like asinh and GHT), color "blanching" stretches (like gamma and MTF), and a color-matching CCM applied to the raw camera data. I've copped a lot of bewilderment (and occasionally criticism) over the use of a CCM—and if the measure of relevance is the ubiquity of use, then a CCM should be irrelevant to AP…right?

 

I was working on The Eye of God this morning when deep within my soul I felt moved to evaluate some of my outcomes with the CIE 1976 UCS chromaticity space. I've done countless CIE 1931 xy evaluations with Colour-Science for Python, but the 1931 xy space is not perceptually uniform. It turned out, plotting in UCS uv color space just took a change to one word in one command in my plotting script—too easy! And UCS is a simple way to exorcise those gremlins in the back of my mind I described above.

 

So here is a toggle through the various stretches on my raw Eye of God data and their effects on color in a perceptually uniform measurement space. Note that all stretch methods require positive values within the working color space (usually monitor-stretched sRGB). This drives asymptotic behavior at the boundary of each channel that distorts the hues. The CCM recognizes no such boundary because the negative values required for color matching in the sRGB gamut are permissible—but a coordinate transformation to AdobeRGB (or a color space encompassing those negative sRGB values) is needed before the stretch so the colors don't get clipped to the sRGB rail.

 

GIF preview

Full size toggle

 

I hope you find that as illuminating as I did.

 

Cheers,

 

BQ

Edited by BQ Octantis, 24 September 2023 - 07:48 PM.

[sharkmelley]

It's an interesting result.  Asinh stretch should result in identical chromaticities to the linear data.  So your result suggests a faulty implementation of asinh or a faulty workflow.

[BQ Octantis]

Hi Mark,

 

Thanks for your interest! I never know if anyone will appreciate the color science behind our image processing.

 

The question you raise is one of philosophy, not of measurement.

 

The raw and CCM data are linear. But to view them onscreen, we need to perform a colour component transfer function (cctf) for the display to properly output linear signals for our eyeballs. The screen gamma is the only accurate transformation. But for plotting, we use the linear data as-is.

 

That is not true for the rest of the stretches because we manipulate the data in encoded display space. To do an apples-to-apples comparison of our stretched results with with the linear data, we need to perform cctf decoding of the result to get to the same color space. Again, the screen gamma is the most accurate; for the plots I just used

 

colour.cctf_decoding(FITS,function="Gamma 2.2")

 

Asinh most certainly boosts colorfulness (indeed, I've fiddled with the asinh slider with Siril "Autostretch" (STF) preview enabled to judge what stretch factor of asinh stretch to use—my options go from 0.0 to 1000.0); in xy/uv chromaticity space, that colorfulness increase is simply an increase in the radial distance of the data from the white point. The overall form of the chromaticity blob isn't really modified by asinh, GHT, or MTF. But their mathematics limit their values to all positive, resulting in the distortion near the gamut edge I mentioned.

 

Cheers,

 

BQ

[sharkmelley]

Asinh most certainly boosts colorfulness 

It's a shame if Asinh boosts colourfulness.  In PixInsight, the ArcSinh stretch and GHS (GeneralisedHyperbolicStretch) used in Colour Stretch mode do not have this problem. They both keep the R:G:B ratios in each pixel constant during the stretch.

Edited by sharkmelley, 25 September 2023 - 08:29 AM.

[BQ Octantis]

It's a shame if Asinh boosts colourfulness.  In PixInsight, the ArcSinh stretch and GHS (GeneralisedHyperbolicStretch) used in Colour Stretch mode do not have this problem. They both keep the R:G:B ratios in each pixel constant during the stretch.

 

If you keep the R:G:B ratios constant during a stretch, then you have change the proportions of the underlying linear data via the screen gamma.

 

Let's say you have a linear sRGB/BT.709 color with coordinates (0.1, 0.2, 0.3). And you increase those values with a proportion-preserving stretch to (0.3, 0.6, 0.9). The proportions of both are 1:2:3, right?

 

But if the 1:2:3 proportions were accurate in linear space, they are no longer accurate in display space.

 

Why?

 

Because the accurate 1:2:3 linear proportions required a screen gamma encoding of 2.2 to be accurately displayed. That is, the accurately displayed values of the linear point (0.1, 0.2, 0.3) are 255×(0.1, 0.2, 0.3)^1/2.2 = (90, 123, 148). The "stretched" point with the same proportions is 255×(0.3, 0.6, 0.9) = (77, 153, 230). The stretched point must be cctf decoded to assess the underlying linear color value = ((77, 153, 230)÷255)^2.2 = (0.07, 0.33, 0.79). So our original linear proportions of 1:2:3 have become 1:4.6:11.2 in linear space. That is a massive change in colorfulness.

 

So by preserving the R:G:B proportions through a stretch, we passively modify the underlying proportions in a nonlinear way by way of the screen gamma. The net result is an increase in colorfulness of the displayed outcome.

 

The same thing happens even if you just multiply by a scalar—which is all I did for the example.

 

BQ

 

[sharkmelley]

Let's say you have a linear sRGB/BT.709 color with coordinates (0.1, 0.2, 0.3). And you increase those values with a proportion-preserving stretch to (0.3, 0.6, 0.9). The proportions of both are 1:2:3, right?

 

But if the 1:2:3 proportions were accurate in linear space, they are no longer accurate in display space.

Exactly.  That's why the order of operations is important. The ArcSinh stretch is applied to the linear data (as I said in my first reply) and this preserves the chromaticities.  The gamma for the colour space is applied at a later stage.   So the reason for your "increase in colorfulness" is probably an ill-considered workflow and not a problem with asinh.

 

Having said that, if your colour space has constant gamma (e.g. AdobeRGB) then the operations can safely be done in either order.

[FrankieT]

That is, the accurately displayed values of the linear point (0.1, 0.2, 0.3) are 255×(0.1, 0.2, 0.3)^1/2.2 = (90, 123, 148). 

Why? In a properly color managed workflow, the user should see linear data, not 255×(0.1, 0.2, 0.3)^1/2.2. So, provided that the appropriate transfer function ("gamma") for the display is applied correctly in the processing pipeline, the net result the user sees should be:

Linear data point:      255×(0.1, 0.2, 0.3)

Stretched data point:  255×(0.3, 0.6, 0.9)

Hence, the R:G:B ratios are preserved.

[BQ Octantis]

I'm not comparing results from a properly managed workflow.

 

I am comparing 32-bit real FITS outcomes before color management is even a thing. The working color space for Siril is BT.709 primaries fed into a screen with a gamma transfer function. And MIT claims my screen gamma is 2.2:

 

http://web.mit.edu/j...lger/gamma.html

 

 

My linear data is just that. It does not display properly in linear preview mode unless I apply the inverse screen gamma of 1/2.2 (although square root preview mode is a close 1/2.0). But plotting the chromaticities requires no cctf decoding. Indeed, that is why I can plot out-of-gamut sRGB colors; all the stretches return NaN for negative values.

 

To compare the MTF, GHT, and asinh stretch results, I must remove their screen gamma of 2.2 to retrieve the linear values for plotting.

 

Color management comes after conversion to AdobeRGB (in linear space) and appending the AdobeRGB ICC profile that color managed applications (Photoshop, Gimp, RawTherapee, and web browsers with activated expanded gamuts) know how to use.

 

You'll have to tell me about the color management savvyness of other AP apps. I've only tested starnet++, and it's oblivious: numbers is numbers.

 

BQ

[sharkmelley]

I'm not comparing results from a properly managed workflow.

 

I am comparing 32-bit real FITS outcomes before color management is even a thing. 

 

If you are not comparing results from a colour-managed workflow then your comparison is potentially misleading.  The whole point of stretches such as asinh is that they are colour-preserving (when used correctly).  Your plots give the wrong impression that asinh is not colour preserving.

 

The working color space for Siril is BT.709 primaries fed into a screen with a gamma transfer function. And MIT claims my screen gamma is 2.2:

 

http://web.mit.edu/j...lger/gamma.html

 

 

My linear data is just that. It does not display properly in linear preview mode unless I apply the inverse screen gamma of 1/2.2 (although square root preview mode is a close 1/2.0). 

The screen gamma is pretty much a red herring because it is normally set at 2.2 and remains fixed.  The important gamma is the gamma of the working colour space.  Almost certainly, like most astro-processing sofware, Siril is implicitly using a sRGB working colour space by default.  Hence to make colours appear correctly on-screen you need to apply the sRGB cctf to the data.  

 

 

To compare the MTF, GHT, and asinh stretch results, I must remove their screen gamma of 2.2 to retrieve the linear values for plotting.

I think I can finally see what you are attempting to do.  You are trying to plot the chromaticities of the colours of a non-colour-managed workflow as they appear to the eye on your display device. Not many people would understand the subtlety of that. But to do so, you need to remove the cctf of the implicit working colour space used by Siril (probably sRGB), not the display gamma.

 

 

Color management comes after conversion to AdobeRGB (in linear space) and appending the AdobeRGB ICC profile that color managed applications (Photoshop, Gimp, RawTherapee, and web browsers with activated expanded gamuts) know how to use.

That's true for Siril because it is not colour-managed but in PixInsight I generally use a colour managed workflow using a linear working colour space. PixInsight then displays the colours correctly as soon as I've applied white balance and CCM (colour correction matrix) for the working colour space I've chosen.

Edited by sharkmelley, 27 September 2023 - 01:25 AM.

[FrankieT]

Forgive me if I'm re-stating the obvious but I'm struggling to understand the workflow you described in #3 and #5

 

 

The working color space for Siril is BT.709 primaries fed into a screen with a gamma transfer function.

 

I haven't been able to find such a reference. On the contrary, it's been stated elsewhere that Siril is not colour-managed; that is, it does not take any particular colour space into account. Unless the software was changed recently, this implies that Siril does not transform the data on input, including the sRGB TRC, the data output from Siril in FITS or TIFF files are not encoded with an ICC profile, including any relevant TRC, and Siril does not apply a gamma transfer function to the data which is fed to the display.

 

 

To compare the MTF, GHT, and asinh stretch results, I must remove their screen gamma of 2.2 to retrieve the linear values for plotting.

 

I understood the original post was to compare the effect of different stretches in a perceptually uniform colour space, irrespective of the AP software and display device being used. For plotting data on a chromaticity diagram, which you stated was taken from a 32-bit FITS (Siril) file, why is it necessary to remove a screen gamma which wasn't actually applied to the data?

 

I think I have probably missed something really obvious so I'm genuinely interested to understand your workflow so I can interpret the results correctly.
 

 

[BQ Octantis]

Hmmm…maybe my experience is unique to Siril.

 

When I open linear data in Linear display mode, the data is not gamma corrected for my screen. The linear RGB values passed by Siril to the video buffer through the OS are raised to the power of 2.2 by the video card (to the best ability of its LUT to morph the actual LCD response into a 2.2 gamma curve) to generate an on-screen color. When properly color-matched, the linear result in this mode is far too dark and oversaturated because raising any number on the interval (0,1) to the power of 2.2 will make the number smaller—and the small differences in proportions get greatly exaggerated.

 

My other display mode options are Logarithm, Square root, Squared, Asinh, AutoStretch and Histogram. The only thing close to a gamma correction is Square root. And indeed, if I manipulate my scalar and asinh values under Square root mode to a passable result, the underlying chromaticities are only slightly distorted if I tell Colour Science to not remove the cctf on the result (i.e., treat the stretched data as linear):

 

Preview GIF:

Full size toggle

 

I had no idea I was supposed to use asinh with a gamma correction, so my apologies for being misleading. But I generally stretch while in Linear display mode for any stretch because Siril warns me upon saving that the data will not be WYSIWYG unless I save in linear mode. Which I can't if I want the displayed TIFF/JPG/PNG to be correct…it needs a gamma correction to display correctly.

 

BQ

 

[sharkmelley]

Hmmm…maybe my experience is unique to Siril.

 

When I open linear data in Linear display mode, the data is not gamma corrected for my screen. The linear RGB values passed by Siril to the video buffer through the OS are raised to the power of 2.2 by the video card (to the best ability of its LUT to morph the actual LCD response into a 2.2 gamma curve) to generate an on-screen color. When properly color-matched, the linear result in this mode is far too dark and oversaturated because raising any number on the interval (0,1) to the power of 2.2 will make the number smaller—and the small differences in proportions get greatly exaggerated.

What you are describing is not unique to Siril but it's common to most astro-processing softwares because they are not colour managed.  In Windows at least, any non-colour-managed image data sent to the video-card/display is assumed to be sRGB and so the video-card/display will "undo" the assumed sRGB gamma curve before display. This is why the image looks too dark/contrasty and it's why the image subsequently looks correct when you manually apply the sRGB gamma curve to the data using PixelMath within Siril. 

 

PixInsight is an exception to this because you can define a working colour space using "Color Management Setup", making the workflow colour-managed.  In PixInsight, I generally work with a linear profile (typically linear AdobeRGB) and do the transformation to sRGB or AdobeRGB as one of the final steps in my workflow.

[BQ Octantis]

Fascinating…a synthetic color management of sorts…? At the OS/GPU-level, OpenGL used to be the solution to bridge linear data with whatever the output hardware. Not sure what Photoshop and RawTherapee are using on my old hardware and OS, but Apple shows OpenGL to deprecated in its current OS in favor of some new Tower-of-Babel variant standard.

 

My workaround is simply to process color and luminosity separately. The color-matching CCM provides the accurate linear chromaticities, so I just synthesize an xyY with the xy from the linear color-matched data. I use AdobeRGB as the output gamut for its expanded cyan and yellows range—it's amazing how much real-life color is clipped to the sRGB rail!

 

GIF preview:

Full size toggle

 

BQ

 

[FrankieT]

But I generally stretch while in Linear display mode for any stretch because Siril warns me upon saving that the data will not be WYSIWYG unless I save in linear mode. Which I can't if I want the displayed TIFF/JPG/PNG to be correct…it needs a gamma correction to display correctly.

 

Well, at least the colour profile of the image data should be embedded in the file. The image data may be encoded with a linear gamma and still display properly provided it's opened in software that is colour-managed.

[BQ Octantis]

Well, at least the colour profile of the image data should be embedded in the file. The image data may be encoded with a linear gamma and still display properly provided it's opened in software that is colour-managed.

 

I use Colour-Science on the FITS to decode the cctf (gamma 2.2) on the luminosity channel, apply the calibrated chromaticities, transform to AdobeRGB, np.clip the values to positive, and then apply the cctf. Nothing good comes when I cctf encode negative values, as the NaN values from Colour-Science to not translate well to Siril NaN.

 

The Colour-Science cctf options are fairly extensive:

 

Gamma 2.2, Gamma 2.4, Gamma 2.6, ProPhoto RGB, RIMM RGB, ROMM RGB, ACEScc, ACEScct, ACESproxyARRI LogC3, ARRI LogC4, Canon Log 2, Canon Log 3, Canon Log, Cineon, D-Log, ERIMM RGB, F-Log, F-Log2, Filmic Pro 6, L-Log, Log2, Log3G10, Log3G12, N-Log, PLog, Panalog, Protune, REDLog, REDLogFilm, S-Log, S-Log2, S-Log3, T-Log, V-Log, ViperLog, ARIB STD-B67, Blackmagic Film Generation 5, DaVinci Intermediate, ITU-R BT.2020, ITU-R BT.2100 HLG, ITU-R BT.2100 PQ, ITU-R BT.601, ITU-R BT.709, ITU-T H.273 Log, ITU-T H.273 Log Sqrt, ITU-T H.273 IEC 61966-2, SMPTE 240M, DCDM, DICOM GSDF, ITU-R BT.1886, ITU-T H.273 ST.428-1, ST 2084, sRGB

 

Since I've moved to AdobeRGB, I just cctf encode with Gamma 2.2. I then apply the AdobeRGB 1998 ICC in RawTherapee (or Photoshop) and use that as the working and output color space.

 

BQ

Edited by BQ Octantis, 28 September 2023 - 06:16 PM.

[KLWalsh]

I think this analysis and discussion is interesting, but as I’ve mentioned before in other threads, the CIE formalism for color analysis is based on photopic intensities and a ‘2° Observer’, ie., daylight luminance levels and a target 4 times the size of the Moon.
Applying CIE metrics to DSOs is non-rigorous since they are in the scoptic intensity range and usually far smaller than 2 degrees across.
So this is interesting in a ‘what if?’ sense of how objects would look if they were big enough and bright enough to be seen in daylight. But no amount of analysis can overcome a somewhat dubious application of the CIE formalism.

[BQ Octantis]

I think this analysis and discussion is interesting, but as I’ve mentioned before in other threads, the CIE formalism for color analysis is based on photopic intensities and a ‘2° Observer’, ie., daylight luminance levels and a target 4 times the size of the Moon.
Applying CIE metrics to DSOs is non-rigorous since they are in the scoptic intensity range and usually far smaller than 2 degrees across.
So this is interesting in a ‘what if?’ sense of how objects would look if they were big enough and bright enough to be seen in daylight. But no amount of analysis can overcome a somewhat dubious application of the CIE formalism.

True. There is no color in deep space.

[timelapser]

Applying CIE metrics to DSOs is non-rigorous since they are in the scoptic intensity range and usually far smaller than 2 degrees across.
So this is interesting in a ‘what if?’ sense of how objects would look if they were big enough and bright enough to be seen in daylight. But no amount of analysis can overcome a somewhat dubious application of the CIE formalism.

Everyone who's observed through a 'scope knows that for most DSOs the colours depicted in images aren't what we actually see with our scotopic vision.  But as others have pointed out here, it seems natural to try to depict them as they would appear if their spectra were simply scaled up by a wavelength-independent factor until they were in the photopic range.  That's the only approach I know of that stands out, and apart from that approach it's pretty much just a matter of making them look pretty, as far as I can tell.

[BQ Octantis]

BTW, you can make any stretch carry the linear chromaticities. That is the purpose of xyL processing.

 

The workflow is

 

1. Synthetic L → stretch (MTF/asinh/GHT) → remove cctf (sRGB or screen gamma) → save as L channel (FITS32)
2. WB factors → background subtraction → background equalization → CCM (AdobeRGB) → save as linear RGB (FITS32)
3. Convert RGB to xyY → replace Y with L → convert back to RGB → clip values to [0,1] → apply cctf (Gamma 2.2) → save as TIFF16
4. Apply AdobeRGB ICC

 

This will even eliminate the small shifts induced by the asinh stretch.

 

BQ

[BQ Octantis]

What you are describing is not unique to Siril but it's common to most astro-processing softwares because they are not colour managed.  In Windows at least, any non-colour-managed image data sent to the video-card/display is assumed to be sRGB and so the video-card/display will "undo" the assumed sRGB gamma curve before display. This is why the image looks too dark/contrasty and it's why the image subsequently looks correct when you manually apply the sRGB gamma curve to the data using PixelMath within Siril.

I confirmed today with the grayscale line on my SpyderCheckr 24 that the Mac OS High Sierra screen buffer just applies the screen gamma to the "Linear" preview mode. If I apply a gamma of 2 and measure the values in Siril, they jibe with the OS screenshot values, the Siril app-level screenshot values, and a mathematical application to the raw data (out of RawDigger). And if I enter "Square root" preview mode with the linear data, the screenshot values are also identical:

 

 

But this highlighted a fascinating problem when assigning the AdobeRGB (1998) ICC to the color space transformed TIFF.

 

Regardless of the stretch applied to the data, Siril saves the 16-bit positive-integer RGB TIFF with the sRGB slope-gamma file compression.

 

Which is fine if you decompress the file as sRGB: all the stretched values are completely preserved.

 

But when you tell the imaging app (Photoshop/Gimp/RawTherapee) to interpret the file as Adobe RGB (1998), they all assume the file compression was with gamma 2.2 and a slope of 1.

 

But it wasn't…it was sRGB.

 

So the darks are too dark.

 

The only way I found to fix this was to remove the sRGB cctf and apply the Gamma 2.2 cctf with Colour-Science. The result is identical chromaticities (with the sRGB values clamped to the gamut rail):

 

 

Amusingly enough, I broke all my GIF and APNG makers…none seem to like AdobeRGB.

 

BQ

 

[sharkmelley]

I'm a bit confused by what you're saying but especially when you say: "Regardless of the stretch applied to the data, Siril saves the 16-bit positive-integer RGB TIFF with the sRGB slope-gamma file compression."

 

I'm assuming that Siril is not writing an sRGB ICC profile into the file.  However, are you saying that Siril is transforming the data values as it writes the file?  I'm not familiar with Siril but this would be very odd behaviour for an astro-image processing application.  How are you verifying this?

 

Also, when you say "Regardless of the stretch applied to the data", how exactly are you applying the stretch and can you see the data values actually change when the stretch is applied?

[FrankieT]

I'm a bit confused by what you're saying but especially when you say: "Regardless of the stretch applied to the data, Siril saves the 16-bit positive-integer RGB TIFF with the sRGB slope-gamma file compression."

 

I'm assuming that Siril is not writing an sRGB ICC profile into the file.  However, are you saying that Siril is transforming the data values as it writes the file?  I'm not familiar with Siril but this would be very odd behaviour for an astro-image processing application.  How are you verifying this?

Siril provides several image "preview modes", such as Linear, Square Root, Asinh etc, which transform the image data that is output to Siril's image preview window. However, the preview modes are for visualization purposes only so the display transformation is not applied to the internal "working data" that is eventually saved to file, i.e FITS or TIFF. The function of the preview mode is clearly described in Siril's documentation.

 

In order to process an image and actually apply a transformation (or stretch) to the internal working data that will be saved to file, Siril provides several functions like Asinh, GHT and Histogram Transformation in the "Image Processing" menu.

 

On saving a TIFF file, Sirl provides the option to embed an sRGB ICC profile to the file: however, on writing the file Siril does not transform or encode the image data according to the sRGB profile, regardless if the option to embed the ICC profile was checked or not.

[sharkmelley]

Siril provides several image "preview modes", such as Linear, Square Root, Asinh etc, which transform the image data that is output to Siril's image preview window. However, the preview modes are for visualization purposes only so the display transformation is not applied to the internal "working data" that is eventually saved to file, i.e FITS or TIFF. The function of the preview mode is clearly described in Siril's documentation.

 

In order to process an image and actually apply a transformation (or stretch) to the internal working data that will be saved to file, Siril provides several functions like Asinh, GHT and Histogram Transformation in the "Image Processing" menu.

 

On saving a TIFF file, Sirl provides the option to embed an sRGB ICC profile to the file: however, on writing the file Siril does not transform or encode the image data according to the sRGB profile, regardless if the option to embed the ICC profile was checked or not.

That all makes complete sense!  

[FrankieT]

That all makes complete sense!  

Yes and I also verified that Siril v1.2 does not transform the image data when writing to file, just in case new behavior was introduced with the new version.

 

For the reference image, your famous colour checker file was loaded into darktable (colour-managed software) with only basic processing options applied; i.e., black point, white balance, demosaic, input profile (standard colour matrix) and display encoding (sRGB).

 

In Siril, the raw colour checker file was converted to fits, bias subtracted, debayered, white balanced and a CCM applied before saving to a 16-bit integer TIFF with and without the sRGB ICC profile tag appended to the file. Just to be clear, both files should contain linear data if, as expected, Siril does not transform the working data when writing to file. I should point out that the working data can be manipulated using Pixel Math, which is how the bias, white balance and CCM were applied. I forgot to mention that in my previous post as another method to apply a transformation in Siril.

 

Each TIFF was subsequently opened in darktable with the input profile set to linear sRGB and display encoding set to sRGB. As expected, both files display the same in the darktable window when compared to the reference image. Conversely, if the input profile is changed to "embedded ICC profile" then both files display the same but look far darker compared to the reference image, which again is expected if linear data is misreported as being gamma encoded.

[BQ Octantis]

I have no issue decoding sRGB TIFFs as sRGB. The input and output match perfectly.

 

BT.709 primaries, γ=2.2, sRGB ICC

 

I had issues decoding sRGB TIFFs as Gamma 2.2. But I already described the fix above.

 

Adobe RGB (1998) primaries, γ=2.2, Adobe RGB (1998) ICC

 

I have no further issues.

 

Cheers,

 

BQ

Edited by BQ Octantis, 04 October 2023 - 09:25 PM.