lepr
-
Posts
5,522 -
Joined
Posts posted by lepr
-
-
1 hour ago, Bobby Henderson said:
The "Align To" issue is more annoying when it comes to the Alignment commands in the Layer>Alignment fly-out menu. Those commands only seem to observe "Selection Bounds" behavior. They don't carry over any optional Align To settings from the Alignment palette. Is there a setting I'm missing somewhere in Preferences or somewhere else?
The alignment menu commands default to using the selection bounds, but they will observe a key object.
To mark the key object, opt/alt-click one of the selected objects after initially selecting it. That can be done after all of the selection is made, or at any moment during the selecting process. The key object is displayed with a thicker than normal outline.
Normally, the key object can be marked in the document view or the Layers panel, but there is a current bug in the macOS apps which prevents marking in the document view when "Allow selection to consider items in a Group" is enabled.
-
Thanks for the file.
The file is very unlike your opening example. It contains no "Unassociated Alpha" channel, and instead contains 4 hidden text objects (the numeral 8s) which I presume are supposed to mask or clip the blues Pixel object. Anyway, we can work with that.
To get a straight RGBA TGA or PNG export from Affinity, the alpha needs to be a raster Mask at the top of the layer stack in Affinity. You are going to convert the 8s to a raster Mask.
- Enable visibility of the four text objects then press cmd+G to group them (do not include the Pixel object in the Group).
- With only the Group object selected, do Select > Selection From Layer And Delete.
- The 8s will vanish and marching ants will appear where their edges were, indicating a pixel selection.
- 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 by pressing cmd+D.
- A raster Mask will now be stacked above the Pixel object and a TGA or PNG can be exported.
I have attached an Affinity document with history that you can rewind and step through, and an exported TGA.
dignumber8.afphotodignumber8.tga
-
14 hours ago, D.VE said:
Problem: If I move the layer it will automatically be added to the underlying artboard, even if the layer is locked
Bug or feature (that I can deactivate somehow)?
Use the little button at bottom left of Layers panel to disable Edit All Layers, and then the Artboards will stop stealing the "global layer".
- walt.farrell and D.VE
-
2
-
5 hours ago, chrisell said:
TGA or PNG or even PSD would work for sure. Interested to hear the workaround.
Then attach a TIFF, as I requested. I want to show you with one of your own files so there are no ambiguities.
-
3 hours ago, chrisell said:
The loaded file won't allow me to save back to a TIF - it's trying to force me to save it as an .afphoto file.
That is because of the additional channel named "Unassociated Alpha".
Affinity's RGBA TIFF output is going to be premultiplied, anyway, which is of no use to you.
I can give you a workaround if straight RGBA output to TGA or PNG format is acceptable (even if not ideal) to you.
Attach a problematic TIFF if you want to know more.
-
1 hour ago, jimh12345 said:
Is there a way to create a mask as a child of an adjustment layer?
No, Affinity insists on adding the Mask above a selected Adjustment. The mask placement options in the Assistant make no difference when the selected object is a Mask or Live Filter.
-
@Guillermo Espertino: By now, you should be doing your own experiments to ascertain or discredit my (and others) claim that Affinity is not storing premultiplied RGB values in pixels and is instead only setting RGB to zero where alpha is zero while storing straight RGB values when alpha is any other value.
If you are struggling to do so, I can try to help.
-
4 hours ago, Guillermo Espertino said:
Pixels with alpha=0 in unassociated images are expected to be lost in compositing. You don't create an alpha channel to preserve those pixels, unless you're doing some channel packing stuff for games.
There are people who wish to use Affinity for "doing some channel packing stuff for games."!!!
Those people are frustrated by Affinity setting RGB to zero where alpha is zero (which is not the associated alpha (a.k.a. premultiplied alpha) that you keep writing about) except when particular unintuitive workarounds are employed.
-
2 hours ago, Guillermo Espertino said:
No, that's incorrect.
Check the attached file. It has a multiplication by the smallest 8-bit integer value possible above 0 and a division by the same number, and the result is the original colour.
Your example is deeply flawed. You have chosen to use one of the only eight RGB colours, out of the available 16,777,216 RGB colours, that will be faithfully restored by the division following the multiplication.
@NotMyFault was correct.
Check the attached file which uses a gradient from black to red instead of your solid red.
-
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.
-
-
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.
-
On 2/15/2023 at 5:38 PM, Dan C said:
I can confirm that as I understand it, the objects location is resolution based, meaning when you have a different DPI from the source to the destination document, it's expected for this object to not be pasted in the same location.
The destination document has physical units, namely millimetres. We have been told that its PPI is half that of the source document.
In the video, the object's physical size is being correctly maintained because the destination document has physical units.
However, its top left corner physical coordinates are being scaled by two, as if the destination had pixels for document units.
I've now tested the pasting behaviour in Designer 1.10.6, 2.0.4 and 2.1.0 beta. All are misbehaving in the same way.
When the destination document has pixels for document units, pixels size and pixels origin of a pasted object are correctly maintained. Good so far.
However, when the destination document has physical document units, physical size is correctly maintained for a pasted object, but the object's physical origin is scaled by the ratio of source PPI to destination PPI because its pixels origin is maintained by mistake.
-
On 2/15/2023 at 5:39 PM, Intuos5 said:
For vector based documents, that's odd, but at least I know why it is happening now, thanks!
When destination document units is pixels, the pasted object should maintain size and top left location measured in pixels.
When destination document units is physical, the pasted object should maintain size and top left location measured in physical units (in Designer and Publisher, but not in Photo).
There is a bug when the destination document units is physical and the source and destination have different PPI: the pasted object's size is correct but its top left location is wrong. See my next comment for further information.
Edited once again: there is a bug.
-
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.
-
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.
-
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.
-
2 hours ago, IncognitoMode said:
Unfortunately this work around isn't very convenient, as when you want to apply multiple masks to the same layer, when stacking the levels adjustment above the mask, you have to apply the same levels adjustment to all of them, and cannot customise the levels adjustment to a particular mask.
Here's another workaround. Better than nothing until the bug is fixed.
Convert the Mask to a greyscale Pixel object and give it an intensity-to-opacity mapping in Blend Options (see screenshot). That Pixel object will act as a mask when mask-nested in an object. Any adjustment can be nested in the "mask", with the adjustment affecting the "mask's" colour channels instead of directly affecting alpha.
-
1 hour ago, IncognitoMode said:
Anyone have any ideas?
It's certainly a bug.
A workaround in your example document is to stack the Levels above the Mask instead of inside the Mask.
-
1 hour ago, loukash said:
Yes, but it won't work with those arrow ends.
The arrow ends can be a separate clipping shape containing a set of staffs Symbols. A minor complication that's outweighed by the convenient editing enabled by a live contoured path.
The attached document, loosely based on yours, is much more easily edited, in my opinion.
-
6 minutes ago, loukash said:
In case you need to change the yellow curve, you simply edit the original inside, expand a copy and use it as a new clipping curve again.
Contour Tool significantly simplifies that workflow by providing a live expansion of a base curve:
- no need to keep a duplicate base curve for future editing
- no need to do an expansion
- no need to move clipped objects from inside an old shape to inside a new shape
- no need to delete an old shape
-
Just now, Joshua Stamper said:
Thanks to you both.
You're welcome! I added a document to my message above.
-
52 minutes ago, Joshua Stamper said:
I'm still dealing with the issue above though, where the bottom three lines disappear and the top two lines terminate in the middle of the yellow stroke. Any ideas?
Your yellow clipping object appears to be an open path with no fill and a yellow path with stroke set to "Draw stroke behind".
Alternative solutions (use one or the other, not both):
- use Expand Stroke command to convert the path to a yellow-filled unstroked shape, and put the purple staff inside it
- use Contour Tool to give the path thickness, and swap fill and stroke colours (and optionally set stroke width to zero although it will now have no colour anyway)
The advantage of the latter solution is the original path is retained and is easier to edit than the shape created by Expand Stroke.
-
On 2/16/2023 at 3:12 PM, Ash said:
We'll have a chat here - perhaps we should just never drop the original using either key, would be more consistent.
If that change were made, it would create an inconsistency between object dragging operations and guide dragging operations. Then it could be argued that making the same change for cmd-dragging of objects would also improve consistency on two levels: creating consistency within object operations and restoring consistency between object operations and guide operations.
Actually, I'm happy with how cmd-dragging and opt-dragging an object has been working for years, and similarly happy that exactly the same modified dragging is now available for guides. My vote would be for leaving cmd-dragging as it is in the initial beta for 2.1.
Transforming selected group of nodes.
in Affinity on Desktop Questions (macOS and Windows)
Posted
Yes, enable Transform Mode in the context toolbar of Node Tool. That draws a bounding box and transform handles around selected nodes, and then the Transform panel can also be used for rotating and shearing in addition to always being usable for translating and scaling.
There is an adjacent button for Enable Transform Origin. However, the TO is buggy in 2.0.4 and 2.1.0 beta, with its location becoming offset when transforms are performed. The TO behaves correctly in In 1.10.6.