How to Edit the Alpha Channel

[BrunoMartelli]

15 hours ago, Guillermo Espertino said:

Photopea is quite impressive for a free web app, but it's a bit silly to compare it to Affinity Photo. 
It's just an 8-bit sRGB image manipulation software, it fails to do proper associated alpha and it bakes high dynamic range destructively into a clipped 8-bit sRGB image.
For a serious imager it's just a toy.

Thank you, I think you will find the thread is called "How to Edit the Alpha Channel" not blah blah blah whatever

[Guillermo Espertino]

On 12/9/2022 at 12:00 PM, BrunoMartelli said:

Thank you, I think you will find the thread is called "How to Edit the Alpha Channel" not blah blah blah whatever

And how exactly do you edit the alpha channel in Photopea? And why are you talking about Photopea in the first place?

[Sigmo]

Oh damn I work within vfx and wanted to try affinity photo, it seemed so promising with exr and aces support, but yes this is a deal breaker. Luckily I am just on the trial to test it so I guess I will head back to adobeXD

[Guillermo Espertino]

On 2/10/2023 at 12:22 PM, Sigmo said:

Oh damn I work within vfx and wanted to try affinity photo, it seemed so promising with exr and aces support, but yes this is a deal breaker. Luckily I am just on the trial to test it so I guess I will head back to adobeXD

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.
I seriously can't understand why are so many people confused about this. If you're going to use it for transparency, using masks will work exactly as in Photoshop. For some special tricks involving channels, apply image will do.
Unless you want affinity Photo to be Photoshop and do things exactly as Photoshop, in which case, you should keep using Photoshop.

[myclay]

10 hours ago, Guillermo Espertino said:

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.

IF you know a way, please make a Video tutorial explaining the process on how it works.
Bonus points if you show the exporting from Affinity Photo.

Edit;
I will make it even easier for you, here are provided test files to use for each channel.
A.tgaB.tgaG.tgaR.tga

 

Edited February 18, 2023 by myclay
added files for Tutorial making

[Guillermo Espertino]

On 2/18/2023 at 5:13 AM, myclay said:

IF you know a way, please make a Video tutorial explaining the process on how it works.
Bonus points if you show the exporting from Affinity Photo.

Ok, I don't have time for a video tutorial, but here's an idea and an example file you can try yourself.

It is, of course, a workaround. But not because Affinity Photo is broken, but because you game people are trying to use the alpha channel for something it wasn't really intended for.

If you're using 16-bit images, just "perturb" the alpha channel with a small value to keep alpha association from destroying your RGB image. 1 out of 65535 will do.

Of course, you have to output to 16 bit formats to make it work.

If your output is 8-bit textures you have two options: One is to use a small value in 16 bit that quantization will turn into 1 when it is reduced to 8 bit. Anything above 128 should work.

The other is to work in 8-bit directly and avoid using 0s in your alpha channel.

There's something that nobody said so far about these channel packing techniques: What do you normally use the alpha channel for? What kind of data is supposed to go there? As far as I know all the standarized practices involve putting different PBR textures in the RGB channels, often quoting alpha channel as "optional". What do you use it for when you do?

 

 

RGBA.afphoto

[myclay]

The showcased snarkiness is troublesome. It doesn´t help that you apparently have no idea nor any fixes or good workarounds.
The recommendation of using Photoshop is also of little value in this 11 pages spawning thread.
16 bit has 65536 colours.

[lepr]

3 hours ago, Guillermo Espertino said:

Ok, I don't have time for a video tutorial, but here's an idea and an example file you can try yourself.

It is, of course, a workaround. But not because Affinity Photo is broken, but because you game people are trying to use the alpha channel for something it wasn't really intended for.

If you're using 16-bit images, just "perturb" the alpha channel with a small value to keep alpha association from destroying your RGB image. 1 out of 65535 will do.

Of course, you have to output to 16 bit formats to make it work.

If your output is 8-bit textures you have two options: One is to use a small value in 16 bit that quantization will turn into 1 when it is reduced to 8 bit. Anything above 128 should work.

The other is to work in 8-bit directly and avoid using 0s in your alpha channel.

 

 

 

There is no need to avoid alpha zeros in either 8 bpc or 16 bpc if you intend to export to TGA or PNG.

The key to making Affinity export intact RGB where alpha is zero in TGA or PNG, is to have the alpha as an object at top of the layer stack, as you did with the mask.

You could have put zeros in the mask instead of using a tiny value; an exported TGA or PNG would still have intact RGB.

Try exporting TGA and PNG from this version of your 16 bpc document with zeros painted across the mask: RGBA new.afphoto

Alternatively, try exporting from this 8 bpc version: RGBA new 8bpc.afphoto

Open the exported files in Affinity and fill their alpha channel to reveal the intact RGB, even where alpha was zero.

 

Edited February 20, 2023 by ,,,
added second document

[Guillermo Espertino]

1 hour ago, myclay said:

The showcased snarkiness is troublesome. It doesn´t help that you apparently have no idea nor any fixes or good workarounds.
The recommendation of using Photoshop is also of little value in this 11 pages spawning thread.
16 bit has 65536 colours.

Ok, so what exactly are you bringing to the thread apart from trying to correct me and saying I have no idea or good workarounds?
I asked you what are you going to use the alpha channel for.

btw, I meant that you had 65535 values that are not 0 to choose from.
Now that you pointed to my mistake and called me clueless, let me return the favour: Each 16 bit channel has indeed 65536 values. Not colours. If you had to count the color values you can produce you should consider the three RGB channels.

 

44 minutes ago, ,,, said:

 

There is no need to avoid alpha zeros in either 8 bpc or 16 bpc if you intend to export to TGA or PNG.

The key to making Affinity export intact RGB where alpha is zero in TGA or PNG, is to have the alpha as an object at top of the layer stack, as you did with the mask.

You could have put zeros in the mask instead of using a tiny value; an exported TGA or PNG would still have intact RGB.

Try exporting TGA and PNG from this version of your document with zeros painted across the mask: RGBA new.afphoto

Open the exported files in Affinity and fill their alpha channel to reveal the intact RGB, even where alpha was zero.

 

I understand the problem, I know what you expect and what you get. I know that Photoshop doesn't behave like that.
What nobody seems to understand here is that Affinity Photo, because of its unassociated alpha internals, needs at some point to associate the alpha channel.

And to make the record straight: ANY compositing software (photoshop included) needs to do that to composite an RGBA image over a background. That's how alpha compositing works and you just can't avoid it. If the image is not associated (premultiplied) the alpha over operation has to perform the multiplication.

I've said it a couple of times before and I'll say it again: In an associated alpha image, RGB means emission (and every pixel counts, even the transparent ones), and in unassociated-alpha images the RGB pixels with alpha=0 are intended to be discarded by alpha compositing.

There's NOTHING wrong about how Affinity is processing those images. The only reason why you notice this "problem" is because you want to use the alpha channel for something that IS NOT transparency.

If you were using your PNG and TGAs as they are intended to be used, you wouldn't even notice it.

I understand that your industry uses files that way and it may be inconvenient that you can't do it in Affinity Photo, but stop saying Affinity Photo is broken because it doesn't let you use that hack.
Just use the workaround I mentioned or move to a different software (or produce you individual channels in Affinity Photo and use a channel packer, ffs.

There's nothing to fix here. It's not broken.

 

p.s.: could you please provide a REAL example of a file that needs to use the four channels with 0s in the alpha that can't be turned into a small value? I'm honestly curious about how problematic this is in reality for people in your industry.

[lepr]

20 minutes ago, Guillermo Espertino said:

I understand the problem, I know what you expect and what you get.

LOL

You wrote:

4 hours ago, Guillermo Espertino said:

If you're using 16-bit images, just "perturb" the alpha channel with a small value to keep alpha association from destroying your RGB image. 1 out of 65535 will do.

Of course, you have to output to 16 bit formats to make it work.

If your output is 8-bit textures you have two options: One is to use a small value in 16 bit that quantization will turn into 1 when it is reduced to 8 bit. Anything above 128 should work.

The other is to work in 8-bit directly and avoid using 0s in your alpha channel.

 

I proved you wrong with your own example document. There is no need to "perturb" the alpha channel to avoid alpha zeros when you know how to export intact RGB with alpha zeros.

 

 

 

[Guillermo Espertino]

16 hours ago, ,,, said:

LOL

I proved you wrong with your own example document.

No, dude. Please read what I wrote.
When alpha is multiplied to RGB, all zeroes are irreversible. When you divide by alpha you can recover the RGB value of the semi-transparent pixels if you need to (for instance for colour grading). Introducing a small value in the alpha channel allows to revert the multiplication.
When you're working with 16-bit images, the value 1 is enough to avoid division by zero, and it's small enough to be considered transparent in practical terms.
I did not invent this workaround. Is more or less what Affinity Photo does to make associated alpha EXRs work in the app.
In 8-bit images the smallest channel value you can produce in that precision is probably too high and in some edge cases could be a problem, that's why I was asking you to produce a REAL WORLD example of an file needing the alpha channel where that workaround isn't suitable.

So far, nobody came up with a single one.

 

 

[Guillermo Espertino]

29 minutes ago, ,,, said:

There is no need to "perturb" the alpha channel to avoid alpha zeros when you know how to export intact RGB with alpha zeros.

But you don't know how to export intact RGB with alpha zeros in Affinity. Isn't that your problem?

[lepr]

1 hour ago, Guillermo Espertino said:

But you don't know how to export intact RGB with alpha zeros in Affinity. Isn't that your problem?

Not my problem. I told you how to do it with TGA and PNG. I don't know what format you want to do it with.

 

 

[Guillermo Espertino]

14 hours ago, ,,, said:

Not my problem. I told you how to do it with TGA and PNG. I don't know what format you want to do it with.

 

 

Ah, sorry. I exported the files and re-opened them in Affinity and I was still seeing zeros, but you're right. When the mask is used on top of the composite the export keeps it as an unassociated mask and doesn't premultiply upon export. It's good to know, so my workaround isn't needed (unless you have individual layers with their own masks, In that case *they are* premultiplied)

You were right and I was wrong. Let's move on.

So problem solved? It's clear that it is possible to produce unassociated RGBA TGA and PNG files.
What's people complaining about here? The import behavior?

[myclay]

15 hours ago, Guillermo Espertino said:

What's people complaining about here?

an easy way of doing this and automation as well as easy editability, easily copy pasting data into channels.

Thats why I posted my plea of getting help while also providing files.

Ease of use to me means;

1 Separate or copy paste each of the provided R-G-B-A images into their respective channel.
2 how to do day to day editing so that it stays in the channel.
3. reusability; Group every channel so we can easily switch the images inside the group.
4.(optional) Ability of working on multiple channels at the same time.

5. File format wise lets start with; TGA, TIFF, PNG, those are the fileformats which Affinity Photo can currently export to and which the game engine I use can import.

@,,,

Your files are pointing at the right direction and seemed to work in a test I did.
To make this useful, we need more modifiability.

Here is an affinity photo example file; RGBA-Groups and procedural Textures.afphoto
 

with grouped channels and procedural Textures for modifying them to adhere to the respective channel - at least that is the plan.

I am at wits end, those procedural textures are not working as expected and still modify the alpha.

The Channels are colour coded so you directly know which channel it should be.

 

[NotMyFault]

13 minutes ago, myclay said:

Separate or copy paste each of the provided R-G-B-A images into their respective channel.
2 how to do day to day editing so that it stays in the channel.
3. reusability; Group every channel so we can easily switch the images inside the group.
4.(optional) Ability of working on multiple channels at the same time.

5. File format wise lets start with; TGA, TIFF, PNG, those are the fileformats which Affinity Photo can currently export to and which the game engine I use can import.

All can be done, mostly non-destructively, or an alternative approach is possible.

the principle is to decomposition an RGBA layer into RGB (alpha filled) and greyscale layer, or even further into 4 greyscale layers.

I assume that you don’t want to use alpha in any classical way as alpha channel, but always as extra channel (while editing in Photo).

This can be done easily with channels adjustment. to get a regular RGB rendering, use blend mode „add“, and channels panel to color the separate layers.

so basically layer structure:

• group alpha. Blend mode normal. Must be switched visible / invisible when you want to see it.
• group red. Blend mode add. Channel mixer with R=100, G=0, B=0
• group green. Blend mode add. Channel mixer 0 / 100 / 0
• group blue. Blend mode normal (bottom layer). Channel mixer 0 / 0 / 100.

you can then edit all pixel layers including copy & paste. 

all you need is 2 macros:

• one to crate this structure after opening a tga file
• one to create a mask layer from alpha group before exporting.

[myclay]

@NotMyFault

Thank you so much!
I fixed my afphoto file with the procedural texture separator setup and attached it.
RGBA-Groups and procedural Textures_fixed.afphoto

In this approach its monumental to have a black background for each channel otherwise the alpha seeps thru.

Macros is a great idea, would be the next step.

Obligatory test result within the gamengine;

 

Edited February 21, 2023 by myclay
added result from game engine.

[Guillermo Espertino]

You can create a template with those groups, layer modes and non destructive filters.
The alpha group on top could be a composite mask and you're mostly done.
As I said earlier, apply image can be handy too if you have the separate channels already and want to "merge" them as channels. It works for merging RGB, and you let alpha for a later step, creating the mask on top of the layer stack, as @,,, pointed out.

[NotMyFault]

7 minutes ago, Guillermo Espertino said:

You can create a template with those groups, layer modes and non destructive filters.
The alpha group on top could be a composite mask and you're mostly done.
As I said earlier, apply image can be handy too if you have the separate channels already and want to "merge" them as channels. It works for merging RGB, and you let alpha for a later step, creating the mask on top of the layer stack, as @,,, pointed out.

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. 

A better replacement is to use channels mixer adjustment, or procedural texture filters, and normal layer blending. By adjusting the alpha value you can control the mixture.

[myclay]

47 minutes ago, Guillermo Espertino said:

template with those groups, layer modes and non destructive filters.
The alpha group on top could be a composite mask and you're mostly done.

Making a template and the composite mask are good ideas, thank you for those.👍

[lepr]

20 hours ago, Guillermo Espertino said:

(unless you have individual layers with their own masks, In that case *they are* premultiplied)

No, premultiplying is not happening in that situation. Affinity sets RGB to zero where alpha is zero in several of its operations (possibly to improve data compressibility, but Serif haven't commented on the reason as far as I know) which you have wrongly assumed to be the premultiplying of RGB by alpha.

Affinity's TIFF export with transparency does premultiply after the document RGBA composite has been rendered without premultiplication. You won't circumvent that with the mask on top trick, of course.

[Guillermo Espertino]

1 hour ago, ,,, said:

No, premultiplying is not happening in that situation. Affinity sets RGB to zero where alpha is zero in several of its operations (possibly to improve data compressibility, but Serif haven't commented on the reason as far as I know) which you have wrongly assumed to be the premultiplying of RGB by alpha.

Affinity's TIFF export with transparency does premultiply after the document RGBA composite has been rendered without premultiplication. You won't circumvent that with the mask on top trick, of course.

Do you know that there is a always multiplication in the alpha-over operation, right? How exactly do you think A over B works when A isn't premultiplied? Check the porter-duff over op. When the foreground isn't premultiplied, the operation includes a fg*a multiplication.

The reason why layers with masks get zeros baked in RGB *is* multiplication (which is also needed for any convolution, proper rotation and scale, etc.)

Mask on top "trick" probably works because being the last operation on the stack, the result is not composited over anything so foreground*alpha doesn't take place on the data. Affinity internals are unassociated alpha, so it makes sense that it doesn't.

At any rate, the workaround I posted earlier, "disturbing" the alpha channel with a value >0 effectively proves that there is a multiplication taking place. Not only a multiplication, a post-division too. Otherwise you wouldn't be able to recover the RGB pixels that fall under alpha 0.

 

3 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.

[lepr]

40 minutes ago, Guillermo Espertino said:

Do you know that there is a always multiplication in the alpha-over operation, right? How exactly do you think A over B works when A isn't premultiplied? Check the porter-duff over op. When the foreground isn't premultiplied, the operation includes a fg*a multiplication.

The reason why layers with masks get zeros baked in RGB *is* multiplication (which is also needed for any convolution, proper rotation and scale, etc.)

Mask on top "trick" probably works because being the last operation on the stack, the result is not composited over anything so foreground*alpha doesn't take place on the data. Affinity internals are unassociated alpha, so it makes sense that it doesn't.

At any rate, the workaround I posted earlier, "disturbing" the alpha channel with a value >0 effectively proves that there is a multiplication taking place. Not only a multiplication, a post-division too. Otherwise you wouldn't be able to recover the RGB pixels that fall under alpha 0.

 

 

Nowhere did I say Affinity never performs multiplications. That would be ridiculous.

It's late here and I'll be busy during the day tomorrow, but tomorrow evening I will provide evidence of Affinity setting RGB to zero where alpha is zero while it is doing nothing to RGB where alpha is greater than zero.

 

 

[Guillermo Espertino]

58 minutes ago, ,,, said:

Nowhere did I say Affinity never performs multiplications. That would be ridiculous.

It's late here and I'll be busy during the day tomorrow, but tomorrow evening I will provide evidence of Affinity setting RGB to zero where alpha is zero while it is doing nothing to RGB where alpha is greater than zero.

It is called premultiply/postdivide. When an operation needs a premultiplied source (convolutions, rotation, scaling, and others) the RGBA image is multiplied by alpha, and later divided by alpha to return to the unassociated state that the software uses.
The reason why 0 stays at 0 is because you can't divide by zero to retrieve the original RGB. The semi-transparent pixels (alpha > to 0) is reversible.
Those are the basics of alpha compositing in every software.

[NotMyFault]

6 hours ago, Guillermo Espertino said:

It is called premultiply/postdivide. When an operation needs a premultiplied source (convolutions, rotation, scaling, and others) the RGBA image is multiplied by alpha, and later divided by alpha to return to the unassociated state that the software uses.
The reason why 0 stays at 0 is because you can't divide by zero to retrieve the original RGB. The semi-transparent pixels (alpha > to 0) is reversible.
Those are the basics of alpha compositing in every software.

Affinity does the multiplication only during layer blending.

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.

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

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-“)

https://en.wikipedia.org/wiki/Alpha_compositing

Straight versus premultiplied[edit]

If an alpha channel is used in an image, there are two common representations that are available: straight (unassociated) alpha and premultiplied (associated) alpha.

• With straight alpha, the RGB components represent the color of the object or pixel, disregarding its opacity.
• 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: