Inconsistent stroke behaviors

[barbBear]

Hello,

I am beginning work on a single page document in Affinity Publisher 2.5.5 on MacOSX 15.0.1.

I have placed three images. Two of the images are .jpg files and one is an .afphoto. All three photos have the same stroke (panel pictured) attributes applied. I have attached a magnified screen grab image.

Each image has a different stroke behavior. As you can see, the selected jpg (Selected with Move tool) has rounded joins and appears(?) to have one point of stroke on each side of the frame. OK; however, the upper jpg appears to have only one point of stroke (to the outside) and the afphoto has no stroke at all. All three images, should, I think, have 1 point of stroke, butt cap, round join, centered on frame coordinates.

I didn't expect this behavior. Why is this happening?

Barb.

 

[NotMyFault]

Can you upload the actual file?
Stroke depends on order. If the stroke is painted first, it will be 1/2 width of stroke painted above a layer.

embedded afphoto file may get treaded differently depending on content and its transparency.

[thomaso]

Additional to the stroke order mentioned above, scaling an object may alter the stroke width and appearance: If the object has the stroke option "Scale with object" selected and gets stretched for instance the displayed stroke value may confuse.

Also, the visibility of stroke & fill depends on the Affinity layer type:

• "Pixel" layers for instance do not display an applied stroke. (I wonder why the stroke or fill panel options aren't greyed out for those layers)
   
• Layers of type "Image" (e.g. jpg, tif, png) are kind of 'pixel layers placed inside a vector rectangle' and an applied stroke appears as in your two examples.
   
• For images within Picture Frames a stroke may get assigned to the parent or to the child object. If applied to the child the stroke may be entirely hidden/invisible and clipped by the parent frame object. If applied to the parent frame the stroke is displayed independently of a current image clipping.
   
• Some certain file formats like Affinity documents, PDF, EPS, SVG may contain vector AND pixel objects and are a kind of "container" file types. Some can exist without a certain 'page' size and/or may have various dimensions if placed in Affinity, where their "Page Box" setting defines the displayed area. They don't display an assigned stroke but need a parent vector object to display a stroke at the edges of their selection box (e.g. a vector shape object or a Picture Frame).

[barbBear]

Here's the packaged and compressed document. (I would typically downsample the images, but I was just getting started and was sidetracked with the frame issue 

PackagedSamplebBear.zip

[barbBear]

Thank you for your input(s).

Transparency should be 100% (as it was not intended to be edited in any manner).

Images were placed and then the frame was applied to each item - as a stroke using the Stroke panel.

"If the stroke is painted first, it will be 1/2 width of stroke painted above a layer." - I didn't know that. Hmm.

Stroke is not set to 'scale with object'.

Images were scaled during placement (with click & drag) and stroke was applied in a separate operation after scale was completed.

'Layers of type "Image" (e.g. jpg, tif, png) are kind of 'pixel layers placed inside a vector rectangle' and...' - I need to research this concept in more detail. My thinking was, then; the Node tool would select the content/child and Move tool would select the object/container; however, when selecting and applying a stroke, the tool used (Move vs. Node) doesn't appear to impact the stroke...? (Attached screen grab). I have not used Picture Frames, so I will need to study this.

Thanks.
Barb

[lacerto]

The different strokes can be explained by the following factors:

1) In the image top left you have cropped the image, and the surrounding stroke retains the original width but the stroke is placed based on alignment and when outside alignment is used, can be cropped totally invisible. When center alignment is used, half of the width is visible (as in your screenshot), and when inside alignment is use, the total width is visible.

2) In context of .aphoto and other documents, and pixel layers, the stroke setting has no effect.

3) The .jpg image is the only one that has "standard" stroke effect; it is because its containing layer is "Image", in practice a vector object (and as mentioned, drawing order can have effect on the width of the stroke). However, it does not appear that scaling has effect on the stroke width [unless forced by using the the appropriate stroke attribute, but then the actual width is also shown in the stroke width box]. 

[NotMyFault]

I think the handling of strokes is inconsistent in the case of using a vector mask.

When using a rectangle shape as mask (center aligned, 2px width)

1. edge get full width stroke on its outer edges of jpeg, but only 1/2 width stroke on inner edged created by ectangle
2. if you rotate or shear the rectangle by e.g. 15 degrees, the inner edges vanish at some distance from the outer edges
3. if you convert to curve, and create a slight curvature at one of the edges, the stroke vanishes immediately

for me it is not reproducible why the stroke width behaves in this way. 
It seems like affinity uses a 2 step approach:

• use the bounding box of the stroke to cut out the image, paint the stroke
• use the actual shape to cut out the masked part

Testing on iPad is hampered as the stroke is always rendered wrong while you edit the masking shape, and only after some zooming a redraw will show the final rendering.

 

 

[barbBear]

Thank you for your insights.

 

[thomaso]

12 hours ago, NotMyFault said:

I think the handling of strokes is inconsistent in the case of using a vector mask.

Generally, or in a certain V2 version only? – Sorry, I can't follow your examples.
• What is "2px width" ?
• How does the image look like without mask?
• How is the stroke created around the image: as vector stroke – or pixel painted?

Your screenshots don't look unusual to me, except this one where I don't understand some details:

For a rectangular mask with a partial curve + an image with a stroke and its edges cropped differently, this is the result I would expect.

Just in case: note that a stroke applied to a vector mask does not appear as stroke but simply increases the mask by the width of the stroke.

[NotMyFault]

The stroke is applied to the embedded jpg image layer. 
I just converted the existing rectangle (no stroke) to a curve, it is used as mask, and moved it to cover both jpeg edges and inner areas. 

[lacerto]

4 hours ago, thomaso said:

Generally, or in a certain V2 version only?

I think that the behavior is identical in both versions. Stroke behavior may appear inconsistent (especially in case of cropping, i.e., when using a vector mask), but IMO it is logical (and not buggy). One just needs to understand the differences and apply stroke attributes accordingly.

[thomaso]

2 hours ago, lacerto said:

IMO it is logical (and not buggy). One just needs to understand the differences and apply stroke attributes accordingly.

me too. - If masked, it may get more complex or confusing with variations of centre / inside / outside stroke alignment: the outer half of a centred stroke can get covered by a vector mask of same dimensions like the image because in this case the image's bounding box is smaller than its visual object (object size minus 1/2 stroke width). This may appear unexpectedly and feel like a bug – or 'just' require another setup … or possibly a workaround, for instance:

[NotMyFault]

In case of layers from jpeg files, with a stroke applied, and added a vector mask the stroke is based on the bounding box of the vector layer, instead of the actual curvature.

This is just a performance improving shortcut of Affinity Apps and a bug in my view, as the stroke is now depending on something (the bounding box) which is out of the control of the user. The behavior means that you cannot use a non-rectangular unrotated vector mask when the parent layer has a stroke, or accept unpredictable results.

The usual workaround of putting the layer into a group and apply the stroke to the group instead of the parent layer doesn’t help either.

so you need to fallback to layer fx outline (which is far more limited vs stroke, e.g. no brushes to choose, no dotter line, line sharp edges possible).

so to get the expected behavior you need to use far more complex workarounds including a linked copy of the masking shape.

I would say it is practically impossible to get a nice centered stroke (with pressure profile or custom brush or dotted line) with sharp (not rounded) edges based on a rotated or sheared or curved vector mask. You would need to use 2 shapes for masking and another copy to create the stroke.

 

[NotMyFault]

What you can do is using the masking shape directly, and apply a bitmap fill to it. This will offer all stroke options.

[thomaso]

2 hours ago, NotMyFault said:

In case of layers from jpeg files, with a stroke applied, and added a vector mask the stroke is based on the bounding box of the vector layer, instead of the actual curvature. (…)

I would say it is practically impossible to get a nice centered stroke (with pressure profile or custom brush or dotted line) with sharp (not rounded) edges based on a rotated or sheared or curved vector mask.

I am not sure what you mean by "actual curvature" and "nice centred stroke". – If you mean the masking vector shape than switching the layer hierarchy may achieve the goal: The stroke gets assigned to the curved, rotated, sheared shape while the rectangular JPG gets nested as child layer of the clipping curve.

[NotMyFault]

Probably we want to express the same but use different wordings.

 

[thomaso]

3 hours ago, NotMyFault said:

What you can do is using the masking shape directly, and apply a bitmap fill to it. This will offer all stroke options.

9 minutes ago, NotMyFault said:

Probably we want to express the same but use different wordings.

I am not sure if it's a language issue only: While you seem to think certain stroke settings are inconsistent or even impossible, I think they can be done in a "just" not intuitive interface.

Accordingly I prefer to avoid using a Bitmap Fill if a nested Image layer can achieve the same result (and more flexible / less destructive than the Fill).

[NotMyFault]

Last try from my side:

The OP tried to combine stroke, applied on an image layer, combined with a vector mask (fill only, no stroke on mask). This method will always give unexpected and inconsistent results wrt to stroke.

Instead, you can use clipping, nest the image layer to a vector shape and apply the stroke to the vector shape. Or use bitmap fill.

just remember that both options (clipping vs. Masking) have certain limitations and are not interchangeable in all use cases:

• clipping does not work with compound shapes or grouped shapes as parent
• masking works with compound shapes and compound masks.
• Anti-aliasing differs (unfixed bugs, use precise clipping not working on iPad)

So you need to accept certain limitations, especially when trying to combine features (like stroke and masking or clipping).

[lacerto]

On 11/12/2024 at 12:07 AM, thomaso said:

Pixel" layers for instance do not display an applied stroke. (I wonder why the stroke or fill panel options aren't greyed out for those layers)

Even if stroke (or fill) attributes do not have effect on Pixel layer, they are "recorded" and can be meaningful when converting a Pixel layer to a Picture Frame object (while not when converting it to an Image object, in which case they simply get reset/zeroed/removed):

 (I have not tested but would imagine that the behavior is identical in v1 apps.)

Somewhat parallelly, a masking shape can have any latent stroke attributes applied (e.g. color, width, drawing order, style, join/align type, etc.), which may or may not have visual (but boundary-only related) effect on the object that is masked when the object serves as a mask, but become visual attributes if the object is released from its masking position. 

[thomaso]

6 hours ago, lacerto said:

Even if stroke (or fill) attributes do not have effect on Pixel layer, they are "recorded" and can be meaningful when converting a Pixel layer to a Picture Frame object (while not when converting it to an Image object, in which case they simply get reset/zeroed/removed):

 (I have not tested but would imagine that the behavior is identical in v1 apps.)

Interesting, thanks, and yes, it's the same in V1. – To me this does not make sense and the difference between Picture Frame and Image layer sounds even more strange. Also, I would assume such a 'recorded' stroke of a Pixel object would appear at its non-transparent edges after this layer type conversion – while it seems to be displayed at the rectangular bounding box edges, entirely ignoring the former pixel shape. (Maybe this is one of the inconsistency cases meant by @NotMyFault before?)

6 hours ago, lacerto said:

Somewhat parallelly, a masking shape can have any latent stroke attributes applied

This seems to be different in V1. Here the pixel object behaves like a no masking / not mask object and different to vector masks which indeed do increase by an applied stroke. Releasing a pixel object from its masking position does not change its dimensions visually if it got a stroke assigned before or after its switch to/from a mask.

[lacerto]

15 hours ago, thomaso said:

Interesting, thanks, and yes, it's the same in V1. – To me this does not make sense and the difference between Picture Frame and Image layer sounds even more strange.

Well, I, on the other hand, see conversion of a Pixel layer to a Picture Frame just as a kind of a power shortcut as it first converts a Pixel Layer to an Image Layer and then creates a clipping vector frame to enclose the Image, to allow visible stroke attributes [separately from the image, which can be controlled independently]. It is basically the opposite of applying cropping on an Image layer, which is a shortcut of creating a masking rectangle.

As for the parallel example, I probably explained myself poorly, as I was just referring to "latent" stroke (and fill) attributes of a masking shape (= vector object).

I can understand that all these combinations can be confusing, but IMO they all operate logically, and can be used in meaningful ways.  

[thomaso]

8 minutes ago, lacerto said:

I can understand that all these combinations can be confusing, but IMO they all operate logically, and can be used in meaningful ways.  

Yes, as I said before the unintuitive interfaces may be more confusing than the logic behind the features.

Maybe I also was mislead by my ideas for a conversion of a pixel object into a Picture Frame object. For the latter I just expected that possible transparency in the pixel layer would be considered when converting and might result in more flexible shapes than just a rectangular frame with the nested pixel layer. (… similar to the 'tracing' feature that may create multi-node curves for APub's Text Wrap)