lepr

Great to see the word "objects" being officially used instead of "layers" in reference to things which are not Layers (capital el), but disappointed to not see exactly the same wording in Photo for consistency between all Affinity apps.

I expect your path will be ignored because it is invalid for a Windows absolute path - it should have a colon after the drive letter, like "C:"

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

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.

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

Apart from a few situations, I've been very impressed with the v2 Boolean results. It's clear the Booleans code has been entirely rewritten. Also, the Shape Builder Tool was never going to be viable with the old algorithms. The new Booleans and SBT have earned the responsible developer(s) much respect from me.

The screenshot below shows the intended symmetrical result of the named objects: "Left" + "Right" - "Remove" - "Remove". I provided a document that works around the bug, without a change to the shape of his objects, but it is not clear that Calvert even downloaded it. His response to me seems to be intended for someone who has asked why he is trying to construct an object from mirrored shapes.

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]

@Red Sands: yes, my mind is going. We've been discussing using Affinity's Move Tool to perform node snapping. If you allow losing the parametric controls of a Polygon object, it can be converted to a Curve object with nodes, and then the Node Tool enables convenient node snapping. Below is the equivalent of the node snapping part of the Inkscape video. I repeatedly used cmd+J followed by cmd+A to quickly duplicate a hexagon and select all of its nodes so that the entire object would be dragged each time. Notice that I was able to drag by any node, not just the node that snapped into place. OK, I cheated by not limiting myself to the Move Tool. snapping hexagons.mp4

Boolean operations bug found in 2.0.4 (and 2.1.0.1709 beta) Further info in linked thread:

Point Transform Tool was my first suggestion, but the OP would like Affinity to be able to snap Polygon vertices when using Move Tool as easily as it is done when using Move Tool in Inkscape - see the video that was pasted in this thread.

You found a bug in the Affinity 2.0.4 and current 2.1.0 beta Boolean operations. (Affinity 1.10.6 adds the green shapes without problem.) I've attached an adjusted document that will work in 2.x. The highest node of each green shape has been converted from smooth to sharp (without affecting the curvature of the S-shaped edges) by opt-clicking on the shorter handle of each of these nodes. Sign A new.afdesign

LOL. Come on, there is node snapping in Affinity. There is room for improvement, of course. As I said earlier, the snapping of the hexagons in the Inkscape video is more convenient.

You aren't using the moving object's Transform Origin as a handle that snaps. Here's my earlier instructions:

My statement of "user error" referred to your failing to use the Move Tool correctly when you failed to achieve the desired snapping when using that tool.

If you look at my previous message, I edited it after re-reading yours. I re-did the snapping of the Curve objects with the Move Tool in exactly the same way as I snapped the Polygons with the Move Tool. I do admit that the Move Tool relying on the use of an object's Transform Origin is less convenient than Inkscape's snapping of the hexagons in the video above.

Your image suggests user error to me. There really is precise snapping in Affinity. The screenshots below feature a zoom factor of over 70 million percent. The Polygon objects vertices and the Curve objects nodes were snapped by using Move Tool as I described earlier in this thread.

A solution is attached. I expect you'll understand how it works when you examine the document, but don't hesitate to ask questions. Sample New.afdesign

The following is broken in the current 2.1 beta, but it does work in 2.0.4. The method using Move Tool: In the app's snapping options, enable Snap To Object Geometry. Use Move Tool to select one Polygon object. Snap the Transform Origin to a vertex of that Polygon. On a Mac, ctrl-drag the Transform Origin to snap to a vertex of the other Polygon - the Transform Origin will act as a handle moving the first polygon. Regarding step 4: if you use Windows, look at the status bar at bottom of the app window to discover the modifier for "to move selected objects" when the pointer is over the Transform Origin.

Note the OP has Polygon objects, not Curve objects. The user would need to convert each Polygon to a Curve, losing their parametric nature, to use the Node Tool for the task. That could be acceptable to the OP, of course. There is a simple way to do the snapping with Move Tool, but it involves using the Transform Origin of the Polygon being moved. Transform origins are buggy in Affinity 2 at the moment, so I don't want to post something that could cause confusion. I was confused! 2.0.4 is OK. It is only the current 2.1 beta that has broken Transform Origins, so the method is posted in my next message.

There is no need to move the centres of rotation. Select only the hexagon that is to be moved. Press F to activate Point Transform Tool. Ensure the second snap option ("Snap to geometry...") in context toolbar is enabled. On a Mac, hold down ctrl key and drag a node of the selected hexagon until it snaps to a vertex of the other hexagon. Regarding step 4: you use Windows, so look at the status bar at bottom of the app window to discover the modifier for "to translate" when the pointer is over a node of the selected hexagon. Also, steps 1 and 2 can be transposed.

Point Transform Tool (F) If playing with the tool doesn't help, try also reading the Help, and then come back here if still needing help. [That comment was full of help, even if not helpful 😀]

I should have provided an example to avoid the misunderstanding. You selected all objects in the document for the vector flood fill. That does not test the situation I described, which had objects behind the selected ones, and the generated fills were placed at the very back of everything instead of just behind the hindmost selected object. Anyway, my problem was in the first 2.1 beta. The current (second) beta behaves as I wanted and initially expected, and so the developers must have considered the unwanted behaviour I witnessed to be a bug. Now the generated fills are placed just behind the hindmost selected object.

Thanks for the new file. I don't know the answer to your question, sorry. The following procedure will give you an Affinity document from which RGBA with intact RGB can be exported in TGA or PNG format: Open the TIFF file with Affinity Photo 2. Cut then paste the "Background" Pixel object (this will be explained later). In Channels panel, right-click on "Unassociated Alpha" and pick Load To Pixel Selection - marching ants will appear. Ensure the Pixel object is not selected in Layers panel because, when a Mask is added, we want it at top of the layer stack and not nested inside an object. Do Layer > New Mask Layer (or use the mask button at bottom of Layers panel) to create a raster Mask from the pixel selection. Optionally deselect the pixel selection and remove the marching ants by pressing cmd+D. A raster Mask will now be stacked above the Pixel object and a TGA or PNG can be exported. Step 2 should not be necessary, but if it is not performed then Affinity will bake the Unassociated Alpha channel into the "Background" object's alpha - including setting RGB to zero wherever alpha is zero - when the Affinity document is saved. Attached is an Affinity document with history that you can rewind and step through, and an exported TGA. dignumber8-2.afphoto dignumber8-2.tga