Re: [Gimp-developer] Bug: Gimp 2.10.18 strips off many Exif-data from jpg-files when processing
Am 09.07.22 um 03:36 schrieb Jacob Boerema: On 2 Jun 2022 at 11:45, Adalbert Hanßen wrote: I use GNU Image Manipulation Program Version 2.10.18 on Xubuntu 20.04.4 LTS (64 Bit). There have been a lot of improvements to our metadata handling after version 2.10.18. I would suggest trying the latest version 2.10.32, possibly as a flatpak, because you also need the latest exiv2 and gexiv2 for up-to-date metadata handling. ... Jacob, thank you for the response. First I was a bit sceptical if Gimp installed as Flatpak can access files from |/tmp |which I often use in order to take delayed screenshots by a shortcut like this: xfce4-screenshooter -fmd 7 -o gimp Once I had Gimp installed as a Snap and it did not work for delayed screenshots because Snaps have difficulties accessing |/tmp|. Perhaps Flatpak behaves differently. I gave it a try to install the current version of Gimp in parallel with sudo flatpak installhttps://flathub.org/repo/appstream/org.gimp.GIMP.flatpakref and I only had to change the screenshot call to xfce4-screenshooter -fmd 7 -o "flatpak run org.gimp.GIMP//stable" in order to continue working (the double quotation marks are crucial!) ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Bug: Gimp 2.10.18 strips off many Exif-data from jpg-files when processing
On Fri, 2022-07-08 at 18:45 -0600, Akkana Peck wrote: > > > Once we get to non-destructive editing using GEGL ops, I could > imagine an EXIF field listing a set of ops used for processing. Undo history in exif might be interesting, agreed, although i think it remains to be seen how that'd work for e.g. brush strokes. I was wondering if the original poster had a use for it today, though :) -- Liam Quin - https://www.fromoldbooks.org/ with fabulous vintage art and fascinating texts to read. https://www.delightfulcomputing.com/ Full-time "slave" in voluntary servitude ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Bug: Gimp 2.10.18 strips off many Exif-data from jpg-files when processing
On 2 Jun 2022 at 11:45, Adalbert Hanßen wrote: > I use GNU Image Manipulation Program Version 2.10.18 on Xubuntu 20.04.4 > LTS (64 Bit). There have been a lot of improvements to our metadata handling after version 2.10.18. I would suggest trying the latest version 2.10.32, possibly as a flatpak, because you also need the latest exiv2 and gexiv2 for up-to-date metadata handling. Besides that, camera makers are part of the problem. They introduce all kinds of proprietary data with every new model. It is always a race to keep up-to-date with new info from all brands and models. Anyway. If an up-to-date GIMP with up-to-date metadata libraries as mentioned above still has problems, then the best thing to do is open an issue, with a zipped (or otherwise compressed) example image attached. It needs to be zipped, because GitLab usually removes most metadata from images. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Bug: Gimp 2.10.18 strips off many Exif-data from jpg-files when processing
> On Thu, 2022-06-02 at 11:45 +0200, Adalbert Hanßen wrote: > > *Suggested further improvement:* Add a new category “Gimp Processing” > > telling about the image processing procedures applied, e.g. lighting > > adjustments and their parameters, color adjustment, cropping, and the > > like in readable form. Liam R E Quin writes: > It's an interesting idea - how would this information be used? Once we get to non-destructive editing using GEGL ops, I could imagine an EXIF field listing a set of ops used for processing. Imagine being able to save as JPEG yet still be able to load back into GIMP and undo the last few ops. Yes, there would be some loss of quality because of lossy compression, and it's certainly not a substitute for saving as XCF, but I can imagine cases where it might be useful anyway. ...Akkana ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Bug: Gimp 2.10.18 strips off many Exif-data from jpg-files when processing
On Thu, 2022-06-02 at 11:45 +0200, Adalbert Hanßen wrote: > > but not shown in Gimp, e.g. the Lens Type. > > *W**hy does Gimp not show the **le**ns**type?* Can you share a sample image? When you export as JPEG make sure "save exif" is checked! > > *Suggested further improvement:* Add a new category “Gimp Processing” > telling about the image processing procedures applied, e.g. lighting > adjustments and their parameters, color adjustment, cropping, and the > like in readable form. It's an interesting idea - how would this information be used? liam / ankh / demib0y / barefootliam -- Liam Quin - https://www.fromoldbooks.org/ Full-time "slave" in voluntary servitude ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
