lloyds

Please find my updated macros. The first breaks everything out into layers so that they may be individually edited. The second does the necessary work to move them back into something that can be exported losslessly. Please note, there is a mask that contains the alpha layer — unfortunately it needs to be there for export to work correctly. I’m putting these macros in the public domain, so use them as you wish. Cheers! EDIT: Fixed the macros. Made some mistakes. RGBAToComposite.afmacro CompositeToRGBA.afmacro

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

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.

Is there an ETA to correct this misbehavior?

When reading a RGBA file, Affiinty masks the RGB layers with the alpha. This is incorrect behavior. NO information should be loss because the alpha changes. The alpha is an independent channel from the RGB channels. If you do the following: Read the attached file. Write the attached file. The two images will be vastly different — because for some reason, Affinity masks the RGB channels with a black and white version of the alpha channel (this makes things really ugly). Attached is my test file. This program should NOT be throwing away information.

Explain.

I was looking at a simple base case that should result in no loss: Read in the sample PNG file above. 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 Read in the sample PNG file above Fill the alpha with all 1’s 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.

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

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.

Let me reiterate: if you read a PNG file, Affinity will mask the RGB channels with the alpha when you write that file. Even if you do nothing. "since you uploaded your testfile in another thread, here is the result directly with an export no other changes to the file;" You literally proved my point: exporting from Affinity to PNG will mask the RGB with the alpha by default. This is incorrect behavior. There is nothing, I repeat nothing about this behavior that is correct. Because you manage to find a work-around does not change the fact that Affinity has an incorrect export function. It is applying the Alpha as a mask to the RGB channels. If I read a PNG file into GIMP then export it, it does not mask the RGB channels. This is true in many programs that I have used. Affinity is the only program that does this incorrectly. RGBA channels are MEANT and DESIGNED to be separate channels.

This would be incorrect behavior. When writing the RGBA channels, they should be treated as separate entities. How Affinity works today is wrong. If I read a PNG file then write it out, Affinity will change the data in the RGB channels (it will apply the alpha like a white mask). This is incorrect behavior. There should be no masking. RGB and Alpha are separate and distinct channels. When writing you do not mask RGB with the alpha. Ever. Doing so means that Affinity can read a PNG file but will alter it upon write — even if the user does nothing. BTW, the .afphoto file retains the RGB information. You just can’t export it without it getting masked by the alpha. This is incorrect behavior.

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.

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.

I want to point out that the problem is in the export. Affinity will mask the RGB layers with the Alpha before export. This is incorrect behavior. Attached are public domain RGBA conversion routines that split the channels into layers and put them back together again, but do not fix the export issue. That requires work from Affinity. CompositeToRGBA.afmacro RGBAToComposite.afmacro

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: Write R, G, B and Alpha 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: Mask the Red, Green and Blue with the Alpha. Write R, G, B and Alpha 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.