How to Edit the Alpha Channel

[lepr]

On 2/23/2023 at 8:19 PM, Guillermo Espertino said:

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

 

On 2/23/2023 at 8:42 PM, NotMyFault said:

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

 

Exactly!

As I've said over the years, the only explanation I've been able to think of is the decision [to set RGB to zero where alpha is zero] was made to improve the compressibility of raster data. If that was the case, we'll never know whether or not that was done with the realisation that it would create inconvenience for workflows which require RGB to remain unadulterated for all alpha values.

[deleted remainder of message: tired of arguing]

Edited February 26, 2023 by ,,,

[NotMyFault]

44 minutes ago, ,,, said:

 

 

Exactly!

As I've said over the years, the only explanation I've been able to think of is the decision [to set RGB to zero where alpha is zero] was made to improve the compressibility of raster data. If that was the case, we'll never know whether or not that was done with the realisation that it would create inconvenience for workflows which require RGB to remain unadulterated for all alpha values.

[deleted remainder of message: tired of arguing]

 

   On 2/23/2023 at 9:19 PM,  Guillermo Espertino said: 

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

 

There is even a official answer from Affinity

 

[lloyds]

On 2/23/2023 at 2:42 PM, NotMyFault said:

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

It is irrelevant because this is incorrect behavior.

It is a software bug.

The RGB channels should not be affected by any change in the Alpha channel.

Never.

I loaded up the following file in Unreal (it should be the same in Photoshop). In both cases you will see the RGB channels are wall-to-wall.

When I write them out in Gimp for example, the RGB channels are not changed by the alpha. This is correct behavior. It has been correct behavior for the last couple of decades.

Algorithm:

1. Write R, G, B and Alpha
2. Done.

Affinity does not change the RGB channels EXCEPT when it writes it out as a PNG file (I haven’t checked other formats, but I assume it is the same). It does the following which is 100% wrong:

1. Mask the Red, Green and Blue with the Alpha.
2. Write R, G, B and Alpha
3. Done

Step 1 should NEVER happen. It doesn’t NEED to happen. It is an extra step that does no one any good.

Simple test: If I read the file uploaded below then write it (say as T_Test.PNG) — the TWO FILES WILL BE DIFFERENT (go ahead, test it!)

Why is this a bad thing? Let’s assume that my .afphoto file is corrupted. Oh. Now I can’t recover the RGB channels from the PNG file! Those portions are gone forever.

It’s not a “design decision”, it is incorrect behavior. It is a software bug. Someone either didn’t test it or didn’t understand what the alpha channel is for.

This cannot be spun into “correct behavior” — not when people’s images are their livelihoods!

EDIT: I really want to emphasize that deleting parts of my RGB image based on the alpha is a step too far: Affinity Photo should not be doing that. Ever. The fact that it retains the RGB data in the .afphoto file but masks it in the export indicates to me someone made a mess in the export and the rest of Affinity isn’t the problem. Bottom line: As a software engineer of 45+ years, this should be a five day fix, worst case. Fix the export, you can fix a good chunk of the problem.

Edited February 27, 2023 by lloyds

[lloyds]

6 hours ago, NotMyFault said:

There is even a official answer from Affinity

Actually, I don’t think they quite understood the issue. You can, today, edit the alpha channel. Even if you are not doing games, there have been PLENTY of instances where I needed to modify the alpha channel.

As I indicated before, what they are doing, using the Alpha as a mask, is incorrect behavior — either that or someone doesn’t understand the concept of an alpha channel. Either way, it is embarrassing to whoever wrote the exporter.

Edited February 27, 2023 by lloyds

[lloyds]

On 2/17/2023 at 3:59 PM, Guillermo Espertino said:

If you work with VFX, you won't have any alpha problems with Affinity Photo.
If you happen to work for the game industry that apparently requires to use alpha channel for things that are not transparency, you can work too. You just have to learn to use the "apply image" filter and you can make any grayscale image be the alpha channel for your image.

This is incorrect. 

The problem is not editing the Alpha, but that when exporting the data the RGB is MASKED by the alpha. 

This means it is possible to read a png file then write it with Affinity and it will be changed. Affinity is not lossless, even with PNG files. 

This a BIG problem when image data is thrown away. 

Edited February 27, 2023 by lloyds

[myclay]

@lloyds

Here is the result with the knowledge provided by NotMyFault and ,,, 

Exporting your file so it does not eat away the alpha areas is possible as you can see here;

Even if there is a hack available to make it "work" with adding the alpha as a mask ontop, I agree with you and everyone else that Affinity Photos Alpha handling needs an overhaul.

[lloyds]

9 hours ago, myclay said:

Exporting your file so it does not eat away the alpha areas is possible as you can see here;

 

That is not the issue.

The issue is the export of a PNG file applies the Alpha as a MASK to the RGB channels, thus deleting information. Whether it is possible isn’t the point — the point is by default it exhibits incorrect behavior.

Edited February 27, 2023 by lloyds

[lepr]

17 hours ago, lloyds said:

Affinity does not change the RGB channels EXCEPT when it writes it out as a PNG file

The change/damage (setting RGB to zero where alpha is zero) happens with many Affinity operations.

The PNG exporter can write out an RGBA with intact RGB for all alpha values, including zero. I showed the forum how to export unadulterated RGBA PNG a couple of years ago, and both methods work to this day.

 

15 hours ago, lloyds said:

This means it is possible to read a png file then write it with Affinity and it will be changed. Affinity is not lossless, even with PNG files. 

Yes, loss will happen with a straightforward import then export when the source file has non-zero RGB where alpha is zero. However, a lossless round trip isn't difficult: the PNG import will be faithful and then, as already said, there are ways to get a faithful PNG export.

 

17 hours ago, lloyds said:

Bottom line: As a software engineer of 45+ years, this should be a five day fix, worst case. Fix the export, you can fix a good chunk of the problem.

Ideally, Affinity would never destroy RGB where alpha is zero, but it is happening in several operations that happen before the exporter, and then the exporter outputs from the already changed/damaged data which is provided/available to it, namely the document composite.

Edited February 27, 2023 by ,,,
completed the final sentence

[lepr]

21 hours ago, lloyds said:

[the PNG export] is embarrassing to whoever wrote the exporter.

I must cook dinner now. I will return tomorrow and demonstrate the PNG exporter is not to blame for the loss of RGB data. Then you might consider apologising to whoever wrote the exporter.

Edited February 27, 2023 by ,,,
change of schedule

[NotMyFault]

To prove and confirm @,,, that the exporter is not the culprit I did some test with:

1. a pixel layer (fully opaque)
2. a mask where I erased some brush strokes
3. a channel mixer with alpha set to 0 

then 

1. merge visible
2. deactivate lower layers
3. use channels panel, alpha->fill
4. you can now see the result (black or original pixel content)

 

RGB will be preserved in the following cases:

• mask layer on top of pixel layer
• adjustment layer on top of pixel layers
• any combination of these in any number (e.g. 2 masks, 2 masks plus 3 adjustments)

In all other cases, RGB will be zeroed:

• nested masks
• nested adjustments
• grouping 
• doing a second merge visible over a pixel layer with erased areas. This is highly relevant: whenever separate pixel/mask layers gets recombined into one RGBA layer, you can only recover RGB by „fill alpha“ destructively. Above this layer, RGB values are lost.

This is clear evidence that erasing happens inside Photo (based on layer structure), and not during export.

 

[lloyds]

5 hours ago, ,,, said:

The change/damage (setting RGB to zero where alpha is zero) happens with many Affinity operations.

Ah, my bad. This actually doesn’t surprise me. If you can’t read then write and get the same data, then you have a serious problem.

5 hours ago, ,,, said:

I must cook dinner now. I will return tomorrow and demonstrate the PNG exporter is not to blame for the loss of RGB data. Then you might consider apologising to whoever wrote the exporter.

If I read a PNG file and export a PNG file, then I should end up with the same file, no?

Someone is making changes to the RGB channel. I know if I fill the alpha with 1’s that RGB are correct. So, Affinity (at that point) has the information. It is only when I export that that information is irrevocably changed.

I will be interested to know how you will show that the information is lost BEFORE writing as it appears to retain it even in the .afphoto file.

Edited February 28, 2023 by lloyds

[lloyds]

4 hours ago, NotMyFault said:

This is clear evidence that erasing happens inside Photo (based on layer structure), and not during export.

I was looking at a simple base case that should result in no loss:

1. Read in the sample PNG file above.
2. Write the sample PNG file with not other operations in between.

Do this will result in a PNG file that is substantially different than the one input. This is incorrect behavior.

Next

1. Read in the sample PNG file above
2. Fill the alpha with all 1’s
3. Write the sample PNG file with no other operations in between.

The RGB channels will all have the correct information (although the alpha will be wrong).

This isn’t to say that there are not other operations that perform a mask on the RGB channels using a B/W version of the alpha (???) — in fact, this doesn’t surprise me. It is as if someone didn’t understand what the alpha channel does (or at least has an imperfect understanding). Nor does it surprise me that other operations result in a corruption of the RGB channels.

[lloyds]

5 hours ago, ,,, said:

there are ways to get a faithful PNG export

Explain.

[NotMyFault]

8 hours ago, lloyds said:

Do this will result in a PNG file that is substantially different than the one input. This is incorrect behavior

No, this is quite normal for image editor apps. These editors are intended to edit images - vs „not change the content“. Use a image viewer, or do not save if you want to keep a file unchanged on bit-level.

1. Open a JPG, save as JPG. The image gets decompresses / newly compressed. Almost every bit will differ, size can change to larger or smaller. I know there are special tools who avoid recoding for e.g. rotation or crop. This is not the use case of Affinity apps.
2. Same with PDF (which uses JPG compression for bitmaps - unrelated to JPG file format).
3. TIFF and other container who support wide range of content formats. Affinity can write only a subset of formats it can read, so encoding can change when exporting or - beware of consequences - save as TIFF.

To get a PNG with restored RGB values, you need a few more step:

• channels panel, create mask from alpha channel (wich must reside on top of pixel layer)
• fill alpha channel
• export (this is intentionally not save).

the main use case for export is converting the internal afphoto format to a really huge choice of non-native formats. 

 

[lepr]

@lloyds

source RGBA.png.zip

The provided file named "source RGBA.png" (which was originally exported from Affinity Photo) contains non-zero RGB in all pixels, although a large square central region is completely transparent because alpha is zero there.

The following procedure will demonstrate:

• Affinity losslessly imports an RGBA PNG file (although the initial Composite RGB channels may suggest different)
• The Affinity document's Composite RGB is, or is not, set to zeros where alpha is zero, depending on the document structure
• Affinity faithfully exports the document's composite RGBA to an RGBA PNG file, and therefore it is possible to losslessly re-export an imported RGBA PNG.

Start by opening the file in Affinity Photo (version 1.x or 2.x).

Use Channels panel to temporarily hide the document's Composite Alpha to reveal the Composite RGB image is black where the Composite Alpha was zero, regardless of the actual RGB values in Background where alpha is zero.

Export an RGBA PNG from the document; it will be identical to the Composite RGBA with zeros for RGB where alpha is zero. Obviously, that is a lossy trip from source file to exported file.

 

Back in the document, use Channels panel to create a new mask from Background Alpha and then fill Background Alpha. That creates a mask at top of the stack and makes Background opaque. The document composite still has the same transparency as before, of course.

Use Channels panel to temporarily hide the document's Composite Alpha to reveal the Composite RGB now has the actual RGB of Background with no zeroing where alpha is zero.

Export an RGBA PNG from the document; it will be identical to the Composite RGBA with non-zero RGB everywhere, even where alpha is zero. That is a lossless trip from source file to exported file.

 

Now in the document, move the mask from top of the stack and nest it in the opaque Background. The document composite still has the same transparency as before, of course.

Use Channels panel to temporarily hide the document's Composite Alpha to reveal the Composite RGB has returned to zeros where alpha is zero.

Export an RGBA PNG from the document; it will be identical to the Composite RGBA with zeros for RGB where alpha is zero. Obviously, that is a lossy trip from source file to exported file.

 

 

 

[lloyds]

Thank you, that is non-intuitive and an amazing PITA. Kudos to those who figured this out.

I agree with people who say that Affinity needs to be reworked — it shouldn’t required this much work just to non-destructively edit images.

I have filed a bug report which, sadly, got the, “Yeah, we know…” response. This is very disappointing.

[lepr]

16 minutes ago, lloyds said:

that is non-intuitive and an amazing PITA

Certainly room for improvement. Anyway, my point was to show that the PNG exporter itself is not at fault. The exporter merely creates a file from the document composite that is available/provided to it. You still owe an apology to the developer of the PNG exporter for the insult you posted, in case you forgot.

[lloyds]

2 hours ago, ,,, said:

Certainly room for improvement. Anyway, my point was to show that the PNG exporter itself is not at fault. The exporter merely creates a file from the document composite that is available/provided to it. You still owe an apology to the developer of the PNG exporter for the insult you posted, in case you forgot.

No. What you have proved is that the RGB channels internally are stored complete — I know that and even said that (hell, they are stored without any form of masking in the .afphoto file). This I did say.

The fact that you came up with a method that allows the RGB to be written without changes does not change the fact that the exporter is incorrect. Nor can you prove that it is NOT the exporter. What you have proved is that you can create a layered system that prevents the RBG from being masked with a binary version of the alpha.

I’m sorry, I have over four decades writing and testing software and all you have proved is that you have a method that prevents the RGB from being masked on output.

This does not change the fact that reading a PNG file and writing a PNG file results in a corrupted version of the PNG file. Since you have proved that the data is retained, and I have verified it, the result is in the action of exporting: data is masked with a 1 bit version of the alpha (which is not even vaguely correct).

What you proved is that with sufficient machinations, you can export a lossless image. Good. That’s awesome. But the data is completely different. You are comparing apples with oranges.

EDIT: This is my last comment per moderators. I created the following macros and put them in the public domain.

EDIT: Macros were messed up. Should be fixed now.

 

RGBAToComposite.afmacro CompositeToRGBA.afmacro

Edited February 28, 2023 by lloyds

[lepr]

On 2/28/2023 at 8:29 PM, lloyds said:

I’m sorry, I have over four decades writing and testing software

Ditto. 43 years to be precise. That doesn't imply either of us is correct.

You've already posted wrong assumptions in this thread, LOL.

 

On 2/28/2023 at 8:29 PM, lloyds said:

and all you have proved is that you have a method that prevents the RGB from being masked on output.

I never claimed to prove anything. I deliberately used the word demonstrate because I'm fully aware that I cannot prove what the software is doing internally.

You cannot prove the exporter is the problem, yet you repeatedly state it is.

[Guillermo Espertino]

The exporter is clearly NOT the problem.
It seems pretty clear to me that masked layers is the source of this problem since it can be consistently demonstrated that compositing layers with masks exhibits the behavior discussed here (and the channels panel reflect it). Layers without masks with a mask on the topmost level avoids the problem, quite likely because the mask on the top level masks the already composited projection and not each layers individually.

As I said earlier many times, I don't see it as a bug or an incorrect behavior. It's problematic for a target audience? Sure. But it's not necessarily wrong.
Affinity Photo is not destructing information. Layers with masks retain its original RGB in the .afphoto file.
The final composite of the layers is destroying some information, but a delivery singler-layer file is always going to be destructive. Every time you composite a semi-transparent or transparent pixel on a background, the resulting pixel will be something different.

Expecting that a TGA or PNG created from stacked layers will retain "the original RGB" in transparent pixels is a problematic expectation: Which RGB? The first layer? The ones composited on top of it? One or both will be lost, depending on the image.

Even GIMP or Photoshop, that seem to "keep" that RGB have to do some compromises to achieve that: both will keep the background RGB where pixels on top layers have 0 alpha, but as soon as those layers have a tiny opacity, the RGB will be replaced by the one from the top layers.
So, for instance, if you have 0 mask opacity in your red background and composite 0 mask opacity in your green foreground layer, the result will be red. Yay.
But when you have 0 mask opacity in your red background and 0.001 in your foreground, the resulting pixel will be 100% green.
That's how they work, and it's not precisely "conservative" or "correct". Works for the people who do channel packing tho.

Affinity seems to do things differently.

Nobody here (unless a developer decides to explain it) can prove how or why it works the way it works, but as I insisted before, it could be related to multiplication.

One common thing in graphics software is the use of temporary buffers for operations, and having the processing pipeline branched in different data paths for efficiency.

Affinity photo keeps every layer as an object that can be transformed (rotated and scaled) live, without committing the transform (as GIMP or Photoshop do). For that kind of operations you need masks to be associated to RGB, otherwise you get edge artifacts. That's a fact, not something I'm guessing, that's computer graphics basics.

Also, compositing masked images together also requires the foreground and its mask to be associated. If the foreground is not associated, then the alpha over operation needs to address it by adding the extra multiplication. That's another computer graphics fact.

https://developer.nvidia.com/content/alpha-blending-pre-or-not-pre (read the formulas. Spot the multiplication in the "old" one).

 

So, why are you so adamant on rejecting this possibility? I don't know.

Just consider this: What if Affinity photo produces a higher precision premultiplied mip-mapped temporary buffer for each layer for compositing on the fly and uses that for the final projection?
Why doing that? Because you want to be able to take most of that stage to the GPU, and apply fast transforms and effects on the fly on cached data.

Definitely a "design decision". A modern approach for a photo manipulation software, and Affinity Photo is definitely the newest kid on the block.

Moving to a premultiplied branch for compositing makes sense from the perspective of eficciency and would be the explanation for those RGB pixels zeroed where alpha=0 (I mean layer's alpha, the one created by layer masks).

Can I prove it? No. Can you prove it is not? No.
But at least let's agree that is another plausible explanation, with at least a little bit of more background than saying it's just because, or that it is for the sake of file compression.

At any rate, pointing this as a bug or a design flaw because it is somewhat inconvenient to some users is probably pointless.
You already showed there are workarounds to make sure that some of the original RGB is preserved during export, so producing channel-packed textures in Affinity Photo is indeed possible and not a big deal.

Personally, I think the latter shows that -for this subject's matter- Affinity Photo is fine as it is and it doesn't have to be "fixed" (granted, some copy and pasting on masks and channels without creating temp ones would be handy).

@NotMyFault and @,,, provided clear instructions that allow users to produce RGBA channel packed images avoiding alpha zeroing,

I also provided a quick and dirty workaround for people who want to preserve RGB from composited layers (adding a tiny offset to alpha, requires the processing to be done in 16-bit though).
 

Anyone bumping into the issues described in this thread can get some info about how to work around them.

[Zack Black]

Jumping in here in 2023 with Affinity Photo 2.1.0. Still seems like AF doesn't have proper alpha channel support. I can paint with white/black on the RGB channels, but only with white on the Alpha. I can make a selection and invert it on the RGB channels, but not on the Alpha. Developers... please, PLEASE fix this!!

[Guillermo Espertino]

On 5/31/2023 at 12:20 PM, Zack Black said:

Jumping in here in 2023 with Affinity Photo 2.1.0. Still seems like AF doesn't have proper alpha channel support. I can paint with white/black on the RGB channels, but only with white on the Alpha. I can make a selection and invert it on the RGB channels, but not on the Alpha. Developers... please, PLEASE fix this!!

 

[Robbin]

Amazed this thing still hasn't had a single ounce of development, it's still in the same state of "do this 20 step process that in convoluted and makes no sense" to just about scrape by. after watching all these tutorials and reading what everyone else has done I still have 0 clue how to do this. I dont get why rgb has to be tied to alpha in the first place

I have this setup right now which just combines rgb channels and I wanted to add another for the alpha channel, however everything just goes wrong once I try add it in, for starters the filters must have alpha ticked otherwise nothing shows up in any channel which already is weird since it should still have the other colour channel data to use?



The alpha should be the exact same system no? as long as it only modifies the alpha then the other data shouldn't be touched, however it seems like the moment I vary the alpha it affects all the other colour channels. So now my other channels have gone from being preserved to having this god awful alpha messing around with it.
Red channel                            Red channel now with alpha messing it up


Is it really this hard to just have alpha stay in its own god damn lane?

[NotMyFault]

1 hour ago, Robbin said:

...

I have this setup right now which just combines rgb channels and I wanted to add another for the alpha channel, however everything just goes wrong once I try add it in, for starters the filters must have alpha ticked otherwise nothing shows up in any channel which already is weird since it should still have the other colour channel data to use?



The alpha should be the exact same system no? as long as it only modifies the alpha then the other data shouldn't be touched, however it seems like the moment I vary the alpha it affects all the other colour channels. So now my other channels have gone from being preserved to having this god awful alpha messing around with it.
Red channel                            Red channel now with alpha messing it up


Is it really this hard to just have alpha stay in its own god damn lane?

In case you want to keep the alpha channel separate, just do it. Keep it in a separate pixel layer.

I cannot see from your screenshots which layers are supported to store the alpha channel. 

Only in case you want to export into TGA, TIFF, PNG etc you need to combine the alpha channel based on the tutorials provided in this thread or below: