The black patch, including the horizontal white lines, is the result of moving the indicated (highlights) slider. The gradient is rotated, so that only the lower part of the image should be affected. Technically, no change should occur above the upper feather line of the gradient mask …
With the highlights slider at zero, there is a (sun) blown circle, as shown below. The black patch appears gradually with the increase in highlights brillance …
No parametric masks were used here, only one gradient, but good to know …
If I use (additionally) the luminance slider in 4ways tab, the effect is much smaller, even if I go beyond 20% …
You can find as @kofa said an extensive discussion of the brilliance issue… The other thing to try is what if you zoom to 100 percent… DT previews are sometimes inaccurate when zoomed out… does that end up making the math more accurate for the mask…
Maybe it also applies to drawn masks. Not sure about gradients. When I encountered it, feathering was definitely involved. There’s an open bug on Github, but the issue is quite difficult to diagnose, it seems.
The 20% is a limitation of the underlying maths, accordingly to the module’s author; it’s not a bug in the usual sense.
Just one detail, that 20% limit is for the combined brilliance added in the highlights, the “global brilliance” and “midtones” can contribute as well (with the same effect).
Oh, I thought we were talking about the 4 “brilliance” sliders.
The luminance control is a different beast. “Brilliance” has different math which can really make the brightness of the pixels shoot off to infinity (or thereabouts).
Yep, I agree. Now to figure out what that limit is…:
if you use a negative global brilliance, you can push the highlights well over 20%, as the effects of the four sliders combine. The inverse is true as well. E.g. +60% on global brilliance, with -60% on highlights causes no problems whatsoever…
So limiting each slider to 20% would be limiting in other ways as well.
Its hard to say…both this issue and opencl code have been worked on over the last year or so and so depending on exactly which version or build of DT you have the answer might be a little different and with DT the first thing to check for with artifacts is opencl… many drivers don’t play well. Often it is found that simply updating the driver to the latest one fixes things but often not… it can just be that certain hardware combo’s just aren’t as clean as others interacting with the opencl data processing of a certain module…
Yes, this is usually so with different hardware and drivers. It may well be, that my specific graphics card/driver combination has its specifics compared to some other installation.
What I meant, is only that on my particular installation (Windows 10m, Nvidia GeForce graphics card - both up-to-date, DT4.4.2), there is no difference in the “anomaly” with OpenCL switched on or off in DT.
Because the problem is with the maths, brightness quickly explodes to infinity. OpenCL or not, the numbers will be the same (maybe the artefacts those infinite (or ‘close to infinity’ ) values trigger will be different).
) values trigger will be different).