Bug 118501

Summary: exifs lost when modifying the images
Product: [Applications] digikam Reporter: Jean-Daniel Dodin <jdd>
Component: Metadata-ExifAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: ach, ana
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In: 0.9.0
Sentry Crash Report:

Description Jean-Daniel Dodin 2005-12-17 11:09:01 UTC
Version:           0.8 (using KDE KDE 3.4.2)
Installed from:    SuSE RPMs
OS:                Linux

When one modify an image, the exifs are lost
this was not the case in 0.7.4 - so I switched back to the old version
Comment 1 Jean-Daniel Dodin 2005-12-17 11:31:27 UTC
rpm was found at packman
Comment 2 Tom Albers 2005-12-17 14:23:00 UTC
Please specify step-by-step what you did.
Comment 3 Jean-Daniel Dodin 2005-12-17 15:37:20 UTC
nothing special. view albums, edit them as usual, save the edited image (edited with digikam) and there are no more exifs in the image. See one here:

http://dodin.org/tmp/img_0336.jpg

original one:
http://dodin.org/tmp/img_0336-2.jpg
Comment 4 Tom Albers 2005-12-17 15:44:14 UTC
if that were the case, nobody would use digiKam. I'll close this bug, unless you can specify how you editted the image...
Comment 5 Jean-Daniel Dodin 2005-12-17 16:51:41 UTC
what do you want me to say? look properties, exif are here. edit the image the exifs are no more. period.

suse 10.0, packman  digikam 0.8
jdd
Comment 6 Jean-Daniel Dodin 2005-12-17 17:00:19 UTC
to be more constructive. Is there a way to install the 0.8 without unistallingh the 0.7.4 version? I have the 0.8 rpm on my disk. If I could have the two version I could make more tests

jdd
Comment 7 Tom Albers 2005-12-17 17:00:59 UTC
can not reproduce
Comment 8 Jean-Daniel Dodin 2005-12-20 11:52:43 UTC
May I insist??

digikam 0.8 have some feature I whould be able to use :-)

I reinstall it and the bug is here

digikam 0.8.0 (kde 3.4.2 level "b" Suse 10.0)
are installed digikam, the doc and the plugins

from ls -l:
2022954 2005-12-13 10:01 digikam-0.8.0-1.pm.1.i586.rpm
43095126 2005-12-13 10:06 digikam-doc-0.8.0-1.pm.1.noarch.rpm
14614793 2005-12-13 10:03 digikamimageplugins-0.8.0-1.pm.1.i586.rpm

suse rpm found on packman repository, installed with yast (it's usually the best method on suse)

the initial photo (example, content of no interest) with exifs:
http://dodin.org/tmp/img_0473-ini.jpg

open in digikam, edit, correct/colors/automatic level, save
nothing more

result:
http://dodin.org/tmp/img_0473.jpg

I have a french install, so the menu entries may no be exactly as said (of course I can give the french version)

I keep the digikam version for testings and wait for you

jdd
Comment 9 caulier.gilles 2005-12-20 12:06:21 UTC
I can't reproduce this problem here (Mandriva 2006). I suspect a broken tarball or installation.

Have you any error messages from the console when you start digikam or showofoto from a command line ?

Have you tested to compile and install yourseft digikam & co on your computer. We are developpers and we working like this, never using packages.

Gilles Caulier
Comment 10 Tom Albers 2005-12-20 12:24:25 UTC
Maybe an old libexif or libkexif?
Comment 11 Gerhard Kulzer 2005-12-20 12:25:22 UTC
Am Dienstag, 20. Dezember 2005 11.52 schrieb Jean-Daniel Dodin:
[bugs.kde.org quoted mail]

Have you veryfiedthat libexif and libkexif are installed?

You sould get somthing similar of this:
$ ldd /usr/bin/digikam|grep exif
        libkexif.so.1 => /usr/lib/libkexif.so.1 (0x4b16b000)
        libexif.so.12 => /usr/lib/libexif.so.12 (0x45f5a000)


Gerhard
Comment 12 Jean-Daniel Dodin 2005-12-20 12:37:21 UTC
no error message.

and I _can_ see the exifs in the property dialog box in the files when they are here
is that what you need? (digikam is _not_ in /usr in my install)
jdd@peter-suse:/opt/kde3/lib> ls | grep exif
libkexif.la
libkexif.so
libkexif.so.1
libkexif.so.1.0.0

I may try to compile digikam.
Comment 13 Jean-Daniel Dodin 2005-12-20 17:08:44 UTC
all digikam uninstalled with yast (the suse package manager).

many -dev installed and compile managed.

console launch normal (no file given on command line)

same bug.

jdd@peter-suse:~/Documents/digikam-0.8.0> digikam
digikam: ScanLib: Finding non-existing Albums: 54 ms
digikam: ScanLib: Finding items not in the database or disk: 2183 ms
digikam: ScanLib: Updating items without date: 4 ms
digikam: ImagePlugin_Core plugin loaded
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_Core
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_RainDrop
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_InPainting
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_Infrared
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_Texture
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_Border
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_OilPaint
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_InsertText
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_Emboss
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_Unsharp
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_HotPixels
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_AdjustLevels
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_ShearTool
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_Solarize
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_DistortionFX
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_LensDistortion
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_FilmGrain
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_BlowUp
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_Restoration
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_SuperImpose
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_Refocus
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_WhiteBalance
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_BlurFX
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_Despeckle
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_AntiVignetting
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_AdjustCurves
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_FreeRotation
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_Perspective
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_ChannelMixer
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_Charcoal
digikam: Saving to :/home/jdd/photos/photos retouchees/ensemble/travail/hk47Aa.tmp (jpeg)
digikam: WARNING: Error in opening output file
digikam: Dirty: /ensemble/travail
Comment 14 Jean-Daniel Dodin 2005-12-20 17:11:10 UTC
I compiled only digicam and the bug seems to come elsewhere. I wil try to compile the plugins.

note: I cam rename a file without loosing the exifs, but I loose them as soon a I do a modif in the editor, even a filter, color change...

jdd
Comment 15 Jean-Daniel Dodin 2005-12-20 17:18:36 UTC
I compiled libexif. It seems that the tags names are bold, now, in the view window, but exifs are still lost :-(
go on with plugins...
Comment 16 Jean-Daniel Dodin 2005-12-20 17:51:21 UTC
recompiled plugins, no change.

may be a problem with kde?

I don't know what to do then :-(
jdd
Comment 17 caulier.gilles 2005-12-20 19:20:12 UTC
digikam: Saving to :/home/jdd/photos/photos retouchees/ensemble/travail/hk47Aa.tmp (jpeg) 
digikam: WARNING: Error in opening output file 

This is the problem ! Your HDD is full ? Trying with a different user !

Gilles
Comment 18 Jean-Daniel Dodin 2005-12-20 20:30:19 UTC
you gave me the hint, I found the problem, but still don't understand why this hits only the exifs.
I noticed that sometimes, quite rarely, I had a "can't write" the file after edit. probably the same origin.

The files I was working on where copyied (by konqueror) from cd's. They kept they readonly attribute (r--r--r--). Restoring the write state closed the bug.

the directory is rwx

I don't understand why I could write the image but not the exifs :-(

this should be advertised somewhere, copying from a backup is a frequent task. I can do this if instructed how :-)

thanks for your help.
Comment 19 Achim Bohnet 2006-02-08 01:31:10 UTC
[ this comment was triggered by http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=349450 ]

Hmm, was this fixed after 0.8.1? There no note when/why
it was set resolved.  I can reproduce it with a write
protected image in 0.8.1:

cp jpeg-with-exif.jpg readonly.jpg
chmod 444 readonly.jpg

start digikam imageeditor with readonly.jpg
RMB -> rotate -> 90 degree
save and exit IE

Now EXIF tab of properties is empty for readonly.jpg :(

Doing the same with original jpeg-with-exif.jpg
and the EXIF tab is still there.


Achim
Comment 20 Achim Bohnet 2006-02-08 02:50:56 UTC
I've build 0.8.2-svn from stable trunk and EXIF infos
are still deleted for a readonly picture.   Here the
output digikam writes:

digikam: Saving to :/home/ttt/Pictures/Test-Test-Test/HUK6qb.tmp (jpeg)
digikam: WARNING: Error in opening output file
digikam: WARNING: Failed to open file: /home/ttt/Pictures/Test-Test-Test/HUK6qb.tmp
digikam: Dirty: /Test-Test-Test
digikam: Found JPEGLossless plugin

Achim
Comment 21 Volker Christian 2006-02-28 20:28:19 UTC
I create a jpeg by use of ufraw from a cr2-raw file, copy the exif information from the cr2 file to the jpeg file with 

   exiftool -overwrite_original -tagsfromfile %f.cr2 -all:all -ext jpg

If i open the file in digikam and try to save it again, i get the output below.
Bad, because all exif-info is lost in the saved file.

I can provide you with example-files also. Just ask!

Please help!
Volker

digikam: /media/MOBILE_HD/Albums/Home/2006-02-27/img_6562.jpg : JPEG file identi
fied
digikam: Reading JPEG metadata: APP1 (size=16916)
digikam: Reading JPEG metadata: APP1 (size=2820)
digikam: mimetypes=image/x-portable-bitmap image/x-pcx image/x-portable-greymap
image/x-xbm image/x-targa image/png image/x-portable-pixmap image/jpeg image/x-x
pm image/x-eps image/x-bmp image/jp2 image/x-rgb image/tiff
digikam: mimetypes=image/x-portable-bitmap image/x-pcx image/x-portable-greymap
image/x-xbm image/x-targa image/png image/x-portable-pixmap image/jpeg image/x-x
pm image/x-eps image/x-bmp image/jp2 image/x-rgb image/tiff
digikam: Saving to :/media/MOBILE_HD/Albums/Home/2006-02-27/YxM1Qa.tmp (jpeg)
digikam: Dirty: /Home/2006-02-27
digikam: Writing JPEG metadata: APP1: DATA=[68 74 74 70 3a 2f 2f 6e 73 2e 61 64
6f 62 65 2e 63 6f 6d 2f 78 61 70 2f 31 2e 30 2f 00 3c 3f 78 70 61 63 6b 65 74 20
 62 65 67 69 6e 3d 27 ef bb bf 27 20 69 64 3d 27 57 35 4d 30 4d 70 43 65 68 ...]
digikam: Dirty: /
digikam: renaming to /media/MOBILE_HD/Albums/Home/2006-02-27/img_6562-2.jpg
Error: Makernote entry 1358 lies outside of the IFD memory buffer.
Warning: Failed to read Makernote, rc = 6
digikam: Dirty: /
digikam: Dirty: /Home/2006-02-27
digikam: Dirty: /
Comment 22 caulier.gilles 2006-03-03 10:59:50 UTC
SVN commit 515268 by cgilles:

digikam from trunk : Metadata support using Exiv2 :

- New image properties sidebar tab named "Metadata" instead old "Exif". This area include :

* Standard Exif tags viewer.
* MarkerNote Exif tags viewer.
* IPTC records viewer.

- New capability to copy metadata in clipboard like text.
- New capability to print metadata.
- Tags name use the "user Friendly" conversion from Exiv2 instead the internal name provided by old Exif viewer based on libkexif.
- Capability to read metadata from CRW files (Canon RAW files)
- New class DMetadata to load/save metadata without loading image data. Actually JPEG, CRW, and PNG files are supported. About PNG (Exif and IPTC raw profiles generated by ImageMagick are supported.

To support new file formats (like NEF, MRW, TIFF, DNG, etc), new image file parsers must be added to Exiv2 library.

IMPORTANT: 

- Exiv2 do not support yet gettext for i18n rules. All informations in metadata viewers aren't yet i18n (tags name, tags values, and tags descriptions)
- Any tag names use internal Exiv2 name, not the user friendly text transformations. This point must be fixed in Exiv2 libs.

To 0.9.0, these tools are just metadata readers. Writting capabilities (metadata editors) will added later 0.9.0. The files in B.K.O directly or indirectly relevant of this commits are listed below :

*Pending:

103255
106103
115764
111560

*Partially fixed:

91812
96459
109253
110598
118501         

* To check before closing:

122264

* Fixed (can be closed):

103489
121371
105670
109319

CCMAIL: digikam-devel@kde.org,  Andreas Huggel <ahuggel@gmx.net>

CCBUGS: 103255, 106103, 115764, 111560, 91812, 96459, 109253, 110598, 118501, 122264, 103489, 121371, 105670, 109319


 M  +2 -1      libs/Makefile.am  
 M  +5 -4      libs/dimg/Makefile.am  
 M  +1 -1      libs/dimg/dimg.cpp  
 M  +1 -1      libs/dimg/dimg.h  
 M  +19 -1     libs/dimg/dimgloader.cpp  
 M  +4 -2      libs/dimg/dimgloader.h  
 M  +4 -61     libs/dimg/loaders/jpegloader.cpp  
 M  +5 -29     libs/dimg/loaders/pngloader.cpp  
 M  +2 -1      libs/dimg/loaders/rawloader.cpp  
 A             libs/dmetadata (directory)  
 A             libs/dmetadata/Makefile.am  
 A             libs/dmetadata/dmetadata.cpp   [License: GPL]
 A             libs/dmetadata/dmetadata.h   [License: GPL]
 A             libs/dmetadata/loaders (directory)  
 A             libs/dmetadata/loaders/Makefile.am  
 A             libs/dmetadata/loaders/dmetaloader.cpp   [License: GPL]
 A             libs/dmetadata/loaders/dmetaloader.h   [License: GPL]
 A             libs/dmetadata/loaders/jpegmetaloader.cpp   [License: GPL]
 A             libs/dmetadata/loaders/jpegmetaloader.h   [License: GPL]
 A             libs/dmetadata/loaders/pngmetaloader.cpp   [License: GPL]
 A             libs/dmetadata/loaders/pngmetaloader.h   [License: GPL]
 A             libs/dmetadata/loaders/rawmetaloader.cpp   [License: GPL]
 A             libs/dmetadata/loaders/rawmetaloader.h   [License: GPL]
 A             libs/dmetadata/loaders/tiffmetaloader.cpp   [License: GPL]
 A             libs/dmetadata/loaders/tiffmetaloader.h   [License: GPL]
 M  +3 -2      libs/imageproperties/Makefile.am  
 M  +82 -323   libs/imageproperties/imagepropertiesexiftab.cpp  
 M  +12 -25    libs/imageproperties/imagepropertiesexiftab.h  
 M  +19 -18    libs/imageproperties/imagepropertiessidebar.cpp  
 M  +10 -9     libs/imageproperties/imagepropertiessidebar.h  
 M  +27 -26    libs/imageproperties/imagepropertiessidebarcamgui.cpp  
 M  +2 -1      libs/imageproperties/imagepropertiessidebarcamgui.h  
 M  +16 -15    libs/imageproperties/imagepropertiessidebardb.cpp  
 M  +3 -1      libs/widgets/Makefile.am  
 A             libs/widgets/metadata (directory)  
 A             libs/widgets/metadata/Makefile.am  
 A             libs/widgets/metadata/exifwidget.cpp   [License: GPL]
 A             libs/widgets/metadata/exifwidget.h   [License: GPL]
 A             libs/widgets/metadata/iptcwidget.cpp   [License: GPL]
 A             libs/widgets/metadata/iptcwidget.h   [License: GPL]
 A             libs/widgets/metadata/makernotewidget.cpp   [License: GPL]
 A             libs/widgets/metadata/makernotewidget.h   [License: GPL]
 A             libs/widgets/metadata/mdkeylistviewitem.cpp   [License: GPL]
 A             libs/widgets/metadata/mdkeylistviewitem.h   [License: GPL]
 A             libs/widgets/metadata/metadatalistview.cpp   [License: GPL]
 A             libs/widgets/metadata/metadatalistview.h   [License: GPL]
 A             libs/widgets/metadata/metadatalistviewitem.cpp   [License: GPL]
 A             libs/widgets/metadata/metadatalistviewitem.h   [License: GPL]
 A             libs/widgets/metadata/metadatawidget.cpp   [License: GPL]
 A             libs/widgets/metadata/metadatawidget.h   [License: GPL]
 M  +24 -1     utilities/cameragui/cameraui.cpp  
Comment 23 Stuart Prescott 2006-04-01 00:19:59 UTC
Much of this discussion has centred around read-only files, but I see this bug when I import pictures from the camera and let digikam auto-rotate them. When the images are brought in to my "Incoming" folder, portrait photos are automagically rotated and lose their EXIF data but landscape photos still have their EXIF data intact.

Unfortunately, I only just discovered it so my last few hundred portrait photos do not have any EXIF data in them, including the date they were taken :( (i.e. this bug means loss of data making it serious not just mildly annoying)

Good to see some progress noted against this bug, but it is unclear as to whether the svn trunk now has this fixed or not.

(digikam and plugins fom Debian etch 0.8.1-3)
Comment 24 caulier.gilles 2006-04-03 14:05:22 UTC
Tested indeep with current trunk implementation. The problem do not exist in image editor and camera gui.

No test yet done with current implemention of stable branch.  Please give me a feedback.

Gilles Caulier
Comment 25 John Green 2006-04-24 21:42:04 UTC
I also get this after moving to ubuntu dapper package 0.8.1-4ubuntu1. Auto-rotated pictures lose exif after import. This did not happen in the previous version (sorry I do not exactly but would have been with breezy KDE 3.5.2 )
Comment 26 Achim Bohnet 2006-04-27 00:54:05 UTC
Confirmed with 0.8.2-beta1 on Kubuntu/Dapper _when_ the image is write
protected as given in debian bug:

 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=349450

Reproduce:

o chmod 444 image-with-exif-info.jpg
o load this image into IE
o Transform -> rotate 90 degree
o save it

==> rotated image is silently overriden, despite the 444 protection.
(silently == no err/info dialog, no output to console).   The exif info
is gone.

Achim
Comment 27 Achim Bohnet 2006-04-27 02:21:29 UTC
#23 From Stuart Prescott
#23 From John Green

Hi Stuart, John

this is a similar but different problem.  See:

       http://bugs.kde.org/show_bug.cgi?id=126326
       [ https://launchpad.net/distros/ubuntu/+source/digikam/+bug/34462 ]

Achim
Comment 28 Marcel Wiesweg 2006-04-30 19:54:38 UTC
SVN commit 535907 by mwiesweg:

digikam stable branch:
Add write permission when copying permissions of original file to temp file
so that std::ofstream of temp file can open the file.

BUG: 118501


 M  +4 -1      imlibinterface.cpp  


--- branches/stable/extragear/graphics/digikam/utilities/imageeditor/imlibinterface.cpp #535906:535907
@@ -1200,7 +1200,10 @@
     // file saved. now preserve the permissions
     if (d->filePermissions != 0)
     {
-        ::chmod(QFile::encodeName(saveFile), d->filePermissions);
+        // Add the user write permission.
+        // There is a problem with lost Exif info on read only files,
+        // and there won't be sophisticated handling for this in the 0.8 branch any more.
+        ::chmod(QFile::encodeName(saveFile), d->filePermissions | S_IWRITE);
     }
 
     return true;