Export to jpg stripping exif data sometimes.

[kaditcha]

I am editing pictures for publication on a naturalist web site.  Workflow is: open original which is a .jpg, crop it, maybe scale the result then export as a .jpg to a different directory.  Has been working OK but now processing a different batch of images and it is stripping the exif data from the export.  I am needing the creation date and GPS location but all is missing.  The metadata is visible within GIMP in the original image and in the cropped image but does not make it to the export.  Export options are the same for both batches as far as I can tell.  (Newbie user).

Two differences I am aware of, the files are older (2013)  compared with earlier batches (oldest 2018) and the camera is different.  As a data free observation, the age of the GPS data may be an issue, there has been a date rollover since the images were taken but I have no idea why GIMP can read the data but not write it.  Since I noticed this I have processed some more files in the more recent batch and these continue to process correctly.

Using GIMP 2.10.20 rev 1 on Windows 10.  I have read the help and searched this forum for topics on export but have not found this issue.

[Ofnuts]

Can you share one of the unedited images?

[kaditcha]

(08-06-2020, 07:04 AM)Ofnuts Wrote: Can you share one of the unedited images?

Happily.  If I could, but they are too big just now, the system rejects them. I will be able to reduce the file size for one of those which works and one of those which does not but I can't do that for the original of one which does not because catch 22.  If you can get an email to me without plastering it all over the board I will send them that way then you can have a before and after.  They are about 4M each.  Thanks.

Or perhaps I can do something with native format.  Don't know what that will do to the data.

[Kevin]

There is an issue reported for this: https://gitlab.gnome.org/GNOME/gimp/-/issues/1367

[kaditcha]

(08-06-2020, 07:04 AM)Ofnuts Wrote: Can you share one of the unedited images?

If it is any use these are the exports of metadata from GIMP for two of the files.  Looking at the data in another viewer I notice that the one that works has little endian byte order and the other camera has big endian but I have no idea of the significance of that.  Unfortunately cannot export from that viewer.  Looking for another tool.

[kaditcha]

(08-06-2020, 09:49 AM)Kevin Wrote: There is an issue reported for this: https://gitlab.gnome.org/GNOME/gimp/-/issues/1367

Thanks for the info.  One difference with those reports is that, for me, these failures are entirely consistent.  I was working with a sample of twenty or so images selected, based on subject matter, from a set of several hundred taken over four months and every one of the selected images behaves the same way.  I cannot separate the problem from either age of image (GPS date rollovers and the like) or change of camera (format of the data).  I don't have images from each camera which overlap in date and the Pentax has gone to God.

[kaditcha]

(08-07-2020, 02:10 AM)kaditcha Wrote:

(08-06-2020, 07:04 AM)Ofnuts Wrote: Can you share one of the unedited images?

If it is any use these are the exports of metadata from GIMP for two of the files.  Looking at the data in another viewer I notice that the one that works has little endian byte order and the other camera has big endian but I have no idea of the significance of that.  Unfortunately cannot export from that viewer.  Looking for another tool.

And here are the full data files from the same two images

[Kevin]

You mention Pentax. That reminds me of the bizzare Pentax issue: https://gitlab.gnome.org/GNOME/gimp/-/issues/2253

[Ofnuts]

(08-07-2020, 02:10 AM)kaditcha Wrote: Looking at the data in another viewer I notice that the one that works has little endian byte order and the other camera has big endian but I have no idea of the significance of that. 

Also noticed that. But I have images from a former smartphone that are big-endian and that work. And It appears that Gimp reads both kinds (as shown in Image>Metadata), but always uses small-endian when saving the image (at least on X86/AMD64 systems, but these are nearly all laptops/desktops these days).

[kaditcha]

(08-07-2020, 08:23 AM)Kevin Wrote: You mention Pentax. That reminds me of the bizzare Pentax issue: https://gitlab.gnome.org/GNOME/gimp/-/issues/2253

You sir are a genius!  I edited PENTAX to Pentax.  There were two occurrences in "Pentax maker notes" Lens type which was coded and I could not change that but I made two changes in "Image file main directory image" which did not do the trick but I found another two occurrences in "XMP TIFF properties"  and bingo!  Now that is one trial and I need to do more images and test if the changes in XMP TIFF are sufficient on their own but this is a good start.  I will post results here.  As you say, bizarre.

Thank you.

---

(08-07-2020, 08:27 AM)Ofnuts Wrote:

(08-07-2020, 02:10 AM)kaditcha Wrote: Looking at the data in another viewer I notice that the one that works has little endian byte order and the other camera has big endian but I have no idea of the significance of that. 

Also noticed that. But I have images from a former smartphone that are big-endian and that work. And It appears that Gimp reads both kinds (as shown in Image>Metadata), but always uses small-endian when saving the image (at least on X86/AMD64 systems, but these are nearly all laptops/desktops these days).

This is a Lenovo laptop so nothing wierd in hardware.

---

(08-07-2020, 09:48 AM)kaditcha Wrote:

(08-07-2020, 08:23 AM)Kevin Wrote: You mention Pentax. That reminds me of the bizzare Pentax issue: https://gitlab.gnome.org/GNOME/gimp/-/issues/2253

You sir are a genius!  I edited PENTAX to Pentax.  There were two occurrences in "Pentax maker notes" Lens type which was coded and I could not change that but I made two changes in "Image file main directory image" which did not do the trick but I found another two occurrences in "XMP TIFF properties"  and bingo!  Now that is one trial and I need to do more images and test if the changes in XMP TIFF are sufficient on their own but this is a good start.  I will post results here.  As you say, bizarre.

Thank you.

---

(08-07-2020, 08:27 AM)Ofnuts Wrote:

(08-07-2020, 02:10 AM)kaditcha Wrote: Looking at the data in another viewer I notice that the one that works has little endian byte order and the other camera has big endian but I have no idea of the significance of that. 

Also noticed that. But I have images from a former smartphone that are big-endian and that work. And It appears that Gimp reads both kinds (as shown in Image>Metadata), but always uses small-endian when saving the image (at least on X86/AMD64 systems, but these are nearly all laptops/desktops these days).

This is a Lenovo laptop so nothing wierd in hardware.

Except perhaps my spelling