Merging layers causing blurring

[mzone3d]

Im not that technical, so in laymans terms...
Merging Flat Colours in AF photo seems to be fine. (version 1.10.1)
As soon as I add an image though, then the blurring starts :)

[MEB]

On 8/19/2021 at 6:44 PM, R C-R said:

This is weird. Sometimes I see this kind of blurring on merge down, other times not, but I have not been able to work out what triggers it.

For example, in this dead simple Door.afphoto file, I can merge down the knob layer into the plate layer & there is no blurring. But merging the resulting layer or just the plate layer into the door layer causes blurring ... & the amount & position of the blurring is not the same for those two merges.

I am also sometimes seeing weird redraw issues for the thumbnails in the Layers panel if I use Merge Down followed by an undo -- sometimes the thumbnail shows the layer's contents off to one side & much smaller than it did before the merge & undo.

Hi R C-R,
This one if failing because the door layer's dpi differs from the other two (it was stretched and has 46x32dpi whereas the other two are 96 dpi). Rasterise the door layer, to set it to the same dpi as the rest of layers/document, then all will work/merge fine (no blurring).

[Stokestack]

On 8/18/2021 at 11:14 AM, R C-R said:

Whenever I do not want my carefully & precisely placed & sized pixel objects arbitrarily moved, resized, or displaying stair-stepped jagged edges.

That doesn't make sense. The defect is that the entire image is blurred. To address (the coherent portion of) your concern, only the overlaying chunk need be resampled and merged down.

Meanwhile, I encountered this yet again and had to abandon Affinity Photo. It can't be trusted with this basic function. I got Pixelmator, which handles this operation just fine; even when the merged item has been stretched.

[R C-R]

39 minutes ago, Stokestack said:

That doesn't make sense. The defect is that the entire image is blurred.

The entire image is blurred because to me it would not make sense to blur just a "chunk" of it.

[Stokestack]

The only part that needs to be "blurred" is the one being merged down; and even then only if it has been resized, or moved by fractional pixels. Once the chunk to be merged is brought into pixel alignment and DPI conformity with the underlying layer, each of its pixels can be mathematically blended with the one directly below it. Any other pixels in the composition should be untouched.

[NotMyFault]

On 9/8/2021 at 10:44 PM, Stokestack said:

The only part that needs to be "blurred" is the one being merged down; and even then only if it has been resized, or moved by fractional pixels. Once the chunk to be merged is brought into pixel alignment and DPI conformity with the underlying layer, each of its pixels can be mathematically blended with the one directly below it. Any other pixels in the composition should be untouched.

This is a mis-conception.

Merge down does exactly what it name says: it merges the upper layer into the lower. If DPI or position do not match exactly, the merge process produces blurriness by design, unavoidable. Think of an extreme example: Merging down a 100x100px layer into a 10x10px layer. 
There is no way to keep the result sharp.

So to avoid blurriness, you have 2 very simple options already explained by others:

1. rasterize the lower layer to bring it into the correct resolution. (Preferred)
2. swap both layers, to have the correct one in bottom position (more complex, same result as option 1 in best case)

Photo works perfectly fine.

Never the less, it would be great if Photo would ring an alarm bell if someone tries to merge down into a layer showing unsuitable DPI (not equal do document DPI), or uses non-integer position for the „down“ position layer.

If you are asking why photo doesn’t automatically rasterizes the „down“ layer: 

• It is absolutely possible that an expert user wants the effect, or even uses higher DPI bottom layer. . 

left: high over low DPI

right: low over high DPI

merge down DPI.afphoto

Edited September 10, 2021 by NotMyFault
Added file and screenshot

[Stokestack]

That is just wrong. What is the "correct" resolutioon?

"If DPI or position do not match exactly, the merge process produces blurriness by design, unavoidable"

Wrong. Only ONE of the images need be resampled, to match the other one. In every case where I've encountered this bug, I was merging a small area down onto a much larger (and non-resized) image. There is no reason the entire large image should be altered.

[MEB]

Hi @Stokestack
I'm sorry for the inconvenience these issues are causing you. There's a few situations where rasterising the layer is necessary. There may also be some bug(s) somewhere.
Do you mind attaching a sample file where you are experiencing those issues please? It's a lot easier if we all start with the same reference file/are on the same page. If you wish i can provide an upload link so you can send the file privately - just let me know. Thank you.

[Stokestack]

On 9/13/2021 at 5:38 AM, MEB said:

Do you mind attaching a sample file where you are experiencing those issues please? It's a lot easier if we all start with the same reference file/are on the same page.

Thanks for the follow-up. I'm happy to provide a file. In this one, select the top layer and merge down. Then do it again. The image degrades further each time.

And you'll note that these images are captured from a screen and cut & pasted into this document with no transformations. So there should be none of the much-debated resampling or DPI-related shenanigans. Not to mention that the hand-drawn portion was drawn right on top of the image, and merging it still causes degradation.

 

PhotoMergeDegrades.afphoto

[R C-R]

10 minutes ago, Stokestack said:

So there should be none of the much-debated resampling or DPI-related shenanigans.

The width of one & heights of both of your Background (Pixel) layers are not integer pixel values:

 

[Old Bruce]

Why are they at two different dpi? 164 and 165? Why are their dimensions fractional pixels if they are just screen captures?

[Wosven]

7 hours ago, Old Bruce said:

Why are they at two different dpi? 164 and 165? Why are their dimensions fractional pixels if they are just screen captures?

And the document PPI is 144...

[MEB]

@Hi @Stokestack,
Thanks for the file. As pointed out already you are merging two layers with different DPI's and also non-pixel aligned. If you rasterise the bottom layer before merging down, all should work without blurring. This is already logged to be looked at and I bumped/updated the issue to bring it up to devs attention again.
If you want to ensure it will work in all cases without having to mess/care about with decimal places, dpi's etc. remember to rasterise the bottom layer first.
Thank you all for your feedback/files/support.

[Stokestack]

Thanks, but I never scaled these images, and "pixel alignment" was ON in Photo when I composed the document. Not to mention that any resampling need only be done once, on one of the mismatched elements.

Yes, these are screen shots with no extra manipulation other than cutting, pasting, and positioning. Their DPI should be the same. Nor did I enter non-integer values for anything.

Also, why would I "rasterize" a bitmap? This is not a reasonable step to expect anyone to guess. Nor have I seen it required in any other image-manipulation application for these simple layer operations.

I appreciate your escalation of the issue.

[walt.farrell]

18 minutes ago, Stokestack said:

Their DPI should be the same.

But it is not. One is 165 DPI, and the other is 164 DPI, and neither matches the document DPI of 144.

If you pasted them into a 144 DPI document, they each came in as an (Image) layer initially. If you resized them to make them fit into the document then you changed its DPI when doing that resizing, and apparently did not get them both to exactly the same size.

(Hint: One way of seeing this is to open the .afphoto file in Publisher, and then to select a layer and use Layer > Convert to Image Resource. Do that for both the screenshot layers, and you can see the difference.)

[Stokestack]

It doesn't matter how many times anyone repeatedly observes the situation. So what?

The same sequence of steps in any other image-manipulation program that I can find does not produce this blurring. So it must be possible to do it right.

Even Photo doesn't always do it. You can paste an image over another, resize its layer, and merge down without blurring in many instances. So the resizing theory really doesn't hold up.

[Wosven]

9 minutes ago, Stokestack said:

So the resizing theory really doesn't hold up.

But it does... and perhaps the only difference is other apps doesn't allow non integer pixel values in all cases (I can't remember entering/reading anything else that integer as pixel values in other apps).

[R C-R]

7 minutes ago, Stokestack said:

It doesn't matter how many times anyone repeatedly observes the situation. So what?

The "so what" is that the DPI's of the two bottom layers do not match those of the document or of each other.

Like Walt said, that won't happen without some sort of user input.

[Stokestack]

5 minutes ago, Wosven said:

But it does... 

And yet you don't say how.

3 minutes ago, R C-R said:

Like Walt said, that won't happen without some sort of user input.

Or a bug.

[Wosven]

7 minutes ago, Stokestack said:

And yet you don't say how.

We notice the different PPI in your files, nothing more to say.

[R C-R]

Just now, Stokestack said:

And yet you don't say how.

There is no way for any of us to know that unless we know exactly how you added those two bottom pixel layers to the file & if you did anything to them afterwards.

One way to do that would be enable Save History with Document on the File menu, & then recreate the file from scratch. Post that file so we can see how it happened, or if it is a bug.

[BitBull]

I have been using Affinity Photo for some time for pixel art. There are no issues with merging layers **as long as you make sure everything is the same dpi and pixel aligned**

The problem IMO is that not everything pixels aligns even when you have all the 'snap to pixel' settings set to 'on'. Copy/paste for example often pastes at fractional pixels. Plus the interface is obtuse, there are far too many options and it should be much easier to select a single preference saying you only want to work at an integer pixel level.

But, as long as you make sure everything is pixel aligned, merging layers does not blur!

 

[Stokestack]

1 hour ago, Wosven said:

We notice the different PPI in your files, nothing more to say.

That has nothing to do with your "but it does" claim, which was in response to this:

Quote

Even Photo doesn't always do it. You can paste an image over another, resize its layer, and merge down without blurring in many instances. So the resizing theory really doesn't hold up.

So again: How?

15 minutes ago, BitBull said:

The problem IMO is that not everything pixels aligns even when you have all the 'snap to pixel' settings set to 'on'. ..

But, as long as you make sure everything is pixel aligned, merging layers does not blur!

So... we're supposed to use the option that doesn't work, to prevent the behavior that shouldn't happen.

[R C-R]

7 minutes ago, BitBull said:

Copy/paste for example often pastes at fractional pixels.

When pasting pixel images, I can sometimes have one of their x or y coordinates to be at a fractional pixel location but so far I have been unable to paste anything where the width & height was anything other than integer pixel values.

Do you maybe have a 'recipe' for pasting an image to a non-integer pixel width or height?

[R C-R]

7 minutes ago, Stokestack said:

That has nothing to do with your "but it does" claim, which was in response to this:

It is undeniably true that the DPI's of two of your layers in your example file are not identical, nor do they match the DPI of the document itself. That can easily be explained if you resized those layers; otherwise there is no other explanation than a bug nobody else seems able to reproduce.