Moving an object through a layer with blending options causes the object to adopt blending options

Heh, an excellent example of a situation, where the parts work as they obviously should, but the result is quite unexpected.

BTW, the GUI does provide a way to get rid of the blending: select the offending objects, go to Object->Filter effects and disable the filter by unchecking the checkbox next to the filter name.

This sounds like a difficult 'bug' to fix, as this would need to have some intelligence to figure out which things I'm moving out of a blended layer that I don't want blended. That's really an artistic decision, isn't it?

Should it be that all objects moved to another layer have all their filter effects reset? Seems like overkill, and lots of people wouldn't like that.

Sure, you could attach a tag to objects to indicate that they really are foreign objects to the blended layer, but how long does it have to be in a layer to be considered to have taken on the attributes of that layer permanently? What if you save and come back to edit it 3 months later and then you're confused why this object has its filter effects reset, when all you did was move it from one layer to another.

I don't mean to throw cold water on this, but merely to illustrate that if anything is to change here, it needs to be very carefully nuanced.

Should this be a wishlist item?

There are two distinctly separate yet tightly coupled questions here:

1. Does any aspect of this feature constitute a usability defect?

2. Could this feature be implemented in a more logical conceptual model, which may exceed the current requirements of the feature?

I would argue that there are aspects of the feature which constitute usability defects. Namely, the blending modes are represented to the user as being a property of a layer, when in actuality, the blending modes are actualized by being applied to objects within the layer. The GUI does not represent to the user that objects assigned to a layer will have their filter settings modified to reflect the settings of the layer.

As an counter example, consider how other applications such as Photoshop perform this task. Layer modes are assigned to the layer itself. The layer is then asked by the application to draw itself. The layer searches for child objects and nested layers, which in turn draw themselves in a manner that is compliant with the parent layer mode. The important distinction is that the attributes of the layer mode always remain attached to the layer, and never permeate child structures. Thus, when child structures move out of the parent layer, they do not retain the settings associated with the former parent layer.

This in turn leads to question #2, "What is the best conceptual model to handle this feature?" I would like to see filter settings able to be applied to layers. When objects are placed within the layer, no filter settings of the child object should be modified. The layer should be capable of drawing itself, and child objects, without modifying the filter settings of child objects. Of course, this conceptual model would require the following:

A. The SVG specification must be capable of supporting this conceptual model.
B. An order of precedence must be defined so that a layer may, during rendering but not persistence, pass its attributes to sublayers, and sublayers may pass its attributes to objects.
C. The order of precedence must address how to resolve the rendering of filter settings in a child which conflict with or reverse the filter settings of a parent.
D. The Inkscape component logic must be modified to support this conceptual model.
E. The Inkscape GUI must be modified to support the underlying component logic.

(if you receive two additional copies of this comment, it's because the ones I sent by email didn't seem to come through)

Uh... That's a great plan you've devised, but I'll have to tell you
something: you've pretty much described the exact way Inkscape handles
these layer blending modes.

From SVG viewpoint layers and groups are the same thing. Actually,
layers in Inkscape are SVG groups with a special attribute telling
Inkscape that this group should act as a layer.

The valid targets for Filter Effects are shapes, groups and text
objects.

When you set a layer blending mode, Inkscape applies a Blend effect on
that layer (and enables the background accumulation buffer). When the
image is rendered, that layer is first rendered to an offscreen buffer,
the filter is applied on that buffer and that buffer is composited on
the working buffer (which may be the resulting image or some other
temporary buffer)

The problem is, when objects are moved out from a group, they retain
some of the settings of the group. Consider this situation: you group
some objects, move that group and then ungroup. If the objects retained
none of parent group properteries when moved outside of the group, the
contents of that group would have jumped back to their original
positions. This isn't the case because the transform attribute of the
group gets applied on the objects in the group when those object are
moved out of the group.

> Uh... That's a great plan you've devised, but I'll have to tell you
> something: you've pretty much described the exact way Inkscape handles
> these layer blending modes.

My pertinent point above was:

> The important distinction is that the attributes of the layer mode always remain
> attached to the layer, and never permeate child structures.

Your explanation states:

> ... the transform attribute of the group gets applied on the objects in the group
> when those object are moved out of the group.

By transformations being applied to objects in the group, the attributes of the layer mode effectively DO permeate child structures, which is contrary to the general concept of a layer (as established by other applications which use layers.)

I think we would be okay if we simply define layers as being special groups whose attributes are never passed onto child structures when child structures leave the layer.

Also, I think it's worth stating that your current approach introduces a level of complexity and inconsistency that will almost certainly generate bugs and confuse users. Let me give you just a few examples:

1. Create Layer 1 and Layer 2. Set the Blend Mode of Layer 2 to "Multiply 50%". The filter "filter2365" (or something) will be created. Create a square in Layer 2. The square will be drawn at Multiply 50%, yet in the Filter settings dialog, "filter2365" will remain unchecked when selecting the square. Now move the square to Layer 1. "filter2365" will now be checked. This is inconsistent behavior.

2. Create Layer 1 and Layer 2. Set the Blend Mode of Layer 2 to "Multiply 50%". The filter "filter2365" (or something) will be created. Create a square in Layer 2. The square will be drawn at Multiply 50%. Create a square in Layer 1. Select both squares, and group them. The square in Layer 2 will be moved to Layer 1, and will lose its blend mode.

3. Create Layer 1 and Layer 2. Create a square in Layer 2. Apply "Multiply 50%" as a new filter to the square. Create a square in Layer 1. Select both squares, and group them. The square in Layer 2 will be moved to Layer 1, but will not move its blend move. This behavior is inconsistent with the behavior demonstrated by example #2.

I understand that you, as developers, can systematically explain exactly the rules that are responsible for the behaviors demonstrated above. However, from an end user perspective, it requires us to know too much about the technical details of your implementation in order to understand why the tool doesn't behave according to a simple conceptual model.

Can i second that i find this an annoyance too, though currently not a huge annoyance, as i just undo the results.

Another useful option (though only solving some of the question) would be to be able to move objects direct from one layer to another without passing through intermediate layers. This could be done by making a selection, clicking a destination Layer, and choose a new menu item "Move Selection to this Layer"

d

I second too, and find this behavior unfriendly for the final user without prior technical knowledge of layer compositing.
Moreover if you try a similar thing in Gimp (copy & paste a selection from a semi-transparent layer to an opaque layer) the "object" (the selected area) gets copied with its own attributes (including opacity) and NOT the one of the layer.
I believe that from a conceptual point of view copying an object should not get the contained layer involved at all.

As for the example given by Niko Kiirala, I find it not relevant because the group is effectively destroyed while the layers remain. When ungrouping, the attributes of the group MUST be passed to the children, otherwise they are lost since the group is deleted. When moving from layer to layer on the contrary the layers remain with their own properties which should not mess with the objects: they are different entities. As said this is the approach followed by Gimp and others.

Finally, with this conceptual approach, what about a "Apply layer properties to objects" option that would effectively - when the user requests it - transfer (composite) the layer properties to the contained objects, then reset the layer properties to default values? This is the approach used in Blender when you want to apply the current transformation to an object. The position, rotation, and scale get applied to the object data, and reset to identity. The object does not move at all (visually) but the transformation (e.g. the translation) effectively reads 0,0,0 instead of the actual position relative to the global origin, because the actual position became the new reference.
This way the objects can be copied and pasted while retaining their properties, and layers and objects get uncoupled - at least conceptually.

Could not reproduce with file CorrectBlendingExample.svg. Please re-test.

Win 7 64-bit
Inkscape 0.92pre1_64bit r15044

Reproduced in Inkscape 0.92.

1. Create a layer (layer 1) and add a Square object
2. Create a layer (layer 2) above and create a Square object.
3. Set the "layer 2" blending options to mutiply.
4. Duplicate the square object in layer 2.
5. Right-click and move to "Layer 1".
6 Remove Layer 2

Expect:
Both Squares have no "multiply" blending options. Both should be solid color with no transparency.

Happens:
The duplicated square still has blending. The previous one in "layer 1" does not. The layer has no blending options. The UI does not allow the object to remove the blending attribute.

Hi, this issue has been migrated to Inkscape's new bug tracker on GitLab.

https://gitlab.com/inkscape/inbox/issues/1360

Closed by: https://gitlab.com/jhofinger