Bug 279403 - Saving Geotagging info fails
Summary: Saving Geotagging info fails
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Geolocation-Engine (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-04 18:59 UTC by bogdan
Modified: 2020-08-29 15:05 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In: 7.1.0


Attachments
Problem image sample in digikam (173.87 KB, image/png)
2013-02-14 05:04 UTC, Samuel Gilbert
Details

Note You need to log in before you can comment on or make changes to this bug.
Description bogdan 2011-08-04 18:59:47 UTC
Version:           0.6.2 (using KDE 4.6.5) 
OS:                Linux

The geotagging process runs well and works, but applying those changes to the files does not work.

I get 
  Failed to save some information:

path_to_file : Unable the save changes to file

Reproducible: Always

Steps to Reproduce:
1) getotag an image
2) press Apply button

Actual Results:  
I get 
  Failed to save some information:

path_to_file : Unable the save changes to file

Expected Results:  
Success applying

OS: Linux (x86_64) release 3.0.0-39-desktop
Compiler: gcc
Comment 1 bogdan 2011-08-04 19:49:57 UTC
I am trying to geotag Sony ARW, it appears that these files cannot store location data, but I man 100% sure
Comment 2 caulier.gilles 2011-12-21 10:06:13 UTC
Bogdan,

About ARW file, this is read only RAW file. Exiv2 library can touch some TIFF/EP RAW file as NEF, but not ARW.

Can you reproduce the problem using kipi-plugins 2.4 ?

Gilles Caulier
Comment 3 Samuel Gilbert 2013-02-13 16:25:46 UTC
I get exactly the same behaviour with JPEG files taken with a Canon Rebel XT.

I tried to launch Digikam from a terminal to get additional output, but I see nothing relevant.

When the process fails, it creates, for each affected file, a 2 byte file named the same as the source but with the Digikam PID appended at the end.  For example :

File to be geo-referenced : 2012-12-19T10:43:49_Val.JPG
2 byte file created in the same folder : 2012-12-19T10:43:49_Val.JPG695

This isn't an issue with the file permissions.  Creating a copy of the file with another name and trying to geo-reference it yields the same behaviour.
Comment 4 Samuel Gilbert 2013-02-13 16:33:25 UTC
I wanted to attach a sample file for which the geo-tagging process fails, but it's to big (4.6MB).

I put the file on my personal Web server (self-signed SSL certificate) :
https://stonewatch.homelinux.org/geo-tagging_fails.jpg
Comment 5 Samuel Gilbert 2013-02-14 05:04:19 UTC
Created attachment 77275 [details]
Problem image sample in digikam

I noticed that all the images for which I encountered this problem show up with theses messed-up properties in digikam.
Comment 6 Samuel Gilbert 2013-02-14 05:16:34 UTC
While trying to understand and solve this problem, I tried to find what was special with the files for which I'm encountering the issue.  This is what I get with exiv2 :

$ exiv2 pr geo-tagging_fails.jpg
Warning: Directory (Last IFD item), entry 0x0001 has unknown Exif (TIFF) type 0; setting type size 1.
Warning: Directory (Last IFD item), entry 0x0001 has unknown Exif (TIFF) type 0; setting type size 1.
Warning: Directory (Last IFD item), entry 0x0001 has unknown Exif (TIFF) type 0; setting type size 1.
Error: Directory (Last IFD item) with 10825 entries considered invalid; not read.
File name       : geo-tagging_fails.jpg
File size       : 4810817 Bytes
MIME type       : image/jpeg
Image size      : 3456 x 2304
Camera make     : Canon
Camera model    : Canon EOS DIGITAL REBEL XT
Image timestamp : 2012:12:19 10:43:49
Image number    : 
Exposure time   : 1/4000 s
Aperture        : F11
Exposure bias   : 0 EV
Flash           : No, compulsory
Flash bias      : 0 EV
Focal length    : 31.0 mm
Subject distance: 0
ISO speed       : 1600
Exposure mode   : Not defined
Metering mode   : Partial
Macro mode      : Off
Image quality   : Fine
Exif Resolution : 3456 x 2304
White balance   : Auto
Thumbnail       : image/jpeg, 7162 Bytes
Copyright       : 
Exif comment    :
$


Since digikam uses libkexiv2, could this be causing the problem?

I don't really understand the JPEG internal structure, but I will try to find if I can remove or fix what makes exiv2 unhappy with exiftool.
Comment 7 Samuel Gilbert 2013-02-19 18:12:15 UTC
All the pictures I have that are suffering from this problem have been imported from the Camera using iPhoto (by a friend).  Files copied directly to Linux from the CF using a USB reader behave normally.
Comment 8 Samuel Gilbert 2013-03-06 04:28:19 UTC
I managed to find a work-around for the problem :

find -type f -iname "*.jpg" -exec exiftool -all= -tagsfromfile @ -all:all -unsafe {} \;

This allowed me to work with the files within digikam.
Comment 9 Marcel Wiesweg 2013-03-09 16:11:32 UTC
I can confirm that exiv2 refuses to write to the sample image that you provide. Error messages:
Warning: Directory (Last IFD item), entry 0x0001 has unknown Exif (TIFF) type 0; setting type size 1.
Warning: Directory (Last IFD item), entry 0x0001 has unknown Exif (TIFF) type 0; setting type size 1.
Warning: Directory (Last IFD item), entry 0x0001 has unknown Exif (TIFF) type 0; setting type size 1.
Error: Directory (Last IFD item) with 10825 entries considered invalid; not read.
Warning: Directory (Last IFD item), entry 0x0001 has unknown Exif (TIFF) type 0; setting type size 1.
Warning: Directory (Last IFD item), entry 0x0001 has unknown Exif (TIFF) type 0; setting type size 1.
Warning: Directory (Last IFD item), entry 0x0001 has unknown Exif (TIFF) type 0; setting type size 1.
Error: Directory (Last IFD item) with 10825 entries considered invalid; not read.
Exiv2 exception in modify action for file /media/fotos/Digikam Sample/TIFF/Test # Album äöüß éç/bug-279403-geo-tagging_fails.jpg:
Invalid ifdId 101

Reading metadata works flawlessly here, I see a lot of Exif information and makernote.

I suspect some unknown invalid entries / an invalid structure which make exiv2 bail out when write is attempted. You can open a bug report with exiv2 providing the sample file and the error messages (which can be produced by the exiv2 command line tool already with
exiv2 -c "text" sampefile.jpg)
Comment 10 Marcel Wiesweg 2013-03-09 16:26:09 UTC
It's either a bug in exiv2 or a broken/non-standard file where the behavior (refuse to write) is safe.
Comment 11 caulier.gilles 2020-08-29 15:05:46 UTC
This problem have been fixed with 7.1.0 release