Colour palette behaviour in linear gamma

[Herbert123]

In Krita and other drawing/image editing applications when a linear colour profile is assigned or converted to, the colours in the colour palette remain the same, regardless of working in linear or non-linear mode.

Like so:

krita.jpg

In PhotoLine switching or converting to a linear gamma affects all the colour palette entries as well:

pl_color_palette.jpg

While strictly spoken from a mathematical or colour management workflow this might seem correct behaviour, as an artist we rely on colour palettes to remain the same whether we work in linear or non-linear mode, because the primary reason to be working in linear mode is to avoid the broken internal representation of how most design apps treat RGB code values by mis-converting light ratios via broken calculations.

This is why Photoshop has that arbitrary "linear blending" preference option to circumvent the broken blend math.

Krita respects the digital artist's workflow by AVOIDING to change the colour palette values from the outset, and even when we work in linear mode and thereby allow the light to blend naturally, we can still rely on the colour palette entries to be 'correct' - perceptually correct. Because working with a linear gamma when selecting colours just doesn't make sense in an artist workflow. That is not how reality works.

As Troy Sobotka[1] mentions:

Linear light transport is crucially important in all DCC pixel compositing math because the RGB code values always represent light, and if the code values aren’t properly converted to light ratios, bad, awful, no-good math results. RGB code values always represent light emissions.

Blending, smudging, generic painting, compositing, blurring, and any other operation where pixels are being manipulated absolutely must be performed upon RGB values that maintain a radiometric linear light transport model set of ratios if we hope to have it model / emulate the experiential learned “correct” results from our physical reality around us.

In my opinion allowing an image editing / digital artist application to affect the colour palette entries based on the colour profile and its gamma setting is just plain wrong. The colour values should be converted to stick perceptually to their original intent.

Because any digital artist is going to have an extraordinarily hard and frustrating time when their carefully selected colour palettes become completely unusable just because they need to avoid the wrong broken blend math when working in non-linear gamma colour modes. I cannot work with the same colour palette between Krita and PhotoLine now. And the colour values in PhotoLine make no sense whatsoever, because the entire palette is broken.

Krita does it right. PhotoLine does it wrong (sorry).

That said, I can see that there is a case to be made (from a purist's math perspective) that some here would argue against all this, so here is my request:

PLEASE include at the very least an option in the colour setting to control how the colour palette behaves when the user switches to linear mode.

In case some here do not understand the issue that I am writing about - see for yourselves:

Wrong broken blend math


Correct blend math


[1] https://hg2dc.com/2019/07/21/question-9/

[shijan]

In Ps and Affinity Palettes don't remain the same in Linear gamma. Sometimes UI just don't refreshes automatically and they look the same. But once you open and close document - palettes gamma will change.

Automatic mode to preserve Linear gamma sounds like nice idea, but it also should be an option to automatically preserve Color Space.
I asked earlier for manual option to "Convert with Color Profile" for Color Swatches here: https://www.pl32.com/forum3/viewtopic.p ... 643#p49643

[Herbert123]

Yes, I know about Photoshop - those developers "solved" part of the issue by introducing that "linear blending" option in the preferences.

Converting colour palettes manually is not a viable long-term solution, in my opinion. Are digital artists supposed to switch to different colour palette versions depending on which colour management profile is used? That's just plain silly!

Nor should the average user be encumbered by such things. Affinity and Photoshop also demonstrate this wrong behaviour. I feel this is caused more by developers' tendency to follow the math and wrong outdated interpretations of colour management theory rather than looking at how physical reality and artists actually work.

[shijan]

In this possible system it is also a big question how exactly transform color space of Color Palettes. Most Color Palettes usually designed for sRGB color space. Relative Colorimetric transformation don't expands color values from smaller to larger color space, so we can't have better saturated color palettes in large color spaces. So in this case we just preserve sRGB look and feel in wide gamut document. This may be not exactly correct way to go.
Color values could be transformed using Absolute Colorimetric, but it also limited by CMM system and can't expand colors to larder color space until you transform to printer ICC profile.
So perfectly it should be some special method to transform Color Palettes to wider color spaces with visually preserved color and same time with sightly expanded color values.

This is why most apps just preserve color numbers in Palettes and don't transform color.

Transformation of gamma tone response curve alone is way easier and simpler task.

[Hoogo]

I'm not an artist, so I lack the thinking of artists...
When I use palettes, then it's for conversions or painting.For both purposes I'm simply happy with sRGB, and I don't care about Gamma.
When I'm doing something "physical" in photos, then I prefer linear Gamma, but do not care about Palettes anymore.

So personally, I don't have the need to think about such detail.I remember that I also was thinking about that detail in the past, but I guess it was just a theoretical question.

And if I REALLY needed to keep same colors for any color space: Shouldn't a palette in Lab fix the problem?

[shijan]

I'm not an artist, so I lack the thinking of artists...
When I use palettes, then it's for conversions or painting.For both purposes I'm simply happy with sRGB, and I don't care about Gamma.

I guess the global Herbert123's idea (as well as my earlier requests) is to use PhotoLine for painting in Linear gamma. This needs at least two improvements:
1. Linear gamma correction for Palettes, so artist could see visually normal colors in Palettes when work in Linear Gamma.
2. 16-bit support for brushes to paint in Linear gamma without banding artifacts.

[Hoogo]

...
1. Linear gamma correction for Palettes, so artist could see visually normal colors in Palettes when work in Linear Gamma.
...

And a palette with Lab Colors won't do? I can't test right now, I assume that Vectors with Lab color look the same, no matter what color space a document has, and I assume that brushes convert their Lab color to document space the moment they are used.

[shijan]

If explain problem in more technical way, currently Palettes colors are not color managed. If Document ICC profile/gamma is different from sRGB, Palettes colors visually looks incorrect. So Palettes behave like non color managed sRGB image.
But from some point it is also not true. For example there are a lot of palettes created specially for CMYK color model, so formally they should not be used in sRGB Documents and it is incorrect to set input sRGB profile to these Palettes.

So we need some user option to apply color management to Palettes. sRGB input profile/gamma may be virtually set to all palettes and then virtually converted to Document Profile or Layer Profile, or Isolated Group profile to preserve original appearance. So Palettes should behave same as color managed sRGB image.

This could be global setting or special individual checkbox for each palette collection.

P.S. I didn't test Lab palettes earlier. I'll check it later.

[shijan]

And a palette with Lab Colors won't do? I can't test right now, I assume that Vectors with Lab color look the same, no matter what color space a document has, and I assume that brushes convert their Lab color to document space the moment they are used.

Ok, i tested it. Palettes in Lab model applied to Vector Objects. Document set to sRGB.
If i change document sRGB to Linear sRGB, Vector object gamma visually don't changes. This is very nice!
But Palettes itself visually change color. This is a problem.



It is also interesting that if i create color Palette in CMYK Mode, palette don't change gamma when i switch document to from sRGB to Linear sRGB.



Another possible useful idea: some option to quickly convert multiple selected Palettes from RGB to Lab/CMYK/Gray/HSV models.

[der_fotograf]

Linear light transport is crucially important in all DCC pixel compositing math because the RGB code values always represent light, and if the code values aren’t properly converted to light ratios, bad, awful, no-good math results. RGB code values always represent light emissions.

Blending, smudging, generic painting, compositing, blurring, and any other operation where pixels are being manipulated absolutely must be performed upon RGB values that maintain a radiometric linear light transport model set of ratios if we hope to have it model / emulate the experiential learned “correct” results from our physical reality around us.

AND

Nor should the average user be encumbered by such things. Affinity and Photoshop also demonstrate this wrong behaviour.

So there is absolutely NO reason to implement some kinky stuff in PL for one or two single users.

If you are not satisfied with PL, go and get some other »better« software. Again: You will NOT pay a surcharge for the features you request. And most of the users don't need those kinky features, so why do you want to put pressure on the developers to waste their time and on the users to pay for something they definitely do NOT want or use?

[Herbert123]

So there is absolutely NO reason to implement some kinky stuff in PL for one or two single users.

If you are not satisfied with PL, go and get some other »better« software. Again: You will NOT pay a surcharge for the features you request. And most of the users don't need those kinky features, so why do you want to put pressure on the developers to waste their time and on the users to pay for something they definitely do NOT want or use?

? Where is this coming from?

I (and shijan) have proposed and requested new features and improvements across the board for PhotoLine throughout the past 15 odd years, and most of those have benefited the average user as well.

Don't you think it is odd and counter-intuitive that the color palette shifts when switching to linear? And isn't a natural blending of RGB intensity values of great value to photographers as well? Because when working in 8bit non-linear srgb the same blending issues occur.

So suppose as a photographer you are blending a blurred reddish object onto a cyan dress, you get the same dark unnatural blending between the two colours. In particular as a photographer (digital artist) we would expect a natural blending of values, correct?

In my opinion these changes would benefit EVERYONE.

And I am quite surprised that a photographer user wouldn't want blending to behave naturally according to what we experience in the physical world. Seems like a no-brainer to me.

(PS the entire reason for this conversation is the fact that we MUST switch to linear gamma in PhotoLine to achieve a natural physical looking blending between RGB intensities. Otherwise the blending is just plain WRONG!)

[shijan]

One more thing that may somehow be related to Palettes color management logic. Here is how to reproduce:
Create document and set sRGB color profile (sRGB color space / sRGB TRC).
Create colored Vector objects (for example with 100% Red Green and Blue value)
Convert document to custom made wide gamut color space that use sRGB TRC (i used PhoPhotoRGB color space / sRGB TRC)
Result: Vector colors visually remains the same, but color values numbers now changed (Green now use 94.2 % value). So vector colors preserve normal color management logic. This is nice, but sometimes may be not desired.
Same time colors in Palettes behave different. Green color still use 100% value and so visually changed:



But if we use vector gradient and convert document to profile with different TRC (for example to sRGB with Linear Gamma TRC), gradient visually changes. So tonal relations don't preserve normal color management logic:


I guess for vector objects in layer settings it could be a checkbox or toggle "Preserve Color Numbers" / "Preserve Visual Appearance", so when transform document to other color profiles, user could manually decide to keep vector objects color and gradient values, or remains them visually the same, but change values.
Same checkbox could be somewhere specially for for Palettes. Or It cold be a Checkbox somewhere directly in Color Editor.

[shijan]

P.S. Probably this "Preserve Color Numbers" / "Preserve Visual Appearance" system may work well for vector objects because they always have Document ICC profile as starting point for Color Space/TRC, but i really can't see exactly how to apply it for Palettes. Palettes don't have any starting point ICC profile, so they rely only to numbers. The only more-less simple way to go - manually duplicate Palettes group and manually convert all palettes from/to some Color Space/TRC, as i requested in earlier.

[shijan]

P.P.S. it is possible to preserve visual look of Vector Gradient, if set own ICC profile to Gradient Layer. This is sort of partial problem fix, but it still feels really strange why vector plain colors and vector gradient use totally different color management logic.