[digikam] [Bug 347737] New: Tagged RAW files do not show tags after round trip to RawTherapee

[Eric Mesa]

https://bugs.kde.org/show_bug.cgi?id=347737

--- Comment #20 from Eric Mesa <[hidden email]> ---
(In reply to Alan Pater from comment #19)

> 1st: It has nothing to do with RawTherapee as the XMP data was written to
> the Exif section of the CR2 image by libkexiv2 via digikam. RawTherapee
> carried over that data unchanged to the JPG.
>
> 2nd: This is why it is labelled experimental. For CR2 images, the correct
> workflow is to allow digikam to only write to XMP sidecar files. Then once
> you have converted to JPG, import the XMP metadata from the sidecar file.
>
> 3rd: There has been some work on improving RAW file support in exiv2, but it
> is not yet complete. This includes reading from Exif.Image.XMLPacket.

I wouldn't mind changing it to XMP sideca (or maybe sidecar+file?), but does
the same workflow hold for DNG files? Because I know that I had the same thing
happen with a DNG file as with a CR2 file. (In other words, the data was not
read in exiv2 after the JPEG was made).

The reason I ask is that, at this point with how good support is across the
board for camera raw files, the only real reason for me to convert to DNGs is
to take advantage of being able to store metadata within the file rather than
in a sidecar file. Otherwise, RawTherapee, Digikam, etc can all read the CR2
file and it works just fine for archival purposes - my descendents will most
likely be able to find a converter and/or the most important files will most
likely have been made into JPEGs anyway. So, should I be able to save this data
to the DNG and expect the resultant JPEG to be read by Exiv2?

That said, I understand this is all FLOSS software done by volunteers. I'm not
trying to be entitled or whatever. I'm just trying to understand the
anticipated workflow as well as bugs to be filed/versions to wait for to expect
the functionality.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Alan Pater]

https://bugs.kde.org/show_bug.cgi?id=347737

--- Comment #21 from Alan Pater <[hidden email]> ---
DNG support XMP directly, which is one of it's advantages.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Eric Mesa]

https://bugs.kde.org/show_bug.cgi?id=347737

--- Comment #22 from Eric Mesa <[hidden email]> ---
(In reply to Alan Pater from comment #21)
> DNG support XMP directly, which is one of it's advantages.

Sure, but it's still having the same issues as the CR2 file. At least in this
context.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=347737

--- Comment #23 from Gilles Caulier <[hidden email]> ---
Alan,

> 1st: It has nothing to do with RawTherapee as the XMP data was written to
> the Exif section of the CR2 image by libkexiv2 via digikam. RawTherapee
> carried over that data unchanged to the JPG.

no. digiKam or libkexiv2 do not force to play directly with
Exif.Image.XMLPacket. I just grep in code to see if Exif.Image.XMLPacket is
used somewhere, and it appear only in digiKam tiff loader for image editor.
This have nothing about this entry.

Typically, digiKam as to Exiv2 (through libkexiv2) to fill Exif, IPTC and XMP.
Exiv2 must decide where tags must be handle (in this case at Exif, or Xmp
section)

The CR2 Raw file can not store XMP value to a dedicated sub container (section,
chunk) as it's do with JPEG or PNG. After all CR2 are TIFF, and there is not
size limitation as JPEG to host data.

Gilles

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Eric Mesa]

https://bugs.kde.org/show_bug.cgi?id=347737

--- Comment #24 from Eric Mesa <[hidden email]> ---
(In reply to Gilles Caulier from comment #23)

> Alan,
>
> > 1st: It has nothing to do with RawTherapee as the XMP data was written to
> > the Exif section of the CR2 image by libkexiv2 via digikam. RawTherapee
> > carried over that data unchanged to the JPG.
>
> no. digiKam or libkexiv2 do not force to play directly with
> Exif.Image.XMLPacket. I just grep in code to see if Exif.Image.XMLPacket is
> used somewhere, and it appear only in digiKam tiff loader for image editor.
> This have nothing about this entry.
>
> Typically, digiKam as to Exiv2 (through libkexiv2) to fill Exif, IPTC and
> XMP. Exiv2 must decide where tags must be handle (in this case at Exif, or
> Xmp section)
>
> The CR2 Raw file can not store XMP value to a dedicated sub container
> (section, chunk) as it's do with JPEG or PNG. After all CR2 are TIFF, and
> there is not size limitation as JPEG to host data.
>
> Gilles

Yes, but in this example the CR2 is a bit of a red herring as it's not working
on DNG either and that's supposed to work fine with XMP.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Eric Mesa]

https://bugs.kde.org/show_bug.cgi?id=347737

--- Comment #25 from Eric Mesa <[hidden email]> ---
DNG file with same issues:
https://www.dropbox.com/s/pmz8oneual5pq82/Pots.dng?dl=0

JPEG:
https://www.dropbox.com/s/l8rw3zpjgf599f7/Pots.jpg?dl=0

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=347737

--- Comment #26 from Gilles Caulier <[hidden email]> ---
Technically, there is not difference between CR2 and DNG : both are tiff/EP
based files. So same dysfunction...

Gilles Caulier

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Alan Pater]

https://bugs.kde.org/show_bug.cgi?id=347737

--- Comment #27 from Alan Pater <[hidden email]> ---
I am sure it is digikam writing the Exif XMLPacket. here is how I tested and
you can repeat this yourself to confirm.

Download a CR2 file:
http://www.rawsamples.ch/raws/canon/400d/RAW_CANON_400D_ARGB.CR2

Use exiv2 to check if XMLpacket exists in the file:

$ exiv2 -g XMLPacket RAW_CANON_400D_ARGB.CR2

Confirmed. XMLPacket does not exist in the CR2 image.  

In digikam, add a Title and a Tag. Go to Image: Write metadata to image.

$ exiv2 -g XMLPacket RAW_CANON_400D_ARGB.CR2
Exif.Image.XMLPacket                         Byte      4326  (Binary value
suppressed)

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Alan Pater]

https://bugs.kde.org/show_bug.cgi?id=347737

--- Comment #28 from Alan Pater <[hidden email]> ---
Try the same test with DNG, but without the experimental writing metadata to
Raw feature-

digikam will save the Title and Tag in a normal XMP section.

Convert the file to JPG in RawTherapee. The resulting JPG does not have normal
XMP section. RawTherapee has removed it.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Alan Pater]

https://bugs.kde.org/show_bug.cgi?id=347737

--- Comment #29 from Alan Pater <[hidden email]> ---
It is indeed exiv2 which automatically adds Exif.Image.XMLPacket to the file
without any explicit instruction from digikam/libkexiv2.

~$ exiv2 -g XMLPacket raw.exiv2.cr2
~$ exiv2 -M'set Xmp.dc.title EXIV TITLE' raw.exiv2.cr2
~$ exiv2 -g XMLPacket raw.exiv2.cr2
Exif.Image.XMLPacket                         Byte      2495  (Binary value
suppressed)

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=347737

--- Comment #30 from Gilles Caulier <[hidden email]> ---
Alan,

Exactly. As i said previously, digiKam as to Exiv2 to store XMP data to CR2.
Exiv2 choose the right place to do it.

For CR2, as it's TIFF/EP file based, the way to store XMP in tiff is to use
XMLPacket from Exif. There is no separated section/chunk in tiff. After all,
tiff structure is a tree of tags.

This way is the same for DNG.

So this is normal until now.

When you convert RAW tiff based with XMLPacket to JPG,  the fast way is to move
XMLPacket to dedicated section. RawTherapee must do it, but it let XMP to Exif
tags. Later when Exiv2 will read JPG file, it found XMP in XMLPacket instead
XMP section. This is ignored because XMLPacket is deprecated than XMP section
for JPEG. Why ? because for JPEG, as Exif section is limited to 64Kb, XMP must
go to XMP section instead to bloat Exif section to prevent to break JPEG
structure. A section more than 64Kb give a corrupted file, excepted if more
than one section are chained to host Exif data (The Adobe way). But i'm not
sure that Exiv2 support it well, as all other metadata framework (excepted
Adobe tools of course).

I don't know how RawTherapee work, but for me the metadata workflow is wrong.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel