IPv6 Posted July 2, 2019 Posted July 2, 2019 I have a workflow in which some groups with nested live filters frequently rasterized, to be used in other files/groups. And with 1.7.* there is some cases when "Rasterize layer" rasterizes only PART of the group. Half of the final layer missing effects, that was active inside group before rasterization! See screenshots before and after rasterization, notice color/lightness change. This bad rasterization can be seen on any zoom level and in save/exported file too (after rasterize). Happens both in Windows and Mac (without Metal enabled), on release and latest betas (just checked with 1.7.2.414-win). This is really critical, since this "partial rasterization" can easily go unnoticesd down the road (sometimes difference is subtle), requiring a lot of additional work after several actions applied on such badly rasterized layer already. Hope this will be fixed soon... rasterization is a basic thing, which should be 100% reliable for stable workflows. Also attached file with this problem to reproduce CriticalRasterizationBug.zip
Max P Posted July 3, 2019 Posted July 3, 2019 I observe this comportement, without understanding the relation with my process, One or more square parts in the picture. I didn’t understand and it seemed a bit random to me.
IPv6 Posted July 3, 2019 Author Posted July 3, 2019 Yes, squares appear after rasterization. They shouldn`t - since there is no squares BEFORE rasterization. Rasterization is the process of converting group (in this case) into single layer with all nested effects without alteration. It`s a flattening process, it should keep all pixels the same. But with this file you can see that group flattening altering some pixels, making squares. In this case rasterization/flattening applies inner effects only partially. Live effect over half of the group pixels just thrown away, dropped. Which should not happen This is not rendering issue, since before rasterization all pixels computed properly (so no squares) Image (gradients) indeed "random" - i ripped group structure from work document and flooded layers with gradients... just to demonstrate issue Max P 1
Max P Posted July 3, 2019 Posted July 3, 2019 Sometimes, I’ve had squares without groups, in your example, the squares came when I wanted to explore procedural texture that you use ; by the way, thanks for this example, maybe a solution for a problem, or an evolution , not so easy.The documentation is summarised.
IPv6 Posted July 3, 2019 Author Posted July 3, 2019 You mean you get squares even before rasterization? Not happen for me // only rasterization brings them into document Anyway, there is no "squares" in masks or similar. By the content of this group - all nested effects should be applied to every pixel in document. And you can see this on first screenshot - this is what is happening while group is active. No squares, each pixel is computed well. But during rasterization some pixels are clearly computed differently, which should not happen, since rasterization should give layer with exactly the same pixels. This is essential. If rasterization randomly skips some effects without any kind of warning (at least) - it just simply can not be used //
Max P Posted July 6, 2019 Posted July 6, 2019 I made an example See the file clik on the invert adjustment select deselect Select give random squares on the screen LAB_schematicBUG.zip
IPv6 Posted July 6, 2019 Author Posted July 6, 2019 2 hours ago, Max P said: I made an example See the file clik on the invert adjustment select deselect Select give random squares on the screen LAB_schematicBUG.zip It`s another issue, it`s a rendering problems... and there is indeed many of such cases. Some tiles inside viewport are not updated even on very relevant changes // There is many reports about this tile things, so hoping this will be also fixed soon
Staff Patrick Connor Posted April 17, 2020 Staff Posted April 17, 2020 Sorry. Thank you for reporting a problem using the pre 1.8.0 beta builds. It appears that a member of the Affinity QA team didn't get round to fully investigating this specific report posted in the bugs forums. We are very sorry for this oversight. Yours is one of a number of reports that I am posting this apology to, using an automated script. Now we have released 1.8.3 on all platforms containing many hundreds of bug fixes, and we hope your problem has already been fully addressed. If you still have this problem in the 1.8.3 release build, then the QA team would really appreciate you reporting again it in the relevant Bugs forum. Report a Bug in Affinity Designer Report a Bug in Affinity Photo Report a Bug in Affinity Publisher Each of those links above contains instructions how best to report a bug to us. If that is what you already did in this thread just copy paste your original report into a new thread. We appreciate all the information that you have including sample files and screen shots to help us replicate your problem. This thread has now been locked as the QA team are not following the threads to which this automatic reply is made, which is why we would appreciate a new bug report if you are still have this problem in the release build. Patrick Connor Serif Europe Ltd Latest V2 releases on each platform Help make our apps better by joining our beta program! "There is nothing noble in being superior to your fellow man. True nobility lies in being superior to your previous self." W. L. Sheldon
Recommended Posts