Images that tagged using MS Windows Explorer (Windows 7) are not searchable with Nepomuk. I think the used exif fields are differnt. Reproducible: Always Steps to Reproduce: 1. try this Image http://www.fiebach.de/error/030313130024.jpg 2. 3. Actual Results: No Metadata Expected Results: Tag's shown in Dolphin
The windows tags seem to be stored in an exif field Tags
Bah... The windows tags seem to be stored in an exif field called "XP Keywords"; it might be possible (and maybe desirable) for the fileindexer to turn those into tags. You should know though that nepomuk tags are not stored with the file, so any changes you would make to them using dolphin would not be seen back in windows.
Note ;-) One of the best features are that Meta Information Saved into the Image not Database. Meta Information are always and everywhere correct.
Reassigned to Baloo and marking as confirmed.
We expect tags to be stored as xAttr right? Windows stores them as 'XP Keywords' exif field as mentioned above. A quick fix could be to make KFileMetaData::userMetaData::tags() read that exif field and return those tags along with the xAttr tags? Or should this be handled by the exif extractor?
(In reply to Pinak Ahuja from comment #5) > We expect tags to be stored as xAttr right? Windows stores them as 'XP > Keywords' exif field as mentioned above. A quick fix could be to make > KFileMetaData::userMetaData::tags() read that exif field and return those > tags along with the xAttr tags? Or should this be handled by the exif > extractor? I was hoping to expand KFileMetaData to add the ability to extract and write back tags. However, I don't want to club it into the UserMetaData class as it's nice to have a simple os independent wrapper over xattr. Eventually, we can create a wrapper on top of both these mechanisms, if required.
(In reply to Vishesh Handa from comment #6) > I was hoping to expand KFileMetaData to add the ability to extract and write > back tags. However, I don't want to club it into the UserMetaData class as > it's nice to have a simple os independent wrapper over xattr. So we extend the exiv extractor to read the exiv field and write them as xattrs?
(In reply to Pinak Ahuja from comment #7) > (In reply to Vishesh Handa from comment #6) > > > I was hoping to expand KFileMetaData to add the ability to extract and write > > back tags. However, I don't want to club it into the UserMetaData class as > > it's nice to have a simple os independent wrapper over xattr. > So we extend the exiv extractor to read the exiv field and write them as > xattrs? Not quite. Here is what I was imagining - * Extractor provides some way to read tags * A new class to write the tags/metadata back into the file * We keep the UserMetaData class users of the kfilemetadata library can then decide what they want to use. If we want we can later create a wrapper over all 3. from a kde user point of view, I'm not too sure what we should be doing by default. Reading/Writing from both? People often do not like their files to be modified as it changes the sha1 hash and what not.
Git commit 06d98a1b9ad475332af12df7de503ee4bb93478f by Stefan Brüns. Committed on 16/11/2023 at 21:46. Pushed by bruns into branch 'master'. [Exiv2Extractor] Add support for XMP DC Title, Subject, Description The XMP Dublin Core metadata may contain title, subject and description values, extract it. Update JPEG, JXL and WebP test images to include Title and Subject. Related: bug 428967 M +17 -3 autotests/exiv2extractortest.cpp D +0 -25 autotests/exiv2extractortest.h M +- -- autotests/samplefiles/test.jpg M +- -- autotests/samplefiles/test.jxl M +- -- autotests/samplefiles/test.webp M +25 -0 src/extractors/exiv2extractor.cpp https://invent.kde.org/frameworks/kfilemetadata/-/commit/06d98a1b9ad475332af12df7de503ee4bb93478f
Waiting for confirmation