GNOME Bugzilla – Bug 338360
XMP Metadata as sidecar .xmp files
Last modified: 2010-07-02 18:32:09 UTC
XMP Metadata should be written as sidecar .xmp files
For RAW files you mean, what's wrong with embedding these into JPEGs?
For *any* file. What is wrong is that I see my JPEG files off camera as a pure read-only set of data.
Changing to Enhancement. For me, the picture itself is the original. But the exif/xmp data is the wrapping around it. Think there is work to create/read a sidecar for raw files, but not for JPEGs.
What's the point of file metadata if it's not in the file? I understand and endore the desire for sidecar xmp files, but I _want_, nay, _demand_ that my metadata be in my file. If an application can't be trusted to read/write metadata without touching the data itself, then that's a completely different issue. If you _really_ don't want to add any actual data to your precious "originals" then I bet you don't actually _use_ your originals either.
some originals perhaps do not support embedded xmp tags? RAW files comes to mind, but I am not 100% sure.
RAW are not to be rewritten. I myself consider files coming from the camera to be *read-only* too.
About comment #2 and #6, whether or not the comments are in the file is orthogonal with whether or not there is an unaltered original file from the camera. (If one wants an unaltered original and comments in the file, then f-spot could make a copy of the file.) Personally, I strongly prefer keeping the metadata IN the file because it makes it much easier to back up or copy the metadata with the image. (I.e., one can use cp rather than being forced to use f-spot, and one doesn't need to put extra files in all of the exported formats.) About comment #5, I believe most (all?) raw formats support embedded metadata. After all, the camera manufacturers have to save the metadata too.
> About comment #5, I believe most (all?) raw formats support embedded metadata. > After all, the camera manufacturers have to save the metadata too. > Writting RAW shouldn't even be allowed. These file format are highly undocumented and modifying them, even if they are mostly TIFF containers is a sure way to have problem in the future given the overall quality and bulletproofness (or lack thereof) of software these days. As for the metadat they support, it is only EXIF (or a subset of). As for backing up, a .xmp next to the .jpg or .{crw,cr2,nef,*} does not pose backup problems. Actually it is easier than the undocumented fspot database (yes I know it is a sqlite and the schema is quite easy to understand).
There is also PNG wich AFAIK has no standard way to embed XMP in the file itself.
png supports xmp embedding and f-spot supports xmp embedded in png.
It seems that some people really want metadata added to the original file but others don't. Because there are formats, such as raw, that make it difficult to update, an option to write metadata or not should exist. This option would be very similar to the import option to copy the files to the Photos area or not. A different question arises at export time. If the export format supports writing the metadata, should the metadata be written on export? Something like 'write metadata to image during export?' Now that I think about it, many of the suggestions for import features, such as writing a copyright notice to the image, should really be implemented in the export phase.
Any updates on this bug/enhancement? I would love to have a more standardised/unified tag format. I'm hoping that it will take the pain out of (re-)using the F-spot tags in other photo software (e.g. solang)
Scheduling this for 0.7.1, if we can get Taglib# support ready in time (bug 618682).
Created attachment 165131 [details] Preferences screenshot. This has been added and is available on the taglib-metadata branch, which should be merged in time. The bug to watch out to is bug 618682.