Export Loses EXIF Data

[ColonelPanics]

Description

When exporting my Ente library every single image separates the EXIF data into a json file that matches the file name. Why is the EXIF data not included with the image (like when downloading an image from Ente)?

This causes all sorts of issues when trying to bulk import my photo library into other applications.

Version

1.7.2

What product are you using?

Ente Photos

What platform are you using?

Desktop - macOS

[mnvr]

Export behaves the same as download. The real issue is that the app has the ability to write Exif only to JPEG files. Likely you're viewing a non-JPEG file from your export which made it seem that the behaviour is different between export and download.

This is confusing indeed, and there have been multiple discussions (internal and with users) around this. Our current plan of action is to remove the part where we update Exif in JPEGs too:

• The behaviour is confusing as you noticed.

• People might be accidentally led to believe (e.g maybe they do a test run with JPEGs) that their Exif is being preserved and they might discard the JSON when actually the metadata is in the JSON only.

• The Exif update even for JPEGs is very limited. It only updates DateTimeOriginal. There is other metadata like captions and descriptions that only remains in the JSON even for JPEGs.

Instead,

• The app will never modify the original, and all metadata (dates, captions, and even Ente specific metadata generated by the user) will be written to the sidecar JSON (like Google Photos does, and/or into a sidecar XMP file, like Apple Photos does).

• We will instead provide a separate utility for people who wish to modify their originals. This utility will be based on exiftool, and will update whatever has a corresponding XMP/Exif slot from Ente's JSON (or XMP). This will allow power users who understand the caveats to modify their originals.

• Thus the behaviour will be consistent across all file types. For convenience, we will see if we can better integrate this separate utility within the existing desktop app too (possibly even as a option that can be toggled during export).

[ColonelPanics]

Thank you for your response!

Likely you're viewing a non-JPEG file from your export which made it seem that the behaviour is different between export and download.

I'm afraid this is not true, the image in my export is FB_IMG_1498073399443.jpg and has an associated FB_IMG_1498073399443.jpg.json. When I find that very same image in the Ente app and download it directly I get FB_IMG_1498073399443.jpg and no FB_IMG_1498073399443.jpg.json (and no EXIF data for creationTime or the like included in the jpg itself) so the EXIF data is essentially lost. (I can confirm that the json file associated with the image in the export has plenty of EXIF data that has been omitted)

I'm a little confused by the feedback here because I'm not trying to modify my photos. I'm looking to download them and the associated information that already exists for them in a way that's easy to work with and doesn't require scripting or mass modification in order to put the files back together as they were during upload.

Our current plan of action is to remove the part where we update Exif in JPEGs

Does this mean that any downloads from Ente are then, essentially, different from the files actually stored/uploaded in Ente seeing as the embedded EXIF data is being removed and/or separated?

[ColonelPanics]

Okay on further inspection it seems that more recent images (ones that I have taken from my camera and not from old google takeout and facebook exports) do include the EXIF data (but still do not download a JSON of EXIF data).

[mnvr]

Does this mean that any downloads from Ente are then, essentially, different from the files actually stored/uploaded in Ente seeing as the embedded EXIF data is being removed and/or separated?

No, they're exactly the same. The only exception is that we try to write the DateTimeOriginal in the Exif of JPEGs when downloading or exporting if you modify its date within Ente after it was imported. This is the code: https://github.com/ente-io/ente/blob/3571281bef869a65c27ee0d329288352ec21064c/web/packages/new/photos/services/exif-update.ts#L86

I'm a little confused by the feedback here because I'm not trying to modify my photos.

If the photo you uploaded already had metadata, then that metadata will be retained. We export the original out unmodified (except for the case I mentioned above, and since this exception is causing confusion, we'll be removing this exception too and instead working on enhancing the JSON that we write).

I think what might be happening is that the photos you're inspecting never had metadata to begin with. When importing from say Google takeout, we try to read the metadata that Google provided in the their JSON. Since we don't want to touch the original, we retain that separately, but you'd have seen the data within Ente. When exporting, we write that out in a JSON, but maybe you're now expecting it to also be in the exported file (but it wasn't in it to begin with).

I'm looking to download them and the associated information that already exists for them

That's already the case. If you upload a photo with Exif, don't do anything with it in Ente, then export or download it from Ente, you will get back the exact same file with the exact same metadata.

[mnvr]

but still do not download a JSON

The JSON is written only when exporting, not when downloading

[ColonelPanics]

I see, my apologies for the confusion! What you mention about google takeout import makes a lot of sense and must be the cause for confusion to me here.

It seems to me like an option to modify files to integrate exif data with them would be useful (perhaps on import/upload of google takeout, for example) but it's not as serious an issue as I thought. I guess that, if I want to take it elsewhere, I'll have to script a solution that merges the exif data from the json files into the original files (and then, perhaps, reupload that to ente but that seems like a rather mammoth task to do without messing something up!)

Thanks for your help and clarification.