Bug 403267 - digiKam is not reading tags from DNG images when sidecars are present
Summary: digiKam is not reading tags from DNG images when sidecars are present
Status: RESOLVED NOT A BUG
Alias: None
Product: digikam
Classification: Applications
Component: Metadata-Sidecar (show other bugs)
Version: 6.0.0
Platform: Microsoft Windows Microsoft Windows
: NOR minor
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-16 11:52 UTC by Steve Franks
Modified: 2021-09-12 01:00 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 7.3.0


Attachments
attachment-32559-0.html (1.81 KB, text/html)
2019-01-16 17:00 UTC, Steve Franks
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Steve Franks 2019-01-16 11:52:40 UTC
SUMMARY
Digikam is not reading tags from (some) DNG images created by my Samsung GX10

STEPS TO REPRODUCE
1. Read metadata from _G103233.dng (https://1drv.ms/u/s!AvrLvU0ceGHjg4oEaNFkH2SnDHRGfA) it's too big to attach.
2. In digikam 6.0.0 Beta3 reread metadata from file
3. Display files with No Tags 

OBSERVED RESULT

_G103233.dng is in Album with no tags
EXPECTED RESULT

_G103233.dng shown with tags from image, or accompanying .xmp
SOFTWARE/OS VERSIONS
Windows: 10 Home 10.0.1734
MacOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION

Dell G3 laptop X64-based with Intel Core i7-8750H cpu, 16gb ram, 500gb SSD 172gb free.
Comment 1 Maik Qualmann 2019-01-16 13:26:38 UTC
No bug, an unfavorable situation. The tags are in the image and not in the sidecar. If you disable the reading of sidecars, the tags are displayed correctly. The problem is that with activated reading of sidecars this priority has. If an entry in the sidecar does not exist, it must be assumed that it has been deleted, and therefore is not displayed, even if it is present in the image.

Maik
Comment 2 Steve Franks 2019-01-16 17:00:50 UTC
Created attachment 117492 [details]
attachment-32559-0.html

Thanks. If I disable reading from sidecars won't that affect other RAW
formats like NEF, RW2 & ORF, that I use?
Regards
Steve

On Wed, 16 Jan 2019 at 13:26, Maik Qualmann <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=403267
>
> Maik Qualmann <metzpinguin@gmail.com> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |metzpinguin@gmail.com
>
> --- Comment #1 from Maik Qualmann <metzpinguin@gmail.com> ---
> No bug, an unfavorable situation. The tags are in the image and not in the
> sidecar. If you disable the reading of sidecars, the tags are displayed
> correctly. The problem is that with activated reading of sidecars this
> priority
> has. If an entry in the sidecar does not exist, it must be assumed that it
> has
> been deleted, and therefore is not displayed, even if it is present in the
> image.
>
> Maik
>
> --
> You are receiving this mail because:
> You reported the bug.
> You are on the CC list for the bug.
Comment 3 caulier.gilles 2020-08-01 15:48:55 UTC
digiKam 7.0.0 stable release is now published and now available as FlatPak:

https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/

We need a fresh feedback on this file using this version.

Thanks in advance

Gilles Caulier
Comment 4 caulier.gilles 2020-12-28 10:34:16 UTC
Git commit 86f907da7edaa01bbb519ddd1da871ac65b773f6 by Gilles Caulier.
Committed on 28/12/2020 at 10:32.
Pushed by cgilles into branch 'master'.

Update internal Libraw to last 0.20.2 to imporve metadata extraction from Exif and Xmp
https://www.libraw.org/news/libraw-0-20-2-Release
Related: bug 426923, bug 320039

M  +1    -0    NEWS
M  +39   -0    core/libs/rawengine/libraw/Changelog.txt
M  +3    -3    core/libs/rawengine/libraw/libraw/libraw_types.h
M  +1    -1    core/libs/rawengine/libraw/libraw/libraw_version.h
M  +12   -2    core/libs/rawengine/libraw/samples/dcraw_emu.cpp
M  +1    -1    core/libs/rawengine/libraw/samples/raw-identify.cpp
M  +7    -2    core/libs/rawengine/libraw/src/decoders/kodak_decoders.cpp
M  +2    -1    core/libs/rawengine/libraw/src/decoders/unpack_thumb.cpp
M  +5    -2    core/libs/rawengine/libraw/src/libraw_datastream.cpp
M  +1    -1    core/libs/rawengine/libraw/src/metadata/identify.cpp
M  +2    -1    core/libs/rawengine/libraw/src/metadata/makernotes.cpp
M  +34   -32   core/libs/rawengine/libraw/src/preprocessing/raw2image.cpp

https://invent.kde.org/graphics/digikam/commit/86f907da7edaa01bbb519ddd1da871ac65b773f6
Comment 5 caulier.gilles 2021-05-13 08:00:09 UTC
Maik,

Following the Q from Steve at comment #2, We need to give a response.

For me, DNG + sidecar are not management differently than RAW + sidecar. If yes, this state is not necessary as DNG is a TIFF/EP pure compliant which is perfectly supported for writing operation by Exiv2. It's not a read only RAW format.

Also, later 7.3.0, ExifTool will help us to write metadata in RAW file. So the necessity tio use exclusively a sidecar with RAW files will become a past. Of course, ExifTool do not support all RAW formats in writing mode, but at least all major. And yes, not all users want to touch the RAW files, so the option to support sidecar with RAW must still available for ever...

Gilles
Comment 6 Maik Qualmann 2021-05-13 08:35:55 UTC
Hmm, this problem doesn't necessarily have anything to do with DNG or RAW. It would also occur with JPG, if a sidecar is used, it has priority over the metadata in the image. The behavior is correct, otherwise Sidecar metadata would not work.

Maik
Comment 7 caulier.gilles 2021-05-13 14:18:44 UTC
So, you are right. The behavior is fine.

I close this file now.