kirkt Posted September 21, 2017 Share Posted September 21, 2017 Hi Folks, This issue appears in both the current commercial release as well as the current beta (1.6.5 B5), so I am guessing it may just be the way it is. I have recently been experimenting with some tonal balancing operations that bring highlights down and shadows up in an image (tonal range compression). The quick and dirty description is that I start with my contrasty image and produce a grayscale from one of the channels that represents that contrast best. I make this grayscale image a new layer above the background, invert it and set it to Overlay mode. This will produce a very flat, mostly awful looking image that has lost much of its local contrast too - however, if you then apply a Gaussian blur of suitable radius to the overlay layer, local contrast is restored. In trying to devise a strategy for automation via a macro and for producing a non-destructive workflow, I have experimented with using a Gaussian blur Live Filter Layer nested in the Overlay layer with an initial radius set - the user can adjust on the fly to get a good balance of local contrast restoration without halo. Here is the rub - if all I do is set up the overlay layer with the Live Filter Layer doing the Gaussian blur and then flatten the image, it takes AP many many seconds to perform the flatten operation. If, however, I apply a Gaussian blur filter destructively to the overlay layer, the effect is nearly instantaneous - if I then perform a flatten operation, the effect is nearly instantaneous. Here is an example: 5760x3840 px Canon 5DIII image. If I use the Live Filter Layer method and nest a 100 px radius Live Filter Gaussian blur to the overlay layer, and then perform a flatten of the two layers (the Overlay layer with the live filter applied, plus the background) it takes **24 seconds** to flatten on my machine; if I perform the same, but destructive, operation of blurring the overlay layer and then flattening, each operation in that sequence is nearly instantaneous. This is on a Mac Book Pro Retina Mid 2015 model, 2.8GHz i7 4 cores, 16GB RAM, etc. OS 10.12.6. OpenGL acceleration enabled. Is there any explanation for why it appears to take AP excessively long to render the Live Filter layer when flattening? The actual drawing to screen when I adjust the Live Filter is fast, pretty much real time. Seems odd. Thanks, kirk thibault berwyn, pa usa anon1 1 Link to comment Share on other sites More sharing options...
anon1 Posted September 21, 2017 Share Posted September 21, 2017 - Link to comment Share on other sites More sharing options...
kirkt Posted September 21, 2017 Author Share Posted September 21, 2017 I read your other posts and I agree with you assessment. Flattening a few adjustment layers on top of the two I mentioned above makes the flattening process even more measurably longer. Something with live layers needs to be optimized maybe. Kirk anon1 1 Link to comment Share on other sites More sharing options...
anon1 Posted September 21, 2017 Share Posted September 21, 2017 - Link to comment Share on other sites More sharing options...
kirkt Posted September 21, 2017 Author Share Posted September 21, 2017 Makes sense. Kirk Link to comment Share on other sites More sharing options...
kirkt Posted September 22, 2017 Author Share Posted September 22, 2017 So... this issue is not a "bug" but part of a much larger problem with rendering Live Filter layers in general? I tried another edit where I added a single pixel layer on top of the layer stack described above and flattened - after almost 3 minutes of churning on all cores and making the fan in my laptop work at full throttle I had to abort and kill the application. This is a real problem that will hopefully get addressed and solved - otherwise building a non-destructive workflow around Live Filters is a waste of time. Live Filter layers are basically similar to nodes in a node-based editor live Resolve, right? kirk Link to comment Share on other sites More sharing options...
Recommended Posts