Might be specific to Windows. I wonder if it’s only me…
To try to reproduce, start with no corrections, make some mask (tested with Control Point, Hue, and AI masks), set LA Clearview to 100 or 50 and then use some Selective Tones slider (Midtones and Shadows tested) to quickly change the setting, either by dragging the slider with a mouse or using mouse scroll wheel. After few tries, you may get the masked area too dark or too bright. The exports look OK, as expected. Selecting another image and going back fixes the display until next occurence. I’m not sure if Clearview setting is important here, or it just makes the problem happen more often.
My setup:
Win11pro 25H2 (26200.8246), RTX4070 (tested 595.79 and 596.36), i7-14700KF (no iGPU), 32GB RAM, 4K monitor @60Hz.
PL9.7, both ‘Viewer quality’ options enabled in Preferences → Display, ‘Windows ML Acceleration’ set to ‘Maximum performance’ (didn’t try the other setting yet), ‘NVIDIA GeForce RTX 4070 [via NvTensorRTRTXExecutionProvider v1.23.2]’ chosen, as seen in PhotoLab log. Windows Update shows the following NVIDIA TensorRT RTX execution providers installed: KB5089168 (installed automatically on 29 Apr, some time after update to PL9.7), KB5083460 (installed by PL9.7?), KB5079257 (by PL9.6?).
Here are some examples of a clear sky photo (dust spots check done in the field) with a Loupe tool used solely to demonstrate the problem – I don’t have to use the Loupe to see the problem, if it happens. Sometimes Loupe displays the right correction and normal display is “wrong”, sometimes it’s the other way around.
@Wlodek , I wonder whether it’s linked to doing LA before GA corrections.
If you do the rough stuff as GA first, then LA what’s needed and only add some fine tuning afterwards, do you see the effect too? I suppose that you do, if you push the sliders far enough.
Somehow, I got the feeling that doing GA after LA is like pulling the carpet…even though a parametric editor shouldn’t be susceptible to the order of edits. And even if the order of edits is irrelevant, because the app uses the correct sequence, the differences you see with and without loupe due to PL not doing the same math in those cases…which is highly irritating from a WYSIWYG point of view.
Can you create a partial preset with settings that reproduce the effect doubtlessly?
I’ll then try with PL7, 8 or 9 - on Mac.
Yes.
I just wanted to narrow down the problem and exclude possible GA interference.
No.
The problem seems to happen only upon fast moving/scrolling SelTones sliders and perhaps when ClearView is previously set locally. It looks like some timing issue. Often I have to try several times to reproduce it, and then just displaying another image and coming back fixes the problem. It can happen on freshly opened PhotoLab.
I came across it only recently, while redoing some old landscape photos (e.g. mountains, hills and sky) made with D700. Clearview was set globally to 0 or small value, while it was set to a large value (e.g. 50) for chosen areas, the air was “dusty”. BTW, D700 raws seem to tolerate larger Clerview values than e.g. Z8. But I’m still unsure if Clearview is important here. I’ll have to experiment with other images.
ooookay. Strange and possible nevertheless. Is there any change of pattern when you e.g. clear the cache before you do the steps? Or if you change the settings for delay and speed of repetition when holding a key (sounds eerie, but who knows)?
I’ll try PL9.8 first, which just appeared, so I’ll make an update in 1-2 days.
UPDATE: The problem is still there with PL9.8(/Win). I think I’ll escalate this to DxO. The simplest way to try to reproduce:
Take a photo of clear sky. Use RAW or JPG file.
Make a Hue mask with eyedropper (selects whole image)
Set Local Adjustments ‘Clearview Plus’ to 50.
Set display magnification to 100%.
Open the Loupe tool, also at 100%.
Move Selective Tones ‘Midtones’ few times, with varying speed and small pauses between them to wait for display update, until you see a clear Display/Loupe brightness mismatch.
Can you reproduce it?
UPDATE2:
The problem is also seen in PL8.16/Win and PL7.24/Win. In PL8/Win you can’t use Loupe together with Local Adjustments sliders and in PL7 there’s no Loupe. You can instead move the slider until you think it’s off. If e.g. the display looks too dark, use the input stepper down button to lower the setting by 1 – if the display gets brighter, you’ve hit the problem.
This thread would read far more fluently with Global Adjustments and Local Adjustments. I of course can figure it out, but even for a PhotoLab veteran like myself, it stopped me for a minute to think.
We should all probably use fewer acronyms here, to make the content more easily digestible for newer users.
By clicking on an estimated value – followed by a ‘careful’ adjustment, whether via a slider or by clicking the step increments – the content of the loupe updates correctly.
DxO said they couldn’t reproduce the problem and asked me to provide a video, which I did, using the Windows Snipping Tool. I was late replying to them, so accepting the case may take longer. Maybe the problem has something to do with the following lines in PhotoLab log (the only thing there which looks related):
DopUI - Warn | ScrollIntoView request can’t be executed: can’t find child DxO.PhotoLab.Correction.Local.ViewModel.CorrectionLayerViewModel in System.Windows.Controls.TreeView Items.Count:1
@Wolfgang – do you have anything similar in your logs (ScrollIntoView)?
In the meantime I’ve updated to PL9.8.0.671 and can still replicate this loupe preview problem. – However, I don’t see an entry from today where the (former) logs are (were ?).
Yes, I didn’t see it too on previous problem occasions, which makes this even more complex. Could be Windows issue. I’ll try to contact you tomorrow, I’m busy now.
Sometimes I get “ScrollIntoView”, but sometimes there’s nothing in the log, except for standard DB interaction every one minute.
Could be some issue with Microsoft code. I have yet to run the diagnostics exe sent by DxO, as I was too busy. Anyway I wouldn’t expect quick response.
