When a layer has a transparent bg, the copy and paste selection covers that layer's content

[tieTYT]

I made an animated GIF to show what I'm seeing:

 

I don't know why that embedded link isn't working, so here's a direct link to the GIF: https://imgur.com/gallery/ivkyvFu

 

Hopefully that GIF explains everything, but I'll write a bug report, too.

 

Steps To Reproduce:

1. Create a new image
2. Create a new layer with a transparent background
3. Create a line in that layer
4. Ctrl+A (to select all)
5. Ctrl+C (to copy selection)
6. Ctrl+V (to paste)
7. Drag the selection around

 

Expected behavior:

Since the layer has a transparent background, the selection should not cover the line from step 3.

 

Actual behavior:

The selection covers the line from step 3.

 

Additional context:

This is probably a very popular use case so I'm assuming it is working as expected? If that is the case, Is there a way to change this behavior?

 

---------------------------

 

I might be reporting a duplicate of this, but most of the context has been lost so I can't tell:

 

Edited January 26 by tieTYT

[Red ochre]

Step 6: Ctrl + shift + V  should work. (Creating new transparent layer to paste into).

 

By pasting into the same layer, the new pasted image is overwriting the existing line, and when resized the copied transparency is replacing the existing line and showing the white background beneath. I don't think it is a bug.

 

@tieTYT I am confused by your gif video - why is 'Windows features' open?

[Tactilis]

7 hours ago, Red ochre said:

@tieTYT I am confused by your gif video - why is 'Windows features' open?

It isn't open @Red ochre.   It's a just screenshot of the 'Windows features' dialog that @tieTYT is editing in Layer 1.

 

 

7 hours ago, Red ochre said:

By pasting into the same layer, the new pasted image is overwriting the existing line, and when resized the copied transparency is replacing the existing line and showing the white background beneath.

That is correct, except that the OP is just moving the pasted pixels (not resizing them).




@tieTYT you have a couple of options:

1. As @Red ochre said, paste the copied Layer 2 area into a new layer: Edit -> Paste into New Layer or Ctrl+Shift+V

or

2. At step 4, don't copy the entire Layer 2. Just do a rectangle select around the line then Copy that, Paste in Layer 2 and then Move. So long as the moved area does not sit on top of the original line, you will get what you want.


 

 

[tieTYT]

On 1/26/2024 at 12:33 AM, Tactilis said:

@tieTYT you have a couple of options:

1. As @Red ochre said, paste the copied Layer 2 area into a new layer: Edit -> Paste into New Layer or Ctrl+Shift+V

or

2. At step 4, don't copy the entire Layer 2. Just do a rectangle select around the line then Copy that, Paste in Layer 2 and then Move. So long as the moved area does not sit on top of the original line, you will get what you want.


 

 

Sorry for the late reply. Both of those solve the problem, thanks.

 

Is this a bug? If it's not a bug, can you help me understand when the behavior in my GIF is advantageous? It'll help me understand when I should use it.

 

Thanks!

[Ego Eram Reputo]

3 hours ago, tieTYT said:

Is this a bug? If it's not a bug, can you help me understand when the behavior in my GIF is advantageous? It'll help me understand when I should use it.

 

No, it is not a bug.

 

It might help to think of the layer as a pane of glass you're swapping between window frames. You take the transparency with you when you replace the old glass with new (in PDN you're copying the clear bits as well as the opaque pixels in the layer).

 

If you were to double-glaze within the new frame, you add the second pane of glass to the first, preserving both layers of transparency (this is akin to pasting into a new layer).

 

This might help explain: https://www.getpaint.net/doc/latest/WorkingWithLayers.html

[Tactilis]

20 hours ago, tieTYT said:

can you help me understand when the behavior in my GIF is advantageous?

It's not specifically that it is advantageous; it is simply the way that pasting to the same layer, which is what you are doing at your original step 5, has to work.

You are taking an area of pixels (i.e. the whole of Layer 2 in your original steps, or a smaller area of Layer 2 around the pink line in my option 2 above) and pasting that to the same layer as a replacement for the existing pixels in that layer.  When you move the pasted area around and pasted transparent pixels replace those in the pink line, then the colour you 'see' is transparent.

Read the section of documentation that @Ego Eram Reputo pointed you at, then experiment to understand what is happening.

Try at your step 4 selecting in Layer 2 just part of the pink line and its surrounding transparent pixels, then paste and drag. Do you see what happens?

Now do the same but with the visibility of layer 1 (i.e. named Background in your GIF) turned off. Is it clearer now what is happening?



 

[Tactilis]

@tieTYT I've realised that part of your misunderstanding likely comes from the way you are referring to a layer's 'background'...
 

Quote

When a layer has a transparent bg
 

Create a new layer with a transparent background

 

Since the layer has a transparent background

Layers do not have 'backgrounds' (transparent or otherwise).  Layers just have pixels, some of which may be set to be transparent.

Every pixel has a Red/Green/Blue colour and an Alpha value (expand the Colors window to see the Alpha).

 

If a pixel's Alpha is 255 then that pixel's colour is fully opaque (like the pixels in your pink line).

 

If a pixel's Alpha is 0 then that pixel's colour is fully transparent (like the rest of the pixels in your Layer 2) which means that the pixel of any layer underneath will be seen through that pixel.

Forget about transparent 'backgrounds'. Just think about the pixels in a layer.


 

[tieTYT]

TL;DR: How does the current behavior improve the user experience compared to the behavior I expected?

 

------------

 

I think I understand, but just to be sure, I'll say it in my own words.

1. In each layer, there is exactly one pixel per "point." e.g., in a 200x300 layer, point (0,0) has exactly one pixel, point (1,0) does too, and this is true all the way to point (200, 300).
2. If you can't see the pixel, that is because it is transparent, but it is still there.
3. When you copy a selection, the transparent pixels of that selection are copied, too
4. When you move the selection, the transparent pixels will overwrite the pixels that existed in that location, even if the previous pixels were visible.

If I'm understanding that correctly, I'm glad I understand and this will prevent confusion for me in the future. I now see the rationale behind the behavior and appreciate the consistency with the way pixels work on layers in general. I can see now this isn't a bug but working intended. That said, I'd now like to change my "bug report" to a "feature request," if possible?

 

I'd like to ask, is this a good user experience compared to the behavior I expected? Namely, I expected the transparent pixels of my paste buffer/selection to leave the non-transparent pixels the way they were. Instead, they overwrite the visible pixels. If the current behavior is a good user experience, can someone explain to me why? I can't think of a situation where transparent pixels overwriting non-transparent pixels would be useful.

Edited February 12 by tieTYT

[Rick Brewster]

24 minutes ago, tieTYT said:

That said, I'd now like to change my "bug report" to a "feature request," if possible?

 

Nope. Use layers. The user experience does not need to be changed. Everything is behaving as intended and as it should.

[Tactilis]

55 minutes ago, tieTYT said:

I think I understand, but just to be sure, I'll say it in my own words.
1. ...
2. ...
3. ...
4. ...

 

@tieTYT You understand correctly.

The only thing I'd change is:

 

4. When you move the selection, the transparent pixels will overwrite the pixels that existed in that location, even if the previous pixels were visible.

 

The last part, while true, is an unnecessary addition.
The moved pixel overwrite, i.e. replace, the pixels that were previously there. Period. There's nothing more to add.

 

55 minutes ago, tieTYT said:

 I can't think of a situation where transparent pixels overwriting non-transparent pixels would be useful.

Then your mental model of what is happening is wrong.

Forget the idea of transparency. Imagine for a moment that the Alpha value is just another special form of 'colour', and that a pixel's colour is a combination of Red (0-255)/Green (0-255)/Blue (0-255)/Alpha (0-255).

When you move a pixel, you are just moving the RGBA value to the new location. That's it! That's all that happens. The previous value in that location is gone. The moved value is now there.

And you keep talking about "transparent pixels" but you are ignoring the fact that transparency isn't an all or nothing thing. There are degrees of transparency. Alpha can have any value from 0 (fully transparent), via degrees of being partially transparent (1-254), to 255 (opaque).

How does your 'feature request' work when you move partially transparent pixels?


As Rick says: "Use layers".  That's what they are there for.

 

 

 

[tieTYT]

1 hour ago, Tactilis said:

And you keep talking about "transparent pixels" but you are ignoring the fact that transparency isn't an all or nothing thing.

Apologies, my ignorance of proper terms is confusing my message. Whenever I have said, "transparent pixels" I meant any pixel with an alpha of zero; "Non-transparent" meant an alpha greater than zero.

 

You never asked for my life story, but in grade school, I was taught this as the definition of transparent: "Things that are transparent are so clear you can see through them as if there’s nothing there." Sometimes I fall back to that definition without considering the context. Sorry about that.

 

1 hour ago, Tactilis said:

How does your 'feature request' work when you move partially transparent pixels?

In this situation it would behave the same way as it currently works: the partially transparent pixels of the selection would completely overwrite the pixel they're covering.

Edited February 12 by tieTYT

[BoltBait]

It's pretty easy to use layers to handle this transparency issue for you.

 

Just press Ctrl+Shift+V instead of Ctrl+V.

 

Drag your selection around until you get it placed where you want.

 

Press Ctrl+M to merge your layer down.

 

You should now have your single layer with the new selection where you want it and transparent pixels will be ignored.

[Rick Brewster]

18 hours ago, tieTYT said:

I was taught this as the definition of transparent

My understanding, and the way I use the term, is that transparent is completely see-through (alpha = 0), while translucent is partially see-through ( 0 < alpha < 255 ). And then of course opaque is, well, neither transparent nor translucent (alpha = 255).

[tieTYT]

6 hours ago, Rick Brewster said:

My understanding, and the way I use the term, is that transparent is completely see-through (alpha = 0), while translucent is partially see-through ( 0 < alpha < 255 ). And then of course opaque is, well, neither transparent nor translucent (alpha = 255).

Awesome! That makes me feel better because I use the same definitions.

 

On 2/12/2024 at 4:21 PM, BoltBait said:

It's pretty easy to use layers to handle this transparency issue for you.

I completely agree! I think I'm making it seem otherwise, but that's not my intent. I now understand how to avoid the behavior in my original post (see the reply I marked as the answer), now I am trying to understand how to benefit from the transparent-pixels-overwrite-visible-pixels-in-the-same-layer behavior. How have you (or anyone else) leveraged this in useful ways?

Edited February 14 by tieTYT

[Tactilis]

7 hours ago, tieTYT said:

now I am trying to understand how to benefit from the transparent-pixels-overwrite-visible-pixels-in-the-same-layer behavior. How have you (or anyone else) leveraged this in useful ways?

You are overthinking this.

 

When you move pixels from one place to another then that is exactly what happens... The pixels are moved.

 

The source pixel's RGBA value is moved to the destination location.

 

That's it. Period.

 

There are no special rules about what happens if a pixel's alpha happens to be 0.

There's no specific "transparent-pixels-overwrite-visible-pixels-in-the-same-layer behavior"  to benefit from or leverage. All you are doing is moving pixels.