Jump to content
You must now use your email address to sign in [click for more info] ×

Affinity Photo 2.1 (not sure if it is only related to this) copy and paste and export is not consistent


Recommended Posts

2 minutes ago, lepr said:

We already know that you utterly failed to comprehend the video I provided you along with a written list of the steps I took. 

I & at least a few others fail to comprehend the relevance of your video to what we have been talking about; namely the creation during a copy of partially transparent pixels when a transformed pixel selection is applied to a pixel layer that has no partially transparent pixels & everything is perfectly pixel aligned.

All 3 1.10.8, & all 3 V2.4.2 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

14 minutes ago, lepr said:

You've written message after message in disagreement with how I said it does work.

Not true. I have been as clear as I possibly can be in post after post that there is no disagreement about how it does work, not by me or by anyone else, only that there is no good reason that it does work as it does. That distinction seems lost on you.

EDIT: If nothing else, please refer to my earlier tests in which I confirm that I do get partially transparent pixels, even when there are none in the pixel layer I am copying from & everything is pixel aligned. Considering that, I do not understand how you could believe I am in any way disagreeing about how it does work.

All 3 1.10.8, & all 3 V2.4.2 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

14 minutes ago, R C-R said:

several others besides myself & @CyberAngel believe there is no good reason why it works like it does now.

Do you mean you think the software is not performing as designed, or do you think the software designer has made an irrational design decision, or do you mean something else?

Link to comment
Share on other sites

13 minutes ago, R C-R said:

Not true. I have been as clear as I possibly can be in post after post that there is no disagreement about how it does work, not by me or by anyone else, only that there is no good reason that it does work as it does. That distinction seems lost on you.

EDIT: If nothing else, please refer to my earlier tests in which I confirm that I do get partially transparent pixels, even when there are none in the pixel layer I am copying from & everything is pixel aligned. Considering that, I do not understand how you could believe I am in any way disagreeing about how it does work.

 

ROTFLMAO

You are actually denying the visible record of your insisting that my version of how the software works is "nonsense".

 

Link to comment
Share on other sites

1 minute ago, lepr said:

Do you mean you think the software is not performing as designed, or do you think the software designer has made an irrational design decision, or do you mean something else?

I think the software should not behave as it does under the conditions described, so if it was designed to work that way, it was a very odd design decision, but I do not know if it was designed to do that or is the result of some bug.

3 minutes ago, lepr said:

You are actually denying the visible record of your insisting that my version of how the software works is "nonsense".

Actually, what I said was nonsense is the notion that a marching ants pixel selection is an actual raster object. Regarding that, please refer to what @Old Bruce just said about a marquee selection just being a defined area of the document, which is what I also believe it to be.

But how the software works under the specific conditions described makes no sense to me (& to some others) so I suppose I am saying that in that very limited & specific case it does behave nonsensically.

All 3 1.10.8, & all 3 V2.4.2 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

@R C-R and @lepr, please correct me if I am somehow misreading your various comments.

I think you are both in agreement that the way the resized marquee selection is copying and or pasting pixels is very odd and unexpected. Meaning there should not be transparency/reduced opacity.

Further to this, at first I was skeptical about it. My tests didn't show me that this was in fact happening. After doing some more tests and looking really hard, I realized I was in fact wrong and am now in agreement with both of you.

The Transparency/lower opacity/Feathering should not be happening. Why it is I do not know. I wish it didn't. I believe the two of you would agree with that "I wish it didn't" statement.

Mac Pro (Late 2013) Mac OS 12.7.4 
Affinity Designer 2.4.1 | Affinity Photo 2.4.1 | Affinity Publisher 2.4.1 | Beta versions as they appear.

I have never mastered color management, period, so I cannot help with that.

Link to comment
Share on other sites

2 minutes ago, Old Bruce said:

I think you are both in agreement that the way the resized marquee selection is copying and or pasting pixels is very odd and unexpected. Meaning there should not be transparency/reduced opacity.

I think it is odd & unexpected. I do not know if @lepr agrees with that.

All 3 1.10.8, & all 3 V2.4.2 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

31 minutes ago, Old Bruce said:

I think you are both in agreement that the way the resized marquee selection is copying and or pasting pixels is very odd and unexpected. Meaning there should not be transparency/reduced opacity.

Further to this, at first I was skeptical about it. My tests didn't show me that this was in fact happening. After doing some more tests and looking really hard, I realized I was in fact wrong and am now in agreement with both of you.

The Transparency/lower opacity/Feathering should not be happening. Why it is I do not know. I wish it didn't. I believe the two of you would agree with that "I wish it didn't" statement.

 

The feathering doesn't upset me because I know why it is happening, and therefore I ensure it doesn't happen.

Link to comment
Share on other sites

2 minutes ago, lepr said:

 

The feathering doesn't upset me because I know why it is happening, and therefore I ensure it doesn't happen.

Other than by not changing the marquee after it has been created, how would you do that?

All 3 1.10.8, & all 3 V2.4.2 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

40 minutes ago, R C-R said:

I think it is odd & unexpected. I do not know if @lepr agrees with that.

I thought it odd the first time it happened to me, but a few tests confirmed my suspicion of why it was happening. I posted a little about it years ago, soon after discovering Affinity.

Link to comment
Share on other sites

2 hours ago, R C-R said:

Other than by not changing the marquee after it has been created, how would you do that?

Not stretching the Pixel Selection is the solution. Please read on before posting a rant.

You were told at least twice in this thread to use a vector Rectangle and only convert it to a Pixel Selection after it has been sized as required. Ensure 'Force Pixel Alignment' is enabled and draw a vector Rectangle, then stretch it as required, and then create a Pixel Selection from the Rectangle.

Of course, someone will complain that the vector Rectangle needs to be opaque and have no stroke at the moment a Pixel Selection is created from it.

It doesn't need to be if you use the attached macro to convert a vector object to an 'opaque' Pixel Selection.

The object stroke and fill are irrelevant to the macro, so you can use a Rectangle with no fill and stroke, or any fill and stroke that you prefer, and the result will be as if the object had an opaque fill and no stroke.

I'm sure your cohort will misinterpret the instructions or the entire message and say it doesn't work.

Object to Pixel Selection.afmacro

 

 

 

Link to comment
Share on other sites

3 minutes ago, lepr said:

Not stretching the Pixel Selection is the solution.

But why is that necessary when no pixel layer is selected? The marching ants pixel selection is independent of any layer, right? This is what we have been asking about, not that it occurs but why it does.

All 3 1.10.8, & all 3 V2.4.2 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

Just now, R C-R said:

But why is that necessary when no pixel layer is selected? The marching ants pixel selection is independent of any layer, right? This is what we have been asking about, not that it occurs but why it does.

 

This discussion is just going round in circles.

You are still asking why because your mind is closed to the information I've provided in responses to you and others. The bilinear resampling part of the story (briefly explained to Brain_J on Wednesday) will seem nonsensical for as long as you cannot see the Pixel Selection is a raster object with transformation matrix.

(An echo chamber of like-minded individuals isn't improving the prospect of you getting your head around the subject, unfortunately)

Link to comment
Share on other sites

6 minutes ago, lepr said:

This discussion is just going round in circles.

Yes, it is. But you still are not considering that the transformation matrix as you call it can be stretched or shrunk independently of any layer and via the Quick Mask + Move Tool + Transform Panel do that while ensuring that the selection still includes only whole pixels. So what is being resampled at that time? And once a pixel layer that is 100% opaque is selected & a copy performed, assuming that everything in the pixel layer is pixel aligned, why is any resampling being performed, & on what is it that causes any of the copied pixels to become less than 100% opaque.

Moreover, why is it that just the edges are affected & why is it that as @Old Bruce mentioned, why when the selection is shrunk does this not happen?

All 3 1.10.8, & all 3 V2.4.2 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

2 hours ago, lepr said:

Not stretching the Pixel Selection is the solution. Please read on before posting a rant.

You were told at least twice in this thread to use a vector Rectangle and only convert it to a Pixel Selection after it has been sized as required. Ensure 'Force Pixel Alignment' is enabled and draw a vector Rectangle, then stretch it as required, and then create a Pixel Selection from the Rectangle.

Of course, someone will complain that the vector Rectangle needs to be opaque and have no stroke at the moment a Pixel Selection is created from it.

It doesn't need to be if you use the attached macro to convert a vector object to an 'opaque' Pixel Selection.

The object stroke and fill are irrelevant to the macro, so you can use a Rectangle with no fill and stroke, or any fill and stroke that you prefer, and the result will be as if the object had an opaque fill and no stroke.

I'm sure your cohort will misinterpret the instructions or the entire message and say it doesn't work.

Object to Pixel Selection.afmacro 1.5 kB · 0 downloads

 

 

 

And you were told a number of times, we should not have to do this. It is now confirmed by the developers as unwanted behaviour and is on their radar to be fixed, that is all that concerns me now.

Link to comment
Share on other sites

5 minutes ago, CyberAngel said:

It is now confirmed by the developers as unwanted behaviour and is on their radar to be fixed...

Do you have a link for that?

All 3 1.10.8, & all 3 V2.4.2 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

7 minutes ago, R C-R said:

Do you have a link for that?

lepr posted a comment in this thread with a link to Serif’s comment about the issue.

On 5/23/2023 at 8:46 AM, lepr said:

Well, there has been a response today. A Serif person has agreed the software is in need of improvement to resized Pixel Selection functionality. I think we would all agree to that, particularly in the cases of rectangular and elliptical selections.

Note there has been no acknowledgement of a bug. That is unsurprising since the effects of geometric transformations of a Pixel Selection (which is a raster object that is effectively the same thing as a raster mask) are clearly in complete accordance with Affinity's non-destructive geometric transformations of other raster objects such as masks and Pixel Layers.

 

 

 

Windows 10 22H2, 32GB RAM | Affinity Designer/Photo/Publisher 2 (MSI/EXE)

Link to comment
Share on other sites

10 hours ago, CyberAngel said:

And you were told a number of times, we should not have to do this.

You misconstrue every message I post. R C-R asked how to do something. I told him how. I did not say we should need to do that thing.

I have been telling how the software works so that (some) people may understand why the feathering occurs. That does not imply that I endorse it.

I have stated that I think the software needs to be improved with regard to rectangular and elliptical pixel selections. I am in agreement with you about the need for improvement, but you seem oblivious to that.

Link to comment
Share on other sites

12 hours ago, R C-R said:

Yes, it is. But you still are not considering that the transformation matrix as you call it can be stretched or shrunk independently of any layer and via the Quick Mask + Move Tool + Transform Panel do that while ensuring that the selection still includes only whole pixels. So what is being resampled at that time? And once a pixel layer that is 100% opaque is selected & a copy performed, assuming that everything in the pixel layer is pixel aligned, why is any resampling being performed, & on what is it that causes any of the copied pixels to become less than 100% opaque.

The answers you seek have already been given. You have tunnel vision and misconceptions at the fundamental level of the subject, so nothing I write in response to you or others has been getting through to you unscrambled when it gets past your blinkers at all.

 

13 hours ago, R C-R said:

Moreover, why is it that just the edges are affected & why is it that as @Old Bruce mentioned, why when the selection is shrunk does this not happen?

That is not true for Pixel Selections in general.

Each pixel of a Pixel Selection raster object can contain a value in the normalised range of 0.0 through 1.0, just like a raster mask. (yawn - repeating myself yet again)

Old Bruce's 'shrinking a selection results in no feathering' scenario, whether you and/or he realises it or not, concerns the subset of Pixel Selections where all pixels of the Pixel Selection's raster grid contain the same value and the Pixel Selection is neither rotated nor sheared.

The non-feathering there is a logical consequence of the resampling algorithm the developers have employed for mapping the pixel values of any raster object (such as Pixel Layer, Pixel Mask or Pixel Selection) from one raster space to another. For example, the analogous effect on colour component values can be seen in the mapping of values from a Pixel Layer's pixels to the document raster grid.

Standing by for more of your drivel in response.

 

 

 

Link to comment
Share on other sites

35 minutes ago, lepr said:

Old Bruce's 'shrinking a selection results in no feathering' scenario, whether you and/or he realises it or not, concerns the subset of Pixel Selections where all pixels of the Pixel Selection's raster grid contain the same value and the Pixel Selection is neither rotated nor sheared.

Please consider this test 5.afphoto with history included. The initial 100x100 px selection was expanded to 100x150 px. According to the Transform panel, everything is pixel aligned. Yet when I use that to copy from the pixel layer & paste it to a new layer, the result is not only partially transparent, but for some reason is 150 X 100.3 px.

All 3 1.10.8, & all 3 V2.4.2 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

2 hours ago, R C-R said:

Please consider this test 5.afphoto with history included. The initial 100x100 px selection was expanded to 100x150 px. According to the Transform panel, everything is pixel aligned. Yet when I use that to copy from the pixel layer & paste it to a new layer, the result is not only partially transparent, but for some reason is 150 X 100.3 px.

The very first step in the History is 'Transform Selection' when a Pixel Selection is already existing. Hmmm... 

That means the document was re-opened by you after being earlier saved with a Pixel Selection existing and no embedded history. You re-opened the document, did your things that are recorded in history and then saved the document with history embedded and posted it in the thread.

Regardless of whether the Pixel Selection was ever stretched, there is a crucial thing evident in your document: the Pixel Layers have a non-destructive transformation. The document pixel density is 72 pixels per inch, but the Pixel Layers each have a density of 93 x 82 pixels per inch. In other words, the source object and pasted objects have transformation matrixes which define a shrinking in width and height. 

The height measured in document space of the pasted object is not an integer because its integer height in its raster space is not equivalent to an integer height in the document raster space.

The feathering of the pasted object is a result of the resampling of the Pixel Selection's pixels to a raster grid of pixels geometrically corresponding to the pixels of the copied Pixel Layer so the alpha of each pixel of the copied object can be multiplied by a selection value.

 

Link to comment
Share on other sites

50 minutes ago, lepr said:

That means the document was re-opened by you after being earlier saved with a Pixel Selection existing and no embedded history. You re-opened the document, did your things that are recorded in history and then saved the document with history embedded and posted it in the thread.

Yes, I first saved it with the pixel selection before I reopened it & enabled save history. I did that just to simplify the history down to what I thought were the essential steps, but I don't think that had anything to do with getting the fractional pixel in the copy. Do you?

But regardless, the point I was trying to make is just like when shrinking the selection, when I stretched it, all the pixels in the enlarged grid enclose the same pixel values in the layer I then used that selection to make the copy from (a 100% opaque green), & the selection is neither rotated nor sheared, as can be seen in the last step of the history in which I used Select > Reselect to make the selection visible again. It is still 100x150 px.

So if there is some sort of transformation of the selection that occurs whether or not it is shrunken or enlarged, why doesn't it have a similar effect either way?

All 3 1.10.8, & all 3 V2.4.2 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

1 minute ago, R C-R said:

Yes, I first saved it with the pixel selection before I reopened it & enabled save history. I did that just to simplify the history down to what I thought were the essential steps, but I don't think that had anything to do with getting the fractional pixel in the copy. Do you?

But regardless, the point I was trying to make is just like when shrinking the selection, when I stretched it, all the pixels in the enlarged grid enclose the same pixel values in the layer I then used that selection to make the copy from (a 100% opaque green), & the selection is neither rotated nor sheared, as can be seen in the last step of the history in which I used Select > Reselect to make the selection visible again. It is still 100x150 px.

So if there is some sort of transformation of the selection that occurs whether or not it is shrunken or enlarged, why doesn't it have a similar effect either way?

I substantially edited my comment, probably after you read it. Please reload the page and read the version that's there now. Hopefully it answers some questions.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.