"Merging Down" Pixel Layers leads to undesired Anti-Aliasing for Illustration work

[josbin]

This is basically a repost to carry it over to the Affinity V2 Forum Section:

As discussed in several Post is the "Merging Down" function causing Anti-Aliasing in many cases. For Illustration this is an undesirable result, as it blurs your edges. Especially in Brush and Line Work this is making the "Merge Down" (and "Merge Selected") function virtually unsuable. 

I am not sure of all the things that cause layers to merge blurred but it is anyways too big a risk for an intuitive illstration workflow to use the "merge down" function with a hotkey (which is a often used and important function). For now the work around is:

1. Select the layer below the layer you want to merge down.

2. "Rasterise & Trim" it.

3. Select the layer you want to merge down and select "merge down" function.

 

As I understand this is not a bug but a intended behaviour. For Photo Editing this is understandable. But Illustartion work suffers, because we need this pixel precision to keep the sharp look of the image. Especially on lower resolution images.

Here are the mentioned Threads:

Shout out to @NotMyFault He illustrates the problem quite extensively and easy to understand!

 

 

Some Screenshots to show the problem:

[josbin]

Suggested Fix would be the same as @NotMyFault suggested in this Post:

 

[loukash]

46 minutes ago, josbin said:

I am not sure of all the things that cause layers to merge blurred

Essentially, most of the time it's just one thing:
The layers are not aligned to the absolute pixel grid.

• In some instances it's a "user error" based on the flexibilty that a user can but doesn't have to align objects to the pixel grid. 
  E.g. "Force pixel alignment" being off, pixel or image layers being scaled so that they don't match the document dpi, etc.
   
• In other instances it's a programming flaw / serious bug because the user has no or not much control or even visual reference about where the actual X,Y=0 origin of the absolute pixel grid is, see e.g. this thread, among many others.

[josbin]

6 minutes ago, loukash said:

Essentially, most of the time it's just one thing:
The layers are not aligned to the absolute pixel grid.

• In some instances it's a "user error" based on the flexibilty that a user can but doesn't have to align objects to the pixel grid. 
  E.g. "Force pixel alignment" being off, pixel or image layers being scaled so that they don't match the document dpi, etc.
   
• In other instances it's a programming flaw / serious bug because the user has no or not much control or even visual reference about where the actual X,Y=0 origin of the absolute pixel grid is, see e.g. this thread, among many others.

Cool, thanks for the calrification!

[loukash]

To clarify a bit more:  
Since this appears to be mostly about merging layers in Photo, the "absolute pixel grid" bug is less likely to be an issue because afphoto documents usually don't have bleed or multiple pages, unlike Publisher or Designer. 

So often the issue is with objects being placed at fractional pixel values. To avoid blurring, all values should be integer pixels.
And here come the next conceptual flaw in Affinity, and that is Preferences > User Interface > Decimal Places. This setting only affects the display of values in the Transform panel etc., not the actual values. So even when you see an integer pixel value of e.g. 267 px, the actual value could be 267.0494, and that will already introduce some antialiasing and thus blur.
I keep all my Decimal Places display preferences at 6. Not "1" which is the default setting for pixels.

[josbin]

Thanks for the information! 

One more question: So if I have the "Force Pixel Alignment" and the "Move by whole Pixel" on all the time, the problem of blurry merges should never happen?

I wonder where those errors (probably user errors as I hear from your first comment) normally occur. From a UX perspective this sucks a lot, cause I would like "hard enforce" that everything is aligned to the pixel grid which is what those buttons do I would assume. Where do they fail to enforce it? While using the move tool or creating a vector shape and then rasterising? Moving between apps? Kinda hard to understand and not intuitive at all.

I think a closer look how PS does it would help, as I have used PS for 10 years and not once did I have this problem...

[NotMyFault]

Besides fractional positions of layers who are probably the majority of cases, the 2nd issue are resized layers which is less obvious to detect and more complex to correct.

I still recommend „rasterize and trim“ as best option to avoid unwanted blurriness in the specific case before a merge down step. Often it does not make sense to pixel-align or „reset to original size“ the lower layer: this could wreck havoc to the overall structure or misplace edits done while the layer dpi or position was not aligned.

[josbin]

Agreed!

Macro Shortcuts would also be a really nice workaround as you pointed out in one of the posts.

[loukash]

1 hour ago, josbin said:

if I have the "Force Pixel Alignment" and the "Move by whole Pixel" on all the time, the problem of blurry merges should never happen?

Um… it's complicated.
It may appear counterintuitive, but "Move by whole pixels" should be off unless you have a specific case where an object must be off the grid by a defined amount, e.g. 0.5 px, and you don't want it to snap back to integer pixels. Thats because "Move by whole pixels" overrides "Force pixel alignment".

In general:

• "Force Pixel Alignment" on
• "Move By Whole Pixels" off
• Decimal Places: 6 (especially pixels)
• Transform panel: keep an eye on it all the time

[josbin]

haha been doing it wrong the whole time 😅 thanks for clearing that up for me!

[NotMyFault]

2 hours ago, josbin said:

One more question: So if I have the "Force Pixel Alignment" and the "Move by whole Pixel" on all the time, the problem of blurry merges should never happen?

This does not protect against resizing, which causes far more blurriness 

[walt.farrell]

27 minutes ago, Red Sands said:

It shouldn’t blur images - period. 

When you're merging layers of different DPIs that are not aligned to the same pixel grid I'm not sure there's a choice.

[josbin]

10 minutes ago, walt.farrell said:

When you're merging layers of different DPIs that are not aligned to the same pixel grid I'm not sure there's a choice.

Different DPI for sure makes it so that there is no choice. But resizing is normally not a problem as people are less suprised to have blurry quality when reszing images and merging down, as it seems more intuitive that there will be blurring.

But on a different but somehow related note : In my creative process I sometimes have to move around images to try different design ideas/patterns/etc.. In PS you could convert those images to a "smart object". This would to a certain degree prevent many resolution Loss and Blurring problems, when performing many transforms in a row. I am not aware of quick way to do that in Affinity Photo. The only way is to safe it out as a file and then place it in the document as an embedded layer or linked file. Or is there a more convenient way to have embedded layer or linked files?

 

[NotMyFault]

In Affinity, every layer is more like a smart object. As long as you not rasterize them, either directly or by merge down, all details are preserved and can be utilized by resetting size to original. 
 

Image layers behave different (wrt to rasterizing/merge down) only in special cases, like resize document with resample: Pixel layers get resample, image layers not. 

[josbin]

5 minutes ago, NotMyFault said:

In Affinity, every layer is more like a smart object. As long as you not rasterize them, either directly or by merge down, all details are preserved and can be utilized by resetting size to original. 
 

Image layers behave different (wrt to rasterizing/merge down) only in special cases, like resize document with resample: Pixel layers get resample, image layers not. 

One more time I am getting schooled  Thanks for pointing that out. Actually thats a great beaviour. 👍

[walt.farrell]

19 minutes ago, Red Sands said:

I have not seen this behaviour in Photoshop. I expect what I see on the screen.

Perhaps Photoshop does not let you have layers whose DPI is different from the document DPI, as Affinity allows?

[NotMyFault]

24 minutes ago, walt.farrell said:

Perhaps Photoshop does not let you have layers whose DPI is different from the document DPI, as Affinity allows?

I don’t use PS, but it seems to always enforce pixel alignment, and automatically rasterize bottom layer before merge down. This eliminates 2 most frequent causes for unintended blurriness

[NotMyFault]

Affinity is not Photoshop and no clone. They must be an independent product, with intentional differences. 

[josbin]

@Red Sands Hey man I get your frustration, and for me as an illustrator (mainly) it is also frustrating. But stick wth PS if you cant handle it...  
I think your statement that it's "madness" has some truth to it. I wouldnt express it this way but I agree, that probably a lot of new users will be put off by this behavior of affinity. And I would strongly suggest the dev team to take the suggestions made by @NotMyFault into account. I get that the "illustration" user base probably is quite small but none the less affinity photo is marketed as an illustration app... So hopefully they will implement it sonner than later

[Dan C]

Hi all,

Apologies for the delayed response here - I just want to provide a little extra information and context, as I have previously covered this in the following thread -

On 1/26/2023 at 8:46 PM, Red Sands said:

If this is an intentional difference

I've also covered this in my reply further down the above linked thread - 

On 7/13/2022 at 11:18 AM, Dan C said:

other image editors will force all layers to be the same DPI as the document, however Affinity allows users control over each layer, independent of the document DPI

I hope this clears things up

[josbin]

Hey Dan,

 

thx for the reply. As mentioned in other threads, it is not a bug but it is counter to many users intuition (I would argue most users even).

So if you could file a ne feature which rasterises and trims and then merges down, that would be awesome. As the @NotMyFault thread  also suggests. 

Here the thread once more:

 

 

Thanks!

 

 

[fde101]

Jeeps and SUVs commonly come with warnings that the vehicles could roll over if sudden maneuvers are made at high speeds.

Minivans typically do not.

 

Jeeps have a turning radius more like that of a car, while a minivan generally cannot make as tight of a turn.  If the same turn is made in a Jeep (or other SUV) that could be made in a minivan, the Jeep is no less safe than the minivan is.

The reason for the warning is that the Jeep can make tighter turns, but it comes at the cost of the driver needing to apply caution when leveraging that capability in order to avoid unwanted results (rollovers if using that feature when moving too fast).

This does not mean that minivans are superior to Jeeps because they save the driver from this particular concern; rather the Jeep can do things the minivan cannot, and the driver must account for that.

 

I look on this particular "issue" in the same way.  If Photoshop forces pixel alignment to the document DPI, that means that layers cannot have positions which are not aligned to the DPI.  This is a limitation compared to the Affinity products, which do permit that.  The fact that the Affinity products permit unaligned layers is does not mean that they are inferior - they can do things that Photoshop cannot do.  As with a Jeep, the "driver" (user) of the product needs to account for this while using it in order to avoid unwanted results.

[josbin]

I have to agree with Red Sands here, that from a UX Experience the solution in Affinity Photo seems to be quite bad for most users, as it is not explained at all in the program why this bevaiour is happening. there isnt even a warning when merging down. In photoshop you get a warning when merging down "smart objects"....

As stated multiple times: include the feature requested by @NotMyFault

 

[fde101]

On 2/26/2023 at 5:37 AM, josbin said:

In photoshop you get a warning

Printing this document will permanently affix ink to paper, which may not be possible to undo.  Proceed?

Saving this document without renaming it will destroy the previous copy of the document, which may not be possible to undo.  Proceed?

Copying the selected object to the clipboard will destroy the information currently on the clipboard.  Proceed?

 

The proposed warning does not impress me as a good idea.  There has to be a limit.

 

Affinity Photo, like Affinity Designer, is not a "true" raster image processor, but rather a hybrid application which is based on vector-based documents which happen to (usually) contain raster information on most of its layers.  Accordingly, there is no true "pixel grid" at the document level - that is an imaginary concept from the perspective of the document.  This allows vector objects to maintain precise positioning independently of the output resolution, as vector data really should do.

The pixel layers in Affinity documents are vector objects.

I think I need to repeat that one: the pixel layers in Affinity documents are vector objects.

The raster data within the pixel layers is raster, but is scaled to fill the vector object (the pixel layer) containing it.

The pixel grid of each layer is scaled to match the proportions of that layer.  Each one could have a completely different pixel density and positional alignment, and this is perfectly legitimate, as the document is vector in nature.

None of this cares in any way about the configured document resolution or the imaginary document pixel grid, as the documents are vector, NOT raster.

 

The current Merge feature, as per the thread linked above, often ignores the document resolution and its imaginary pixel grid when merging existing layers.  This makes perfect sense in a vector document as the important aspect of the merge is to match the layers to each other (all of the layers must be rasterized to match each other).  If the layers are not aligned with each other to begin with, the conversion process which rasterizes them against a grid different from the one they contain before the operation can result in artifacts caused by anti-aliasing as well as simply by the differences in their resolutions.  This cannot be avoided by the software.

 

While there is no true document grid in the Affinity Photo document, it still presents a rasterized preview of the image based on the imaginary pixel grid associated with the document resolution - it imposes a "fake" pixelated view of the document (which is possible in Designer as well, but is turned off by default; in Photo you are basically stuck with it).  When layers are not aligned with the document pixel grid which is used when displaying the information to the user, there can be similar artifacts in the display which may not be present in the actual underlying layer.  This too cannot be avoided by the software.

 

The challenge users are facing here is that the merging of layers happens between the layers within the vector document space and ignores the pixel grid which is used for display purposes.  As a result, if any of the layers is not aligned to the imaginary pixel grid used for display purposes, the reality of the layers behind the scenes is different from what the users may perceive them to be, and the merge operation can operate on the layers at a different alignment than users anticipate based on what they are seeing.  After the merge completes, the layers are then being presented through the lens of the imaginary document pixel grid, causing yet another layer of distortion on top of whatever exists in the actual document, in the layer itself.

 

While all of this does make sense and should be expected when you understand how it works, the manner in which it works does violate the principle of least surprise for those who have not taken the time to understand how the software works, and the results are not particularly desirable for the primary purpose that the software is marketed for - that being, photo manipulation.

 

While the current merge functionality is not a bad thing, it would be much better for most users if the merge rasterized against the imaginary document pixel grid instead of purely between the layers themselves, in order to better match the expectations of its users.  While @NotMyFault, in his thread linked above, only referenced the rasterization of the bottom layer (as opposed to ALL of them which are not already aligned with the grid, which would be necessary to be able to merge at all), and erroneously refers to the current option as not rasterizing (it does, but it does so against the other layers being merged rather than against the imaginary document grid) he otherwise was basically on the right track with how to better match the feature to the needs of most of its users.

[debraspicher]

In the very least, offering Merge options that are in the context of the actual behavior of Merge, would seem to be in order. "Merge Against Document Grid" (vs Merge & Rasterize), or "Merge and Resample Layers", etc... maybe not those exact operations, but something like that. Something that gives some immediate clue that the programs do not behave the way users of other programs have come to expect when they see Merge.

It's far better to have users to come to the forums or to check documentation to ask "What does this option mean?", versus, "Why does this Merge operation I've used in a dozen other programs look terrible compared to what I'm used to". A more graceful introduction to different functionality if you will rather than making the user feel embarrassed that the functionality is not doing what they expect and they can't figure out why. I feel like the current approach is more insulting.

The larger context also: UX issues and longstanding bugs still exist, seeing that they're still behind on features. This already demands user patience. It's like the program is asking them to have complete faith but with total blindness as to where they are going, when necessary UX is missing. When a user "complains" and is told that all is well, it's "by design", they're being asked again to have faith using that same approach. Personally, I think that's one of the worst feelings a designer can have, is to not feel they have an intimate understanding of their tools and even worry that it is liable to do things they don't expect or anticipate. That's the source of frustration for many here I suspect and blowing it off as "They don't understand the program's design" is adding fuel to the fire rather than diminishing it. Staff needs to be more sensitive to this and others could be more aware that not everyone comes to these programs with the same understanding of complexity that they do.

And to be fair here, all graphic programs have their UX issues/bugs. It's like a badge of honor to have to learn some weird workflow. Adobe's software had quirks and silly workarounds I'd long found tiresome by time I moved onto to other things. It's less about the programs being perfect or being seen as perfect, and more to do with these shortcomings being handled in a more graceful manner so that a user doesn't feel completely ignored or left in the dark about what they should/shouldn't have done to fully realize the design process. That can apply to forum responses, sure, but I think in many cases, people are often advocating they just get a better feeling overall from the programs themselves. All designers are problem solvers at the end of the day, they just need to feel empowered.