The Thumbnail Problem

[meteorquake]

None of the rival formats (jxl, webp, avif...) come close to jpeg(li) in ability to show thumbnails at high speed. It's literally for me a huge problem because I have half a million botanical photos and constantly view and move large numbers of them about, using voidtools Everything or external scripts, which means jpegli seems preferable to jxl when in other ways jxl is preferable. There's no tool that is a substitute for Everything for my purposes. Sometimes thumbnails get slow and the thumb cache needs deleting. Sometimes I'll need to glance over 10000 photos and obviously can't wait for them to generate.

I don't know if anyone has a good solution to this other than sticking with jpegs.....

[jkm]

You're talking about browsing in XnViewMP, right?

I did some tests at one point, when I was configuring the app, and I seem to recall that using webp for thumbnails was a little bit faster than using jpeg.

Have you actually timed both settings on the same folder?

[meteorquake]

For me webp plods slowly along one by one (likewise jxl), jpeg shows hundreds of thumbnails extremely fast (despite being new files not previously seen), so there's no need to do any actual timing...
I don't have an issue with using jpegli instead of webp, the main thing is that the preferred option of jxl is impacted by this general situation.

[jkm]

What size do you have thumbnails set to? It sounds like you’re using the embedded jpeg thumbnail, which will render instantly. All other formats have to actually be created. If you make your thumbnail size larger and turn on the option to create thumbnails from the source image, then the larger jpeg thumbnails will also have to be created, and you will see the times equalize.

And are you caching thumbnails in the catalog? You don’t say.

[meteorquake]

Yes, that's what's at stake. JPEG is fast because of embedded thumbnails, which is something other formats cannot match because they have to read the actual file data (which even for progressive files is slow).
I was wondering if there is a way of resolving this slowness for jxl particularly given I move a lot of files around, even if it means the ability to create a custom meta tag with the thumbnail...

[jkm]

In my view, there is no “slowness” to resolve. When you’re using embedded thumbnails, the computer isn’t creating a new image, and for other formats it has to. It’s zero work vs some work. Some work takes longer than zero work.

If you browse images with embedded webp thumbnails, then you would see webp as the fast format.

Really, your complaint lies with the files you are browsing, not the software.

If you want jxl to be “fast” with instant thumbnail display, just browse images that have embedded jxl thumbnails.

I don’t have any of those. Cameras create jpeg and raw images with embedded thumbnails that are in jpeg format.

Perhaps someday a desktop computer will be fast enough that it can scale and render an image in a new format in a millisecond, and then it will seem instant.

[meteorquake]

I would happily have jxl files with embedded thumbnails but neither XNView nor Irfanview provides such an option to, and when I asked Gemini it said there is no standard facility since it was expected images would be viewed by decoding the image data, which is what makes it slow.
Unless someone can suggest how to get thumbnails into jxl...
This is why I'm asking how to make thumbnails workable through some means, in the scenario where files are constantly moving around.

[meteorquake]

I think the XNView side could be resolved by saving thumbnails not against file path but against "(drive-)modified-size" combination or "unique file number" as the thumbnail key so that the thumbnails are immune to moves. Obviously to use modified-size it would be up to the user to avoid a combination of settings whereby saves were performed without updating the timestamp that also didn't alter the size (such as changing a PNG from entirely red to entirely blue with no modified date change), it would need to "poke" the timestamp by a tick on the filesystem concerned in order to achieve that so that the modified was changed but not from a human perspective.

[user0]

1.9.5: Slow rendering speed of JXL images
0.89 - 1.9.5 Selecting a large image in the browser is very slow
jxl, jpegli are slower to decode than jpg

[meteorquake]

Yes that's the case. The post is about how to circumvent the problem.
I think a change of key strategy on the thumbnail catalogue is the best solution, I'll post it up as a suggestion.