| Summary: | exifs lost when modifying the images | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Jean-Daniel Dodin <jdd> |
| Component: | Metadata-Exif | Assignee: | 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
rpm was found at packman Please specify step-by-step what you did. 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 if that were the case, nobody would use digiKam. I'll close this bug, unless you can specify how you editted the image... 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 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 can not reproduce 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 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 Maybe an old libexif or libkexif? 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
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. 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 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 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... recompiled plugins, no change. may be a problem with kde? I don't know what to do then :-( jdd 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 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. [ 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 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 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: / 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 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) 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 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 ) 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 #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
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;
|
