lepr
-
Posts
5,522 -
Joined
Posts posted by lepr
-
-
2 hours ago, jimh12345 said:
I don't get it at all. If I click on the path, I see this dialog:
If I mouse over it, a tooltip says its "a common path for items exported from this slice". But it's ignored when I actually export.
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:"
-
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.
-
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.
-
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.
-
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.
-
3 hours ago, lacerto said:
It is "interesting" (to avoid using a harsher word) that these things keep on happening. In many respects the Boolean operations have improved in 2.x versions but then there are new flaws that I hope are "just" regressions. But this one [thanks for the workaround] shows that there might be something that is more fundamentally broken. It is as if we'd need to have combined functionality of version 1 and 2 apps. I have called this in some of my posts as Affinity kind of Boolean co-operation, but I am still hoping that this is just a bad joke so that it is not necessary to permanently keep three versions of each app installed (1, 2 and latest beta) to get things done.
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.
-
3 hours ago, Ron P. said:
I still am unclear as to what the end result should look like. Are the examples provided what it should look like? There's more than one way to do things, especially when there are bugs in the software.
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.
-
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]
-
@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.
-
Boolean operations bug found in 2.0.4 (and 2.1.0.1709 beta)
Further info in linked thread:
-
48 minutes ago, user_0815 said:
If I use the "point transformation tool", I can click on the node I want to snap and it will snap to any node of the other polygon.
Is that what the op was looking for? Or did he just want to suggest a different way of doing it?
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.
-
On 2/24/2023 at 2:18 PM, Calvert said:
I am trying to weld the left and right together to form a symmetrical shape. Then Im trying to subtract the 2 small circles from the corners.
When I take the left and right, and add, it is actually subtracting, leaving the area not overlapped. That is NOT what I want... I want it to add the 2 as one curve. Not to mention once this is done, the (cntrol +Z) function wont work and have to fo to the menu to make it undo.
Version is latest Beta.
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.
-
1 minute ago, Red Sands said:
Hahaha now I see the transform origin part. You gotta be kidding:
I didn't fail anything. This is pushing the workaround concept to the maximum. Even by Linux standards. Don't call anything like that "using it correctly".
NO node snapping implemented in Affinity. Simple as that.
!Over and out!
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.
-
4 minutes ago, Red Sands said:
What setting prevents me from succes here? I only see vertical or horisontal edge snapping:
You aren't using the moving object's Transform Origin as a handle that snaps. Here's my earlier instructions:
15 hours ago, ,,, said: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.
-
15 minutes ago, Red Sands said:
I wouldnt call this "User error" - I would call it clumsy workaround. Different behavior even depending on type of shape? Not how it should be done.
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.
-
8 minutes ago, Red Sands said:
Ah, I can see there is some kind of node snapping if you select all nodes with the node tool and move the object. But then you will have to know this is how to do it, and toggle between the move and node tool to rotate and skew. I wouldnt call this "User error" - I would call it clumsy workaround. Different behavior even depending on type of shape? Not how it should be done.
But the conclusion is still that this type of snapping is not implemented in Affinity as such. There are just ways to achieve it in a roundabout way.
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.
-
6 hours ago, Red Sands said:
Bottom line, there is no real node snapping in Affinity when using the move tool. Even with these advice, zoom in and discover this:
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.
-
On 2/22/2023 at 5:09 AM, Frankly said:
I've been reworking this pattern trying to find a method that repeats seamlessly, but haven't discovered the secret. I used the exact stroke and blur for each line, but when it has the pattern underneath, it doesn't match in a couple of areas. When I create the stroke lines without the pattern art, they match up better, but still not perfectly seamless. I see other artists that do pattern work with shadows and gradients. There must be some instruction on how to do this. Here is the basic shadow pattern without the art to illustrate what I tried to do to patch the areas that had mismatches, but it's virtually impossible to so that. If you remove the patches on this sample shadow pattern it matches up pretty good. This is a half drop repeat, so I made the tile accordingly.
A solution is attached. I expect you'll understand how it works when you examine the document, but don't hesitate to ask questions.
- DesignerMatt, lacerto and Frankly
-
3
-
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.
-
50 minutes ago, Old Bruce said:
Don't use the Move tool. Use the Node tool and select both objects. Drag select all the nodes on the one you want to move. Grab the node you want to be aligned and drag it (and all the other selected nodes, solid in the picture) overtop the one you want it aligned to. If you have the for the node tool context toolbar setup to be able to Snap you can get the nodes to snap. You can even turn off the regular snapping and still get the nodes snapping.
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. -
24 minutes ago, Philou7168 said:
And again, you have to move the center of rotation of each object to the node you want to snap, otherwise it doesn't work, or I set the snapping wrong.
You have to do a lot of manipulation for a simple snapping of 2 nodes.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 😀]
-
On 2/23/2023 at 9:33 AM, Sean P said:
Hi ,,,
I believe this is intentional - It allows you to retain the 'look' of what you're filling.For example if I have a series of overlapping rectangles with a stroke and no fill, I can see each stroke overlapping the other objects:
If I select all of those shapes and fill a region it is placed at the bottom of the layer stack. This allows all the strokes to retain their thickness:
If I move that fill to below the object the strokes above begin to get lose their thickness due to layer ordering:
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.
-
5 hours ago, chrisell said:
I opened it in AP2 and for sure it doesn't show an unassociated alpha. Being a little confused as to what that was, I deleted the hidden layers in the TIF texture and re-saved it and now it does show unassociated alpha when imported into AP2. I've attached the new file here too.
So that leads to another question I guess - why is the behaviour different if there are hidden layers in the source texture?
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
Auto select option in move tool
in [ARCHIVE] 2.3, 2.2 & 2.1 Features and Improvements
Posted · Edited by ,,,
deleted misunderstanding
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.