Difference between these two layer situations?

[Chris26]

Publisher V 1

I can not seem to notice or understand the difference between these two simiar screenshots that I have taken of the same layers but arranged differently - Though I have seen this many times I took no notice of it because it did not seem to matter how it was positioned. I arranged the USM in different positions to demonstrate.

[thomaso]

In your example these two variants don't differ in my opinion.

The vertical hierarchy defines the executing & rendering order, the horizontal hierarchy causes clippling/cropping/masking of the indented 'child' layer. IMHO it doesn't make sense to nest an adjustment or filter layer inside another adjustment or filter layer (which would mean to apply the child to its parent, not to the image). In this example the two nested adjustment/filter layers (red) don't really affect their parent layers.
(Nevertheless, there might be very specific combinations  of adjustments or filters that could not achieve a same result without such nesting or without a separate clipping/cropping object.)

[NotMyFault]

You have 2 types of nesting child layers to a parent layer:

1. regular child layer position / half way ident
2. masking position / full ident

depending on positions, nested layers may or may not impact or interact with the alpha channel of the parent layer.this will become obvious  if the parent layer is not fully opaque.

 

[thomaso]

To keep informations together I borrow this from another recent thread:

3 hours ago, NotMyFault said:

The child layer position (masking/clipping) influences how colors and alpha values of the child layer get used.

• in masking position:
  • alpha values will impact the full canvas, unrestricted
  • color values (e.g. RGB channels) are simply ignored. Only color values from lower layers incl. parent will be blended, but the alpha value impacts the blend results.
• in clipping position
  • alpha values are clipped to the parent layer (where parent alpha is above 0)
  • color values are used (blended regularly), but again clipped to the parent layer nonzero alpha pixels.

this applies to all layer types (pixel, mask, adjustment, filter).

there are some exotic edge cases (stack use alpha as binary values), and groups (including Layer layers, symbols, compounds) are beasts on their own.

There is still much room for confusion (– apart from possible app issues, e.g. redraw or layer thumbnails for adjustments set to invisible).

In the samples below the Curve Adjustment has Alpha edited (causing inversion & increased contrast). The ellipse has a red fill + thin red stroke. All Blend modes + layer opacity are 'normal' / '100'.

It seems for the Mask layer alone it matters only for the Ellipse stroke whether the mask is in masking or in clipping position …
(all adjustments are deactivated):

… whereas with additional Adjustment layer the stroke doesn't get affected in each sample … while the various Mask results confuse:

Can you describe in words what process gets executed in the 4 samples?

Yellow: the adjustment affects the mask brush as expected … but why does the Mask not mask anymore?
Green: what prevents the mask brush from occurring within the background rectangle … but occurs outside only?
Blue: what prevents the mask brush entirely from occurring?
Pink: what is the black resulting from (… there is no 'white' in this layout that might got inverted) / and what limits the black to this rectangle (… not the full page)?

My goal is not to confuse or detect issues but to understand what's happening with the purpose to be able to predict a result of a setup instead of the need to try it.

v1105 mask&clip.afpub

[Chris26]

Wow, thank goodness all I ever need are the USM and Curves layers, they do not interfere with each other.  Thank you - read with interest.

[NotMyFault]

2 hours ago, thomaso said:

whereas with additional Adjustment layer the stroke doesn't get affected in each sample … while the various Mask results confuse:

Can you describe in words what process gets executed in the 4 samples?

Yellow: the adjustment affects the mask brush as expected … but why does the Mask not mask anymore?
The mask is misplaced. Use the move tool and select the mask in layer stack.

[NotMyFault]

2 hours ago, thomaso said:

Pink: what is the black resulting from (… there is no 'white' in this layout that might got inverted) / and what limits the black to this rectangle (… not the full page)?

 

The curve adjustment triggers an old unfixed bug.

It seems to affect (erroneously) the alpha channel. When you switch to photo persona and channels panel, activate alpha channel. When toggling visibility of the curves adjustment, you see that about half of the canvas gets black. This is a bug.

 

[NotMyFault]

2 hours ago, thomaso said:

Blue: what prevents the mask brush entirely from occurring?

you have added curve adjustments in CMYK mode, in a RGB document. bad idea. I strongly suggest to never use adjustment for anything in CMYK mode (either document or adjustment). Adjustments are only defined for RGB (Lab and GREY work, too. But CMYK is different). In CMYK, you have an inherent redundancy of K channel to CMY, leading to unexpected / wrong results in almost all cases. Don't use it.

 

Except you totally know what you are doing, or intending to get "creative" effects.

[NotMyFault]

2 hours ago, thomaso said:

Pink: what is the black resulting from (… there is no 'white' in this layout that might got inverted) / and what limits the black to this rectangle (… not the full page)?

again, rendering bug caused by curves in CMYK mode. 

[NotMyFault]

I would suggest to start with a less complex document. Use RGB only, not adjustments at this time. Stroke in mode "top".

 

 

 

parent child clipping masking.afphoto

[NotMyFault]

same with stroke "behind"

 

[thomaso]

@NotMyFault, Thanks for all your comments and views. I am aware that some of my tests appear strange, I think this helps me to understand the various processes. I don't have difficulties to distinguish between masking / clipping for colour layers but rather lack in predictable understanding of the influence of combinations of the other, color-less layer types like mask, adjustment, filter in their possible layer positions. (… as @Chris26 in the initial post of this thread)er

What exactly is a mask layer if its set as child in the clipping position? How does this position modify its masking property? Or: why don't I see change if I switch the position for a nested mask layer? (without an additionally nested object)

6 hours ago, NotMyFault said:

Yellow: the adjustment affects the mask brush as expected … but why does the Mask not mask anymore?
The mask is misplaced. Use the move tool and select the mask in layer stack.

I placed the mask at the clipping position in the Layers panel on purpose (to experience its result there). – But now I realised my question was a misunderstanding based on a wrong assumption: If the adjustment gets activated the mask in fact does mask but is just inverted: the Ellipse's fill is fully masked while the mask's brush remains. Sorry, it was an unnecessary, misleading question.

6 hours ago, NotMyFault said:

Blue: what prevents the mask brush entirely from occurring?

you have added curve adjustments in CMYK mode, in a RGB document. bad idea. I strongly suggest to never use adjustment for anything in CMYK mode (either document or adjustment). Adjustments are only defined for RGB (Lab and GREY work, too. But CMYK is different). In CMYK, you have an inherent redundancy of K channel to CMY, leading to unexpected / wrong results in almost all cases. Don't use it.

What do you mean by "Adjustments are only defined for RGB"? That their functions in Affinity aren't fully / failure-free coded? Or do you rather mean generally, regardless of Affinity? I am asking that explicitely because of the existing UI + menu options literally for CMYK adjustments. So, do you mean by "wrong results" the CMYK adjustment options in Affinity may cause buggy results? (… same reason you mention for the pink part?)

Initially I started the test in my standard CMYK test afpub and continued (copied) in a new RGB file later. Obviously the default colour space for a new adjustment matches the current document's space, I did not select cmyk in the adjustment. – But, since I alter in the adjustment Alpha only (which displays the same graph for RGB and CMYK, other than the various colour channels, while transparency has no colour space imho, I would expect an identical result, regardless of cmyk or rgb alpha setting.

Well, when I now create a new adjustment in this RGB document with a change for RGB Alpha then the result does not differ towards the previous CMYK adjustment: In both cases the Ellipse is fully masked (empty) and the brush not displayed, the Ellipse stroke excepted. Whereas both adjustments together do show content ( I assume because inversion + inversion = no inversion), while I wonder why in gray, not red then. – Is this again one of the "wrong" / buggy results?

Why is neither Ellipse fill nor mask Brush visible?

(dto.)

Why is the Ellipse fill grayscale now?

[NotMyFault]

6 hours ago, thomaso said:

What do you mean by "Adjustments are only defined for RGB"? That their functions in Affinity aren't fully / failure-free coded? Or do you rather mean generally, regardless of Affinity?

Hi Thomaso, 

we had similar discussions a year before, e.g.

 

Adjustments targeting all color channels (using the master channel in curves, or the invert adjustment) will lead to simply wrong results.

Do a simple test:

• Create new RGB document
• use a colorful photo (e.g. rainbow), id needs to show all shades of colors and saturation (not only fully saturated plus grey).
• add invert adjustment
• duplicate invert adjustment: the image looks as the original
• now convert to CMYK color space, and deactivate on of the inverts
• The inverted image looks different between RGB and CMYK

The reason behind this is simple math. Inversion just inverts every available channel. 

As long as you have an image where K is all zero, the results visually match between RGB and CMYK.

But when the CMYK version contains nonzero K, the visual results are unexpected.

It would be technically possible to provide a „cmyk invert“ which does what a unexperienced user wants. This is what i mean tha adjustments are not sanely defined. They do simple math, extended to the K Chanel, but the subtractive nature plus „K redundancy“ will provide visually different results in CMYK vs RGB, and the results are useless in most cases.

Edited September 24, 2023 by NotMyFault
Edited, first version of my reply was wrong

[NotMyFault]

8 hours ago, thomaso said:

Well, when I now create a new adjustment in this RGB document with a change for RGB Alpha then the result does not differ towards the previous CMYK adjustment:

I can’t follow what exactly you are doing, but i think you have an adjustment on alpha only (invert alpha, or create nonzero alpha), nested to a vector shape.

This triggers an old but still unfixed (in V1 and  V2.2) bug: Nested to a vector shape, the rendering gets erratic outside the shapes area, and normally will create black areas of random sizes (depending on zoom level).

 

Edited September 24, 2023 by NotMyFault
tested V2.2: big still present.

[NotMyFault]

another example: if you have a cmyk document, and want to visually invert it (getting similar result to invert adjustment in RGB document):

• add curves adjustment
• set mode to RGB
• use master channel
• invert start node and end node to get a falling line

This gives almost the same result as an image inverted in RGB, and then converted (as rasterised layer) to CMYK.

Similar, you can switch the curves adjustment to all color modes and inspect the results by inverting the curve. Only RGB and GREY will give what a normal user expects, CMYK and LAB will produce unexpected results. Again, these are correct by math, but unexpected and the reason why using most adjustments does not make sense in CMYK

 

[NotMyFault]

Next example: use HSL adjustment, set saturation to 0, do desaturate an image.

Use info panel with 3 color pickers (RGB, HSL, CMYK) to inspect the result.

The image still contains pixels with up to 10% saturation. The RGB values do not match.

HSL in CMYK seems to "equalise" all CMY values, and let K untouched. This works in RGB, but not so good in CMYK.

Edited September 25, 2023 by NotMyFault

[lepr]

@thomaso

Maybe the following will be of some help to you, although it isn't intended to directly answer your specific questions regarding alpha and compositing bugs.

It is an abstraction of an object as a stack of layers. It intentionally omits complications introduced by multiple fills and multiple strokes that are available in Appearance panel.

• effect is a Layer Effect
• transparency is the alpha modulation by Transparency Tool
• mask is any mask-nested entity
• child is any clip-nested entity
• there is only one fill
• there is only one stroke, and it is either 'in front' or 'behind'

 

{ effectn
    ⋮
  effect2
  effect1
  transparency
  maskn
    ⋮
  mask2
  mask1
  stroke that is 'in front'
  { childn
      ⋮
    child2
    child1
    fill
  }
  stroke that is 'behind'
}

 

[NotMyFault]

@thomaso

the main point to understand is:

• how parent and child layers interact which each other, on colors and alpha 
• This includes:
  • what child layers "can see" from layers below (their input)
  • does data color channels and/or alpha channels get used for blending, depending on position (their output)
  • does a child layer impact the parent's shape area (edge, non-zero alpha pixels)?
  • where does blend range of layers show their impact (what is meant with source and destination blend range)

Unfortunately, the names which were chosen for "clipping" and "masking" positions of child layers are kind of misleading. As lepr pointed out, the sequence of operations matters, e.g. when adjustment layers are executed, specifically the mask of those layers.

And when it comes to adjustments / filters affecting alpha, there are unfixed bugs in all 3 apps. 

 

Add strokes, layer fx, blend ranges, live mask filters and it becomes very complex immediately. Never the less, in theory everything is well defined (simple math).

Using groups and the very unfortunate blend mode passthrough implementation of Affinity can drive you insane in seconds.

If you want to continue digging deeper, try to focus on one case at a time. And stay in RGB model. CMYK introduced another layer of complexity (and some old bugs in affinity apps wrt color management). We can discuss CMYK related topics, but it makes more sense to discuss this for specific cases where the case is fully understood for RGB documents.  

[thomaso]

On 9/24/2023 at 9:33 AM, NotMyFault said:

we had similar discussions a year before, e.g.

Thank you, and sorry, I had overseen / forgotten this previous thread of mine.

On 9/24/2023 at 9:57 AM, NotMyFault said:

I can’t follow what exactly you are doing, but i think you have an adjustment on alpha only (invert alpha, or create nonzero alpha), nested to a vector shape.

This triggers an old but still unfixed (in V1 and  V2.2) bug:

Yes, just alpha, in both adjustments (RGB / CMYK) with same settings.

On 9/24/2023 at 9:33 AM, NotMyFault said:

As long as you have an image where K is all zero, the results visually match between RGB and CMYK.

But when the CMYK version contains nonzero K, the visual results are unexpected.

It would be technically possible to provide a „cmyk invert“ which does what a unexperienced user wants. This is what i mean tha adjustments are not sanely defined. They do simple math, extended to the K Chanel, but the subtractive nature plus „K redundancy“ will provide visually different results in CMYK vs RGB, and the results are useless in most cases.

Thank you! The explicit references to bugs in your various responses are helpful to understand that some visible results cannot be explained and understood in their genesis (~ "a causes b") while they show a wrong result (~ "a should cause b, but does c"), and that therefore a given process cannot be explained and understood because its correct process cannot be made visible with the use of a certain layer setup but possibly as final result only (~ 'merged / rasterized'). Whereas your references to "simple" mathematics appear unclear to me if they do not distinguish between "correct" (failure-free simplicity) and "not sanely defined" (too much simplicity).

I assume that due to my limited mathematical skills I am not able to predict a correct result, and therefore I run in difficulties to distinguish an incorrect workflow of myself from an application bug. You are right, a solution would be to generally avoid such workflows for CMYK, on the other hand it works sufficiently for many of my uses. Thus, also to proof my workflow by viewing or editing alpha channels doesn't really avoid my confusion since I can't judge if the Channels panel works fully correct (for the pink example above it seems not to work correctly / does not reflect in the panels thumbnails the issue of a black rectangle in exceeding size).

[Chris26]

Well along with the things that have been written here, plus the A.Photo's filters, its layer masking and its re-sizing dialogue are the reasons I decided to stop learning A.Photo and stayed with Photoshop.   I have to add that Publisher is great and Designer is great, nothing negative to say about either of these programs that I use extensivley, but A.Photo -what a nightmare -  gruelling and unwieldy.  I did not mind abandoming Adobe Indesign and Adobe illustrator, because of that I decided to get into A.Photo and abandon Photoshop as well.  Sorry, I have had a few years of Affinity and they do a fantastic job, and for their pricing one should not even begin to moan, but unfortunately I do wonder who actually designed  A.Photo, the final straw came for me when I went into soft proof, I decided, per off chance to compare Photoshop's soft proof with A/Photos soft proof.  I used Custom Made ICC profiles for both screens, I used all the same settings, Callibrated both monitors carefully and lo and behold, affinity's soft proof was so out of sync I was shocked.  And I have been soft proofing for over 15 years on and off, so it was not my screen to blame.  I wonder if Version 2 is any better? Still, affinity is to be congratulated, I still believe, for the other two programs.  So I am thankful.