| Summary: | Loading metadata from XMP sidecar files | ||
|---|---|---|---|
| Product: | [Applications] gwenview | Reporter: | Nikita U <ds.highwind> |
| Component: | general | Assignee: | Gwenview Bugs <gwenview-bugs-null> |
| Status: | REPORTED --- | ||
| Severity: | wishlist | CC: | audvare, vdanjean.ml, yshuiv7 |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: |
XMP file example
XMP file example |
||
|
Description
Nikita U
2009-09-28 16:08:25 UTC
That would be nice indeed. Could you attach one or more example files to this report? Created attachment 38934 [details] XMP file example An example XMP sidecar file. I've checked this meta-data file to be valid – it is possible to embed tags, creator, publisher and the source of the image into the image file using the exiv2 command line tool (http://www.exiv2.org/). Created attachment 38935 [details]
XMP file example
Allowing to use XMP sidecar file and to not touch the original files will also improve backups: for now, each time I change any metadata (usually tags), the file is backuped again and again. My backup program (backuppc) must store a full new version of the image instead of using (hard)links to the previous 'version'. If XMP sidecar were used, the original image would not change, avoiding similar but not exact copy in each backup. XMP files would be duplicated but their size is a lot smaller than the original image. A second thought: I see that you will use the same basename with the .xmp extension. How will you deal with 'foo.jpg' and 'foo.avi' when both present ? (ignore one ? which one in this case ?) Won't 'foo.jpg.xmp' and 'foo.avi.xmp' be a better choice ? A third thought: some other software (geeqie) allow to read/write xmp files in another directory. This way, photos can be on a read-only medium (CD or ro NFS) and xmp files (and so metadata) can still be edited and saved on the hard-disk. I hope a support for using XMP files will soon be present. Many thanks for your work on this part. Regards, Vincent Oups, my previous comment was for bug 220545. I duplicated it. Anyway, I think that both bugs must be merged. How about reading an XMP file that has the same name as the file minus the extension? I rsync from my iPhone and before iOS 5 the rotation data was not put into the image file. Instead an XMP meta data file would be made with the same name minus the extension. IMG_0266.PNG IMG_0266.XMP The XMP data file (has real \n\0 bytes at the end): <x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="XMP Core 4.4.0"> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Description rdf:about="" xmlns:tiff="http://ns.adobe.com/tiff/1.0/"> <tiff:Orientation>8</tiff:Orientation> </rdf:Description> </rdf:RDF> </x:xmpmeta>\n\0 Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved. This is still not resolved, gwenview still doesn't load metadata from sidecar. |