IPv6

AP has nice function - "Repeat <last used filter>", Ctrl-Alt-F by default. The greatest part of this feature, that you can do some filter on layer, then select several other layers and and call "Repeat ..." - and your filter will be applied to every selected layer, very effective. There is also warp tool. It also can be repeated - so you can select part of image, do warp on one layer and repeat exactly the same deformation on another - BUT if you select several layers at once, repeat will work only on the active. Not on each layer, as with filters. So if you have several dosens of layers, that needs the very same warp action applied - you have manually choose each and press Ctrl-Alt-F... very tedious. Please, make "Repeat warp" behave on selection in the same way as with filter - i.e. repeating automatically happen on each selected player, not only active one. For now this feature looks bugged, when some actions auto repeated on all layers and others not.

When using curves with gradient colors we are currently locked to linear, radial, etc... but essential gradient that is used specifically with curves is missed - gradient along the path. It just needed // So the gradient colors follow the curve from beginning to end, not simply horizontally (as in linear)

Still, press-and-hold would be fantastic addition... really helpful

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

Please, add options to set Direction/Angle for Ripple and Displace filters This filters can be really useful but now they are pretty useless... Their current uses quite limited to simple cases only

Just hit another similar case (with wrong rasterization) and... you were definitely right! Seems this is the real problem with rasterization - or, better to say, with Fill layers Some Fill layers after rasterisation receives wrong bounds! They should cover whole document (and most of them do) - but some, after rasterization, became smaller. So the problem is how Fill layers rasterized - there is a bug with final bounds of pixel layer. So a temporary workaround for anyone hitting this - in case of rasterization problems just rasterize fills inside group and fix bounds manually... then global rasterization will do the job right. Finally

All masks can be seen on last screenshot. There is no other masks. And all this masks cover whole area of document. You can activate arrow tool and click on each layer/mask to see it bounds. Each and every mask in this document cover whole area You can also tell this looking at screenshot before rasterization - there is no squares, each pixel is affected in the same way

It`s not weird. It`s a Fill layer (if you check the file i attached), so it always fill whole document. It should not be rasterized (it`s intentionally a Fill), it should cover whole area. This is very convinient when you change the size of the document - Fill layers just always cover it all. And it covers the whole area when you open document - no squares... And so should be during rasterization (i suppose). See screenshot, it`s not a pixel layer. But you are right - looks like it`s "Fill" mode is ignored during rasterization, which lead to squares... Obviously rasterization should respect layer type in the same way as in usual compositing

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 //

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

With 1.7.* there is some cases when "Rasterize layer" on group with nested effects rasterizes only PART of the group. Half of the final, rasterized 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 also goes into save/exported file too (after rasterize), so this is not rendering issue Happens both in Windows and Mac (without Metal enabled), also in betas. 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. See attached file with this problem to reproduce CriticalRasterizationBug.afphoto.zip

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

Yes, its possible to get something colored out of this adjustment by moving sliders. But still, the very nature of LAB channels dictates some important behaviours for a/b channels and how they contribute to colors. and current way is clearly broken. You can compare to Photoshop channel mixer in LAB document, for example. In photoshop it behaves as it should, predictable. In AP it is not

I can second this problem, layer can be easily lost due visibility.. with deep grouping this is madness And this happens with all export settings, there is no workaround (aside tediously doing "show all" before each export)

Hm... i tried and this indeed works! Tnx. I mean when single alt-click stops to work - then double-click "unlock" situation. Similar to checkbox ticking Still, normal way (by documentation) to enter isolated mode is to alt-click once. and another click on another layer - to exit this mode. Randomly switching method between single and double clicks is not user-friendly, imho