Merge Down improvement

[NotMyFault]

There are several heated discussions about merge down leading to unexpected blurriness.

https://forum.affinity.serif.com/index.php?/topic/53609-merging-layers-causing-blurring/page/9/&tab=comments#comment-836764

One main cause is that the lower layer could have DPI deviating from document DPI, rotation, or fractional position.

The best course of action would be to include an automated rasterization of the lower layer before the merge down is executed, to avoid unexpected blurriness.

For expert users, a new „merge down un-rasterized“ function could be offered, offering the current behavior.

Reasoning:

• The automated rasterization step is what most users expect and would avoid lots of user frustration 
• It would be more in line with how other apps deal with the situation 
• The current behavior favors an almost irrelevant edge case (resampling inside a document using a layer with deviating DPI etc. from main document)

 

[R C-R]

8 hours ago, NotMyFault said:

One main cause is that the lower layer could have DPI deviating from document DPI, rotation, or fractional position.

The best cause of action would be to include an automated rasterization of the lower layer before the merge down is executed, to avoid unexpected blurriness.

That might work for DPI differences but how could it avoid at least some blurring when the layers are not all rotated to the same angle or do not all have the same shear value? If any layer is at a fractional pixel position or one or both of its dimensions are not integer pixel values, what should rasterizing do about the fractional pixel parts, discard them or what?

Maybe I am looking at this all wrong but it seems to me that there are several different potential causes for blurring when merging pixel layers, & at least for a few of them rasterizing before merging would just change what was blurred, not eliminate it.

EDIT: just to make sure we are talking about the same thing, by "blurring" do you mean antialiasing or something else?

[NotMyFault]

1 hour ago, R C-R said:

That might work for DPI differences but how could it avoid at least some blurring when the layers are not all rotated to the same angle or do not all have the same shear value? If any layer is at a fractional pixel position or one or both of its dimensions are not integer pixel values, what should rasterizing do about the fractional pixel parts, discard them or what?

Maybe I am looking at this all wrong but it seems to me that there are several different potential causes for blurring when merging pixel layers, & at least for a few of them rasterizing before merging would just change what was blurred, not eliminate it.

EDIT: just to make sure we are talking about the same thing, by "blurring" do you mean antialiasing or something else?

Rasterizing can avoid most of the damage, but not all. 

Avoidable damage:

• All effects (blurriness) caused by non-matching DPI of lower level
• rotation of lower level
• misalignment with respect to merge down from upper level (but not to lower level itself)

Unavailable damage:

• Blurriness caused by misaligned of lower level itself.

Anti-aliasing normally does only occur for edge pixels. This can be ignored for merge down in most cases.

I don’t say that my request is a magic bullet against all possible sources for blurriness.

I only say it avoids certain most frequent causes (DPI mismatch from pasting / resizing of lower layer).

[R C-R]

3 minutes ago, NotMyFault said:

Avoidable damage:

• All effects (blurriness) caused by non-matching DPI of lower level
• rotation of lower level
• misalignment with respect to merge down from upper level (but not to lower level itself)

If the DPI of the lower level has different values in the x & y directions because it has been stretched or shrunk in either or both directions from its initial dimensions, then even if every part of that layer was perfectly pixel aligned beforehand, there will be blurring everywhere there is an edge color transition due to antialiasing.

Likewise, if I rotate any pixel layer to an arbitrary angle that is not a multiple of 90°, I immediately get blurred edges everywhere there is a color transition due to antialiasing, even if every part of that layer was perfectly pixel aligned & there was zero blurring or antialiasing before the rotation. The same thing happens if I shear the layer.

Please note that it is not at all unusual in a great many workflows to make changes like this, not only to pixel layers, but also to text, shape, & vector layers that eventually may be rasterized during merge operations. In fact, the edge blurring due to antialiasing often is exactly the effect desired to avoid the stair-stepped artifacts sometimes referred to as the jaggies.

So I can't agree that this is something that can or should usually be ignored, or that it is somehow a form of damage.

[NotMyFault]

3 minutes ago, R C-R said:

If the DPI of the lower level has different values in the x & y directions because it has been stretched or shrunk in either or both directions from its initial dimensions, then even if every part of that layer was perfectly pixel aligned beforehand, there will be blurring everywhere there is an edge color transition due to antialiasing.

Likewise, if I rotate any pixel layer to an arbitrary angle that is not a multiple of 90°, I immediately get blurred edges everywhere there is a color transition due to antialiasing, even if every part of that layer was perfectly pixel aligned & there was zero blurring or antialiasing before the rotation. The same thing happens if I shear the layer.

Please note that it is not at all unusual in a great many workflows to make changes like this, not only to pixel layers, but also to text, shape, & vector layers that eventually may be rasterized during merge operations. In fact, the edge blurring due to antialiasing often is exactly the effect desired to avoid the stair-stepped artifacts sometimes referred to as the jaggies.

So I can't agree that this is something that can or should usually be ignored, or that it is somehow a form of damage.

this does not in any way contradicts what i said.

[R C-R]

1 minute ago, NotMyFault said:

this does not in any way contradicts what i said.

IMO, the contradiction is in the premise that this is some form of damage rather than the normal, expected, & often desired consequence of combining pixel based elements that are not all perfectly pixel aligned to begin with.

YMMV.

[NotMyFault]

 

2 hours ago, R C-R said:

IMO, the contradiction is in the premise that this is some form of damage rather than the normal, expected, & often desired consequence of combining pixel based elements that are not all perfectly pixel aligned to begin with.

YMMV.

Did you read the thread linked in my first post? It seems many users have a different opinion.

Personally, am absolutely fine with the current "merge down". But it totally surprises many users, especially those migrating from competing apps.

And please keep the different causes for blurriness apart:

• Unavoidable blurriness by rasterizing the lower layer
• Avoidable blurriness by merging the upper layer into a non-rasterized lower layer.

 

[R C-R]

1 hour ago, NotMyFault said:

And please keep the different causes for blurriness apart:

• Unavoidable blurriness by rasterizing the lower layer
• Avoidable blurriness by merging the upper layer into a non-rasterized lower layer.

It would seem that more than a few users do not understand the difference between avoidable & unavoidable blurriness.

Maybe more to the point, if the upper layer is not pixel-aligned with the lower one, and/or they do not have the same dimensions, then would not one or both need to be realigned & possibly at least one of them be resized before merging to avoid blurring? These are things I want control of. I do not want the app to arbitrarily decide if or how that should be done.

[NotMyFault]

10 minutes ago, R C-R said:

It would seem that more than a few users do not understand the difference between avoidable & unavoidable blurriness.

Maybe more to the point, if the upper layer is not pixel-aligned with the lower one, and/or they do not have the same dimensions, then would not one or both need to be realigned & possibly at least one of them be resized before merging to avoid blurring? These are things I want control of. I do not want the app to arbitrarily decide if or how that should be done.

I never said the original "merge down" should be removed, just the opposite:

 

13 hours ago, NotMyFault said:

For expert users, a new „merge down un-rasterized“ function could be offered, offering the current behavior.

To make this more clear:

- the current "merge down" should be renamed "merge down un-rasterized"

- a new "merge down rasterized" should be added.

So nothing will be taken from you.

Edited September 20, 2021 by NotMyFault

[R C-R]

5 minutes ago, NotMyFault said:

To make this more clear:

- the current "merge down" should be renamed "merge down un-rasterized"

- a new "merge down rasterized" should be added.

But unless I have misunderstood what you have said previously, we have agreed that this new 'merge down rasterized' still won't eliminate many of the causes of blurring; that in fact it is intended primarily to address DPI mismatches.

So I think that even if it was implemented it still would not stop the complaints.

[NotMyFault]

2 minutes ago, R C-R said:

But unless I have misunderstood what you have said previously, we have agreed that this new 'merge down rasterized' still won't eliminate many of the causes of blurring; that in fact it is intended primarily to address DPI mismatches.

So I think that even if it was implemented it still would not stop the complaints.

It would stop all those complaints caused by not having the lower layer rasterized. This includes DPI mismatch, and more, as explained in the 3rd sentence of my original post.

 

 

14 hours ago, NotMyFault said:

One main cause is that the lower layer could have DPI deviating from document DPI, rotation, or fractional position.

 

I read new complaints from at least 6 different users since August 2021 in the thread linked in my original post.

Most of them would be covered by my request. As you already expressed your opinion repeatedly that "it is a feature not a bug" I'm not surprised at all to get your resistance here again.

I agree it is not a bug technically, but the current function is a trap of unexpected behavior for new users which can be simply avoided by a minor UI adjustment.

 

[R C-R]

17 minutes ago, NotMyFault said:

I agree it is not a bug technically, but the current function is a trap of unexpected behavior for new users which can be simply avoided by a minor UI adjustment.

At best, it will only help new users who have figured out what "merge down rasterized" means & how it differs from "merge down un-rasterized" (or however these two options get named).

Considering how many new users do not seem to have a good understanding of what rasterized or pixel alignment means to begin with; or that you can't really split pixels into smaller, differently colored parts; I seriously doubt adding this option will make much difference. 

[fde101]

On 9/20/2021 at 6:50 PM, R C-R said:

you can't really split pixels into smaller, differently colored parts

You can if you increase the DPI further by over-sampling, which would be another way to approach this problem.  If you have difficult cases like this you could oversample the DPI to minimize the artifacts from the misalignment, perform the merge, then reduce the DPI again.

There are enough different ways to do this, and the possibility of needing to use different approaches for different combinations of layers in the same set of layers being merged, that if you truly want to optimize this process you will need more than just two menu commands to do it.

[Wosven]

I don't know how other work, but when I'm rasterizing layers, this is because I'm already at the desired PPI. I wouldn't rasterize before augmenting... but the other way if there's vector objects to rasterize (or simply wait and export only the final work).

So we should assume the document's PPI isn't the problem and modifying it isn't in the solution.

You'll notice that by default, APub is set to whole pixels and move by whole pixels, when switching to AP persona. Doesn't it mean that at some point this problem of bluriness is aknoledge and they try to prevent it with those default settings?

We're talking about a specific problem: mergin down a layer causing unexpected bluriness. Since there's already other means like filters to achieve it, and since this result is completely different than the expected one (it doesn't appear before the merging down), it shouldn't appear.

Imagine if merging down was inverting the colours... It would be unexpected (and more flagrant), everyone would consider this as a bug.

[Wosven]

Oh, and I would like to see examples of situations when this unexpected blur is the desired result, even if we can't see it before mergin some layers.

[R C-R]

3 hours ago, Wosven said:

We're talking about a specific problem: mergin down a layer causing unexpected bluriness

As I understand it, we are talking about blurriness occurring for a specific situation, that being when the layers to be merged are not all set to use whole pixel positional and/or dimensional values, particularly when they are not all using the document's DPI/PPI resolution. Therefore, I cannot agree that the document PPI is not part of the problem.

But frankly, I find it difficult to understand why anybody would be surprised that this causes blurriness in the merged layer. I can't speak for anybody else but for me this is exactly what I expect to happen; in fact, it is usually what I want to happen to soften color transitions that otherwise would look terrible. 

[Wosven]

21 minutes ago, R C-R said:

But frankly, I find it difficult to understand why anybody would be surprised that this causes blurriness in the merged layer.

Perhaps because after working since the 90' with photo apps of different kind, it's the first time some users get this kind of problem?

[NotMyFault]

I never used Photoshop since 1.0.

Never the less, I learned from other users that Affinity Photo has almost identical functionality, and mostly by functions called identical or similar to PS. In those cases where Affinity Photo has a deviating implementation, it totally confuses user switching from PS or other vendor apps who more stringently mimic PS.

Besides “merge down”, this happens where Photo falls behind PS, e.g. gradients, displace filter/bump maps, using masks on stacks, unwanted and non-disengageable dithering of gradients, …

It seems to be no problem at all for Affinity as volunteers like you answer the same questions over and over again to those who have fallen into these traps.

[R C-R]

Just now, Wosven said:

Perhaps because after since the 90' and working with photo apps of different kind, it's the first time some users get this kind of problem?

Maybe the real problem is expecting the same results when merging layers with dissimilar pixel values in Affinity vs. in whatever other apps they have used?

Or more generally maybe it is expecting any Affinity app to be or aspire to be a clone of any other app they have used?

[Wosven]

No @R C-R

It looks really like a bug when there's only one app messing the expected result, not the other way around.

And it's not like if doing montages/collages, mosaiques of images isn't common.

But my earlier question stay open and without real examples.

[R C-R]

5 minutes ago, Wosven said:

It looks really like a bug when there's only one app messing the expected result, not the other way around.

Over the several decades I have been using various graphic apps, some I have used do not even allow raster layers to be located at non-integer positions or have non-integer pixel dimensions. That's one way to avoid what some would consider to be unexpected results but not something I want to be limited to.

 For that matter a few do not even support multiple layers, and/or rotating images to anything other than 90° increments, and/or shearing layers, etc. In fact, a few do not support text as text (just bitmaps) or hybrid documents combining vector, raster, & text objects.

Besides, many things look like bugs if you do not understand why they work as they do, but that by itself does not mean whatever it is must be a bug. 

[Wosven]

2 hours ago, R C-R said:

Besides, many things look like bugs if you do not understand why they work as they do, but that by itself does not mean whatever it is must be a bug. 

Again, some example files of use of this mergin feature, instead of using a filter would be welcome. I don't see anyone really using this merge-and-blur as a feature when other means like filters, that can also be use with non integer pixels, more in the WYSIWYG way of today seems a real work flow.

[R C-R]

54 minutes ago, Wosven said:

Again, some example files of use of this mergin feature, instead of using a filter would be welcome. I don't see anyone really using this merge-and-blur as a feature when other means like filters, that can also be use with non integer pixels, more in the WYSIWYG way of today seems a real work flow.

You have this backwards. The issue here is how to avoid blurring when merging layers with different pixel resolutions. As has already been mentioned more than once, there is no magic bullet solution or single addition to the existing merging options that will always do this.

[Wosven]

9 hours ago, R C-R said:

You have this backwards.

No, you have it backward, wanting to keep a "feature" that isn't logical and end with a different result that the one expected and displayed...  Results that can be achieve more logically with other means.

That's why I ask for examples of the usefulness of what has all characteristics of a bug.

[NotMyFault]

1 hour ago, Wosven said:

No, you have it backward, wanting to keep a "feature" that isn't logical and end with a different result that the one expected and displayed...  Results that can be achieve more logically with other means.

That's why I ask for examples of the usefulness of what has all characteristics of a bug.

A recent use case was a user creating retro 80 style pixel art / video games.

He used circle etc and needed them pixelated.

If you want to combine multiple DPI versions inside one document, you get a much simpler workflow (vs. using multiple documents with different DPI)

One reason for combining low and high DPI layers is using text / fonts, and avoiding in this case smoothening effects when stretching layers.