[Feature Request] Write Metadata like Release Date&Time into Images

[Aster-the-Med-Stu]

As talked in #248 it is possible to write all available metadata into file or folder names. So why not write them into picture's EXIF data for photo management softwares like DigiKam?

Besides, it is possible to add EXIF data into a png file.

[SonicoXD]

+1, this would come in extremely handy. This could be done by using exiftool to write the metadata.

[Korvox]

I surveyed the landscape for implementing this:

• Theres a pure python exif library that does have some users but is relatively new. Testing shows it works though and is license compatible. It looks a bit fragile in what files it likes - some pngs it can read, some pngs it can't, etc. Also depends on plum.
• pyexiv2 is a mature framework for all metadata types but has both a c++ library dependency on exiv and is license incompatible being GPL3. In general exiv is the de-facto standard library in open source for image metadata manipulation, though. And the library itself is GPL2 licensed so if there were another wrapper it would work? Theres another wrapper called just exiv2 that is Windows only and MIT licensed.
• python-xmp-toolkit is xmp-only, has a binary lib dependency on Exempi, and isn't tested to work on Windows. Is license compatible but also looks pretty dead going 3 years with no commits.

So the exif package looks like a reasonable path to take. Since XMP is an Adobe spaghetti standard of fraken-XML implementing a pure-Python parser seems way out of scope of sanity and having a binary library dependency seems like a no-go. A shame since in theory XMP is way more sane to actually use since its not fixed-index binary data throughout your image file.

[Aster-the-Med-Stu]

Is it possible using external tools and a wrapper like how ffmpeg is used? Exiftool is a handy tool for doing these things. It could write EXIF, IPTC and XMP, available on Windows, Linux and MacOS, and is actively maintained.

Exiftool itself is using the same license as perl (GNU or the "Artistic License").

[Blinix]

Would be really useful to classify images. Right now the only way I can do something like this is by adding a line like this one to the config "filename": "{id}_{num}_{tags}.{extension}", then searching that tag in the search bar and finally editing the details of the image to add that tag. Can take some time, but I only add the series name tag to the images I download so its quick for me. I believe long filenames can create some problems on windows but so far I dont have that problem.

[github-account1111]

Can this be done for videos too? Just generally all downloaded files?

This is kinda what I was trying to achieve in #1884 - embed the post url into the file.

[Hrxn]

As basically already mentioned in here: Not without an external dependency (like Exiftool).

_{Edit: Of course it is also possible to do this directly with Python.. but this would be a massive increase of the codebase, I guess, because this would need to be rolled by hand}

But it should actually be possible already... That's what the exec postprocessor is for, which can run commands for every item handled by gallery-dl.

So, based on these... Exec postprocessor example 1 Exec postprocessor example 2

...the command would be something like this:

{
    "name"   : "exec",
    "async"  : false,
    "command": ["/path/to/exiftool-binary", "-keywords={category} -keywords={title}", "{_filename}"],
    "event"  : "after"
}

This is only a basic example of the Exiftool CLI syntax, obviously. But the principle should stand. Note that we have to use the built-in {_filename} as the final argument for Exiftool, which is the destination file. The other argument is the usual gallery-dl metadata collection that can be used freely here.

So, if someone wants to try :)

[github-account1111]

@Hrxn this is insanely helpful! I tried:

"url-metadata": "gdl_file_url",
"postprocessors": [
  {
    "name"   : "exec",
    "command": ["/path/to/exiftool-binary", "-overwrite_original", "-title={gdl_file_url}", "{_path[4:]}"]
  }
]

(had to use {_path[4:]} because it was prepending weird stuff like \\\\?\\ with {_path}) and while this does successfully save the file's url as the file's title, putting "-comments={gdl_file_url}" instead leads to a Warning: Sorry, comments is not writable Nothing to do. error, and I kinda don't wanna save anything into the Title field, because that one gets overused by various image viewers and video players.

Edit: Oh so it does apparently work for videos. But not images. I guess images don't have a Comments field? But then, there's definitely a Comments field in Windows' File Properties window for jpgs..

Is there maybe a field that's common across both video, audio and images?

Edit 2: I've also realized some of the downloaded pngs (like 50%!!) don't even have a Title field. Even from the same website.

Edit 3: Disregard Edit 2. PNGs do have a Title field, but Windows doesn't show them for PNGs. This could be useful for those on Windows: https://exiftool.org/forum/index.php/topic,6591.msg32875.html#msg32875 Of note are "xp" fields.

[KonoVitoDa]

@Hrxn @Hrxn any ideas on how to write japanese characters in the metadata? In my attempts they are always being replaced by "?".

[rudolphos]

This would be very useful for downloading flickr photos with tags, titles and descriptions and written in EXIF or IPTC fields of the jpeg.

But is it possible to use gallery-dl to acquire flickr photo page metadata info about location? Sometimes jpeg itself doesn't have geolocation data, but author has chosen to select it manually on a flickr page. This location data is not embedded in the downloaded jpeg.

Example photo. The jpeg file doesn't contain location data, but it is set on the flickr page as 'Santa Teresa Gallura, Sardegna, Italia'

[cunlem]

This would be very useful for downloading flickr photos with tags, titles and descriptions and written in EXIF or IPTC fields of the jpeg.

Flickr started stripping Exif tags from uploaded files at some point and making them available through webpage only. The necessary step would be extracting them as gallery-dl keywords. Then they could be reapplied to file with postprocessor as demonstrated above