Affinity Suite: Alpha transparency calculation

[NotMyFault]

12 hours ago, thomaso said:

1. Why is the Affinity "Blend Gamma" options and this thread only relevant for …

• … a.) Alpha/transparency but not opaque objects, which are affected by the un-linear perception, too?
• … b.) RGB documents but not CMYK, while the human''s un-linear perception doesn't change between colour spaces?

Opaque objects fully cover lower layers, so the de/re-gamma equals out.

CMYK should be gamma-sensitive, too. Need to test.

but it makes zero sense to use RGB blend formulas in CMYK. Blending is done in the document color model - except those blend modes which work by converting to HSV and back. And as we discussed in another thread the K channel and subtractive nature of CMYK leads to unexpected results when just using the formulas but on cmyk channels instead of rgb channels. cMYK works better when using tints instead of alpha, and tint on paper in substructure mode is a physically different way to work with light vs. Self-emitting RGB subpixel in additive mode.the dynamic range of cmyk printed on paper is smaller than RGB, so gamma matters less.

the human eye works the same and does not care about the color model used in software. 
 

Edit: 

Affinity simply ignores layer blend gamma in CMYK and uses gamma 1.0 for layer blending.

[NotMyFault]

2 hours ago, thomaso said:

Why does RGB 128 128 128 appear different than Grey 50% in an sRGB document?

Depends on which grey you are using. Grey color in GREY color format is differently encoded as sRGB. Those deviate especially in the darker tones.

for a test, create a black to gray gradient once in RGB and once in GREY (2 documents, and use the color panel in the native format of that document), make screenshots, and put them edge to edge to see the difference.

[NotMyFault]

2 hours ago, thomaso said:

3. How did brightness consistency work between Windows and Apple when they used different gamma settings until 2009?

Not sure, we must distinguish between gamma used in apps for layer blending, and gamma used on the linke to the display. Both can differ, when the OS, App and display is properly color managed the result will look identical. Only when you use non-color-managed apps, or e.f. Use a device profile as document profile, this would lead to rendering differences when devices use a different gamma than the app expects.

Important is that the full chain of color formats / profiles is managed end 2 end - something sRGB delivered by using a common subset which all devices are now capable since decades, or OCIO which provided standardization and tools to easily implement end-2-end color management across any input/output device and any app 

[NotMyFault]

3 hours ago, lepr said:

The upper and lower layer's RGB values are exponentiated by (2.2 / upper Blend Gamma) before blending, and the blending result's RGB values have the inverse exponentiation applied to them. The measured results in Affinity verify that, allowing for decimal rounding errors.

Notice that that implies no exponentiation happening in the case of the default Blend Gamma 2.2, and the measured results in Affinity verify that the RGB values are used "as is" in that default case.

Sounds promising, I will try to reproduce this when back on Mac /Windows

i was working on iPad last week where Photo has no info panel and I have no Excel.

[lacerto]

Obsolete.

[NotMyFault]

8 hours ago, lacerto said:

Why don't you bother to check if your arguments actually work or do not work in real life?

We are cross-talking. 

my example showing the issue:

1. take an image in RGB. It should have natural mix of colors - no test image with only 1-3 colors. Colors can be muted to fit into CMYK color space when converted in step 3.
2. add an invert adjustment.
3. now convert to CMYK. The rendering drastically changes. And I don’t focus on gamut differences, it’s about the formulas produce different results in additive vs. Subtractive color models.

As thomaso has found out:

in CMYK, Affinity ignores gamma values. If you put a rectangle gradient of blue from 0 to 100% opacity above a fully red rectangle, and set gamma to 2.2 on top layer, results will differ between RGB and CMYK documents.

take colors from within CMYK gamut, not fully saturated SRGB colors.

 

[NotMyFault]

15 hours ago, lepr said:

Leaving aside RGBA/32 documents where Blend Gamma is ignored and RGB values are used "as is" in blending, the following concerns RGBA/8 and RGBA/16 documents.

The upper layer's Blend Gamma value is factored in, yes, and I did not assert the opposite. However, your claimed linearisation of upper and lower layers before blending and then gamma encoding of the blending result is not performed, and that's why your spreadsheet does not give the same results as Affinity.

The upper and lower layer's RGB values are exponentiated by (2.2 / upper Blend Gamma) before blending, and the blending result's RGB values have the inverse exponentiation applied to them. The measured results in Affinity verify that, allowing for decimal rounding errors.

Notice that that implies no exponentiation happening in the case of the default Blend Gamma 2.2, and the measured results in Affinity verify that the RGB values are used "as is" in that default case.

Contrast that with your assertion that, in the case of Blend Gamma 2.2, RGB values are exponentiated by 2.2 before blending, and the blending result's RGB values have the inverse exponentiation applied to them. The measured results in Affinity prove that wrong.

 

 

so lepr was right and I had one misconception.

The color values are stored with gamma 2.2 (using sRGB profile). When you set a gamma value in blend ranges for a layer, Affinity transforms the values to that gamma value. As 2.2 is the default, no gamma correction applies and gamma 2.2 encoded values will be used for layer blending. This gives essentially wrong results in the sense that it does not conform to how physical light blends. To get a match to physical effects, you must use blend gamma 1 for all layers,

attached you can find  the improved formulas and a test document.

It shows  simple gradient with transition from blue to red. It uses afphoto instead of Designer to use color samplers (info panel), the results are other wise identical in Designer.

left side: RGB colors.

right side: CMYK colors.

 

top: gamma 2.2 (used for anything except text by default)

middle: gamma 1.45 (used for text by default)

bottom: gamma 1.0

between the test rectangles are gamma 2.2 reference rectangles, allowing to spot the difference where the layer edges touches.

Things to Do:

1. use the color samplers to read actual Affinity color values, and compare them with values from the excel sheet. Matches within bounds of rounding issues.
2. Convert document into CMYK. see how layer gamma becomes irrelevant: Affinity uses gamma 1.0 in CMYK. I need to check if values are store gamma encoded or linear.
3. Convert to RGB/32. See that blend gamma gets ignored, and document valour values are stored with gamma 1.

layer blending with alpha and gamma.xlsx Gma RGB CMYK.afphoto

[thomaso]

On 8/20/2024 at 3:30 PM, walt.farrell said:

2. In Document Setup (Designer, Publisher) or the Document menu (Photo), turn off Transparent Background. Sample the resulting color of the top Rectangle.

With "Transparent Background: off" the different gamma settings of text (1.45) vs. non-text objects (2.2.) may cause unexpected results: Then it appears Affinity can ignore the gamma setting of a transparent object on a white Page background, other than a white rectangle as background, and thus make text with gamma 1.45 appear like gamma 2.2.

16 hours ago, NotMyFault said:

Affinity simply ignores layer blend gamma in CMYK and uses gamma 1.0 for layer blending.

Why doesn't this cause issues … or why doesn't it ignore blend gamma for RGB ? – And does Affinity in CMYK documents use 1.0 – or does it use its default gamma 2.2 ? In case of 1.0, wouldn't the result look brighter, compared to 2.2 and 1.45, right?  – However, for what purpose / advantage might it work this way? Why should text objects require an extra gamma in RGB only – but don't in CMYK?

16 hours ago, NotMyFault said:

Grey color in GREY color format is differently encoded as sRGB. (…)
for a test, create a black to gray gradient once in RGB and once in GREY

Yes, obviously it's differently coded. I rather want to know/understand for what purpose/advantage Affinity got Greyscale coded with this difference?

Didn't the forum notice/mention here or there that Affinity handles Greyscale like RGB, and, for instance, therefore requires the extra button "K Only" for placed grayscale images in CMYK documents, although CMYK works with a K channel anyway (whereas RGB documents without a K channel did not get this button and thus should get more difficulties to convert Greyscale input)?

Your mentioned test shows identical gradients in the RGB document but different grays in the Greyscale document. It reminds me to the gradient comparison in your linked article, it looks as if in the Greyscale document RGB gets displayed with a different gamma setting. Still I don't understand why this happens or for what purpose it was coded this way.

…

This lead me to comparisons of K 50% with its numerical equivalents in the Colours panel (rgb 128, luminance/grey 50%), setup in CMYK versus RGB documents (both generic.icc, other profiles may differ more, for instance sRGB). In all three test documents LAB differs remarkable (why?), whereas only in the CMYK document also Greyscale shows a large difference.

Again I am attacked by the question: Why that difference of LAB in particular or of Greyscale especially in CMYK? You may say it's because of subtractive (materials) vs. additive (light) colours – but on screen every space is displayed via light and thus I'd expect they could be calculated & displayed with less difference, especially K-only vs. Greyscale.

@NotMyFault, thank you for your various answers! And sorry for asking same questions repeatedly. I just notice again and again that I didn't understand yet, sometimes I simply fail with certain terms or descriptions (e.g. "de/re-gamma" + "gamma equals out"). If it's annoying just ignore my thoughts, please. I might never be able to fully understand it.

[NotMyFault]

So many questions.

 

Affinity seems to use blend gamma (in blend range) only in RGB color model, but in no other color model (there it uses linear or gamma 1.0).

I can only guess that it historic convention and performance optimisation.

Before color management got widely standardised and implemented (by Adobe, HP, Microsoft, Apple when memory serves me well), graphic apps worked mostly "unmanaged" and the values in the documents were 1:1 send to output devices - you worked essentially in the color profile of the output device.

When sRGB was introduced, PCs and even graphical workstations were slow ( 1Mhz CPU 1 MB RAM 1 Mpix display) and gamma / exponential function was extremely slow, so many apps ignored the topic and performed layer blending without de-gamma (physically wrong, but fast).

CMYK is intended for paper - which has no inherent gamma curve (other than displays, the CRT).

sRGB simply standardised Gamma to be identical for stored files and displays (which is convention and has no direct technical reason), with the benefit of less CPU required for layer blending.

Even Affinity uses gamma 2.2 for layer blending by default, but at least you can change the default to get physically correct layer blending.

But note that gradients still produce wrong results, only if you create gradients manually by 2 or more layers you get correct blending / results.

LAB was introduced to create a more human oriented color model, so it is natural that it does layer blending correctly in gamma 1.0

 

Just to prevent one misconception:

Gamma encoding of RGB files is a method to more efficiently store color values, loosely related to human perception of brightness.

Unrelated, gamma curve of Devices is a technical attribute of CRT (cathode ray tubes) and has been carried over into the digital world originally for backward compatibility. By chance, both have been matched since introduction of sRGB, and this lead to the ugly performance hack of wrongly blending layers in most apps, including Affinity.

 

All said above is my personal mental model of what is going on, based on studying countless books and web pages, Affinity documentation and lots of experimenting with Affinity apps.

 

[NotMyFault]

Just to add another can of worms.

A more generic term is "transfer function", where gamma encoding is only one example off.

See https://en.wikipedia.org/wiki/Transfer_functions_in_imaging

Affinity recently added support for newer image formats, especially HDR capable formats. Those use new types of transfer functions, specifically HLG and PQ (e.g Canon CR3)

When opening such formats, Affinity converts them to RGB/32 and linear gamma. This is extremely unfortunate, based on more complex edit steps, more storage for files, and restrictions in filters (dust & scratch removal) and layer blend modes.

Affinity would need a major refactoring:

• allowing to edit images with any transfer function in best matching bit depth (e.g. RGB 16 for 10/12/14 bit HEIF files)
• Using Gamma 1.0 for layer blending by default instead of the outdated "classical sRGB Gamma 2.2", no matter what transfer function or gamma is used for encoding in stored files. Of course, allow classical gamma 2.2 for backward compatibility (option by user)
• When I say layer blending, this affects much more
  • pixel brushes always use gamma 2.2 in sRGB as far as I know, and ignore blend gamma. leads to ugly color seams, reported as feedback 
  • gradients use gamma 2.2 (in sRGB) ignoring layer blend gamma
  • you will find more

[NotMyFault]

4 hours ago, thomaso said:

With "Transparent Background: off" the different gamma settings of text (1.45) vs. non-text objects (2.2.) may cause unexpected results: Then it appears Affinity can ignore the gamma setting of a transparent object on a white Page background, other than a white rectangle as background, and thus make text with gamma 1.45 appear like gamma 2.2.

I cannot reproduce. Can you please share the actual file(s)?

[NotMyFault]

On 8/20/2024 at 2:59 PM, Pyanepsion said:

Hello everyone,

When we work in the Affinity suite and create an image with a single layer, alpha transparency modifies the perception of RGB colours in the software. But how do you calculate the equivalent colour without transparency? This is an important question, because not all software handles transparency in the same way, which can lead to differences in colour rendition.

Let's take a concrete example:

Suppose we have an image consisting solely of a rectangle with RGB colour (117, 120, 123) and alpha transparency of 70%. How can we determine the resulting colour if this transparency was not applied, in other words, the ‘flattened’ colour with no alpha transparency effect?

Happy creating!

I think we have now collected all facts to provide a definite answer:

• When using documents in RGB/8 or RGB/16, affinity uses sRGB layer blending and respects the specific blend gamma values set in every layer.
• By default, gamma 2.2 is used for all layers except text which uses 1,45. The default can be changed globally, but only affects new documents or new layers.
• Both is somewhat in line with many other apps, but leads to many ugly blend results, spefically 50% red on 100% blue
• For all other color formats (RGB/32, CMYK, LAB, GREY) Affinity ignores any blend gamma in layers and uses linear blending - which is physically correct and gives more natural looking results.
• In RGB/8 and /16, many tools like brushes (when used destructively in pixel layers) or gradient tool are fixed set to use Gamma 2.2 which gives unnatural blend results.
• In all other color formats, brushes and gradients create more natural results.
• Extra care may be required when exporting to PDF or using embedded documents and mixed color formats.
• Extra care may be required when using color panel in other color formats as document format.

[thomaso]

3 hours ago, NotMyFault said:

I cannot reproduce. Can you please share the actual file(s)?

@NotMyFault, nochmal Danke!  [Selbst auf Deutsch übersetzt kann ich deine Antworten kaum nachvollziehen, manches klingt widersprüchlich, weil mir Grundkenntnisse fehlen und ich von anderen Voraussetzungen ausgehe, oder weil ich Englisch anders verstehe/verwende als du. Schließlich wird es auch unklarer durch die Möglichkeit, parallel zu meinem Unverständnis über einen Affinity bugs zu stolpern, den ich dann nicht als solchen erkenne. ]

v1 gamma & opacity.afpub   Der Weiß-Weiß Test ist auf S. 2. (wenns für dich anders aussieht liegts vlt. an meiner V1).

[NotMyFault]

5 hours ago, thomaso said:

@NotMyFault, nochmal Danke!  [Selbst auf Deutsch übersetzt kann ich deine Antworten kaum nachvollziehen, manches klingt widersprüchlich, weil mir Grundkenntnisse fehlen und ich von anderen Voraussetzungen ausgehe, oder weil ich Englisch anders verstehe/verwende als du. Schließlich wird es auch unklarer durch die Möglichkeit, parallel zu meinem Unverständnis über einen Affinity bugs zu stolpern, den ich dann nicht als solchen erkenne. ]

v1 gamma & opacity.afpub   Der Weiß-Weiß Test ist auf S. 2. (wenns für dich anders aussieht liegts vlt. an meiner V1).

Das liegt an der Gruppe und blend mode passtrough. Ist ein immer noch open bug seit V1. 

[thomaso]

5 hours ago, NotMyFault said:

Das liegt an der Gruppe und blend mode passtrough. Ist ein immer noch open bug seit V1. 

Does "still open bug since V1" mean that you now can reproduce it in V2? (or @walt.farrell?)

To me neither blend mode "Normal" nor un-grouping changes the appearance of gamma 1.45 on a white page background.
– Also I experience this in a CMYK document, where gamma gets ignored (= independent of gamma), and regardless of the colour model of the black, semi-transparent object.

The Affinity page white appears to work different than a white fill colour – but also than transparency: Page white has to be disabled to preserve transparency for a PNG export, and different to PDF export for instance.

[walt.farrell]

11 minutes ago, thomaso said:

Does "still open bug since V1" mean that you now can reproduce it in V2? (or @walt.farrell)

Sorry, but I'm not sure which bug is meant, and this conversation has gotten far beyond my understanding, so I won't even try to reproduce what is being discussed as I would probably get it wrong.

[PaulEC]

To be honest this thread left me behind long ago; I'm still wondering why anyone would use transparency to modify a colour in the first place, if it's so important to reproduce the colour exactly! 😏

[NotMyFault]

@thomaso @walt.farrell

[NotMyFault]

57 minutes ago, thomaso said:

 

To me neither blend mode "Normal" nor un-grouping changes the appearance of gamma 1.45 on a white page background.

I tested your file on Publisher V2 on iPad. As there is no V1 on iPad I test with Photo V1. Changing the group layer blend mode immediately gives correct result.

 

 

Edited August 27, 2024 by NotMyFault
Correct attachments

[thomaso]

1 hour ago, walt.farrell said:

I'm not sure which bug is meant, and this conversation has gotten far beyond my understanding, so I won't even try to reproduce what is being discussed as I would probably get it wrong.

Sorry if I confused with various questions. My last post (with video) refers to your first post in this thread with the hint to activate page white for the colour picker on transparency – and my deviating experience: On page white a transparent object with gamma 1.45 (-> i.e. a text object by default) appears visually & numerically different … than on a white fill colour:

     

1 hour ago, NotMyFault said:

Changing the group layer blend mode immediately gives correct result.

Does it mean that text objects with gamma 1.45 do correctly appear identically like gamma 2.2… not brighter or darker? – Compare the video at 37 – 43 sec.:

1. Blend mode "Passthrough" shows different greys on page white vs. white filled rectangle:

2. As soon "Normal" gets selected for this Group the greys appear like gamma 2.2. and regardless of page white or white fill:

3. As soon the Group gets ungrouped the difference between grey on page white vs. white fill is back:

PS: Doesn't your linked bug AF-2951  explicitly concern/require masking… whereas in this thread / this example a mask is not involved?
 

1 hour ago, PaulEC said:

I'm still wondering why anyone would use transparency to modify a colour in the first place, if it's so important to reproduce the colour exactly! 😏

Yes, especially transparency on nothing / on white may lack in a practical use case. Meanwhile I am rather interested to understand what's going on when I see different greys / get different values just caused by different "types of white". Also, if there is a bug involved it appears useful to be aware of that culprit, right?

[NotMyFault]

1 hour ago, thomaso said:

PS: Doesn't your linked bug AF-2951  explicitly concern/require masking… whereas in this thread / this example a mask is not involved?

The bug affects any layers having partial transparency. 
No matter if caused by mask layers, layer opacity, color opacity, fill opacity.

It is independent from gamma. Just by chance you used an example with group and passthrough. To keep everything organized, don’t use this combination when discussing gamma related topics, because you have then 2 issues combined, making it even more complex.

for the discussion of gamma impact and transparency blending, we do not need groups. When creating example files, use rectangles as parent layers instead (this have own issues with anti-aliasing at edges, so make the rectangles large and don’t clip anything at the edges).

a similar unfixed bug (at least in V1) exists with fill layers and partial opacity, please don’t use them as example in this thread, too.

[thomaso]

On 8/20/2024 at 7:06 PM, NotMyFault said:

Test layers use gamma=1.45 by default, so layer blending can differ for text and other layers (visible when layer opacity is not 100%. For a test, use a text layer and rectangle, both 50% opacity, each covering a different part, but touching at the edges. blend color will differ.)

On 8/21/2024 at 7:44 AM, NotMyFault said:

The test file shows the impact of gamma. Both the text and the upper rectangle share the same global color 117/120/123, and use 70% opacity.

no matter if you use white or black background, the blendung results differs due to gamma 1.45 for text and 2.2 for all other layer types.

you cannot ignore gamma for semi-transparent layers, in RGB/8.

Apart from the grouping/blend mode issue: If, as mentioned early in this thread, the visual appearance is meant to differ with gamma 1.45 versus 2.2, then I don't understand your recent conclusion in the iPad test where you judged the sample with same colour appearance as the correct result and the one with brighter appearance as the wrong one:

2 hours ago, NotMyFault said:

Changing the group layer blend mode immediately gives correct result.

"Passthrough" + visually different colours = wrong?

"Normal" + visually same colours = correct?

Or vice versa: If objects with gamma 1.45 and others with 2.2 are supposed to look the same (= don't influence the object's appearance), – what is the purpose of the extra gamma setting for text?

[NotMyFault]

40 minutes ago, thomaso said:

Apart from the grouping/blend mode issue: If, as mentioned early in this thread, the visual appearance is meant to differ with gamma 1.45 versus 2.2, then I don't understand your recent conclusion in the iPad test where you judged the sample with same colour appearance as the correct result and the one with brighter appearance as the wrong one:

I have to correct myself, as i was focussing on color difference between text and rectangle on the left, leaving aside the correct color.

The rendering is wrong when layers are child of the group, it only gets correct when you remove them from the group. While grouped, child layers get blended without considering the lower layers below the group, and then the blend result gets blended against lower layers, but this time using the blend gamma of the group (instead of child layers). 

please test by not using groups in this thread. The impact of groups is another level of complexity we should discuss in a separate thread.

[thomaso]

4 minutes ago, NotMyFault said:

The rendering is wrong when layers are child of the group, (…)

please test by not using groups in this thread.

It is still unclear – entirely independent of groups/blend modes:

What is the correct look of colour brightness for gamma 1.45 objects vs. 2.2 objects in your two iPad screenshots: The same brightness ("Normal") or different brightness ("Passthrough")? You said "Normal" would show the correct result. This conflicts with your earlier hints about differing colours.

Of course, I realized this issue with white page background initially with an ungrouped layer setup. The groups were created only for the screenshot, a slimmed Layers panel and to separate visually between upper (white background rectangle) and lower examples (paper white).

Also the video shows the relevant example (on white page background) with entirely ungrouped/childless layers, as shown before or in this detail: No group, no children but darker gray on page white versus lighter gray with the white rectangle background.

[NotMyFault]

Hi

lets start fresh with a very simple test document. It shows how Affinity is rendering transparency with different alpha values.

3 red rectangles (255 0 0 127) over transparent background and a white rectangle in bottom half with a alpha transition from 0 to 100%. Only difference is blend gamma 

Please inspect the color rendering of Photo, in combination with the info panel color values.

on transparent backgrounds the red rectangle look identical, no matter what gamma is used.

Here Affinity is kind of cheating: because you have no background, it does not perform any layer blending, and gamma is not used.

Nevertheless, the color shown as rendering result is the same as if you had a fully white canvas or white rectangle (and important: as if the top layer had gamma 2.2, ignoring the actual layer blend gamma)

In the bottom half, you have a white rectangle with a gradient on alpha. in the very bottom it is fully opaque.

And then you will spot color differences both in info panel and in color rendering.

What do we learn?

• Better do not create documents with remaining semi-transparent areas. it is getting messy, as Affinity is actually imitating a white background and gamma 2.2 for top layer  for rendered results (and not a black background!), and you can't see the impact of layer gamma, and rendering differs between "virtual" white background and a real white rectangle.
• I just found another inconsistency which I will file as new bug report separately.

 

layer blending alpha gamma.afphoto