Summary: gthumb 3.4.0 (Fedora 22) overwrites photo timestamps with
garbage when editing photo comments. This results in irrecoverable data
loss.
Details: after importing my photos from my camera, the embedded date
fields looked like this:
$ exiftool -G -EXIF:DateTimeOriginal -EXIF:CreateDate photo.jpeg
[EXIF] Date/Time Original : 2015:09:26 17:42:31
[EXIF] Create Date : 2015:09:26 17:42:31
I then opened the photo in gthumb and added a description and location
("Description" and "Place" fields). I didn't touch the "Date" field.
The "Save only changed fields" box was disabled. Afterwards, the
embedded date fields had been overwritten with garbage:
$ exiftool -G -EXIF:DateTimeOriginal -EXIF:CreateDate photo.jpeg
[EXIF] Date/Time Original : 2015:09:26 00:00:00
[EXIF] Create Date : 2015:09:26 00:00:00
The same garbage date appears in the external XML file:
$ cat .comments/photo.jpeg.xml
<?xml version='1.0' encoding='UTF-8'?>
<comment version="3.0">
<caption />
<note>Something</note>
<place>Somewhere</place>
<time value="2015:09:26 10:42:31-07:00" />
<categories />
</comment>
My photo metadata requirements are simple:
* A UTC timestamp (set by the camera)
* A localized timestamp for display purposes
* Description
* Location
* Metadata must be stored either in embedded tags or in
easily-consumable external files such as JSON or XML, as opposed to the
opaque databases favoured by a lot of the photo management software out
there.
* A reasonable metadata editor GUI
These requirements used to be easily achievable using gthumb. Every
version that I have used in since ~2004 stored timestamps, descriptions,
and locations in xml files, and all but the oldest also stored this
metadata in embedded tags. gthumb 2 never touched the EXIF date fields,
storing any timestamp entered through the comment dialog in
IPTC:DateCreated and IPTC:TimeCreated fields, as well as in the XML
file. More recent gthumb 3.x versions would write anything entered in
the timestamp field in the comment dialog to the EXIF:DateTimeOriginal
and XMP:DateTimeOriginal fields. Unfortunately, there is no way to set
a time zone through the gthumb UI and while the XMP:DateTimeOriginal
field can hold a UTC offset, the EXIF:DateTimeOriginal field can't.
Consequently, I avoided touching the timestamp in the gthumb UI and used
my own tools (https://github.com/rdegraaf/dyphal) to manage the
timestamps. If I accidentally modified the timestamp in the gthumb UI, I
could recover by using other tools (eg, exiftool) to replace it with the
EXIF:CreateDate field, which was unmodified. The older gthumb 3.x
versions also had the unfortunate habit of overwriting the
XMP:DateTimeOriginal field with EXIF:DateTimeOriginal, thus losing
information. However, it would not actually save that to disk unless I
saved the comment dialog, so I could work around that issue by never
trusting the timestamps displayed in the gthumb UI and by always
re-running my timestamp update scripts after modifying comments.
If everything was done correctly, the timestamps in the embedded tags
would look like this after I'm done:
$ exiftool -G -EXIF:DateTimeOriginal -EXIF:CreateDate
XMP:DateTimeOriginal photo.jpeg
[EXIF] Date/Time Original : 2015:09:26 17:42:31
[EXIF] Create Date : 2015:09:26 17:42:31
[XMP] Date/Time Original : 2015:09:26 10:42:31-07:00
A few weeks ago, I updated to Fedora 22, which uses gthumb 3.4. In this
version, when the "Store metadata inside files if possible" option is
enabled in the "General" page of the Preferences dialog, every embedded
tag containing the original timestamp generated by the camera is
overwritten with garbage whenever I edit the comments, even if I do not
touch the timestamp in the comments dialog (as described above). This
is an unacceptable data loss bug -- I had to buy a card reader so that I
could run a deleted file recovery tool on my camera's memory card in
order to recover my photos.
Going forward, I may be able to work around this issue by keeping the
"Store metadata inside files if possible" option disabled, and using my
own scripts to fix the timestamp in the XML file and to copy the
comments from the XML to the embedded tags; more investigation is
required. gthumb is becoming more of a liability than an asset; this
release meets fewer of my requirements than older versions did and data
loss bugs are serious business. The only reason why I'm still using it
is that everything else that I've investigated meets even fewer of my
requirements and I haven't found anything else that can import my
existing metadata. But if these regressions keep up, I'll be forced to
ditch it anyway.
Rennie
Attachment:
signature.asc
Description: OpenPGP digital signature