Summary: | The DocumentName tag is not added when importing [patch] | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | Jonas Norlander <jonorland> |
Component: | Import-PostProcessing | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alain.quincerot_lnx, caulier.gilles, metzpinguin |
Priority: | NOR | ||
Version: | 1.2.0 | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | http://commits.kde.org/digikam/52bb19ec9265a7fae58d65de502b8e417c46f0ce | Version Fixed In: | 4.12.0 |
Sentry Crash Report: | |||
Attachments: | ImportDocumentName.patch |
Description
Jonas Norlander
2010-04-07 15:38:17 UTC
What is the specification of this tag? Currently, I see that it is set to the original file path when an (edited) image is saved, or when a JPEG operation like rotation is done. From that, I would understand the tag gives the original file name. In which case the use in DImg's updateMetadata is all right, in jpegutils doubtful, if the file is changed in place. Jonas, as reporter of this bug, what it your usage of this tag? It has been almost a year since I reported this bug and reading my bug report now don't make much sense. I'm not sure exactly what I was doing when reporting this but if I remember right it was during import and if autorotate was enabled the DocumentName tag was updated/added _only_ when the picture was rotated. Renaming the files during import could have something with it to do to, as I think the value of the DocumentName tag was updated with the old name of the file before it was renamed during the imported. Storing the original filename in the tag can be a good thing to do, I think. The bug is still there for me with Digikam 1.8.0. What version of Digikam are you using? I thought I check if this bug is still there when i was importing some photos and it turns out the bug is still there. When importing (from flash card), if the picture is auto rotated the Exif tags Exif.Image.ImageWidth, Exif.Image.ImageLength and Exif.Image.DocumentName is added. For those pictures that not are rotated this tags is not added. I think this tags should always be added when importing not only when the pictures are rotated. At least it should be the same rotated or not. This is JPEG pictures from an Canon IXUS 100is. The question is still what the tag is supposed to mean. The specification does not really help. The tag is used to store the information about the origine of the image. If the file created come from another one, for ex, by a conversion (as TIFF to JPEG), we must copy the original file name with TIFF extension in this tag. If file is created from a device (a scanner for ex), we copy the scanner information. I use this way into RAW converter or in image editor. In camera interface, if file is converted from JPEG to lossless format, tag must be patched. Gilles Caulier Marcel, Some progress here from you ? Gilles Caulier Jonas, This file still valid using digiKam 2.4 ? Gilles Caulier DImg::prepareMetadataToSave is settings the DocumentName tag, and is called from ImageEditor, batch tool and fileworker iface. Apparently not from CameraInterface, so probably this one is missing to fix this bug? Purpose : I use this tag for adding comment to images, and then use it in html export. Presently, I receive images from my relatives with this tag and I import them into my digikam. the "Dublin Core" Title is not displayed below the thumbnail by digikam, whatever the lang is set (fr-FR or x-default). however the Metadata tab (in the XMP part) displays the title. This happens on images whom dc.title has been set with digikam (version 4.8.0) running on Windows 8.1 then transferred to digikam 4.6.0 on openSuse 13.2 using exiv2 0.24 001800 (64 bit build) Note : I remember I have already seen this problem 2 years ago with older versions. I can not confirm this bug. The "Dublin Core" title is in the DB imported and displayed under the thumbnail, when the title checkbox ist activated. Maik Same for me. This bug is not reproducible here. This probably depend of Exiv2 and libkexiv2 shared libs installed and used by digiKam... Gilles Caulier oups, subject of this entry is not DC tags, by DocumentName tag. This is different. Else problem from comment #11 is not reproducible here... Gilles Caulier Maik, Do you see comment #10 from Marcel ? Anyway, it can be easy to see if problem is reproducible while download, when not specific operation is done on metadata. The Exif DocumentName must be set in all cases, as it's ask in original report. Gilles Created attachment 93478 [details]
ImportDocumentName.patch
This patch set the document name when images are imported. It also resolves that color labels, pick labels and rating are set if no template is applied. We set metadata only for JPEG files when importing, but we could not apply it to other image formats (TIFF, PNG)?
Maik
Comment on attachment 93478 [details]
ImportDocumentName.patch
There is no limitation about file format to patch, if Exiv2 support it. This is the case for PNG, and TIFF.
But applying over all type of image format require more work especially with read only files as RAW. There is a file about this topic in bugzilla if i remember.
Typically, we must set a metadata cache in import tool including all change to apply to files while importing, download files, scan new items, and patch DB.
Gilles
Forget to said, that patch sounds fine for me. Gilles Git commit 52bb19ec9265a7fae58d65de502b8e417c46f0ce by Maik Qualmann. Committed on 05/07/2015 at 06:37. Pushed by mqualmann into branch 'master'. apply patch #93478 to added the DocumentName tag when importing images FIXED-IN: 4.12.0 M +2 -2 NEWS M +34 -27 utilities/importui/backend/cameracontroller.cpp http://commits.kde.org/digikam/52bb19ec9265a7fae58d65de502b8e417c46f0ce Git commit 2de7ad489b546bff770d7c0b8755eedbaecd93f4 by Gilles Caulier. Committed on 05/07/2015 at 08:22. Pushed by cgilles into branch 'frameworks'. backport commit #52bb19ec9265a7fae58d65de502b8e417c46f0ce from git/master to frameworks branch M +34 -28 utilities/importui/backend/cameracontroller.cpp http://commits.kde.org/digikam/2de7ad489b546bff770d7c0b8755eedbaecd93f4 |