Jump to content

olivierlafitte

Members
  • Content count

    17
  • Joined

  • Last visited


Reputation Activity

  1. Thanks
    olivierlafitte reacted to GabrielM in [By Design] Merge Down Layers in AF corrupts/blures image in some cases: example attached, solution offered   
    I've logged this with our developers for further clarification.
  2. Like
    olivierlafitte got a reaction from danmerey in [By Design] Merge Down Layers in AF corrupts/blures image in some cases: example attached, solution offered   
    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 ????" 
       
  3. Like
    olivierlafitte got a reaction from danmerey in [By Design] Merge Down Layers in AF corrupts/blures image in some cases: example attached, solution offered   
    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 ????" 
       
  4. Like
    olivierlafitte got a reaction from Alfred in [By Design] Merge Down Layers in AF corrupts/blures image in some cases: example attached, solution offered   
    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 ...  
  5. Like
    olivierlafitte reacted to danmerey in [By Design] Merge Down Layers in AF corrupts/blures image in some cases: example attached, solution offered   
    Can you please stop running away from problem and accept that there's a huge bug here?
    This facts shouldn't affect the merging anyway, this is not expected behaviour for any normal user. Merging shouldn't corrupt image in any way. "How it looks before merge" must be equal to "How it looks after merge". Why I need to make some stupid workaround to get normal behaviour of merge? If you change floating points to integer, problem still remains. How about to check it before posting this answer? That's why I said, that it's not the problem. Or I need to make a video to prove it? I'm really tired of explaining why this is a bug and not my imagination How can I avoid getting decimals in my image anyway? I can't because I use resize and rotation tools all the time. Or maybe I shouldn't ever resize anything so it won't corrupt after merge, lol? Come on, it's easy to fix (I already found a solution: just rasterize lowest layer before merging) – why do you make it so hard for us to enjoy the product and customer support?
    PLEASE, fix this already and stop making exuses. Software should be easy and pleasant in use, but we are frustrated instead (because of a bug and because of not wanting developers to fix it)
    Corrupted Merge with Integers.afphoto
  6. Like
    olivierlafitte got a reaction from danmerey in [By Design] Merge Down Layers in AF corrupts/blures image in some cases: example attached, solution offered   
    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
  7. Like
    olivierlafitte got a reaction from danmerey in Merging layers causing blurring   
    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.
      
  8. Like
    olivierlafitte got a reaction from danmerey in [By Design] Merge Down Layers in AF corrupts/blures image in some cases: example attached, solution offered   
    Same issue with the 1.6.11 version on macOS Sierra.
  9. Like
    olivierlafitte reacted to danmerey in [By Design] Merge Down Layers in AF corrupts/blures image in some cases: example attached, solution offered   
    Hello, this bug is being discussed in another thread, but since it's being ignored by Developers for pretty long time, I decided to refresh it by creating a new topic with some new facts and a solution.
    "Merge Down Layers" (Ctrl+Shift+E) is very common and frequently used command, that we use to merge layers. Although it can corrupt your image in a lot of random cases by blurring you layers after merge. You can see what happens to layers if that occurs on attached image. After 1 merge you are losing sharpness, and after 2 or 3 merges you will start to notice that image got blurred, but it will be too late – your file is already corrupted. I attached *.afphoto file, so you can reproduce bug and see why this happens.
    I already found a workaround in the past, which is super annoying, but better then nothing – Create Empty Layer (Ctl+Shift+N) and merge down to this new layer.
    But today I found an ultimate solution for Affinity Developers, which is super easy to implement, and I hope they will do it ASAP: If you rastirize lowest layer before merge, nothing will be corrupted. So before Merge we should automatically rasterize lowest layer, and then we will never corrupt our image again.
    Some important facts for Affinity Developers:
    I attached *.afphoto file, you can reproduce the bug I reproduced bug in Beta too It's not because of "Force Pixel Allignment" or "Floating point coordinates" This is critical bug, that corrupts our work (I corrupted my images without noticing, other guys from previous thread also corrupted 4+ hours of work) This is not intended behaviour, please pay attention to this one and put yourself in our place This never happened in Photoshop with similar actions To get "bugged" layer you can resize existing normal layer and it becomes corrupted for future merges To fix this bug you just need to automatically Rasterize lower layer before "Merge Down" operation Thanks, hope you fix this asap and notify us!

    Corrupted Merge.afphoto
  10. Like
    olivierlafitte reacted to danmerey in Merging layers causing blurring   
    I started a new topic, since this one is pretty old and being ignored for a long time by Affinity Developers. If you have something to add, you are welcome. I also found an easy solution for Developers and one of the reasons, why this happens
     
  11. Like
    olivierlafitte got a reaction from Wosven in Merging layers causing blurring   
    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 ....).
          
  12. Like
    olivierlafitte got a reaction from Wosven in Merging layers causing blurring   
    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.  
     
×