"Select same transparency" does not select objects with same transparency

[R C-R]

3 minutes ago, walt.farrell said:

But note that selecting the Layer does not select all its constituents.

Adding slightly to what Walt said, note also that this holds true for any kind of layer that has child layers. This includes both "(Layer)" & "(Group)" container layer types, but also can include among other things "(Curve)" layers with other "(Curve)" layers nested in them, like in this nested curves.afdesign example.

[Pioof]

7 hours ago, MEB said:

Layer structure/content sets the context for some of the behaviours/funcionality implemented in the app.

That is very well, but does it relate to the action of selecting objects? You show that a given effect applied to a layer or to an object give different results. I can see that this can be exploited in smart ways. Now if I select an object, apply "select same whatever" and do not get a collection of objects but a heterogeneous set of objects and layers, then every function I'll apply of this heterogeneous selection will have different effects on the visible objects, whether they're affected as individual objects, or whether they're affected as constituents of a selected layer (I initially thought it could make no difference, but you pointed me to one it makes --thank you for that). So this way of selecting "same transparency" does not seem any smarter, on the contrary.

And I hate to repeat myself but apparently this is something that does not shock you, guys: if you select an object A and ask "select the same transparency" and the result of that is A and B, every normal human being expects that to be symmetrical: select B, ask "select same transparency" and you should get A. AD does not do that. You don't seem to believe me, it's funny, so try it on MEB's file above (select_same_transpaqrency_2.afdesign

Click on the top left square, apply "select the same transparency", get the middle one selected. Deselect everything, click on the middle square, apply "select the same transparency", you won't get the top left one selected but still another square selected. The operation is not symmetrical. Not. It may be "by design", I don't care, I feel, and trust that 99% people would feel the same, that it should not behave this way.

Why do we see this asymmetry? AD does this because it treats separate opacity parameters, object opacity and layer opacity, the same (whereas they're not and they interact), but nevertheless only object opacity, when an object is selected, is considered as the key value to be matched (so, irrespective of the opacity of the container layer). In contrast, a consistent way of programming would be to consider as key value the product of the layer and object opacities. To be anal, that would not be always the apparent object opacity either since this perceptual opacity is affected by fill and stroke opacities, on top of that. The product of layer and object opacities would be some half-evident transparency property, at best. But at least this way of doing things would give a symmetrical behavior. Select an 50% opaque object in a 100% opaque layer, and you'll get all 100% opaque objects in a 50% opaque layer (and all 62.5% opaque objects in a 80% opaque layer etc). Select any one of these latter objects, choose "select same transparency" and you'll get all of them again. "Same" finally meaning same.

Obviously another way to do it is to make opacity a heritable property of a layer, whenever layer opacity is not 100%. Objects would inherit their non-100% opacity from their container layer. That would also allow symmetrical behavior, and you could always play with fill/stroke opacity if ever you wanted an object with a different perceptual opacity inside that non-opaque layer. Actually I much prefer this second version. It makes the concept of transparency sounder, and does not multiply redundant parameters.

In both cases the resultant selection would be a homogenous collection of objects, so whatever you decide to do on them would have consistent effects.

Sure, you could still find some other mechanism. I don't really care. As long as "same" means "same".

[walt.farrell]

You're right that it doesn't work as you want.

I'm happy with it meaning "object opacity as defined in the Layers panel" as it does today.

And I think that if someone is coloring some objects by using the color opacity, and others by Brush opacity, and others by using Tint, and others by using object opacity, and others by using the opacity of the object that contains the object (Layer, or Group), they are simply going to confuse themselves. Yes, those 5 methods may all give the same visual appearance, but it is a confusing way to work.

However, if you would like to raise a Feature Request for a new function, Select > Select Same > Visual Color (or possibly Color Appearance), I can see that it would be useful for a user who is making a design like that. 

[walt.farrell]

8 hours ago, Pioof said:

Click on the top left square, apply "select the same transparency", get the middle one selected.

But for the record, that statement is incorrect.

You must look at the Layers panel, where your will see that the top rectangle, and Layer1 are selected. But the Rectangle within Layer1 is not selected. You cannot determine from what is selected by looking at the canvas. The selection box there may enclose many items that are not actually selected Only the Layers panel will show you the selection accurately in all cases when there are multiple items selected. (Edit: Or even, sometimes, when there is only 1 object selected, as when Layer1 is selected and nothing else.)

[Old Bruce]

12 hours ago, Pioof said:

Obviously another way to do it is to make opacity a heritable property of a layer, whenever layer opacity is not 100%. Objects would inherit their non-100% opacity from their container layer. That would also allow symmetrical behavior, and you could always play with fill/stroke opacity if ever you wanted an object with a different perceptual opacity inside that non-opaque layer. Actually I much prefer this second version. It makes the concept of transparency sounder, and does not multiply redundant parameters.

Set the Layer (container) opacity to 40%, that makes the rectangles have 40% opacity. Remove one of the rectangles from the Layer. Is the 40% opacity still applied to that rectangle? Put a rectangle with 60% opacity into that Layer. Is it now 40% of 60% or just 40%? What happens to Rectangles at 50% opacity being placed into a layer with 90% opacity?

As it is now Rectangles have their opacity and Layers have their opacity. The Layer's opacity is then applied to the Rectangles' opacity. This is consistent.

[Pioof]

2 hours ago, Old Bruce said:

Set the Layer (container) opacity to 40%, that makes the rectangles have 40% opacity. Remove one of the rectangles from the Layer. Is the 40% opacity still applied to that rectangle?

If you drop it to a Layer with 70% opacity it'll have that 70%. If you drop it to the background (which as far as I understand behaves like a layer with 100% opacity, it has 100% opacity.

2 hours ago, Old Bruce said:

Put a rectangle with 60% opacity into that Layer. Is it now 40% of 60% or just 40%? What happens to Rectangles at 50% opacity being placed into a layer with 90% opacity?

You can't put a rectangle with 60% opacity into a Layer with 40%. It inherits its opacity from the Layer so its value can't be chosen independently. If you want to achieve a different perceptual effect you work with fill/stroke opacity, or you move it to a Layer with 24% opacity.

2 hours ago, Old Bruce said:

As it is now Rectangles have their opacity and Layers have their opacity. The Layer's opacity is then applied to the Rectangles' opacity. This is consistent.

It's a choice that has lead to an inconsistent behavior of "same transparency". As I said, there are several ways around that issue. The last solution I outlined is my preferred right now but I understand that the constraint it creates (all objects in the transparent layer have the same "layer transparency" --unless that layer transparency is 100%) may not please everybody.

[walt.farrell]

18 minutes ago, Pioof said:

If you drop it to a Layer with 70% opacity it'll have that 70%. If you drop it to the background (which as far as I understand behaves like a layer with 100% opacity, it has 100% opacity.

That is not how it works today.

18 minutes ago, Pioof said:

You can't put a rectangle with 60% opacity into a Layer with 40%. It inherits its opacity from the Layer

Yes, you can put it there, and no, it does not (today) inherit its opacity from the Layer. Opacity is a multiplication process, in a way. If you have a 100% opacity object in a 100% opacity Layer, its apparent opacity, on the canvas, is 100%.

But if you have a 100% opacity object in a 50% opacity Layer, it still has an absolute (layer, object) opacity of 100%, but an apparent opacity on the canvas of 50%.  100 * .5.

If you put a 60% opacity object in a 70% opacity Layer, it will have an apparent opacity, on the canvas, of 42% (.6 * .7) But the opacity shown in the Layers panel is still 60% for the object, and 70% for the layer, as each has its own absolute opacity, separate from the apparent or visual opacity you see on the canvas.

That is the way it works today, and thus that is the way we must work with it.

To make it simpler to understand, you could always use an opacity of 100% on any Layers, and assign lower opacities directly to the objects within the Layers. Then when you select an object that has 50% opacity, and do the Select Same > Transparency, you will get only other objects defined with 50% opacity via their definitions in the Layers panel.

 

[Old Bruce]

27 minutes ago, Pioof said:

It's a choice that has lead to an inconsistent behavior of "same transparency". 

No it hasn't lead to any inconsistency.

opacity select same.afdesign

[Pioof]

36 minutes ago, walt.farrell said:

That is not how it works today.

Yes, I know, I was explaining how my "solution 2" quoted by Old Bruce would work. Sorry for the present tense, it does not belong to a current reality.

[Pioof]

29 minutes ago, Old Bruce said:

No it hasn't lead to any inconsistency.

Yes it has. It slightly edited your file. Click on the object I called A, select same transparency, do whatever you like with the resultant selection : move it around, scale it, change fill color... whatever crosses your mind. It will affect object B (among others).

Undo, deselect everything and click on object B. Select same transparency, do whatever you like with the resultant selection : move it around, scale it, change fill color...  It won't affect object A.

transparency of A = transparency of B, but transparency of B ≠ transparency of A.
Didn't I already write this somewhere?

opacity select same.afdesign

[MEB]

Hi @Pioof,
There's a lot of things that can affect the opacity of an object on canvas (from the layer opacity, to color opacity, to masks, FX effects etc). If we would consider the visual appearance on canvas as the reference for the output selection it would select a huge variety of objects which probably have very few attributes in common that you could actually change in practise. Usually when you are creating artwork that require the use of various similar objects we tend to use the same attributes (even for consistency sake) to create them - think of an icon set with its similar stroke widths, colours, rounded corners etc or markers on a map or roads, or some common design elements repeated along a project - those are cases where selecting the object through their attributes makes sense because their all share (or should share) common elements that cab be used to select them consistently and precisely. If their visual appearance is coming for a diverse set of methods that don't really share the same base/common attributes is probably because these consistency isn't that important to start with. If you know from the start that selecting them precisely is a requirement for the job being done, having a command that selects exactly by a specific attribute (layer opacity in this case) is the only way to ensure you select the objects you really want and can edit "globally" because of their shared attributes rather than a nuisance.

[MEB]

44 minutes ago, Pioof said:

Yes it has. It slightly edited your file. Click on the object I called A, select same transparency, do whatever you like with the resultant selection : move it around, scale it, change fill color... whatever crosses your mind. It will affect object B (among others).

Undo, deselect everything and click on object B. Select same transparency, do whatever you like with the resultant selection : move it around, scale it, change fill color...  It won't affect object A.

transparency of A = transparency of B, but transparency of B ≠ transparency of A.
Didn't I already write this somewhere?

opacity select same.afdesign 11.74 kB · 1 download

In the first case selecting the object A (which have 40% opacity) does NOT select object B, it selects the layer that contains the object B which is different. Of course if you move the layer (which was selected because it shares the same layer opacity as object A) object B moves with it because it's contained inside that layer.

In the second case selecting object B (which have an opacity of 100%) doesn't affect object A because this object do not have the same opacity (which is 40%) and also because it is NOT contained in any layer with 100% opacity - it's an independent object.

Also note here objects are just being placed arbitrarily in layers in to explain/show how this works. In a real world case it would pay off to plan/structure your project and layers ahead according to what you are doing which should give you more predicable results when selecting and manipulating objects.

[Old Bruce]

47 minutes ago, Pioof said:

Yes it has. It slightly edited your file. Click on the object I called A, select same transparency, do whatever you like with the resultant selection : move it around, scale it, change fill color... whatever crosses your mind. It will affect object B (among others).

It will affect Layer 40% and all the items inside Layer 40%. That is why I put these items in Layer 40%. I want them to be affected together.

49 minutes ago, Pioof said:

... transparency of A = transparency of B...

Wrong. So wrong. Transparency of A is the same as the transparency of Layer 40%. The transparency of A is obviously not the transparency of B.