Bug 517862 - Poor rendering of JXL thumbnails in general thumbnails view.
Summary: Poor rendering of JXL thumbnails in general thumbnails view.
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Plugin-DImg-QImage (other bugs)
Version First Reported In: 9.0.0
Platform: Debian stable Linux
: NOR minor
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2026-03-19 20:53 UTC by Alain60
Modified: 2026-03-27 17:13 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In: 9.1.0
Sentry Crash Report:


Attachments
screen capture of 3 thumbnails of the same image in DNG, HEIF and JXL formats (435.93 KB, image/png)
2026-03-19 20:53 UTC, Alain60
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alain60 2026-03-19 20:53:01 UTC
Created attachment 190828 [details]
screen capture of 3 thumbnails of the same image in DNG, HEIF and JXL formats

SUMMARY
Poor rendering of JXL thumbnails in Album thumbnails view.

STEPS TO REPRODUCE
1. Open digiKam and display images of an Album in "Thumbnails" view mode
2. Observe the definition of differents thumbnails of the same image encoded in differents formats, among which JXL

OBSERVED RESULT
JXL thumbnail is very poorly definied compared to other thumbnails.

EXPECTED RESULT
JXL thumbnail should have the same definition as other image formats

SOFTWARE/OS VERSIONS
digiKam: 9.0.0
KDE Frameworks: 6.20.0
Qt: Using 6.10.1 and built against 6.10.1
Debian GNU/Linux 13 (trixie) (Xcb)
Build ABI: x86_64-little_endian-lp64
Kernel: linux 6.5.0-0.deb12.4-amd64

ADDITIONAL INFORMATION
Comment 1 caulier.gilles 2026-03-20 02:02:53 UTC
A quick test with digiKam 9.0.0 under macOS using editor, to convert HEIF to JXL lossless or not, do not generate a blur thumbnail.

https://flic.kr/p/2s36avh

libjxl come from Macports and it's version 0.11.2

The JXL codec is included in the KImageFormat KDE frameworks which is the version 6.20 as you.
Comment 2 caulier.gilles 2026-03-20 02:06:07 UTC
Q: how did you generate the JXL version ? Outside digiKam ? With Editor or Batch Queue Manager ? Which libjxl version did you use ? Which compression level ?
Comment 3 caulier.gilles 2026-03-20 02:19:09 UTC
JXL issues from KImageFormat KDE component :
https://bugs.kde.org/buglist.cgi?bug_status=RESOLVED&classification=Frameworks%20and%20Libraries&product=frameworks-kimageformats&query_format=advanced&short_desc=XL&short_desc_type=allwordssubstr

Q : Can you reproduce de bug with Gwenview which use the same JXL codec ?

Can you reproduce the issue using the Linux digiKam AppImage bundle that we provide :

https://files.kde.org/digikam/
Comment 4 Maik Qualmann 2026-03-20 05:24:18 UTC
Without a sample image, it's impossible to reproduce here. I suspect that the JXL image only contains a very small thumbnail or preview image, which is then used for the digiKam thumbnail.

Maik
Comment 5 Alain60 2026-03-21 22:15:08 UTC
Here is my process and results :
1) create B517862-original.jxl from original raw file with ART raw editor.
 → thumbnail is perfectly viewed in digikam
2) (fake) edit this image with dgk internal editor
 → result saved as lossless file "B517862-dgk_internal_editor.jxl" (note how big the file has grown !)
     thumbnail is very blurred viewed in digikam
3) use `exiftool -exif:all= -iptc:all= -xmp:all= B517862-dgk_internal_editor.jxl` to create a metadata stripped copy from dgk editor's output
 → "B517862-stripped_metadata_copy_by_exiftool.jxl" has a perfect thumbnail viewed in dgk !

Here is a link to a .zip file containing the 3 files.jxl + thumbnails screen capture:
https://jottacloud.com/s/43854c01d8bea7c403aba63cb52771602cf

This bug is driving me nut !
Could it be an crooked initial analyse injected in dgk thumbnail's database ?
Comment 6 Maik Qualmann 2026-03-22 06:00:43 UTC
Based on your screenshot, I suspect you're using a 4K resolution and therefore very large thumbnails.

The digiKam image editor creates an Exif thumbnail of approximately 160 pixels so that thumbnail creators (also in other programs) can generate a thumbnail more quickly. With a 4K resolution, this is obviously insufficient, as twice the pixel size is required for display.

Maik
Comment 7 Maik Qualmann 2026-03-22 06:55:32 UTC
Git commit cf5f4e2ee6c1763f718afa473b6ed21701363644 by Maik Qualmann.
Committed on 22/03/2026 at 06:54.
Pushed by mqualmann into branch 'master'.

check the size of the embedded preview for a thumbnail
FIXED_IN: 9.1.0

M  +1    -1    NEWS
M  +15   -0    core/libs/threadimageio/thumb/thumbnailcreator_engine.cpp

https://invent.kde.org/graphics/digikam/-/commit/cf5f4e2ee6c1763f718afa473b6ed21701363644
Comment 8 Alain60 2026-03-22 20:44:47 UTC
(In reply to Maik Qualmann from comment #6)
> Based on your screenshot, I suspect you're using a 4K resolution and
> therefore very large thumbnails.
> 
> The digiKam image editor creates an Exif thumbnail of approximately 160
> pixels so that thumbnail creators (also in other programs) can generate a
> thumbnail more quickly. With a 4K resolution, this is obviously
> insufficient, as twice the pixel size is required for display.
> 
> Maik

My screen is 1920x1200. The screenshot I made was with 512 pixels thumbnails for clarity.
I normally use ± 340 pixels, so I have 5 images per line.
Comment 9 Alain60 2026-03-22 20:47:36 UTC
(In reply to Maik Qualmann from comment #7)
> Git commit cf5f4e2ee6c1763f718afa473b6ed21701363644 by Maik Qualmann.
> Committed on 22/03/2026 at 06:54.
> Pushed by mqualmann into branch 'master'.
> 
> check the size of the embedded preview for a thumbnail
> FIXED_IN: 9.1.0
> 
> M  +1    -1    NEWS
> M  +15   -0    core/libs/threadimageio/thumb/thumbnailcreator_engine.cpp
> 
> https://invent.kde.org/graphics/digikam/-/commit/
> cf5f4e2ee6c1763f718afa473b6ed21701363644

Thank you for your intervention in the code.
I'll check in version 9.1.0, also in logs.
Comment 10 Alain60 2026-03-27 17:13:28 UTC
Bug fixed in 9.1.0
Thank you Maik and all the team.