Bug 493838

Summary: DigiKam and DNG files
Product: [Applications] digikam Reporter: Bertil Rolf <b.g.rolf>
Component: Plugin-Bqm-DngConverterAssignee: Digikam Developers <digikam-bugs-null>
Status: REPORTED ---    
Severity: normal CC: b.g.rolf, metzpinguin
Priority: NOR    
Version First Reported In: 8.5.0   
Target Milestone: ---   
Platform: Microsoft Windows   
OS: Microsoft Windows   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Bertil Rolf 2024-09-29 16:03:30 UTC 
Hello!
The DAM facilities of DigiKam are absolutely superior to those of Adobe Lightroom 5 and Adobe Bridge. Also, the speed and slide show capacities are outstanding in comparison with them.

But there is a problem about the way DK handles DNG files. I use that format to store photos in a a relative non-destructive way. 

I shoot photos using HDR which results in far too strong colors. In LR, I crop the photo, correct angles and colors. From LR, I then export a JPG file.

About DNG files, ChatGPT says: “In summary, DNG files allow the metadata to be written directly into the photo file, without the need for external XMP sidecar files, while preserving the original raw image data for non-destructive editing.”
What seems to be happening in DK, is that DK – in some cases - reads off the original raw image data and displays that image file while ignoring the metadata that had been written from Lightroom 5.

This shows in several contexts. In DK for Windows, the following happens.
1)	Optically, the DNG and JPG photos are shown the way they look in LR5.
2)	In slide shows in DK, the DNG photos are shown optically as preprocessed.
3)	If I use DK to convert DNG to JPG, the JPG photo shows the preprocessed version, ie the photo as it came out of the camera, strong colors, queer angles and no cropping.

I enclose three files in 3 formats, 3 DNG, 3 JPG exported from LR5 and 3 JPG, converted by DK.
Also, it remarkable that DK sometimes converts DNG files into JPG files much larger than the original.
—
As for wishes, my workflow would be easier if DK Batch Queue Workflow included options for a) importing files from an SD-card, b) a choice of location for storing those files (after conversion, say) and c) a choice of delete files on SD-card after import and verification of file transfer. Adobe Bridge has a corresponding set of alternatives.

I hope this helps.
Best regards
Bertil Rolf,
Baden bei Wien

PS. I will transfer a zipfile (53 MB) with 9 photo files one way or another. Here a link:
https://drive.google.com/file/d/12_q0RMDsMn1QWiJSvl1Dft8FRPXVfh6a/view?usp=drive_link

SOFTWARE/OS VERSIONS
Windows: W11

Linux/KDE Plasma: 8.5.0


ADDITIONAL INFORMATION
Comment 1 Maik Qualmann 2024-09-29 16:16:53 UTC 
In the BQM there is an option under Behavior, whether for RAW files (DNG is also a RAW file) the RAW file is decoded or the embedded preview is extracted and used. If you convert to JPG you will probably need the last option if you want to keep the crop.

The BQM is not intended to read from external media such as SD memory cards. The import tool can do all of this, specify a destination, convert to DNG and delete images after importing from the SD card.

Maik
Comment 2 Maik Qualmann 2024-09-29 18:52:52 UTC 
Yes, you could use the "Extract embedded preview (faster)" option as the image source that you use when converting DNG to JPG.

But the result is not the same - visually yes - but the JPG image would have a smaller resolution.
The reason is, LR applies the saved image processing history (Xmp metadata) and saves an edited image from the DNG as a JPG.

We can never use this process, only LR can do that.

Maik
Comment 3 Maik Qualmann 2024-09-29 18:59:13 UTC 
By the way, whether you see the embedded preview or the full DNG in the digiKam preview or slideshow depends on the view settings in digiKam. For a good view quality you should generally set it to "full image preview (automatic)".

https://docs.digikam.org/en/setup_application/views_settings.html#preview-settings

Maik
Comment 4 caulier.gilles 2025-04-11 18:13:46 UTC 
Hi,

The 8.7.0 pre-release Windows installer from today have been rebuilt from
scratch with Qt 6.8.3, KDE 6.12, OpenCV 4.11 + CUDA support, Exiv2 0.28.5, ExifTool 13.27, ffmpeg 7, all image codecs updated to last version (jxl, avif, heif, aom, etc.).

Please try with this version to see if your problem still reproducible...

https://files.kde.org/digikam/

Thanks in advance
Best regards

Gilles Caulier