Jump to content

olivierlafitte

Members
  • Content count

    17
  • Joined

  • Last visited

About olivierlafitte

  • Rank
    Newbie

Recent Profile Visitors

146 profile views
  1. Dear developers, I had reasonably no hope for this problem to be solved in the 1.7 version. Presumably thousands of other stuffs to fixe before this surreal dead-line. Probably now hundreds of new stuffs to work on now thousand of impatient users shake the beast and feed the forum with new requests. So this cordial reminder. I've just done one new test on the 1.7 version I've just downloaded. The PROBLEM remains. This is not a minor one. And what really worries me at the moment is that I've just checked the whole forum. https://forum.affinity.serif.com/index.php?/topic/53609-merging-layers-causing-blurring/ https://forum.affinity.serif.com/index.php?/topic/56935-blur-image-issue-after-merging-layers/ https://forum.affinity.serif.com/index.php?/topic/46138-image-blur-when-merging-image-together/ https://forum.affinity.serif.com/index.php?/topic/46290-resolution-loss-when-merging-layers/ https://forum.affinity.serif.com/index.php?/topic/26598-loss-of-detail-when-merging-down-in-ap-and-delays-in-merging/ The problem is known for years (this last and current topic being the one that characterized it with the more precision. Actually it even suggest an answer [ if needed ] : bottomLayer.rasterise() . Just before the mess) I hardly understand. It's definitely one of this feature that suggests Affinity is not a solution, but a problem (I haven't opened Affinity Photo for a month). More than ever, I'm eager to read from you. There must be a missing plot, a functional one (the technical solution being there), something I can't grasp, to justify this situation. Don't be a stranger. A sad user full of hopes.
  2. This subject is being discussed in two other threads. But in each case, the discussion has shift towards peripheral considerations, leaving no chance for the initial question to be answered. I voluntarily put here no links to those threads in order to prevent readers to be parasitised by pheripherical and noisy considerations. What should be strictly discussed here : The "Merge Down Layers" (Ctrl+Shift+E) , a very common frequently used command, in some case (see details below) currently corrupts the image: contents of merged layers are blurred. Question: is there a good functional reason for this function to work so, knowing there's a simple way (doing a rasterization of the bottom layer before merging) to achieve the expected result : a merge that simply preserve the data of each layer ? Or is there currently an option to be activated to achieve in any case automatically the expected result ? Details : afphoto file attached to reproduce the bug reproduced in : 1.6.5.135 and Beta on Windows 10 and 1.6.11 on macOS Sierra reproduced with "Force Pixel Alignment" or "Floating point coordinates" options on and off: those options are no way a solution to this problem. a simple way to reproduced the bug with two pixel layers is to apply a transformation on the bottom layer before merging (note: by doing so, coordinates of the layer are no more integer ones) a simple way to prevent it : rasterize the bottom layer before merging For many users, the current behavior of the merge function is a fondamental problem (you can corrupt your work with one click if you're not aware). We would be glad to have an answer to the question above or the function to be fixed. Cos there is no technical limitation considering our use (it may not be elegant, but the merge function could simply process a rasterize operation before applying, which is the manual action required currently if you want to preserve the quality of your image). PS: actually, there's a video that illustrates this tricky behavior here Demo . See the seventh post
  3. Thx . I'm French. "Nominal" in French means in some case "common". Ex "Nominal use case" vs "Alternative use case". I though it could be used this way in English. I know the limitations of my English mays lead sometimes to incomprehensible sentence ...
  4. Despite the goodwill of Danmerey to recenter the thread on the initial question by opening a new thread, this thread has already got out of control. It's a failure . It's discouraging. Cos it deals about a specific "bug". On a nominal, fundamental function. That ruins So far, no one has pointed a good functional reason (if there's one, it's time to lay it down) for the merging function to work has it does, damaging the quality of the image. And there is a simple technical way to make it work as it should (I'm eager to read the arguments of someone for whom the current behavior must prevail. Really. I want to understand). I suggest to close this thread (or to let it live for those who want to deal with peripherical subjects) and to open a definitive third one using the initial posts. The aim of this third thread would be strictly : Why does the merge currently gives a shity result whereas there is a simple way to make work as it should ? So answers in this new thread shouldn't in any case be technical but functional : "there is a good reason fro the merge function to work as it does, cos if it would achieve the result you want in this thread you would lost the capacity to ????"
  5. Please R C-R , You're about to lead this new thread to same direction that the previous one (... which leads nowhere ). Can you considering just this fact : If you rasterize your bottom layer before processing merge, you got what can be considered as a perfect result. The global image before and after (rasterize+merge) operations are strictly the same. No blur. The result some of us (everyone ?) would like to got. If you didn't, your result is sadly blurred (the content of both initial layers). Useless. So the application is currently totally able to proceed a perfect merge, the one (casual / most ?) users would like to got. So why not ? Why the merge function didn't simply proceed this way (the green one) ? Where is the gain for the user to proceed otherwise ? If there's one (I'm not an expert), it's the missing argument in this thread. The only one. Elsewhere, the merge function should be upgraded (maybe one line of code ....) for the happiness of most of us
  6. 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.
  7. 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.
  8. 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)
  9. 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 ....
  10. 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 ....).
  11. 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. mergeLite.afphoto
  12. 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
  13. 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.
×

Important Information

These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.