Merging layers causing blurring

[Stokestack]

3 hours ago, R C-R said:

It is undeniably true that the DPI's of two of your layers in your example file are not identical

I don't know why you're talking about that, because it's irrelevant to what you're replying to.

Meanwhile, here's a step-by-step illustration of how this problem afflicts users. This example is thrown together for clarity; it shows me putting together a silly file-browser dialog. A more realistic example would be fixing someone's hairdo in a portrait by copying, pasting, and transforming patches of hair, merging each patch down to build up a larger one that could subsequently be copied and pasted and distorted again to expand the patch until complete. But I don't have time to scrounge up an ideal image at the moment, and this one clearly shows that the underlying image is not only degraded, but it's degraded with every merge even though it hasn't been manipulated in any way after its initial placement.

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

Do you mind attaching a sample file where you are experiencing those issues please?

Done. To demonstrate the problem, open the file (the "books" layer should be selected) and merge down. Then select the "patch" layer and merge down again. The "dialog" layer gets blurred, twice.

getBlurred.afphoto

[R C-R]

30 minutes ago, Stokestack said:

Meanwhile, here's a step-by-step illustration of how this problem afflicts users.

That video clearly shows you resizing the Pixel layers to non-integer sizes & changing their DPI's. This is something you claimed here that you did not do in your earlier example. Several people have explained to you why this causes blurring when you merge layers.

If you do not believe this is relevant, so be it. 

[Stokestack]

It shows nothing of the sort. I MANUALLY resized the layers with "pixel alignment" turned on. Furthermore, there's no reason for the underlying layer to be blurred, and certainly not TWICE.

And finally, there have been several other demonstrations of this problem earlier in the thread by other people, where none of your alleged explanations holds. And they haven't been explanations anyway; you delight in simply re-stating the problem. If you had an explanation, surely you'd have stated it by now.

Keep bleating the same debunked excuses all you want, but this is defective behavior.

BYE BYE

[telemax]

After rasterization, fractional is removed, and there is no blurring.

Full screen is preferred

[Wosven]

How to  merge without blurring: integer pixel sized, andrasterizing if different PPI

 

Result:

[Wosven]

But as @telemax say, you can simply select and rasterize the 3 layers (at once!), it'll give only integer values, correcting the layers smartly, before merging them.

[Fixx]

It should not be necessary to think about pixel alignment or resolution differences (as long as there is resolution enough).

The document should look the same before and after merging. Layered document creates a merged look on screen on the fly anyway and it should be true. If the look changes upon merging it is up to devs to correct behaviour, it should not be up to user to adjust layers.

[Wosven]

12 minutes ago, Fixx said:

it is up to devs to correct behaviour, it should not be up to user to adjust layers.

And it seems to be missing steps in the merge feature, since when grouping and rasterizing, there's no blur result. Each layer is probably rasterized before merging, steps that should be also applied when mergin out of a group.

[Wosven]

And really, when we want to blur something, we don't use not integer pixel values, just a (live) blur filter... so this should be corrected.

[NotMyFault]

2 hours ago, Fixx said:

It should not be necessary to think about pixel alignment or resolution differences (as long as there is resolution enough).

The document should look the same before and after merging. Layered document creates a merged look on screen on the fly anyway and it should be true. If the look changes upon merging it is up to devs to correct behaviour, it should not be up to user to adjust layers.

This is again a mis-conception.

Merge down is a destructive operation which includes resampling. Do you really expect Photo to show the same fine details after resampling to a much smaller resolution? 

In the merge-down situation it is not possible for Affinity to make an automatic decision what the user wants:

1. Preserve the resolution and position of the lower layer (the destination for the merge result)
2. Preserve the resolution of the upper layer 
3. Replace the lower layer by a layer using the document resolution 

no 1 is the current default, and no 2 or 3 require (very simple) manual steps like rasterize or add new pixel layer.

Going forward Affinity may provide

• a global user-selectable option how merge down should work.
• a safety net showing a warning ⚠️ when merging down into a layer with DPI not matching the document DPI, or having fractional position. User should be able to deactivate warning 

I would rate this as feature request, not a bug in an technical sense. 

[Wosven]

37 minutes ago, NotMyFault said:

it is not possible for Affinity to make an automatic decision what the user wants: […]

???

The resolution is either define by the new document settings or the backgroung layer (=original opened image). That's not an app choice using PPI from a random layer in the stack, it's the usual behaviour.

When mergin down, you usually want the upper layer to get the properties of the lower one since it'll be part of it. But it's a rasterisation of 2 objects, they won't keep their original and individual properties as PPI or metadata, so the logical step is to rasterize at the document resolution, removing/transforming to partly tranparent — I didn't check what rasterisation result method use— pixels without integer values.

[NotMyFault]

1 minute ago, Wosven said:

??? The resolution is either define by the new document settings or the backgroung layer (=original opened image). That's not an app choice, it's the usual behaviour.

Even more uncertainty for Photo. You may start opening an image, do some edits, place other images, delete the background. 
Who says the user will stay with that resolution? He can resize/resample any time.

Another user will come and complain about the wrong decisions.

I agree automatically rasterizing the lower layer (before merge down) will make many users happy and seems to what fits to their expectations.  But it will remove a great tool from expert users (resampling to a layer with defined DPI, not the whole document). 

Once again i plea for giving the users the choice:

• merge down with pre-rasterization of lower layer
• Merge down (as implemented today) without pre-rasterization

[Wosven]

3 minutes ago, NotMyFault said:

Even more uncertainty for Photo. You may start opening an image, do some edits, place other images, delete the background. 
Who says the user will stay with that resolution? He can resize/resample any time.

Again, the document 's properties should override any other data when rasterising a layer.

How would we produce correct files if those settings were randomly modified to use those of another layer?

If I'm working on a web banner with specs 600×250 & 72 PPI RVB and in the end get a 300 PPI CMYK image, I won't be happy (if it modify resolution, why not color mode or other original properties?)

[R C-R]

12 hours ago, Stokestack said:

It shows nothing of the sort. I MANUALLY resized the layers with "pixel alignment" turned on.

Your video very clearly shows the DPI changing when you resize the layers; for example at the 11 second mark,  where you resize the books layer from 72 DPI to 105 DPI; or at the ~15 second mark where you distort its proportions, resulting in 146 x 132 DPI. Just look at the context toolbar, where this is clearly shown:

It also shows layers being resized to non-integer pixel values -- just look at the transform panel to confirm this. I am not sure why this happens with Force Pixel Alignment & Move by Whole Pixels enabled. Perhaps it is a bug?

Regardless, as has been mentioned many times now, to prevent blurring when using the Merge Down feature, you need to rasterize any layers that are not currently set to use the same DPI before merging them. This is because the merged layer can only have one DPI, & the only way to do that is to resample at least one of them. Rasterizing a layer (of any kind) automatically sets it to the document DPI, eliminating any further need to resample it.

[R C-R]

5 hours ago, Wosven said:

Again, the document 's properties should override any other data when rasterising a layer.

Isn't that what happens now?

[NotMyFault]

6 hours ago, Wosven said:

Again, the document 's properties should override any other data when rasterising a layer.

How would we produce correct files if those settings were randomly modified to use those of another layer?

If I'm working on a web banner with specs 600×250 & 72 PPI RVB and in the end get a 300 PPI CMYK image, I won't be happy (if it modify resolution, why not color mode or other original properties?)

Well, you personally started this by:

6 hours ago, Wosven said:

???

The resolution is either define by the new document settings or the backgroung layer (=original opened image). That's not an app choice using PPI from a random layer in the stack, it's the usual behaviour.

When mergin down, you usually want the upper layer to get the properties of the lower one since it'll be part of it. But it's a rasterisation of 2 objects, they won't keep their original and individual properties as PPI or metadata, so the logical step is to rasterize at the document resolution, removing/transforming to partly tranparent — I didn't check what rasterisation result method use— pixels without integer values.

It seem you do not want Affinity to use the original resolution when initially created (as said in your older post), but the current resolution (as said in your later post).

Never the less, i do not understand why you are continuing to discuss with so much rigor, including leaving negative feedback to my posts, despite I already agreed two times that i share there is room for optimization:

7 hours ago, NotMyFault said:

Going forward Affinity may provide

• a global user-selectable option how merge down should work.
• a safety net showing a warning ⚠️ when merging down into a layer with DPI not matching the document DPI, or having fractional position. User should be able to deactivate warning 

 

6 hours ago, NotMyFault said:

I agree automatically rasterizing the lower layer (before merge down) will make many users happy and seems to what fits to their expectations.  But it will remove a great tool from expert users (resampling to a layer with defined DPI, not the whole document). 

Once again i plea for giving the users the choice:

• merge down with pre-rasterization of lower layer
• Merge down (as implemented today) without pre-rasterization

 

 

 

[R C-R]

7 hours ago, Wosven said:

When mergin down, you usually want the upper layer to get the properties of the lower one since it'll be part of it.

But what if the lower layer has a different resolution from the document resolution or the upper one; or if its dpi/ppi values are not even the same for its width & height?

I can't speak for anybody else but this frequently occurs in many of my workflows, typically as the result of adjusting the size & position of various layers, snapping objects to different places on the canvas, converting image layers carefully placed at specific sizes & positions to pixel layers so I can edit their contents, etc.

Consequently, I often do not want the merge to use the properties of the lower one. The only logical choice for me is for the merged layer to use the properties of the document, like it does now.

YMMV.

[Wosven]

1 hour ago, R C-R said:

Isn't that what happens now?

Yes, and it's normal behaviour.

46 minutes ago, NotMyFault said:

Well, you personally started this by

It seems I didn't explain well enough, so, you've got usually to options:

• Creating a new document with specified PPI, color mode, size

• Opening an image with specific PPI, color mode, size

In either way, if you paste or place another image in those documents, the rasterised layer of this image should have as new properties the ones of the original document (for PPI and color mode). It'll loose its specificity, since it's not anymore a 'smart object/embedded document'.

I never said differently.

An AP document is not an APub document, that'll keep different placed image at different PPI (you can use it like that, and export to PDF to keep those properties, but I don't think it's the apropriate use or app, and the subject of this thread is about merging in AP), so, when you need to merge layers, the rasterisation should apply the properties of the original document (case 1 or 2 in the list above), not the properties of the layer below, unless it's the original/backgroung one, that got obviously the document 's properties.

That means that if you want to merge down (img3) and retain the properties of a placed/embedded image (img2), you shouldn't do it in another document (img1), but open independently this image (img2), paste the part you want to merge (img3), merge down, and the properties will remains the ones of the opened image (img2).

[Wosven]

I understand now what you understood

14 minutes ago, R C-R said:

8 hours ago, Wosven said:

When mergin down, you usually want the upper layer to get the properties of the lower one since it'll be part of it.

But what if the lower layer has a different resolution from the document resolution or the upper one; or if its dpi/ppi values are not even the same for its width & height?

For me, the bottom layer or blank canvas is the one with the desired resolution and size. Meaning I can have ten layers to merge, I expect the final result to have the resolution and size of the document (or I modify them).

Foe example, with the library file, when layers are rasterized at the document PPI, I find it logical. 

I'm not sure/remember PS or Gimp giving effective PPI, they just convert when needed.

It's important to have this info in AP to avoid errors or visible montages...

[kaffeeundsalz]

2 hours ago, R C-R said:

It also shows layers being resized to non-integer pixel values -- just look at the transform panel to confirm this. I am not sure why this happens with Force Pixel Alignment & Move by Whole Pixels enabled. Perhaps it is a bug?

From what I can see in the video, it's because the scaling happens proportionally. In this case, Affinity Photo can only align to whole pixels in one dimension if the original aspect ratio can no longer be written as discrete integer pixel values after resizing.

[R C-R]

28 minutes ago, Wosven said:

For me, the bottom layer or blank canvas is the one with the desired resolution and size. 

If I understand what you mean correctly, "blank canvas" is the same as what is normally referred to as the document so we are both talking about the document resolution, right?

But the bottom layer is a completely different thing. It could be any kind of layer, an image or pixel layer, a quick shape like cog or rectangle, whatever. So it could be of any size or resolution, located anywhere on the canvas, page, or artboard  container, or even partially or completely off of it.

So I do not think it is justified to say users usually want the upper, or for that matter for any other layer being merged to be converted to the resolution, size, or pixel position of the bottom one. There are just too many different workflows with far too many possibilities for that.

[R C-R]

9 minutes ago, kaffeeundsalz said:

From what I can see in the video, it's because the scaling happens proportionally. In this case, Affinity Photo can only align to whole pixels in one dimension if the original aspect ratio can no longer be written as discrete integer pixel values after resizing.

I think you are right about that. At least in my own experiments, to preserve the original aspect ratio, the width is forced to an integer value, so the height must be forced to a non-integer one.

[ronald618]

Why is this no problem for the world's standard in photo editing: Photoshop? The software that is used all over the world by professional studios? Used by professionals for decades?

You merge down and there is no blurring. Period.

Going back and forth about this issue for years with nothing resolved is unfortunate.

In the meantime, plenty of unsuspecting users will have their work ruined without realizing what's happening until closer inspection.

Why Serif is fine with that is beyond me.

[kaffeeundsalz]

10 hours ago, R C-R said:

At least in my own experiments, to preserve the original aspect ratio, the width is forced to an integer value, so the height must be forced to a non-integer one.

It depends on the control handles you use. If you drag from a corner, width takes precedence. If you drag from an edge, the dimension that gets scaled by whole pixels is always the one you‘re actively manipulating.

[Wosven]

16 hours ago, R C-R said:

If I understand what you mean correctly, "blank canvas" is the same as what is normally referred to as the document so we are both talking about the document resolution, rightt?

Blank canvas as when you create a new document and there nothing inside (=/= opening an image). In fact, it's similar to the document's properties when opening a file, but those properties come from the file opened. By default, its size and resolution are the ones of the document.  You can delete/hide the background layer if there's one, it won't modify the document's properties, but the empty canva will have those.

16 hours ago, R C-R said:

But the bottom layer is a completely different thing. It could be any kind of layer, an image or pixel layer, a quick shape like cog or rectangle, whatever.

Instead of "bottom layer", it wiuld be better to use "canvas". Since even the Background layer, the one from an opened image, can be unlocked and resized. From memory, by dedault PS added a white pixel layer at the bottom if "transparent background" wasn't checked. And other apps add also a blank or white pixel layer to work on by default.

Any object, top or bottom position, if merged or rasterised, will be at the document's PPI, and usually will be cut to the document's area.