DT 4.6.0 - full preview lighttable mode is sometimes slow (forces a full pixelpipe cycle)

[vancouverbluesea]

Describe the bug

When I am browsing in full screen non processed images only - DT 4.6 appears to be noticeably slower than DT 4.4

• The issue is observed only with files that are not processed
• If the files are already processed - I don't think I am observing the issue
• The issue is only observable when browsing in full screen. https://discuss.pixls.us/t/darktable-lighttable-4-6-slow/41156?u=vbs

Steps to reproduce

1. The behavior can be seen easier if the images are located on a slower drive - like a network drive.

Set lighttable thumbnails as below

1. use raw file instead of embedded JPEG from size = never
2. high quality processing from size = always
3. enable disk backend for thumbnail cache = yes
4. enable disk backend for full preview cache = yes
5. generate thumbnails in background = 4k

Expected behavior

when using full screen preview - the preview should load fast - because backend cache is enabled

Logfile | Screenshot | Screencast

No response

Commit

No response

Where did you obtain darktable from?

downloaded from www.darktable.org

darktable version

4.6.0

What OS are you using?

Linux

What is the version of your OS?

PopOS 20.04

Describe your system?

Are you using OpenCL GPU in darktable?

Yes

If yes, what is the GPU card and driver?

Nvidia RTX 2070 8GB

Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip

No response

[vancouverbluesea]

Providing darktable -d common dcomon.txt

[gi-man]

Please a txt file or pastebin. This is unreadable.

[vancouverbluesea]

Please a txt file or pastebin. This is unreadable.

Sorry - edited the comment and attached .txt

[gi-man]

From the conversation on Pixls.us, it looks like dt is doing what it is supposed to do. You triggered a change to the processing of the image (#11 Color Calibration), so the image has to be processed instead of using the embedded jpg.

[vancouverbluesea]

I am not sure I understand the logic.

• The top image is processed - indicated also by the +/- sign - these type of images load fast when previewed in full screen.
• The bottom image is not processed - indicated by the lack of +/- sign - this type of image loads slow in full screen

One would expect that once the thumbnails are generated - the program would read the thumbnails because they are cached.

Based on what I am seeing in the behavior when displaying on the screen and the network load - I strongly suspect that

• when the program displays processed images (like the top one) it does utilize the backend cache (in full screen mode) - this is as expected
• when the program displays not processed images (like the bottom one) it does not utilize the backend cache - this is not expected because the cache exists (I can find the cache by using the image ID) and also the cache is at sufficient size - level 6 is enough to display a full screen view on a 2k monitor - yet - these type of images contribute to a noticeable network load and also significant delay when displaying on the screen (compared to the processed images)

Further - to my understanding - (https://github.com/darktable-org/darktable/pull/11 Color Calibration) is invoked at first opening on the image in dartkable for processing (not at the time of adding to the library).

Is there anything that I am misunderstanding?

[wpferguson]

The cache contains different size previews for different purposes. If you have an HD (1920 px wide) then a size 2 thumbnail is generated (or retrieved from the raw) on import. If you do a full screen preview, a size 4 thumbnail is required. If it doesn't already exist, then it has to be retrieved from the raw (fast) or generated by the pixelpipe (slow).

I have a 4K screen. I have a Canon R7. The lighttable preview requires a size 3 thumbnail which is embedded in the raw file. The full screen preview requires a size 6 thumbnail. Size 3 is the largest preview included in the raw file, so the raw file has to be loaded and a preview image generated for size 6.

You can enable preferences->lighttable->generate thumbnails in background to automatically generate a full thumbnail set so that full size preview is more responsive.

[vancouverbluesea]

I thought I already did that. Backend cache is enabled Also - it is enabled for full screen preview The thumbnails are generated - I can see them.

Is there anything else that I am supposed to set but I missed them? Or is there anything that I have set incorrectly?

[gi-man]

On the second image, when you go to full preview and back to file manager, does it display the edit symbol?

[vancouverbluesea]

No - it does not. Even if I open it in darktable and go back to lighttable - without any change - it won't display the edit symbol +/-

But

• if I am to have a minimum edit - exposure from .700 to .701 - then the edit will be noticed

• if I make the duplicate and one is edited as above the other is not - they are different So - the edit is registered only after I consciously change a setting.

• left - unchanged (uses the embedded JPG)

• right - changed exposure and then reset the exposure to default - the edit is registered. This is expected and we can see it both in the +/- icon and also in the actual color of the image (uses the RAW to produce the processed image)

[jenshannoschwalm]

You say "never" process thumbs using raw file. That doesn't make any sense - at least for me - if you want to view on a 4k monitor. The thumbs available in the raw file are mostly pretty small -- thumbnails. I don't fully remember exactly how mipmap images are generated but i think that resizing will be suboptimal also for performance.

[vancouverbluesea]

Reading the manual https://darktable-org.github.io/dtdocs/en/preferences-settings/lighttable/

It says

use raw file instead of embedded JPEG from size When generating thumbnails for images that have not yet been processed in the darkroom, if the thumbnail size is greater than this value, generate it by processing the raw image data. If the thumbnail is below this size, use the JPEG preview image embedded in the raw file. Once an image has been processed in the darkroom, thumbnails will always be generated from raw data (you can revert back to the JPEG preview by discarding history). To render thumbnails with the best quality choose “always”.

Further - when I am to click on the drop down I am getting the following

If the embedded .JPG is unable to produce 4k image (because it is smaller) what does the option mean?

Then if the 3 options are selected And level 6 cache is successfully generated

• Where is DT expected to take the picture from to display on full screen?
• Is there a difference where DT takes the picture from depending if the image is processed or not processed?

Last but not least. Why did the performance degraded after the upgrade 4.4 to 4.6? I do not recall observing issues in 4.4 and have been keeping the same workflow for a while.

Processed or not processed - 4.4 had the same performance. But in 4.6 there is a difference.

[jenshannoschwalm]

ok, i checked - you can do so by using -d lighttable -d pipe btw.

Indeed - absolutely not depending on thumbs taken from raw or embedded jpegs - i can reproduce the lag. This may happen if the darktable window size you are using while watching does not "match good" the precalculated mipmaps and thus forces a pipeline process. This is certainly new in dt 4.6 and the result from how we visualize the data on the window.

Will put this on the bug pending list we should fix for 4.8 (not sure how to do that correctly atm) @dterrahe will know :-)

EDIT: missed to ask for a) monitor resolution and b) any internal (gnome) scaling.

[vancouverbluesea]

Thank you. Is there anything that I can do currently to improve the experience?

Missed the resolution question. This is the 2k screen. Sometimes I do switch to 4k (different monitor).

[sg456]

I'm a bit late to the discussion here - I'm seeing the same thing on 4.6, also 4.5.0+1401~gc2455d4619 Running on windows 11 Pro 21H2, GTX1650, 16GB ram, i5-2400, cheap SSD main drive.

You say "never" process thumbs using raw file. That doesn't make any sense - at least for me - if you want to view on a 4k monitor. The thumbs available in the raw file are mostly pretty small -- thumbnails.

FWIW, my Nikon .nef files have what appears to be a full res, highly compressed jpg embedded, which (on 4.4.2) works perfectly for quickly culling images without waiting for dt to produce previews. 2560x1440 (2k) screen here too.

[jenshannoschwalm]

Thank you. Is there anything that I can do currently to improve the experience?

Unfortunately i don't think so. You might change the issue title to "full preview lighttable mode is sometimes slow (forces a full pixelpipe cycle)" :-)

[vancouverbluesea]

I can observe it also on a 4k If I am understanding correctly - slowdown can be about 10x

773.8686 dt_dev_pixelpipe_synch_all [thumbnail] defaults 0.0443s, history 0.0046s 773.9282 [dt_view_image_get_surface] id 203894, dots 3764x1986, mip 3840x2560, surf 2979x1986 773.9364 done in 0.0051 sec 774.0015 done in 0.0621 sec 774.0512 done in 0.0488 sec 774.1008 done in 0.0488 sec 774.1239 done in 0.0224 sec 774.1488 done in 0.0242 sec 774.1736 done in 0.0242 sec 774.2355 done in 0.0611 sec 774.2836 done in 0.0476 sec 774.3370 done in 0.0529 sec 774.3855 done in 0.0478 sec 774.4373 done in 0.0511 sec 774.4846 done in 0.0465 sec

[gi-man]

Thank you. Is there anything that I can do currently to improve the experience?

I dont experience any issue with these settings:

[vancouverbluesea]

I dont experience any issue with these settings:

Thank you! I can try modifying mine. But this one

use raw file instead of embedded JPEG from size

can be a challenge because I normally like to see the image as processed by the camera. Even when in fact I am not trying to replicate it - it helps me recall what I liked (or disliked) at the time of the shot.

always

effectively ignores the embedded JPG

[jenshannoschwalm]

I dont experience any issue with these settings:

I didn't either see problems with these, i had to use some other window proportion like large width & small height.

[vancouverbluesea]

I didn't either see problems with these, i had to use some other window proportion like large width & small height.

It maybe worth it to describe what I do and why I do it. Maybe not everybody has the same approach.

• I work with folders and these folders are with significant amount of pictures. Typically more than 2k but very often 5k to 10k
• After processing I am left with 5% to 10% of the initial amount of pictures. So - a significant number does not get processed and kept
• When processing the images I typically work in batches of few hundred. I would open then in full screen then move through them in a rather rapid approach color coding what is considered for processing. This is the step where the system chokes because I am trying to assess few hundred images - in full screen in a minimum amount of time.
• Once the selection is done I work on the sub set - culling if needed, processing and rejecting what is not needed. This step can also include full screen viewing but is less intensive than the previous so even if the issue is present the effect is less.

I tried what @gi-man suggested.

• My experience is that full screen (that is level 6 if I understand correctly) was not pre generated.
• However - once the picture is generated in full screen - then it is fast to be observed.
• This does not work very well for me in terms - I don't have the big previews pre generated so they are ready when I am to start work.
• Tried to change

generate thumbnails in background

to 4k - everything else left as per the suggestion from @gi-man but the issue re appeared.

• Checked some older collections with processed images - mostly previewed faster on a full screen - less than 500. While another that is more than 500 had some slow downs but not as significant as the one I am working on (several thousands and many are not processed).
• I did not have to scale the window up or down to see the issue. DT is occupying the whole screen and some times I press F11 to completely maximize it.
• The system has sufficient amount of memory - 64 GB but I can't see a big hit on it. I am using about 20 GB and this is already with a browser and mail running together with DT.

[jenshannoschwalm]

It's really not helping to describe again. Already understood what goes wrong, just not top priority atm.

[wpferguson]

It maybe worth it to describe what I do and why I do it. Maybe not everybody has the same approach.

I shoot sports. My workflow is similar to yours in that I shoot thousands of image at an event and need to be able to cull through them quickly. To solve the image cache problem I wrote a lua script, import_cache.lua, that generates thumbtable and full preview cache after importing. You can also build cache images for a collection or selection by assigning a shortcut.

I've attached the script. Just unzip it and drop it in your ~/.config/darktable/lua/contrib directory. Start it, configure it, then import some images.

Here's my lighttable thumbnail configuration

Here's the lua options configuration

and here's the script

import_cache.zip

[jenshannoschwalm]

Got it after some investigation. Indeed we had a problem in the backthumbs crawler if history was deleted for an existing image.

[vancouverbluesea]

I believe I am still experiencing issues with 4.8.1 Can we please re visit this issue? https://discuss.pixls.us/t/darktable-troubleshooting-cache-speed/44858/9