Import description from EXIF data

[chipoman]

I have hundreds of photos that have their description stored in the EXIF data (the same data is in the title, caption and headline tags). Can I get Ente to put this into its description field when uploading photos? It's not a job I want to do manually for every photo! Many thank for any help.

[mnvr]

Ente can reads the description from the "description" field in the Google Takeout JSON (this feature is available on the web app, and will also be available in the next desktop app release 1.7.6, expected to be out in a day or two). Inspite of the Google in its name, this is a generic JSON file that can be created by any software (Ente itself will write out data when exporting in this same format).

So one option is to use exiftool to extract the relevant Exif tags, and put them into a JSON file, one for each of the photos that have the caption. This file has a simple format, and in particular, if one only wishes to use it to provide the description during the import, it can be just a simple file like this:

{"description": "xyz..."}

For a file named eg. flower.jpg, a file with contents like above can be placed next to it and named flower.jpg.json. Then Ente will automatically read it during the import.

I understand this might be cumbersome for people not acquainted with shell scripting, I'm only mentioning this flow just in case it helps since you asked for "for any help" :)

---

ps. if possible, could you also mention the exact Exif tags which has the description. We've had conflicting information about which (if any) Exif tag is meant as as standard for descriptions / captions, and thus we avoid reading them to avoid cluttering the user's photos with autogenerated (e.g. by camera makers) descriptions. But if there is indeed an Exif tag which is reserved solely for user generated descriptions, that would be good to know.

[chipoman]

Thank you for your detailed response, @mnvr. I am considering a move away from Flickr (deadline for decision 20 November) and if I swap to Ente, I will have about 2,500 photos to upload. They are ordered in albums by filename (this works well because I have the same order mirrored in folders on my desktop drive). I use gthumb on my Linux desktop, which works very well for organising photos and loading them, with their title, up to Flickr. The big gain with Ente is obviously privacy and protection for my data, but I still want to be able to share (and, I admit, "show off") my photo albums to family and friends. So, having a nicely organised and presented album is important to me. The safest thing to put in the Ente description, by default, would be the filename. I have consistently used this to organise and describe my photos for 20 years. I have used different apps over the years which have written different EXIF tags (I agree with you about the lack of standards!) The one I have been able to rely on though is, "Title". All the apps have written to this and Flickr imports it like a dream. I'll try and attach a screenshot from exiftool. I hope that helps! Thanks again. Best wishes.

[mnvr]

That's great that your photos have a single tag that you can use! In that case, one option is to use exiftool to extract that tag's value, write it into a JSON file that I described above. Then when you drag and drop both the image and the corresponding JSON (or select the folder with them side by side), Ente will read in the description.

For example, here is a quick shell script I made as a proof of concept (warning: untested, use at your own risk, I just wished to provide it as a sample/starting point, I feel there might be other more robust such scripts out there):

#!/bin/sh                                                                                                                        

for f in *.JPG; do
  printf '{"description":"' > "$f.json"
  exiftool -s3 -title "$f" | tr -d '\n' >> "$f.json"
  echo '"}' >> "$f.json"
  echo "Created $f.json"
done

What this will do is create a file like flower.JPG.json for each JPG in the current folder, and that JSON will look like this

$ cat IMG_4380.JPG.json
{"description":"Test"}

[chipoman]

Thank you for the further help, @mnvr. I really appreciate it. I'm beginning to think I may be able to make this work by writing a script (if my coding is up to it!) I have realised that while all the photo managers I've used have written to the title tag, there are many photos were I have not added a title, just relying on the file name. I'm going to have a go at writing a script that will look for the title tag and if it doesn't find it, use the filename (with ".jpg" stripped") as the description. At the same time (in relation to #3859 about dates, I'll see if I can strip the date from the filename and add that to the JSON too. This will at least give me some description (rather than it being blank) and hopefully result in the photos being in the right order in the albums. :)

[chipoman]

[scott-ainsworth]

There are many standards and conventions for placement of title, description, caption, etc. in photo metadata. Given its dominance, please consider supporting the tags created by Lightroom Classic exports. (These tags seem to be used by SmugMug--which exactly, I don't know.) Here is an abbreviated exiftool dump from a Lightroom Classic export:

[System]    FileName            : 20250104-5697 - Snowy egrets (Egretta thula) fishing - final sRGB 3961 x 1980 LR92 geo.jpg
[IFD0]      ImageDescription    : These snowy egrets...
[IPTC]      ObjectName          : Snowy egrets (Egretta thula) fishing
[IPTC]      Caption-Abstract    : These snowy egrets...
[XMP-dc]    Title               : Snowy egrets (Egretta thula) fishing
[XMP-dc]    Description         : These snowy egrets...

[StefanOltmann]

I conducted some research to understand how different tools handle this.

The screenshots below are from my tool https://stefan-oltmann.de/exif-viewer

---

If I take a blank original.jpg and add a description using Microsoft Photo I get a microsoft_photo.jpg that has EXIF IFD0 | 0x010e | ImageDescription, XMP-dc:description & XMP-dc:title set:

ACDSee offers multiple fields that look suitable for a description (like title & headline), but regardless in which "description" field the users enter the data, it will be written into EXIF IFD0 | 0x010e | ImageDescription, XMP-dc:description, XMP-dc:title & IPTC | Caption/Abstract (120):

Picasa writes XMP-dc:description and IPTC | Caption/Abstract (120) (but no EXIF):

Like ACDSee Mylio has separate fields for a title and a description:

It seems other tools also rely on the same fields that @scott-ainsworth mentioned for Lightroom. There doesn’t appear to be any additional fields in play.

---

The interesting question now is: in what order should these fields be read if they contain conflicting values?

As always, ExifTool is our friend here:
exiftool -overwrite_original -IFD0:ImageDescription="This is IFD0 ImageDescription" -IPTC:ObjectName="This is IPTC ObjectName" -IPTC:Caption-Abstract="This is IPTC Caption-Abstract" -XMP-dc:Title="This is XMP-dc Title" -XMP-dc:Description="This is XMP-dc Description" conflicting.jpg

That created conflicting.jpg:

---

Microsoft Photo prioritizes the XMP-dc:title field.

Picasa uses the XMP-dc:description field for its main text display but shows both XMP-dc:title and XMP-dc:description in its detailed metadata view.

ACDSee and Mylio display both XMP-dc:title and XMP-dc:description if XMP data is available, while ignoring all other metadata fields.

This makes it clear: if XMP data is present, it should always take precedence. This approach makes sense because XMP is the most modern metadata format.

Additionally, if you later introduce support for sidecars, an XMP sidecar should override any embedded metadata values. This behavior is standard and expected in tools with XMP sidecar support, such as Mylio and Ashampoo Photo Organizer.

When choosing between XMP-dc:title and XMP-dc:description for a single "description" field, you could flip a coin. However, the ideal solution would be to display both fields to ensure complete and accurate metadata representation.

---

Going further: What happens if there is no XMP like in conflicting_without_xmp.jpg?

In this case, Microsoft Photo ignores IPTC data and displays EXIF IFD0 | 0x010e | ImageDescription.

On the other hand, ACDSee and Mylio both prioritize displaying the IPTC values, while Picasa specifically opts to show the IPTC Caption/Abstract field.

---

In conclusion, Ente should remain consistent with other commonly used tools. Users may become confused if it displays fields different from those used by tools they are likely familiar with.

Read the description in order:

1. XMP-dc:description
2. IPTC | Caption/Abstract (120)
3. EXIF IFD0 | 0x010e | ImageDescription

Read the title in order:

1. XMP-dc:title
2. IPTC | ObjectName (5)

If you need to fill in a single field, flip a coin to decide whether to prioritize the "title" or "description" field first. Providing both fields will generally be less confusing.

Conflicting values shouldn’t be a major issue, as good tools typically write consistent values to multiple places and ensure they include XMP data. Poorly designed tools might not, but those tools are best avoided altogether.

Additionally, I reviewed some of my out-of-camera JPEGs, and it seems camera manufacturers don't usually populate the "description" or "title" fields with default values. So, it's unlikely you'll encounter entries like "Shot with Canon" or similar placeholders.

---

@scott-ainsworth If you like, add the order in which Lightroom classic finds the fields. I don't have that tool available.

---

I hope my research was valueable for you! :)

[mnvr]

It was valuable indeed. Thank you, I have implemented this flowchart in #4629. The changes are already deployed on the web app, and will be in the next desktop app release too (1.7.8).