olivierlafitte
-
Posts
17 -
Joined
-
Last visited
Posts posted by olivierlafitte
-
-
On 4/10/2019 at 3:03 PM, R C-R said:
Plain & simple, this is not a bug; it is inherent in the document format itself, not just in Affinity apps but in any app that supports similar layer types & edits.
There's no way "it's inherent in the document itself", since just applying a rasterize operation on the bottom layer you're about to merge before merging leads to the perfect and expected (and logical) result for most of us. A result without any blur.
- Rasterize bottom pixel layer and then merge layers => perfect result. Merging didn't affect the quality of the data (as does PS). Before and after the whole operation (rasterize+merge), you got visually strictly the same result.
- Directly merge the layers => the content of both initial layers are blurred.
From the beginning of this thread, I don't understand how this simple fact can be ignored. Maybe it's due to langage (english is not my natural langage and there's no doubt some of my sentences are incomprehensible). Maybe we didn't deal strictly of the same subject :
Maybe some got in mind the case when merging deals with non-pixel layers. In this case, yes, data of the non-pixel layer is necessarily affected due to the rasterization of its content before merging. No problem with that. It's logic. It's not what this thread is dealing about (it's dealt with pixel layers, normal blending, full opacity ).
And maybe there's a difference between the rendering of a pixel layer whom the content had be transformed before and after it's rasterization (in this case, rasterization (not a real-time operation) should logically lead to a better result (i.e less blurred), cos it can use more complexe algorithms) [to my experience : the result are strictly the same. Besides, the free wrap function which is far more complexe forces the user to commit its transformation. Which leads to think that for other transformations, the application achieve to comput and display the same image before and after rasterization]
But, considering the bullet points above, no acceptable justification had been given so far (I don't say there's none ... I'm neither an expert, neither a professional user).
So far it's a bug (unless there's hidden interest). And there's an alternative way to achieve the logical result that people who opened this thread expected (green bullet point above).
Those peoples, as myself, simply would like the application to produce nominally the result achieve with this alternative process. Who wanted to get a blurred image when merging when it's easily possible to get the perfect one (one line of code maybe) ? What the use ? Where's the gain ? If there's a gain, that what this post should eventually deal with now.
-
Fixx,
The fact that you introduce here the notion of dpi in this thread troubles me. Actually, in my case, my works are mainly pixel ones and not enough gorgeous to be printed. At the end, before exporting it in a jpg format to eventually share it to someone, I always merge all my layers. It's an habit. It's a way to act the work is finish (no way to rework it). Due to the fact I often process of resizing during export, I never chalenge the quality of the export.
But the fact you're talking of DPI make me realize now that users, more professional users, or user's who mixed rasterized layers, no-rasterized pixel layers and vector's ones, who's reasonable goal is to preserve data until export, are fully interest by keeping their un-rasterized vector layers intact. It's logical they don't process unneeded merges that lower the quality of their work not intended strictly to be seen on a digital display at its nominal resolution.
Now I got it. So thx.
..... but, my problem remains.
When merging layers, which is a nominal function, that lead to rasterized the layers to be merged, you obtain a different result according the fact the bottom layer is pixel-aligned or not. I can't find a reason that justify the blur that occurs on the step C of the left process of my presentation. All the more that if you first proceed to a rasterization of the bottom layer, you got a perfect result.
-
R C-R,
I got the point. From beginning. The problem for me is not that some transformations lead to blur a bit the source image. It's logical. There's no other way: the app had to comput a resulting image and due to pixel model and the resolution limitation, some rough approximation are needed leading to a blur effect [it's the blur you observe on my presentation on step B for square 2].
But the blur that occurs during the merging of a pixel-aligned layer into a non-pixel-aligned layer, THE problem pointed in this thread, is something else that can't be justified (so far). Proof : if you follow the right process of my presentation, the results is perfect (the only blur you got is the on due to the transformation on step B)
-
Yes. I got this point. But what I find tricky is the fact that the activation of those both options didn't prevent at all misalignment cos like you said, rotations, warps, shears/skews, or perspective adjustments (no mention of various filters) corrupt this state. Only the displacement tool works fine with these options and guaranty that your workflow remains a full pixel one from beginning to the end.
Finally those options (which are probably dedicated for web design workflow) are misleading to me. Maybe they should be automatically shut off when you process a transformation that corrupt alignement. Or a warning should alarmed the user.
The more I think, the more I think the concept of un-aligned layers which is in theory great, powerful, is debatable. For most users, casual user like myself, the reference is what is displayed. To display a misaligned layer, AF does the job to calculate full pixel translation. That what the user see, and if didn't configure the UI to display layer coordinates, he can easily though he has a simple rasterized layer in front of him. That was always the case in my old version of PS: every pixel layer was rasterized (cos transformations leading to comput a full pixel image to approximate the result of the transformation were committed (rasterized) immediately). Only the vector layers could be rasterized.
It's a powerful concept that AF enable user to process successively multiple transformations on a layer without damaging the original data (impossible with my old version of PS), but it leads at the end at some confusions by introducing misaligned layers ....
If only the merge function would process the logical result (the one, most of the users would like to got I think) when merging (result you got if you just rasterize the bottom layer before merging, see previous post), it would be ok. Seamless. If this current behavior is not a bug (ie. if it has a real function for some users), I wish there was an option to constraint merge function to process as I attempt. I'm sure it would glad many casual users ....
-
Thx,
It works and it's a one click process (versus three for my current solution). The Rasterise function commit the transformation and convert the layer to a pixel-aligned one.
Fine ..... But ...
It remains a problem to me. Cos you can forget to process this operation (it just occurs to me and I lost a 40h work. I didn't realize immediately that I've blurred my main layer and I save my document ..... a pure nightmare). So working with AF is so far a bit dangerous for nerves ....
A part of my question remains : does this behavior got a real use for some users ? Personally I can see one. As long as transformations are committed as soon as you merge your layer. On the other hand, it's hard to think it's a bug, cos it's so obvious and linked to such a fondamental function that I can't believe it wouldn't have been reported and corrected before (the correction being so simple: auto rasterized the bottom layer before processing merge. A one line code correction maybe....).
Clearly to me, it's fondamental this behavior to be adjust to definitely shift from PS (I had opened only one time for few months) to AF. Or a warning to be implemented when your about to corrupt your data. Did the Beta fixe something ?
And I didn't completely understand the options "Pixel aligned" and "Pixel Movement" (I use the French version. I don't know the strict english name of those options) since a simple transformation as a rotation corrupt this logic (the only the simple nominal behavior works with translation function. Maybe useful for pixel-art amateur ....).
-
So my whole post was a total failure ....
. I should improve my english.
By "content" I means initial content of each layer before merging, i.e : square I for layer 1 (the background layer), square II for layer 2 ... .
- On step C of the left process, squares 2 and 3, just merged into one layer, are blurred (artefacts are not the result of the jpg compression: it's a real blur)
- On step C of the right process, squares 1 and 2, just merged into one layer, remains intact.
According the order of merging, you achieve a fine or a blurred result. Merging a no-pixel-aligned layer into a pixel-aligned layer is the right way to annihilate the pervers effect of no-pixel-aligned layer during merging. If before step C, you merge layer 2 into a new blank layer (doing so, you commit the transformation, but you also "convert layer 2" into a pixel-aligned layer), you got the same final result as the right process. The right one (.... the one a non-professional user would like to got I think).
The fact merging a pixel-aligned layer into a no-pixel-aligned leads to blur the initial content of BOTH layers is so far a "bug" to me. If this blur was due to the fact transformation of one of the two layer remains not committed (meaning in this example rotating square II in reverse would lead to the perfect initial square ), I could accept it. It would by tricky, but there would be a functional reason. But it's not the case. Transformation are committed in each case of merging (which is logical)
I join the AF file at step B for test.
-
PS: there is no a long way for the app to achieve what would be perfect to me (and some of us). On merging, first merge bottom layer with a new blank one and then proceed. So far, I had to remember to do it manually each time
-
Wosven, R C-R,
Here is simple presentation (I'm not proud of ... but I hope it's clear. It's the main goal) that sums up the previous statements.
The problem is no matter the pixel alignments options are on, as soon as you process a transformation that is not a simple displacement (rotation, skew ...) on the content of a layer (which is a basic use for composition), you produce a NO-pixel-aligned layer. And the way AF deals with merge of pixel-aligned and no-pixel-aligned layers is (at least for common users) a mess.
- Merging a no-pixel-aligned layer into a pixel-aligned does the job: contents are preserved. The resulting layer is aligned. And problems are over. Great.
- Merging a pixel-aligned layer into a no-pixel-aligned does a mess: BOTH contents are blurred. The resulting layer is not aligned. And by no way there's a way to retrieve a crisp original content by adjusting layer alignment after. The blur is build-up, commit. And it might be the begging of your problems cos, because the resulting layer is still not aligned, you can now spread this effect to other layer contents with futur merging operations (and each time, the blur build up to achieve a foggy content by the end .... )
When I switch from PS (a very old version) to AF, I was first amazed by the fact AF doesn't commit layer transformations. If you proceed a rotation, a skew on a layer content, the transformation is not destructive: if you proceed later the reversed transformation, you retrieve your initial data. Great feature. In PS, you had to commit your transformation. Transformation were destructive. It was not cool but it leads to a simple task for the app to manage layers merging.
A simple (laborious) way to avoid this problem in AF is to immediately merge a transformed layer into a new blank layer: the transformation is then "commit" in the new pixel aligned layer (PS behavior). We lost the capacity to correct it later but we are sure to preserve the global file integrity along the way.
I don't understand the way AF deals with merge. Maybe a developper or a pro-user can justify a use case when this current behavior is useful, but I can't see. For a casual, non-professional use, to my opinion it's a problem. The fact merging a pixel-aligned layer into a no-pixel-aligned leads to blur BOTH contents is so far a "bug" to me. A real pin in the ***.
Wosven, we definitely share the same problem. Merge some layers in our workflow each time an intermediate result is fine to maintain a reasonable amount of layers in our file. I though this was a common way to work. Maybe not. Cause doing so, at the moment, is not simple in AF.
I hope this behavior to be adjust in further versions (or that someone gives me the right way to work with this app which is by every other ways (... I got problems with gradients that are not fine to me. Maybe due to my colorimetric space ?)) a great app, a great alternative to PS, that is not an option for a non-professional user due to its price.
-
Hi Wosven,
I understand the principe of alignement on the pixel grid (note: english is not my natural langage. I may hurt this langage integrity ...). Clearly a solution to prevent this problem.
What I don't understand is : how the app manage to display in real time, before the merge, a perfect image (without blur), but fail to commit the layers consolidation (which should lead to the same result) when merging ? Should I understand that the image displayed before the merge is inaccurate, an approximation comput considering the layers aligned, and the real resulting composited image really considering the fact the layers are in reality not aligned is only computed when merging (resulting a logical blur) ? In this case, what is the purpose to allowed the user to work without the limitation of pixel alignement if he can't see the result before merging ? I would not understand the goal of this function. During a photo composition, I often need to go over this rule of pixel alignement to achieve a good result. So I though. Now there's the shadow of the doubt. It was just an illusion ? If the image displayed before merging is inaccurate and doesn't take into account displacement lesser than 1 pixel, I was a fool .... The fine adjustments I though to provide by slightly adjusting layer position were just mirages ....
I couldn't open the joined file to the previous post with my AP version. But i try this proposition on my file. My blurred layer was not aligned on the pixel grid. A fact. But the blur was not the result of this non-alignement. By zooming the image, i can clearly see each pixel is spread in every direction (right and left, like a real blur. An initial 4*4 pixels square is now 8 pixels width . A strict blur due to a non-alignment should produce 5*5 pixels square at the most)
...
I now realize I've done so many merges during my work, this last assertion (the grey one) is without value. The non-alignement blur may have built up at each merge. In this case, the problem remains total : if you don't imediatly realize that the result of a merge produced a blurred image (due to non-alignment of resulting layer with the pixel grid), after your second merge with this layer, your image is fucked up definitely.
If the hypothesis (the image displayed before merging is inaccurate and doesn't take into account displacement lesser than 1 pixel), my position remains the same : that's not the way the app should deal with merges. The nominal behavior should be non-destructive. If this hypothesis is right, I just don't understand the purpose of the option "pixel alignement". It shouldn't be an option. It should be forced. I can't see any use case ....
-
Hi everyone,
I've just fu****-up a file i was working on for 40hours, suddenly realizing all has been blurred without my consent many steps ago. No way to undo the damage ....
Without doubt to me, this occurred on a merge-layers action. Indeed it's not the first time I've been fooled by this function. Each time I realize the problem had just occurred, I always manage to achieve a correct merge adding a certain amount of blank layers on the bottom or the middle of the pile of layers to be merged, according a logic that remains obscured to me. The main problem to me is not that this way of processing is tricky, but that it may lead to definitive "artistic" file corruption if i didn't catch the problem on time (my current issue).
I've read this thread.
The Force Pixel Alignement is no way a solution to me. I don't necessarily want my pixels to be aligned during my creation process. All I want is a merge function achieving a logical and simple "you get what you see" result (blurred if blurred due to non-alignement. Plain elsewhere. The one i got on Photoshop during many years). I hardly understand this result not to be the nominal one. The real need. And I hardly understand how it couldn't be achieved, simply considering the simple trick I've found (adding some blank layers and process merging on a specific order) leads to solution.
This thread seems to be a dead end. Yet I can't imaging users to be satisfied with this fondamental dysfunctional function.
Some news ?
[ 1.6.11 on macOS Sierra ]
. I should improve my english.
Merging layers causing blurring
in Pre-V2 Archive of Affinity on Desktop Questions (macOS and Windows)
Posted
We fully agree.