I'm using geeqie to add Subject tags and Titles to my JPEG files. If I later edit one of these files in Gimp and overwrite, the metadata is lost, even though I checked the option to save XMP data. The console has errors like this: Metadata parasite seems to be corrupt While parsing XMP metadata: Error on line 57 char 1: Nested elements (<rdf:Bag>) are not allowed in this context ** (file-jpeg:3579): WARNING **: JPEG - unable to decode XMP metadata packet While parsing XMP metadata: Error on line 58 char 1: End of element <exif:Flash> not expected in this context gimp-2.8.4-3.fc19.x86_64
Matt, would you please attach an image file which exhibits the problem, i.e. has such an additional tag? Thanks.
Created attachment 751332 [details] Before edit in gimp
Created attachment 751333 [details] After open in gimp and export to jpg
Added before and after images. It's possible that it's actually Geeqie (and exiv2) in the wrong; after the edit it (or just exiv2 directly) says: Error: XMP Toolkit error 203: Duplicate property or field node Warning: Failed to decode XMP metadata. but exiftool works fine.
Still in gimp-2.8.14-1.fc22.x86_64
GIMP appears to create this bug itself ... A picture directly from a camera, does not have the problem. Once the file has been loaded into GIMP, and then exported as a JPEG (using command-line batch mode) The resulting saved JPEG image demonstrates the above problem if subsequently reloaded into GIMP, with following errors ... While parsing XMP metadata: Error on line 43 char 1: End of element <exif:Flash> not expected in this context While parsing XMP metadata: Error on line 57 char 1: End of element <exif:Flash> not expected in this context Metadata parasite seems to be corrupt Using ... localhost:Test.dir> gimp -v GNU Image Manipulation Program version 2.8.14 git-describe: GIMP_2_8_12-2-ge62e6fe using GEGL version 0.2.0 (compiled against version 0.2.0) using GLib version 2.42.1 (compiled against version 2.41.5) using GdkPixbuf version 2.31.1 (compiled against version 2.31.1) using GTK+ version 2.24.22 (compiled against version 2.24.22) using Pango version 1.36.7 (compiled against version 1.36.7) using Fontconfig version 2.11.1 (compiled against version 2.11.1) using Cairo version 1.12.16 (compiled against version 1.12.16) Attachments for original, processed images and batch file script to follow
Created attachment 958542 [details] Original Camera JPEG
Created attachment 958543 [details] Gimp created JPEG This JPEG demonstrates the bug
Created attachment 958544 [details] batch file for gimp command-line mode script file run from command line using > gimp -i -b '(batch-jpeg-resize "*.jpg" '$QUALITY' )' -b '(gimp-quit 0)
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
I think I've found a corresponding bug upstream and it doesn't look well for existing stable versions of GIMP. https://bugzilla.gnome.org/show_bug.cgi?id=746958#c15 "I think we can all agree about metadata being totally broken in 2.8, probably unfixably broken. ..." As I understand it, GIMP on the master branch, i.e. the version that is slated to become 2.10 eventually, has a different metadata implementation that shouldn't show this problem, but the upstream reporter hasn't tested this yet. Matt and Enski, can you test this with either git master of gimp (ideally), or the gimp-unstable package from my COPR (which is version 2.9.4)? https://copr.fedorainfracloud.org/coprs/nphilipp/gimp-unstable/ You can then post your results here, or upstream. I'll close the bug as UPSTREAM, because I don't see how I can fix this here ;).
I can't test your Copr right now because there are no F25 builds, but I tried the nightly Flatpak, which is 2.9.4 (build becd85e), and that appears to... entirely destroy all EXIF and XMP metadata. So.... I'll have to find a nightly build of master, I guess, to figure it out.