Merging layers causing blurring

[ronald618]

None of that answers the question:

"What would be a case where such blurring when merging down would be desired?"

I'd like to know a real-world example.

I can't think of any and I first started working with PS in 1996.

 

 

[R C-R]

4 minutes ago, ronald618 said:

What would be a case where such blurring when merging down would be desired?

Whenever I do not want my carefully & precisely placed & sized pixel objects arbitrarily moved, resized, or displaying stair-stepped jagged edges. This is very important if for example I intend to resize the merged object so it blends nicely with some other part of my design.

[ronald618]

"Whenever I do not want my carefully & precisely placed & sized pixel objects arbitrarily moved, resized, or displaying stair-stepped jagged edges. This is very important if for example I intend to resize the merged object so it blends nicely with some other part of my design."

I never ever had that problem when simply merging down a layer in other programs.

I have never heard from any of the professionals I have worked with over the decades complaining about how PS handles the simple act of merging layers. 

However, I HAVE heard complaints here  about how Affinity Photo handles merged layers....going back years.

Maybe it's time to stop making excuses for a design flaw and get it fixed.

Look, I like the program. I use it. But I'm realistic about it.

[Wosven]

1 hour ago, 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. This is very important if for example I intend to resize the merged object so it blends nicely with some other part of my design.

It just means that all your image parts/selections will be blured... if you don't keep your eyes on the Transform panel.

I can understand wanting blured edges, but if all your pixels are misaligned, there's really no benefit.
As you said, if you want to blur something, you do it consciously using filters, not misaligning before merging.

All other app will give color/alpha value for whole pixel. 

You can have part of pixel when working with vector, due to/while calculation, but even those should be defined as whole pixels' color/transparency when merging or exporting to raster files to avoid blured results.

 

I suspect that  if there was an option for the app(s) to behave like other apps when doing selections and merging layers, everyone would enable this and forget about those .xxxx pixels mesures.

[R C-R]

1 hour ago, Wosven said:

It just means that all your image parts/selections will be blured... if you don't keep your eyes on the Transform panel.

If by blurred you mean the edges will be antialiased, then yes they will be blurred ... because they already are antialiased/blurred.

[Wosven]

8 minutes ago, R C-R said:

If by blurred you mean the edges will be antialiased, then yes they will be blurred ... because they already are antialiased/blurred.

No, I mean the part copied and pasted and merged. In fact, the problem discussed in this tread, not the antialiazing.

[R C-R]

8 minutes ago, Wosven said:

In fact, the problem discussed in this tread, not the antialiazing.

The problem discussed in this thread is merging pixel layers.

Can we agree that each pixel in a pixel layer can have exactly one color & opacity level? If so, if you merge two pixel layers that are not perfectly pixel aligned, how do you want the app to handle fractional pixels during the merge?

[Andrea Andrea]

6 hours ago, MEB said:

Hi @Andrea Andrea,
Can you be more specific regarding the fix you are expecting please? As long as the layers have the same dpi and are pixel aligned they should merge without causing any blurring. Can you post a file/example where the merge operation blurs the output/result for inspection please? Thank you.
 

I merged on by one. It seems to be working for me as I said.

[Wosven]

7 hours ago, R C-R said:

if you merge two pixel layers that are not perfectly pixel aligned,

That's the problem, there shouldn't be pixels non pixel aligned.

Only values for color and transparency, that vary depending of the selection or result of calculations (if vector, gradient, etc. are rasterized) and the antialisazing value.

Here an example with few "pixels" (but with bad choice of colors, too dark, but no time to do it now):
(the "halves pixels" being result of calculations before merging)

merging_pixels.afphoto

[edit] I should have done this with transparency, not mode multiply... half baked ideas with first coffee early in the morning [/edit]

[Lothyende]

On 8/17/2021 at 6:57 PM, MEB said:

Hi @Lothyende,
Welcome to Affinity Forums
Do you mind attaching the afphoto file shown in your screenshot above please? Thank you.

Hi Meb,

thanks for the reply! I’ll have a look but I’m not sure I kept the file; it was just a quick-and-dirty fix for an object in an animation. I thought this was already discussed so thoroughly that I didn’t consider that.

FWIW: it was an imported image, with the original layer duplicated and rotated; and another layer added and painted upon. The “pixel alignment” and “move by whole pixels” were both on.

I’ll try and find it or reproduce it otherwise.

 

[Lothyende]

On 8/17/2021 at 7:26 PM, Andrea Andrea said:

(…) but I'm glad you posted so I'm not gonna work with Affinity Photo until they fix that 😅.

Thanks

I’m happy it helped you, but why not just use “merge visible” instead and buy a new bicycle from the money saved by cancelling your Adobe subscription?

As far as I know only the “merge down” function behaves in this particular manner. I can’t say I understand the rationale either - or, more accurately: I do understand why a rasterised image will blur when rotated, scaled or merged with a non-aligned other layer; but it’s beyond me why “merge visible” blurs the image so much less than “merge down” on the exact same layers.

It seems obvious from all the comments that this behaviour is contrary to what people expect - (disclaimer) I’m not denying the validity of all that about pixel alignment even though I don’t get it - I would just make the least ”distorting” operation the more obvious choice, to spare users who are not into the nitty-gritty of blending and sub-pixel alignment some vexation and lost work.

In other words, I’d make “Merge Down” behave as “Merge Visible” does now, and maybe introduce a new merge mode called “Merge Aligned” that works like “Merge Down” does.

[walt.farrell]

1 hour ago, Lothyende said:

As far as I know only the “merge down” function behaves in this particular manner. I can’t say I understand the rationale either - or, more accurately: I do understand why a rasterised image will blur when rotated, scaled or merged with a non-aligned other layer; but it’s beyond me why “merge visible” blurs the image so much less than “merge down” on the exact same layers.

It may depend on the order of merging, or on how many layers are misaligned, or both. 

[R C-R]

9 hours ago, Wosven said:

That's the problem, there shouldn't be pixels non pixel aligned.

??? Are you saying that the app should restrict us to creating/positioning/resizing pixel objects such that they always align to document pixel boundaries? So for example, if we create a pixel object with a diagonal edge, the app should automatically stair-step that edge instead of antialiasing it, or if we use a brush with a non-integer pixel width it should do the same thing?

What about vector objects that we rasterize, anything we scale up or down, rotate, etc.? Should they also be treated the same way?

For that matter, what about changing the document DPI or anything else that can result in non-pixel aligned pixel objects?

[JimmyJack]

Pixel perfect and same DPI (...and, yes, the document is also 96dpi) = BLURRING

[R C-R]

17 minutes ago, JimmyJack said:

Pixel perfect and same DPI (...and, yes, the document is also 96dpi) = BLURRING

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.

[MEB]

@JimmyJack,
Do you mind attaching the file shown in the video please? Thanks.

[R C-R]

Well, just to stir the pot a bit more, in this Another Merge Down.afphoto test, it does not matter how the upper layers are stacked, the document DPI, or which of the upper layers I select & merge down, there is no blurring that I can detect. Everything is pixel-aligned & there is no antialiasing or blurring visible except in the waves of the "7 wave" layer that were there before any merging was done.

I also tried rotating layers to arbitrary angles other than 90° to produce edge antialiasing but again, merging down did not change the amount or size of the antialias blur. I even tried increasing the height of the large bottom layer beyond the document edges, unclipping to increase the document dimensions, but that did not produce any blurring either.

[Wosven]

6 hours ago, R C-R said:

??? Are you saying that the app should restrict us to creating/positioning/resizing pixel objects such that they always align to document pixel boundaries?

Yes. No more extra pixels when exporting and having our image at the wrong size and rebuked when send to the ones asking a  specified size… Or having white lines appearing around, caused by 1/x th of pixel unaligned. 

6 hours ago, R C-R said:

So for example, if we create a pixel object with a diagonal edge, the app should automatically stair-step that edge instead of antialiasing it,

If it's stair-stepped, you probably need more pixels in your image, good antialiasing can help, but not do miracles.

6 hours ago, R C-R said:

if we use a brush with a non-integer pixel width it should do the same thing?

The resulting borders or the lines drawn will have soft color...  it also depend of flow, accumulation, spacing and other parameters.

If you've got non-integer values in your brush size, you can't expect sharp borders. Those border will have lightly colored pixels, resulting perhaps of the average of background color/opacity + brush color/opacity. (What I did with my "big" pixels when merging part of a pixel with a "full" pixel.)

6 hours ago, R C-R said:

What about vector objects that we rasterize, anything we scale up or down, rotate, etc.? Should they also be treated the same way?

About those, the calculation is only made before exporting, the result will depend of the PPI of the final image (and can be checked with Pixel view mode if at same PPI). But for example, if you can only create a square/rectangle on exact pixel values (coordinates), the result should be clean.

6 hours ago, R C-R said:

For that matter, what about changing the document DPI or anything else that can result in non-pixel aligned pixel objects?

For raster image, depending of the mode used, it'll add whole pixels, and calculate the resulting color of each pixel in its own way.
It's like mixing paint: you always end up with a color, whatever proportions are used, never a half, a third, etc. of a color.

 

6 hours ago, R C-R said:

non-pixel aligned pixel objects?

Can they really exist?

Affinity apps are the only ones where you need to display 6 digits after the decimal point to check there's no unaligned pixels. How all the other app manage this? They seems to round at the nearest pixel.

To be picky, I would say it's the same with vector: there's no really straight diagonals... if we zoom enough, we should see pixel size stairs , not only in pixel view.

But it's easier to see lines, and not display them as pixels when they are only mathematical datas.

 

When merging layers, if one is unaligned, it's possible the result is blured because the app can't manage less than a whole pixel, and will then add (average) half/third... of the top pixel + the other part (to get an area of a full pixel) with the pixel below on the other layer. (Simple example where only the x value is misaligned, if we add a misaligned y, it's not the average of 2 but more colors.

 

Another play with merging "giant pixels"   :

 

merging_pixels2.afphoto

 

[R C-R]

19 minutes ago, Wosven said:

If it's stair-stepped, you probably need more pixels in your image, good antialiasing can help, but not do miracles.

Why should I increase the pixel size of my document when antialiasing does exactly what I want?

20 minutes ago, Wosven said:

If you've got non-integer values in your brush size, you can't expect sharp borders.

You don't get it. I do not want sharp borders. I want nice smooth transitions from one color to another ... just like in just about every color photo ever taken.

22 minutes ago, Wosven said:

But for example, if you can only create a square/rectangle on exact pixel values (coordinates), the result should be clean.

Why would I want to be limited to that? For almost all my pixel work I don't want artificial, "clean" looking rectilinear patches of any solid color. If that is what I'm after, I am most likely going to use vector tools for such things, but even for that, I do not want to be limited to exact document pixel values -- that's the beauty of working with resolution independent vector objects.

34 minutes ago, Wosven said:

How all the other app manage this? They seems to round at the nearest pixel.

I do not want the app to do that for me, at least not without warning me that it is going to do that & giving me a choice of how to align everything. It does not know if I want fractional pixels loped off by rounding down, anything moved to make it pixel aligned or why I chose not to pixel-align every element in my document in the first place.

[Wosven]

6 hours ago, R C-R said:

Why should I increase the pixel size of my document when antialiasing does exactly what I want?

You talked abour stair-stepped images first... The only ones I see like this today are when people send the logo from their web site, at only 72 PPI, when we need for print 300. When exporting a vector logo (we're primarily talking aboutt raster image), the raster result will depend of PPI. (Test with a circle in 1cm canvas exported at 72 or 300 PPI if you want).

6 hours ago, R C-R said:

I do not want sharp borders. I want nice smooth transitions from one color to another

Just use the right brush. Since we're talking about blured images, it's the way the colors are calculated when there's non-full pixels when mergin that cause problems. A lot of people use other apps to paint and their resulting images aren't blured when they export their work. I don't remember complain about this, so perhaps the apps behave differently in this case than when mergin layers in AP. Perhaps something to study.

7 hours ago, R C-R said:

Why would I want to be limited to that?

Because when rasterized/merged, there's no half pixel mesurement? Do you really work at pixel level on an image, to use .xxx pixel size? Again, you seems limited by this, but all other apps use full pixels as mesures, and nobody complain...

7 hours ago, R C-R said:

that's the beauty of working with resolution independent vector objects.

Yes, and that's why when merging, value (color/opacity) of resulting pixels will be calculated. But if you allow non whole pixel as mesure for a regular shape like a square, don't espect clean result (it's usually what we espect, if not, we add a blur effect).

7 hours ago, R C-R said:

I do not want the app to do that for me

Perhaps you, but people posting here and in similar threads whan it the other way. They don't want blured images when merging, they want the app to manage it in way that'll keep sharp images/mergings. Not wasting time, hours working to get a final result completely unusable.

[R C-R]

9 hours ago, Wosven said:

You talked abour stair-stepped images first...

Yes, because that is what you get if there is no antialiasing to soften/blend/blur edges. But as I said & you seem to keep ignoring, antialiasing is exactly what I want, not sharp stair-stepped edges that do not look anything like the natural blended edges in photos.

9 hours ago, Wosven said:

Just use the right brush.

What would be the point of using a brush that can paint on partial pixels to produce exactly the kind of soft color transitions I want (which is why I am using one of those brushes to begin with!) if the app is going to ignore that & arbitrarily round everything up or down to whole pixel values before calculating what color an exported pixel should be, if any partially filled pixels should be discarded, & so on?

The Affinity apps give us the freedom to work with several different kinds of objects without forcing them to be pixel aligned. This includes vectors, text, raster images, & several different kinds of container objects. This permits us to place things anywhere in the document we want, to resize or otherwise transform them as we see fit, to use expressions that do not & should not produce whole pixel values, to snap objects to various positions & sizes that are not & should not be whole pixel values, etc.

Sure, this can produce antialiasing/blurring on export but just as surely that may be exactly the effect some of us are trying to achieve. IOW, it is not always about creating "clean" exports with sharp edge transitions, particularly when we are doing things like retouching photographs.

All that aside, there does seem to be something wrong with the Merge Down function since sometimes it causes blurring when everything is perfectly pixel aligned. I have posted examples of both when it works as expected & when it does not. @JimmyJack has posted a video of it going wrong & may post the file as well.

This is what I think this topic should now be focused on, not the merits of making all exports "clean" -- that is something I think we never will all agree on because as said earlier (& not by me!) there are good reasons for both behaviors.

[Wosven]

@R C-R 

I had fun today reading the beginning of this thread and your replies that said nearly the same as I was writting in those previous posts. I had no time to read a lot, but it's funny. 

[Stokestack]

Wow, THREE YEARS now? And yet people regurgitated the same incorrect workarounds and "explanations" just a few months ago when I posted about the same problem.

The application is seriously defective, people. There's no excuse for this behavior.

[R C-R]

2 minutes ago, Stokestack said:

The application is seriously defective, people.

There is a defect with the Merge Down function: by design it should never cause blurring if the objects to be merged are pixel aligned. The problem is sometimes that works as designed & sometimes not.

[Stokestack]

Anyone else want to re-state the problem?