+- Gimp-Forum.net (https://www.gimp-forum.net)
+-- Forum: GIMP (https://www.gimp-forum.net/Forum-GIMP)
+--- Forum: General questions (https://www.gimp-forum.net/Forum-General-questions)
+--- Thread: What is the basis for metadata contained in image files produced by GIMP? (/Thread-What-is-the-basis-for-metadata-contained-in-image-files-produced-by-GIMP)
What is the basis for metadata contained in image files produced by GIMP? - ajax - 09-16-2022
Have been using GIMP for long enough to remember when it just couldn't handle metadata. Have been pleased to see that change such that metadata is included. The documentation (i.e., User guide) on this subject has also been a work in progress and seems to lack reliability. For example, the User Guide includes text at the beginning of the main section which says "Note: ... PNG, JPEG, TIFF and WebP preserve existing metadata. ...". Then when reaching down into the more detailed explanations, for Exif data, there is text which says "It is not supported in JPEG 2000 or PNG.". Pretty much adds up to a direct contradiction.
When working with photographs, which is the basis for this post, the idea of simply preserving the metadata produced by the camera is desirable. In the case of Exif data there is a standard which is thought to apply to cameras (i.e., files produced by cameras). This means that post processing software like GIMP and lots of others ought NOT be changing it. Must admit it took a while to notice but that is NOT the case.
It seems that GIMP recognizes different types of metadata to include Exif, XMP, & IPTC. There is also something called Makernotes which is produced by cameras where the term "maker" is believed to mean that it is specific to a particular camera (i.e., proprietary rather than a universal standard). It appears as though post processing software, to include GIMP, treat this as though it is Exif data. For example, GIMP includes it when Exif inclusion is specified for image files to be created and excludes it otherwise.
The new finding is that the Exif metadata included in image files created by GIMP closely resembles what the camera produced. However, one discrepancy involves GIMP adding tags to describe the dimensions of the new image file along with bit depth which is flat out wrong (i.e., Bits per sample: 8 8 8 in the case of an image file with 16 bit precision). It has been noticed the cameras are prone to making this same mistake but that might could be reconciled by saying it applies to the preview image whereas in the example mentioned there is no thumbnail or preview image.
When it comes to Makernotes such minor discrepancies are no longer the case. The differences are major. For example, as much as 30% of tags are simply omitted. Given that Makernotes are particular to the camera it would be expected that GIMP ought NOT be changing anything. What scenario would call for GIMP making such alterations to be desirable? Thinking here is that it would be better for GIMP to omit the Makernotes rather than make changes. What reason might there be for doing this.
Afraid these new discoveries suggest that, at least for Exif data, GIMP's support is more destructive than productive.
RE: What is the basis for metadata contained in image files produced by GIMP? - Ofnuts - 09-17-2022
Yes, there are missing tags...
However,
Some tools put together stuff from the Exif and more technical file data or data computed from the Exif. If you use exiftool -a -H -g Input.jpg you see that some data has no "tag" and only applies to the file, and not to the image that the file is a representation of, so this can change with each instance of the file, and these include Image Height, Image Width and Bits per sample. in particular, if I create a file with 16-bit precision in Gimp and export it to TIFF, I get a 16-bit Tiff and the "Bits per sample" is indeed 16.
RE: What is the basis for metadata contained in image files produced by GIMP? - ajax - 09-18-2022
A statement in my original post is "... bit depth which is flat out wrong (i.e., Bits per sample: 8 8 8 in the case of an image file with 16 bit precision).". I have now pretty conclusively determined that this problem occurs consistently when producing output files in .png format. Output files produced in .tiff format seem to be consistently correct in this respect.
With that said, Makernotes are a consistent mess at least in the case of output files produced in both .png and .tiff format. Unfortunately, requesting Exif metadata seems to necessarily include the messed up Makernotes. Since GIMP does properly adjust a few things that might get revised, such as ImageWidth, ImageHeight, X & Y Resolution, by editing operations it is desirable to include this basic Exif data (possibly referred to by the Group Name of IFD0) in the image files it produces. However, it would be MUCH better if GIMP simply excluded Makernotes from the output files it produces if it cannot do it correctly.
RE: What is the basis for metadata contained in image files produced by GIMP? - mikebyrne - 02-03-2023
(09-16-2022, 09:15 PM)ajax Wrote: Have been using GIMP for long enough to remember when it just couldn't handle metadata. Have been pleased to see that change such that metadata is included. The documentation (i.e., User guide) on this subject has also been a work in progress and seems to lack reliability. For example, the User Guide includes text at the beginning of the main section which says "Note: ... PNG, JPEG, TIFF and WebP preserve existing metadata. ...". Then when reaching down into the more detailed explanations, for Exif data, there is text which says "It is not supported in JPEG 2000 or PNG.". Pretty much adds up to a direct contradiction.
When working with photographs, which is the basis for this post, the idea of simply preserving the metadata produced by the camera is desirable. In the case of Exif data there is a standard which is thought to apply to cameras (i.e., files produced by cameras). This means that post processing software like GIMP and lots of others ought NOT be changing it. Must admit it took a while to notice but that is NOT the case.
It seems that GIMP recognizes different types of metadata to include Exif, XMP, & IPTC. There is also something called Makernotes which is produced by cameras where the term "maker" is believed to mean that it is specific to a particular camera (i.e., proprietary rather than a universal standard). It appears as though post processing software, to include GIMP, treat this as though it is Exif data. For example, GIMP includes it when Exif inclusion is specified for image files to be created and excludes it otherwise.
The new finding is that the Exif metadata included in image files created by GIMP closely resembles what the camera produced. However, one discrepancy involves GIMP adding tags to describe the dimensions of the new image file along with bit depth which is flat out wrong (i.e., Bits per sample: 8 8 8 in the case of an image file with 16 bit precision). It has been noticed the cameras are prone to making this same mistake but that might could be reconciled by saying it applies to the preview image whereas in the example mentioned there is no thumbnail or preview image.
When it comes to Makernotes such minor discrepancies are no longer the case. The differences are major. For example, as much as 30% of tags are simply omitted. Given that Makernotes are particular to the camera it would be expected that GIMP ought NOT be changing anything. What scenario would call for GIMP making such alterations to be desirable? Thinking here is that it would be better for GIMP to omit the Makernotes rather than make changes. What reason might there be for doing this.
Afraid these new discoveries suggest that, at least for Exif data, GIMP's support is more destructive than productive.
Hi,
I have just recently begun to use GIMP 2.10.12 for retouching images - but have used it for years for drawing. What I now notice is that images exported as JPEG's invariably have the current day's date and time as the DateTaken and this, in my examples, is often several years ago.
I have had to resort to using jExifGUI to reinstate the correct dates and times in the newly-saved images. This is probably a mix-up in selecting which date tags to read from and write to in this newer version of GIMP as in the relatively few images saved in earlier versions I never noticed this behaviour.
I often use Faststone Viewer to compare original and edited images and like to have them appear side-by-side in the thumbnails so I can use the arrow keys to switch quickly and easily from one to another to compare. Beefore-and-After comparisons within software is of little use to me as I often want (need?) to compare several versions rather than simply two.
Has anybody else noticed this changed dates and times issue? I should be interested to hear if anybody has, and I am also interested to know Ajax has fared with the problem he outlined in the above quote.
I am guessing that if a way could be found to temporarily disable ExifTool operations within GIMP the problem might be solved since GIMP couldn't then read or write to image files. What do other user think?
Lastly, as a new member, Hello to all and thanks in advance for any comments.
Mike