pixel layer DPI, channels panel fill result in excessive layer size

[NotMyFault]

Photo V2.0.3

This might be a take-over from V1

1. create new document 512x512px, use default 72 dpi
2. Add rectangular shape of 1x1px
3. rasterise layer
4. use move tool / transform panel to resize pixel layer 100x100px (reduces DPI to 1/100th - unfortunately resulting DPI is not visible for pixel layers, only image layers show this)
5. rotate pixel layer by 45 degree
6. use channels panel, to fill pixel alpha

Result: you get a layer of size more than 51.200x51.200 px, and it is very tedious to get rid of those unwanted extra pixels outside the visible canvas. For unknown reasons, if you reduce layer DPI, the layer keeps some hidden / secret information about its old number of pixels, and there is no way to get rid of them after transforming. You would need to rasterise & trim before transforming. Those fully transparent superfluous extra pixels outside the visible canvas should not be filled at all.

[Lee D]

Sorry for the delay.

Thanks for the report, I've logged this to be looked at.

[lepr]

On 12/21/2022 at 3:13 PM, NotMyFault said:

Those fully transparent superfluous extra pixels outside the visible canvas should not be filled at all.

 

The key to understanding the results:

• When an object is rasterised, the created Pixel object covers the entire canvas (or greater when any of the object lies outside the canvas), but its pixels have alpha of zero where the source object did not exist or was fully transparent.
• The bounding rectangle of a selected Pixel object is only as large as required to contain all of the pixels with alpha greater than zero, and so the real extent of a Pixel object can be greater than the user interface leads us to believe.

 

Using your example:

Step 3. rasterising the 1 px vector rectangle actually created a Pixel object as big as the canvas, 512 x 512 px, but with only one 1 pixel having alpha greater than zero.

Step 4. scaling the Pixel object by 100 so that its 1 visible pixel covered 100 x 100 document pixels actually scaled the entire Pixel object to cover 51,200 x 51,200 document pixels.

Step 6. filling the alpha of the Pixel object, made all of its pixels have alpha greater than zero, and so its bounding rectangle became the full extent of the Pixel object.

[lepr]

On 12/21/2022 at 3:13 PM, NotMyFault said:

resulting DPI is not visible for pixel layers, only image layers show this

The context toolbar for Move Tool displays the PPI of Pixel objects (and Image objects and placed documents).

[NotMyFault]

12 minutes ago, ,,, said:

Step 4. scaling the Pixel object by 100 so that its 1 visible pixel covered 100 x 100 document pixels actually scaled the entire Pixel object to cover 51,200 x 51,200 document pixels.

But here lies the issue / bug. If you have only 1px filled in a pixel layer, and activate the move tool, affinity shows a bounding box of 1px, and size of 1px. Affinity reduces the observable part of every pixel layer to non-transparent pixels, in every aspect:

• transform panel
• copy / paste, or copy / new from clipboard

So the canvas size becomes de-touched, and only the bounding box stays “touchable”.
 

If you now move the 1px to a different position inside the canvas, it becomes totally unclear where the invisible “ghost” canvas is positioned. In Some situations Affinity automatically crops them off, in others like my example it wont.

As you want to keep your workflow non-destructive, you normally never rasterize&trim, especially when having stretched a layer.

 

[lepr]

1 minute ago, NotMyFault said:

But here lies the issue / bug. If you have only 1px filled in a pixel layer, and activate the move tool, affinity shows a bounding box of 1px, and size of 1px. Affinity reduces the observable part of every pixel layer to non-transparent pixels, in every aspect:

• transform panel
• copy / paste, or copy / new from clipboard

So the canvas size becomes de-touched, and only the bounding box stays “touchable”.
 

If you now move the 1px to a different position inside the canvas, it becomes totally unclear where the invisible “ghost” canvas is positioned. In Some situations Affinity automatically crops them off, in others like my example it wont.

As you want to keep your workflow non-destructive, you normally never rasterize&trim, especially when having stretched a layer.

 

Yes, I understood that the way the software works is creating a problem for you.

I was only explaining what was happening under the covers, and was not trying to say that the knowledge would solve the problem.

 

[NotMyFault]

Affinity extends a pixel layer even when you don’t strech it to different DPI.

1. new file
2. add pixel layer
3. paint 1 px in top left corner
4. use move tool and move pixel layer into bottom right corner
5. make a fresh dot in top left corner

now how large is your pixel layer? You have no easy way to find out. The only way to my knowledge is to fill alpha. Big surprise, layer is far larger than canvas.

if you have a file with multiple of these “paint a small area, then reposition, erase a bit, pain a bit” pixel layers the invisible ghost size can become huge and cause issues with masks and certain operations.

Affinity must handle these ghost areas either fully automatically, or make them recognizable and manually editable (crop without rasterizing).

i have seen quite some reports where these areas caused real issues.

[NotMyFault]

On 2/1/2023 at 10:19 PM, NotMyFault said:

Affinity extends a pixel layer even when you don’t strech it to different DPI.

1. new file
2. add pixel layer
3. paint 1 px in top left corner
4. use move tool and move pixel layer into bottom right corner
5. make a fresh dot in top left corner

now how large is your pixel layer? You have no easy way to find out. The only way to my knowledge is to fill alpha. Big surprise, layer is far larger than canvas.

if you have a file with multiple of these “paint a small area, then reposition, erase a bit, pain a bit” pixel layers the invisible ghost size can become huge and cause issues with masks and certain operations.

Affinity must handle these ghost areas either fully automatically, or make them recognizable and manually editable (crop without rasterizing).

i have seen quite some reports where these areas caused real issues.

1, 2

3

4

5 

6 zoom 100%, create greyscale layer from channels alpha

7 you get a greyscale layer which is of unnecessary excessive size, despite transform panel showed much smaller size of source layer

[lepr]

1 hour ago, NotMyFault said:

1, 2 [...] 7

 

That happens because of the reason given in my first reply. I don't think it's a bug, although there clearly is room for improvement in how the software handles the situations of your examples.

[NotMyFault]

49 minutes ago, ,,, said:

That happens because of the reason given in my first reply.

I did not say anything different (yet), even if I believe your statement was not covering all relevant causes.

My replies are not intended to you post specifically, so no need to repeat these statements.

49 minutes ago, ,,, said:

I don't think it's a bug,

I disagree. You made your point. It is documented.

I rate this as a bug as several users have run into issues when layers have grown in size beyond canvas, for no obvious reasons. My examples are to show how how this can happen with regular innocents edits. It is intended for other users who observe this, and Serif staff. 

Prime example of a document becoming uneditable:

 

 

 

[lepr]

6 hours ago, NotMyFault said:

My replies are not intended to you post specifically, so no need to repeat these statements.

7 hours ago, ,,, said:

I don't think it's a bug,

I disagree. You made your point. It is documented.

 

Oops, I thought a forum is a place for discussion.