Jump to content
You must now use your email address to sign in [click for more info] ×

How to Edit the Alpha Channel


Recommended Posts

If pre-multiplication would be used, any RGB/8 image reduced to the lowest possible alpha value of 1/255, it would loose all color details, as the multiplication would result in either 0 or 1 (divided by 255) for every color channel. This is not the case. 

Mac mini M1 A2348 | Windows 10 - AMD Ryzen 9 5900x - 32 GB RAM - Nvidia GTX 1080

LG34WK950U-W, calibrated to DCI-P3 with LG Calibration Studio / Spider 5

iPad Air Gen 5 (2022) A2589

Special interest into procedural texture filter, edit alpha channel, RGB/16 and RGB/32 color formats, stacking, finding root causes for misbehaving files, finding creative solutions for unsolvable tasks, finding bugs in Apps.

 

Link to comment
Share on other sites

8 hours ago, Guillermo Espertino said:

 

12 hours ago, NotMyFault said:

Apply image has a big disadvantage: It cannot be used with macros and free choice of source and destination image. One layer will be baked-in during macro recording. 

Ah, ok. good point. In all fairness, the lack of scripting and the limited scope of macros is an aspect where Affinity apps fall short.

To add another even more relevant point, without macros: you cannot save the parameters/formulas in any form. You need to manually fill in all parameters every time, which is really tedious.

All other adjustments can be saved as presets, and both adjustments and filters can be copied or saved in template files for easy reuse.

Mac mini M1 A2348 | Windows 10 - AMD Ryzen 9 5900x - 32 GB RAM - Nvidia GTX 1080

LG34WK950U-W, calibrated to DCI-P3 with LG Calibration Studio / Spider 5

iPad Air Gen 5 (2022) A2589

Special interest into procedural texture filter, edit alpha channel, RGB/16 and RGB/32 color formats, stacking, finding root causes for misbehaving files, finding creative solutions for unsolvable tasks, finding bugs in Apps.

 

Link to comment
Share on other sites

9 hours ago, NotMyFault said:

Affinity does the multiplication only during layer blending.

Yes, this is what I said.

9 hours ago, NotMyFault said:

But it does not store the pixel layers pre-multiplied, neither in afphoto, nor in exported formats by default. There are very few exceptions of exported files formats who store alpha premultiplied.

Yes, that's correct and it's easy to confirm that in the channels panel.
However, when you export an image to an unassociated alpha format, composited layers get indeed premultiplied/postdivided. Try creating any image with masks applied to layers (not on top of the layer stack) and check the exported image and the semi-transparent pixels.
That's why I suggested the workaround of using a small value for alpha instead of 0, to allow the premultiply/postdivide operation with a minimum value avoiding division by 0.
As I mentioned earlier, that's the same idea behind the import method for associated EXRs, that otherwise would lose the luminescent transparent pixels in Affinity's unassociated pipe.
 

9 hours ago, NotMyFault said:

Otherwise it would be impossible to regain RGB colors in places where we have zero alpha value.

"regain" RGB colors in places where alpha is 0 is impossible with unassociated alpha after an alpha over operation. Unassociated alpha is not really alpha transparency but a stage in the creation of a transparent image. Compositing it over a background always requires a multiplication by alpha.
That's why In unassociated alpha it's impossible to express pixels that emit light and are transparent at the same time.
Associated alpha allows that but Affinity Photo, like Photoshop, is designed to use unassociated.

Pixels with alpha=0 in unassociated images are expected to be lost in compositing. You don't create an alpha channel to preserve those pixels, unless you're doing some channel packing stuff for games.
Apart from that, there's only one use-case for a non-destructive mask, and that's the need of editing the transparency later.
But you don't use final delivery formats for that, that's what formats like PSD or AFPHOTO are for, where masks stay as masks, and not as alpha channel.

 

9 hours ago, NotMyFault said:

Pre-multiplied is defined as RGB values are stored pre-multiplied with alpha, which is not the case. It is not forced-coupled with alpha-composition during layer-blending where you always can to this multiplication on the fly (without “pre-“)

Not exactly. Pre-multiplied is a crappy term that should be replaced by "associated". There are many ways to produce an image where RGB represents emission and alpha represents occlusion (that's the model of alpha transparency) without involving any multiplication. CG renders, for instance, have associated alpha without multiplying rgb*a
You can alpha-composite an image of a candlestick with its flame shot on black background using a roto of the stick, without any multiplications (a multiplication would destroy the flame).

However, when the pipeline/workflow uses unassociated alpha, the multiplication is mandatory. Either pre-multiplying the alpha or using a multiplication in the alpha-over operation. If it's done pre-multiplying the source or on the fly by the alpha over op doesn't change the fact that the foreground loses the RGB where alpha is 0.

The over operation is basically an addition. You're adding light from FG's RGB to BG's RGB. Alpha dictates what pixels are covered by the foreground (occludding bg's light) or not. That's why I said above that unassociated alpha is just a stage in the formation of an image with transparency. The emissions that don't belong to the foreground need to go away.

Link to comment
Share on other sites

8 hours ago, NotMyFault said:

If pre-multiplication would be used, any RGB/8 image reduced to the lowest possible alpha value of 1/255, it would loose all color details, as the multiplication would result in either 0 or 1 (divided by 255) for every color channel. This is not the case. 

No, that's incorrect.

Check the attached file. It has a multiplication by the smallest 8-bit integer value possible above 0 and a division by the same number, and the result is the original colour.

multiplication-division.afphoto

Link to comment
Share on other sites

2 hours ago, Guillermo Espertino said:

No, that's incorrect.

Check the attached file. It has a multiplication by the smallest 8-bit integer value possible above 0 and a division by the same number, and the result is the original colour.

multiplication-division.afphoto 1.33 MB · 1 download

 

Your example is deeply flawed. You have chosen to use one of the only eight RGB colours, out of the available 16,777,216 RGB colours, that will be faithfully restored by the division following the multiplication.

@NotMyFault was correct.

Check the attached file which uses a gradient from black to red instead of your solid red. 

gradient multiply divide.afphoto

Link to comment
Share on other sites

4 hours ago, Guillermo Espertino said:

Pixels with alpha=0 in unassociated images are expected to be lost in compositing. You don't create an alpha channel to preserve those pixels, unless you're doing some channel packing stuff for games.

There are people who wish to use Affinity for "doing some channel packing stuff for games."!!!

Those people are frustrated by Affinity setting RGB to zero where alpha is zero (which is not the associated alpha (a.k.a. premultiplied alpha) that you keep writing about) except when particular unintuitive workarounds are employed.

 

Link to comment
Share on other sites

48 minutes ago, ,,, said:

 

Your example is deeply flawed. You have chosen to use one of the only eight RGB colours, out of the available 16,777,216 RGB colours, that will be faithfully restored by the division following the multiplication.

@NotMyFault was correct.

Check the attached file which uses a gradient from black to red instead of your solid red. 

gradient multiply divide.afphoto

to proof this with exactly all possible 8 bit colours:

 

image 1: all 16,7 million colours:

1143792426_Screenshot2023-02-22at19_49_58.thumb.png.7b51aca27be44f6bf815d8c313251583.png

Image 2 pre-multiplied values with 1% leads to posterization with 3 steps (after restoring alpha to 100%):

2126661425_Screenshot2023-02-22at19_50_09.thumb.png.96cc33467d82acfecf9c7b242fd6c326.png

Image 3 whereas alpha of 1% makes colors almost invisible - but the scope panel shows all is still present:

1045720598_Screenshot2023-02-22at19_50_55.thumb.png.b1835dadc3e917d609f98a937686a071.png

Image 4: adjusting the alpha channel to 100% gets back all colours without loss or posterisation:

2060652266_Screenshot2023-02-22at19_51_02.thumb.png.93fed861ef269d2a324bca185ebaee67.png

all8bitcolors premultiply alpha.afphoto

Mac mini M1 A2348 | Windows 10 - AMD Ryzen 9 5900x - 32 GB RAM - Nvidia GTX 1080

LG34WK950U-W, calibrated to DCI-P3 with LG Calibration Studio / Spider 5

iPad Air Gen 5 (2022) A2589

Special interest into procedural texture filter, edit alpha channel, RGB/16 and RGB/32 color formats, stacking, finding root causes for misbehaving files, finding creative solutions for unsolvable tasks, finding bugs in Apps.

 

Link to comment
Share on other sites

4 hours ago, Guillermo Espertino said:
12 hours ago, NotMyFault said:

Affinity does the multiplication only during layer blending.

Yes, this is what I said.

I disagree, what you describe as "premultiplied" its definitely not what I described as "not premultiplied".

As other people besides my person provided more than sufficient evidence to disprove your claims, I step away from continuing this discussing to avoid endless repetition of the same arguments. All is said. Everyone can find claims and arguments from all involved document here, and build his own conclusions.

Mac mini M1 A2348 | Windows 10 - AMD Ryzen 9 5900x - 32 GB RAM - Nvidia GTX 1080

LG34WK950U-W, calibrated to DCI-P3 with LG Calibration Studio / Spider 5

iPad Air Gen 5 (2022) A2589

Special interest into procedural texture filter, edit alpha channel, RGB/16 and RGB/32 color formats, stacking, finding root causes for misbehaving files, finding creative solutions for unsolvable tasks, finding bugs in Apps.

 

Link to comment
Share on other sites

@Guillermo Espertino: By now, you should be doing your own experiments to ascertain or discredit my (and others) claim that Affinity is not storing premultiplied RGB values in pixels and is instead only setting RGB to zero where alpha is zero while storing straight RGB values when alpha is any other value.

If you are struggling to do so, I can try to help.

 

 

Link to comment
Share on other sites

I was definitely wrong when I implied that any colour could be retrieved after multiplication and division. In 8-bit precision is really low and therefore destructive. You're right, thanks for pointing it out and showing the example. Even further, if you used the value I suggested (1 in 8-bit integers) it would be even more destructive than your example, where you used 1%.

I'm perfectly fine with being wrong, and you proved that many of the things that I affirmed were wrong. I've been wrong before, I can be wrong on this one too, and I'm certainly going to be wrong in the future, not a big deal.

Now, honest question: why do you think that what you just showed in your all-colors example doesn't happen when you use the same small value as a mask and composite a few layers together?
I'd expect the same destructive behavior in 8-bit, since the foreground has to be multiplied. Alpha over for unassociated alpha in 8-bit is fg*a+((255-a)*bg).
The pixel math doesn't change, unless affinity is using internally more precision for the composite and it reduces the precision for the final projection.

Link to comment
Share on other sites

1 hour ago, Guillermo Espertino said:

Now, honest question: why do you think that what you just showed in your all-colors example doesn't happen when you use the same small value as a mask and composite a few layers together?

Affinity deletes RGB color values (set to zero / black) whenever the alpha channel inside one layer gets zero, e.g. by erase brush, or layer blending. This is unrecoverable.

Similar, when layers get blended and alpha gets zero, RGB gets zero.

But if you have a separate mask layer on top, the values inside the layers below stay intact. Masks layers are not subject to layer blending! They get combined with layers below directly by setting a new alpha value. No blend formula is applied on the mask itself. Several mask layers get „multiplied“
The result of pixel layer + mask layer of course can be blended with other layers.

When exporting, Affinity leaves RGB values unchanged if a separate mask layer is used on top. (No layer blending!).

When importing files, you can recover RGB values within a pixel layer by filling the alpha channel (after extracting alpha as spare channel).

But you can’t use a channel mixer adjustment for recovery non-destructively : because layer blending kicks in, and zeroes out RGB.

Mac mini M1 A2348 | Windows 10 - AMD Ryzen 9 5900x - 32 GB RAM - Nvidia GTX 1080

LG34WK950U-W, calibrated to DCI-P3 with LG Calibration Studio / Spider 5

iPad Air Gen 5 (2022) A2589

Special interest into procedural texture filter, edit alpha channel, RGB/16 and RGB/32 color formats, stacking, finding root causes for misbehaving files, finding creative solutions for unsolvable tasks, finding bugs in Apps.

 

Link to comment
Share on other sites

3 hours ago, NotMyFault said:

But if you have a separate mask layer on top, the values inside the layers below stay intact. Masks layers are not subject to layer blending! They get combined with layers below directly by setting a new alpha value. No blend formula is applied on the mask itself. Several mask layers get „multiplied“

The result of pixel layer + mask layer of course can be blended with other layers.

The part I can't wrap my head around is how do you avoid layer compositing if you have two layers with masks?
You have to put masked A over masked B, and that's the part that I insisted before that is inescapable.

Let's say you want to put 50% red over 50% green. How exactly is that done if it's not with alpha blending? The foreground is partially occluding the emission from the background. That occlusion is a multiplication by mask!

With linear associated images it's easy: it's basically adding  0.5 red to 0.25 green and the alpha channel ends up being 0.75

Leaving the non-linearity of 8-bit images aside, how does one composite 50% red over 50% green in unassociated 8-bit without multiplying RGB by mask?

I swear I'll stop if you explain that, because it's the main reason why I insisted so much on alpha association before (and although I admitted being wrong about a couple of claims I made, I'm still pretty convinced that you can't do it without multiplying by mask at some point, unless there's some compositing formula that's not porter-duff I'm not aware of or Affinity is actually doing it, but using more precision for internal buffers).

Link to comment
Share on other sites

5 hours ago, Guillermo Espertino said:

Let's say you want to put 50% red over 50% green. How exactly is that done if it's not with alpha blending?

When you treat the alpha channel as something different from alpha, e.g. as z-axis / depth (this is the use case for this thread and the requirement to edit alpha channel directly) it makes no sense to use it for layer composition/ alpha blending. 

You have de-compositioned all 4 channels into greyscale layers, and use blend mode add to combine the 3 color channels back into a regular RGB colored representation. The alpha channel stays separate as mask on top of the layer stack.

Never the less, you can use the alpha channel for layer blending whenever you want - just apply mask layers directly to pixel layers instead of keeping it separated as top level. But then zero alpha will erase RGB colors. It does not make sense to combine both styles within one document from a workflow perspective.

So if you are asking for a way to eat a piece of cake and do not eat the cake - I have none. Decide what you want. You can do both - but not at the same time.

 

Mac mini M1 A2348 | Windows 10 - AMD Ryzen 9 5900x - 32 GB RAM - Nvidia GTX 1080

LG34WK950U-W, calibrated to DCI-P3 with LG Calibration Studio / Spider 5

iPad Air Gen 5 (2022) A2589

Special interest into procedural texture filter, edit alpha channel, RGB/16 and RGB/32 color formats, stacking, finding root causes for misbehaving files, finding creative solutions for unsolvable tasks, finding bugs in Apps.

 

Link to comment
Share on other sites

9 hours ago, NotMyFault said:

When you treat the alpha channel as something different from alpha, e.g. as z-axis / depth (this is the use case for this thread and the requirement to edit alpha channel directly) it makes no sense to use it for layer composition/ alpha blending. 

You have de-compositioned all 4 channels into greyscale layers, and use blend mode add to combine the 3 color channels back into a regular RGB colored representation. The alpha channel stays separate as mask on top of the layer stack.

Never the less, you can use the alpha channel for layer blending whenever you want - just apply mask layers directly to pixel layers instead of keeping it separated as top level. But then zero alpha will erase RGB colors. It does not make sense to combine both styles within one document from a workflow perspective.

So if you are asking for a way to eat a piece of cake and do not eat the cake - I have none. Decide what you want. You can do both - but not at the same time.

 

Sorry, but this doesn't address what I asked above at all.
You and @,,, insisted that I was wrong and that alpha multiplication wasn't used, and Affinity photo for some mysterious reason just zeroed RGB pixels with alpha=0.
I suggested that the most likely suspect for that was alpha multiplication in layer blending, but you consistently tried to prove me wrong.
However neither of you have answered so far my question: How do you composite unassociated layers without multiplying the foreground by its mask?
And if the answer is that you can't composite layers without that multiplication, what do you think that happens when alpha is zero?

I know this has been long and tedious, but people complained in this thread about RGB being zeroed when alpha=0, and I tried to provide both an explanation and a workaround that in 16bit works well (but in 8-bit falls apart as you correctly pointed out because of the lack of precision).

Don't get me wrong. If you're a game artist who has 4 grayscale textures and need to pack them into an unassociated RGBA image for some game engine, the solution you provided is PERFECT. It shows you can produce that kind of images in Affinity (while some people suggested it wasn't possible).
So one of the good outcomes of this thread was that there's an excellent method for that, and you don't have to move to different applications sinces it's already possible in Affinity.
Also, temporarily removing alpha channel from an imported image and replacing the alpha with a fully opaque one solves the problem of RGB set to zero where alpha is zero, so you can also edit imported images.
Anyone who needs the channel packing method and reads this thread can pick that up, and that's a huge win.
I think it would be a good idea to start a completely new thread with a tutorial showing how to do channel packing and dealing with importing/exporting PNGs and TGAs. so the resource is handy and free from all this discussion.

On the other hand, some artists may bump into the problem of alpha=0 with complex composites, with several layers and masks, and try to find a way to avoid it, for whatever reasons.
Saying that "Affinity just turns RGB with 0 alpha to 0 just because" isn't going to help anyone.
We can't say for sure what's going on unless a developer steps in and explains what the code does, but an educated guess is that multiplication by mask is happening at some point, and that's why zeros are unrecoverable on post-division.
And it doesn't happen only in layer blending. Images have to be premultiplied for convolutions like gaussian blur or even rotating/scaling an image.

I understand if you want to stop right here, because it has been overly long, but if you want to keep insisting that I'm wrong and that zeroing doesn't come from multiplication, I'd be very interested to see how you prove that blurring unassociated RGBA or compositing unassociated RGBA works *without* multiplying by alpha/mask.
 

Link to comment
Share on other sites

3 hours ago, Guillermo Espertino said:

However neither of you have answered so far my question: How do you composite unassociated layers without multiplying the foreground by its mask?

If i understand this question correctly (not sure): you cant, but i cannot understand or imagine any reason why you want to do this.

Can you please explain for what use case you need this? 

Can you provide the mathematical formula of what you want to calculate?

use

  • r0, g0, b0, a0 for result.
  • r1, g1, b1 for upper layer
  • r2, g2, b2, a2 for lower layer.
  • provide formula for f using these variables, rgba0 = f(rgba1, rgba2) using the operators +-*/ and functions listed in procedural texture filter (E.g. min, max, clamp, abs, sign, leap, …)

 

Mac mini M1 A2348 | Windows 10 - AMD Ryzen 9 5900x - 32 GB RAM - Nvidia GTX 1080

LG34WK950U-W, calibrated to DCI-P3 with LG Calibration Studio / Spider 5

iPad Air Gen 5 (2022) A2589

Special interest into procedural texture filter, edit alpha channel, RGB/16 and RGB/32 color formats, stacking, finding root causes for misbehaving files, finding creative solutions for unsolvable tasks, finding bugs in Apps.

 

Link to comment
Share on other sites

30 minutes ago, NotMyFault said:

If i understand this question correctly (not sure): you cant, but i cannot understand or imagine any reason why you want to do this.

I guess you misunderstood my question, otherwise you wouldn't be asking *me* for a formula.
I asked what operation do *you* think Affinity is using for compositing the layer stack if it's not porter-duff's alpha over (that includes a multiplication of the foreground layer by its alpha).
If it's alpha over, then the multiplication is the most plausible explanation for zeroing RGB pixels with Alpha=0, as I've been saying since the beginning.
If you think it's not, please provide the evidence for that. @,,, is welcome to explain it too.

Link to comment
Share on other sites

6 minutes ago, Guillermo Espertino said:

If it's alpha over, then the multiplication is the most plausible explanation for zeroing RGB pixels with Alpha=0, as I've been saying from the beginning.

It is not the multiplication alone. Affinity is erasing RGB whenever alpha gets zero. This can be the result of layer blending leading to alpha=0. But there Is a  multitude of functions in Affinity, which are totally unrelated to blend formula and multiplication:

  • using channels panel, choose alpha channel, clear
  • using channels panel, choose alpha channel, invert (when alpha is 1 before)
  • Using apply image, use 0 for alpha channel
  • using erase brush
  • using adjustments and „merge down“
  • using PT texture filter with A=0 (non-live)
  • using channels panel, a spare channel with all zero, and „load to pixel layer alpha channel“
  • a lot more! 

in all these cases no multiplication is involved at all. So your fixation to „multiplication is caused RGB zeroing“ is simply wrong. It is one of multiple possible triggers Which led to zero alpha. Zero alpha is the cause. Multiplication can produce zero alpha, too.   

Mac mini M1 A2348 | Windows 10 - AMD Ryzen 9 5900x - 32 GB RAM - Nvidia GTX 1080

LG34WK950U-W, calibrated to DCI-P3 with LG Calibration Studio / Spider 5

iPad Air Gen 5 (2022) A2589

Special interest into procedural texture filter, edit alpha channel, RGB/16 and RGB/32 color formats, stacking, finding root causes for misbehaving files, finding creative solutions for unsolvable tasks, finding bugs in Apps.

 

Link to comment
Share on other sites

Actually, it is quite rare (next to impossible) that layer blending leads to alpha=0. You need to have both alpha a and alpha b equal to 0. If you have layers both with alpha = 0, the damage has been done already before, at the input layers.

From Wikipedia:

As an example, the over operator can be accomplished by applying the following formula to each pixel

{\displaystyle \alpha _{o}=\alpha _{a}+\alpha _{b}(1-\alpha _{a})}

 

  • With premultiplied alpha, the RGB components represent the emission of the object or pixel, and the alpha represents the occlusion. The over operator then becomes
    {\displaystyle \alpha _{o}=\alpha _{a}+\alpha _{b}(1-\alpha _{a})}

Mac mini M1 A2348 | Windows 10 - AMD Ryzen 9 5900x - 32 GB RAM - Nvidia GTX 1080

LG34WK950U-W, calibrated to DCI-P3 with LG Calibration Studio / Spider 5

iPad Air Gen 5 (2022) A2589

Special interest into procedural texture filter, edit alpha channel, RGB/16 and RGB/32 color formats, stacking, finding root causes for misbehaving files, finding creative solutions for unsolvable tasks, finding bugs in Apps.

 

Link to comment
Share on other sites

4 hours ago, Guillermo Espertino said:

On the other hand, some artists may bump into the problem of alpha=0 with complex composites, with several layers and masks, and try to find a way to avoid it, for whatever reasons.

Only in case they use masks or layer which have alpha=0 as input. You can‘t create zero alpha by regular blending, except doing operations which reduce alpha below 1/255 and rounding down happens. Even if one layer has a=1/255, and the other 0, rounding will give 1/255 as result.

You problem statement is irrelevant in real workflows. Either use alpha channel for alpha composition. Or use alpha channel as z (depth information) or „4th channel“. But then you are not doing alpha composition. 

Mac mini M1 A2348 | Windows 10 - AMD Ryzen 9 5900x - 32 GB RAM - Nvidia GTX 1080

LG34WK950U-W, calibrated to DCI-P3 with LG Calibration Studio / Spider 5

iPad Air Gen 5 (2022) A2589

Special interest into procedural texture filter, edit alpha channel, RGB/16 and RGB/32 color formats, stacking, finding root causes for misbehaving files, finding creative solutions for unsolvable tasks, finding bugs in Apps.

 

Link to comment
Share on other sites

40 minutes ago, NotMyFault said:

Only in case they use masks or layer which have alpha=0 as input. You can‘t create zero alpha by regular blending, except doing operations which reduce alpha below 1/255 and rounding down happens. Even if one layer has a=1/255, and the other 0, rounding will give 1/255 as result.

You problem statement is irrelevant in real workflows. Either use alpha channel for alpha composition. Or use alpha channel as z (depth information) or „4th channel“. But then you are not doing alpha composition. 

I think you completely misunderstood what I said.
Read again all my comments and see that I'm talking about RGB turning to 0 *because* alpha is 0. I'm not talking about alpha, but RGB *after* some compositing/convolution.

Why unassociated RGB pixels that have alpha=0 turn black after compositing?
Focus on RGB. Why does it turn black if it's not because it was multplied by the zeros from the mask?

Link to comment
Share on other sites

1 hour ago, NotMyFault said:

It is not the multiplication alone. Affinity is erasing RGB whenever alpha gets zero. This can be the result of layer blending leading to alpha=0. But there Is a  multitude of functions in Affinity, which are totally unrelated to blend formula and multiplication:

  • using channels panel, choose alpha channel, clear
  • using channels panel, choose alpha channel, invert (when alpha is 1 before)
  • Using apply image, use 0 for alpha channel
  • using erase brush
  • using adjustments and „merge down“
  • using PT texture filter with A=0 (non-live)
  • using channels panel, a spare channel with all zero, and „load to pixel layer alpha channel“
  • a lot more! 

in all these cases no multiplication is involved at all.

Good god.
Just look for the unassociated alpha over formula! THERE IS LITERALLY A MULTIPLICATION THERE, so whenever you're using alpha transparency in a layer stack there is a multiplication. If you're using unassociated alpha, chances are that you sooner or later will bump into a multiplication of RGB*A. It's inescapable when you use layers with masks. It's also inescapable when you use gaussian blur on an image with a mask.
Stop trying to prove me wrong and look at the damn formula. Stop giving me examples of things I didn't say and look at the formula.

Link to comment
Share on other sites

19 minutes ago, Guillermo Espertino said:

WHY is Affinity erasing RGB whenever Alpha is zero? That's the whole point of my discussion. Just explain why.

It is a design decision made by Serif / Affinity as product owner. 

Mac mini M1 A2348 | Windows 10 - AMD Ryzen 9 5900x - 32 GB RAM - Nvidia GTX 1080

LG34WK950U-W, calibrated to DCI-P3 with LG Calibration Studio / Spider 5

iPad Air Gen 5 (2022) A2589

Special interest into procedural texture filter, edit alpha channel, RGB/16 and RGB/32 color formats, stacking, finding root causes for misbehaving files, finding creative solutions for unsolvable tasks, finding bugs in Apps.

 

Link to comment
Share on other sites

31 minutes ago, Guillermo Espertino said:

Good god.
Just look for the unassociated alpha over formula! THERE IS LITERALLY A MULTIPLICATION THERE, so whenever you're using alpha transparency in a layer stack there is a multiplication. If you're using unassociated alpha, chances are that you sooner or later will bump into a multiplication of RGB*A. It's inescapable when you use layers with masks. It's also inescapable when you use gaussian blur on an image with a mask.
Stop trying to prove me wrong and look at the damn formula. Stop giving me examples of things I didn't say and look at the formula.

once again, I stop discussing this matter with you. Have a nice evening. peace.

Mac mini M1 A2348 | Windows 10 - AMD Ryzen 9 5900x - 32 GB RAM - Nvidia GTX 1080

LG34WK950U-W, calibrated to DCI-P3 with LG Calibration Studio / Spider 5

iPad Air Gen 5 (2022) A2589

Special interest into procedural texture filter, edit alpha channel, RGB/16 and RGB/32 color formats, stacking, finding root causes for misbehaving files, finding creative solutions for unsolvable tasks, finding bugs in Apps.

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.