File browser question (curiosity, not a problem)

1.16.4 on Windows 11

As the subject line says, this isn’t a problem - I’m just curious.

When I first click on a thumbnail in the file browser (just to select, not open*), it takes a second or two before the highlight shows up on the thumbnail border and it’s visually selected. If I select another image and go back to the first, it’s instantaneous. If I go to yet another “first-time selected” image there’s a slight delay again. If I open an image in the editor and then click from image to image using the arrow buttons, the images I’ve opened are thereafter quick to select in the file browser. So thunbnails are quick after their first selection.

This happens only with raw images, though (at least my CR3). TIFs, JPGs, etc., are always quick.

I’m guessing something is initially loaded each time and thereafter cached, making it faster on subsequent selections. The “caching” doesn’t persist between sessions, though. I wouldn’t think the actual thumbnail image is the culprit since it’s already loaded. EXIF should be quick to retrieve, right? Or is something like exiftool / exiv2 being invoked each time?

* The only actual functional impact is when I open an image for the first time. Simply double-clicking doesn’t initially work, since apparently the first-time delay blocks the second half of the double-click. I have to select, wait briefly, then double-click. Hardly the end of the world, though. :wink:

But that said, if there’s something I have sub-optimally configured and it can be ‘fixed’, please let me know. Maybe it’s possible to enable caching of whatever’s being loaded…?

My laptop isn’t a fire-breathing graphics dragon, but it’s a pretty new machine with an 8-core AMD Ryzen 7 5700U, an AMD Radeon Vega and 16 GB RAM. So (other than the cheesy little GPU it has), it’s quick enough for most work.

Thanks.

Maybe you have lazy updates :slight_smile:

I don’t know what the lazy caching does and I suspect it to be only relevant when entering new folders, but simply try it. There is also an option in pref > file browser “showing embedded jpeg as thumbnail…” you could try. You might need to delete/rebuild the cache for this option to take effect. A little further down on the same page. I don’t have this delay, all my options are pretty much default.

A funny thing: Be sure there is no compatibility mode set for ART.exe in Windows… I once had that for DT and wondered why its browser was so laggy until I accidentally found out. :man_facepalming: No idea why it was activated. Maybe there was a crash and Windows did some “problem solving”. :man_shrugging:

Actually I do… :grin:

image

I don’t know for sure what it does but ISTR in other apps similar features allowed folder contents to populate “unthumbnailed” (with a generic icon, etc.) for a moment or two while the thumbnail population caught up rather than wait on each individual image and cause delays. But there’s already a setting for that, so I dunno… Maybe @agriggio can help clarify.

There’s this:

image

But I like the idea of that, which is the same way darktable works.

I’m fully “incompatible”! :slight_smile:

At any rate, I tried toggling all these options (restarting in between) and it made no difference. It’s no biggie, just a curiosity.

Thanks.

I really didn’t know either but it seemed like a funny suggestion and appropriate for a slow down :slight_smile:

I found only one post referencing Lazy Caching and it was just Alberto recommending someone disable it (and another option) to work around a particular issue.

No further enlightenment… that’s me, searching for enlightenment!! LOL :smiley:

It might be exiftool – on windows it’s particularly expensive to run. You can try disabling it by clearing “Preferences → Image Processing → Exiftool command” and see if that makes a difference.
Normally exiftool is run only as a fallback if exiv2 can’t decode the metadata properly. If this happens, maybe you can share one of your raw files so I can take a look…

Oh, I can reproduce, but only with CR3.

You can see ARW and NEF are selected instantly, CR3 with lag.

Didn’t recognize as those are not my own photos… So, just switch your camera system :+1:

most likely this is exiftool – I have to investigate why it gets called, maybe I miscompiled exiv2

Yeah, exiftool is Perl, right? That means it’s gotta compile to bytecode first (IIRC) and that’s slow on Windows. Anyway, without it there’s no EXIF at all - Zilch. Several images remained black in the browser until I deleted all sidecars, now they’re OK - Just no EXIF.

Here’s a sample CR3:
Uploading: IMG_1692.CR3…

Thanks.

Check’s in the mail, I presume? :rofl:

Maybe… we see what Alberto will find out first :upside_down_face:

Gaaned’s build doesn’t lag, which I guess confirms Alberto’s suspicion.

I’m not sure it’s because it’s Perl or simply because spawning subprocesses is slow on windows – or a combination of both. Anyway:

ok, so I might have miscompiled exiv2. I’m rebuilding right now, let’s see…

I have uploaded a new version of the windows installer (1.16.4.1, just to distinguish it from the previous one), hopefully it fixes the problem…

It does for me. Thanks :+1:

Unchanged here (no EXIF), but I’m not sure if all went properly.

I downloaded this…
image

…which is this…
image

…and says this in Control Panel…

But when I run it, Preferences | About | Version says this…
image

I don’t know if the missing minor number matters, but the commit date is two weeks ago…

???

I totally uninstalled / reinstalled, too.

Did you revert your config? (I mean the Exiftool command)

Also, did this version pick up the other things you’ve changed (e.g., single click folders, etc.) or is that a different branch? No change on that, either.

I left the exiftool field empty, so exiv2 will do it instead…

Wait a minute, this is weird. I’m getting EXIF in some folders, but not in the one I was testing. Let me poke around and report back…

OK, so apparently I had to clear cache One More Time… working now. Weird but I’ll take it. It’s also recognizing my Sigma lens properly now! Woo Hoo! I assume the other commits are a different branch which will make it into the next “full” release.

Thanks for the assist.