ExifTool – Read, Write and Edit Meta Information
exiftool.org
exiftool.org
pip install xklb[full]
library fsadd --image ./photos/
Actually, I'm not sure if I wrote my pyproject.toml correctly. You may need to install PyExifTool directly: https://github.com/chapmanjacobd/library/blob/f778e22bf80c58... # List all metadata of a file (exif)
exiftool -s screenshot.png
# Remove GPS coords in a file
exiftool -gps:all= filename.jpg
# Clear out all metadata
exiftool -all= filename.jpg somesong.mp3What I’m trying to highlight is that an image’s literal metadata may include some data that in practice would be considered part of the main content. It would be nice if we had some clear, common language with which to draw that distinction rather then resort to enumerating individual fields.
exiftool -all= -tagsfromfile @ -AllDates -Make -Model -LensModel -Artist -FNumber -ISO -ExposureTime -ExposureProgram -ExposureMode -ExposureCompensation -FocalLength -WhiteBalance -Flash photo.jpgWhen on mobile, I use Imagepipe for this, it can be found on F-droid.
It works on multiple files too. Much less flexible than exiftool, but still sometimes useful.
* https://en.wikipedia.org/wiki/Photo_response_non-uniformity
> This table is either carried in camera non-volatile memory and dynamically applied to the image on each capture, or ships with the camera to be applied by an external image processing and correcting pipeline.
Not affiliated, just love it.
What is the date of an image other than when it was taken?
you can image an image (say a print) so that the newly taken image has a NOW() like date but you can then put in the date of the actual image into metadata.
Trying to get exif to handle this kind of random approximation to date is really hard. The systems just don't agree "how". Dublin core has several approaches. They map into EXIF. Kinda.
Google, simply never rescan. If you autoload the image as yesterday, that's its date forever. Change by hand in photos is hard. Microsoft does appear to relearn. Apple? Not sure.
I've also read that ISO 8601 (https://www.datafix.com.au/BASHing/2020-02-12.html) covers approx dates.
I haven't seen any standard though on how to actually record that data in a files metadata. Could you point me in the right direction there?
I want to be able to indicate what aspects of a date are real and which ones are estimated or calculated. Or which ones are just missing.
Exiftool supports missing date elements, but only if you have the higher order elements. For example, you can have just the year and month and no day, but you can't have month and no year. See this in the exiftool FAQ: https://exiftool.org/faq.html#Q5
It isn't guaranteed that other tools will know what to do with partial dates either way.
Dublin Core/ISO 8601/Library of Congress has a comprehensive spec for partial dates: https://www.loc.gov/standards/datetime/ While the spec looks good, I haven't seen any solution of saving this as metadata. I'd love to get my hands on some assets that LOC tagged with this spec to see how they log it. There is a python library that supports the extended datetime format, (not for metadata tagging though): https://pypi.org/project/edtf/
GEDCOM, the standard genealogy format, supports its own version of partial dates https://www.gedcompublisher.com/en/dates.htm
Flickr has it's own version of partial dates that can only be updated online/API and not pulled through metadata: https://www.flickr.com/services/api/misc.dates.html
I am in the process of scanning and archiving about 20k old family photos from the 1850s to today. My goal is a format to reliably log the metadata in the photo in such a way that it is clear when dates are accurate or guesses.
From what I can tell, the ideal path (aside from everyone agreeing to a standard in metadata) is to not use partial dates in the standard date fields because of compatibility issues. That leaves the only option of using other fields to indicate the status of the date. There are thousands of esoteric potential metadata fields that exiftool can read and write to, but also for compatibility sake, I'd like to stick to standard fields that most tools can at least read.
There are 3 main options I am looking at: 1) Keywords: log the status of the date in a standard keyword format. Something like. "DateStatus: 1950S2" In the edtf from the python library above. 2) Description or Notes field: Use a standard text string in one of these two fields similar to keywords solution above. 3) Use the time aspect of the datetime fields to indicate the status. Come up with a code using the hours, minutes and seconds part of the date to indicate the status of the date field. Something like: if seconds = 22 then year is estimated. This could work seeing as the time of scans is typically not known. (at least in my use case).
From there I need to develop a workflow that allows me to tag the photos with the estimated datetime and then converts that to a sortable datetime in the standard field.
It should support edtf and gedcom format. With some standard rules on how to sort something that is listed as "Circa" or "Before"
EXIF has almost 500 fields, but look at 0x9003 DateTimeOriginal, 0x9004 CreateDate.
Then you have in the GPS tags: GPSTimeStamp, GPSDateStamp
And those are just the common tags...
Next question is, what format do these tags use. DateTime, while it's supposed to be "YYYY:MM:DD HH:MM:SS", is generally a free-for-all in practice when it comes to the order of the date components, the format of the components, or what separator to use.
I've seen software write DateTimes e.g. like "1-12-23/1:13pm" instead of "2013:01:12 13:13:00". Whether it was actually M-DD-YY or D-MM-YY, etc in this case is more of guesswork when all the values are below 12 :P
And if I remember correctly there was one piece of software which wrote UTF-16-BE strings instead of the mandated ASCII.
I believe the original author is still very active on ExifTool's forum and helps people day in day out.
choco install exiftool --version=12.47 && choco pin add -n exiftoolHow might I use the tool for editing geodata? Their forum seems to point to the use of other tools.
It’s not obvious at first glance but it handles an incredibly long tail of non-standard maker notes and other odds and ends I’ll never get to. Stuff from hardware over multiple decades. Few authors have can match this kind of dedication. Deserves a FLOSS award of some kind.
Highly recommended on Windows in stripper by steelbytes available from https://www.softpedia.com/get/Multimedia/Graphic/Graphic-Oth...
cc -o exifstrip main.c # this is hacker news, after allIt is not only the connection speed but also the storage space that is a consideration. I use small form factor computers with limited storage space. I also like things that are feasible on slower connections. Generally, unless I am using a program on a regular basis I will uninstall a program after using it. For example, if I need Perl for some task, such as compiling OpenSSL, I will install it, perform the task, then uninstall. Compared to exiftoo, exiv2 is a smaller, faster download and as suggested by another commenter, it finishes faster than exiftool. I choose exiv2 over exiftool to same time and space. Every user is different and exiv2 works better for this user.
The reason I do not keep large scripting languages like Perl, etc. installed is because I do not use them regularly. The ash shell is what I use the most. I keep Lua installed, since I use that with haproxy every day.
This suggests you are a maintainer or author of the tool you recommend over exiftool. Your other two comments are written in a way to suggest a disinterested preference. Which is it?
2. As an occasional exiv2 user, I am interested to know if and where it fails.
3. exiv2 is written in C++. I prefer C. I am not an author or maintainer of exiv2.
Hope that helps.
I regularly use it to backfill gps tags on my photos as: exiftool -geotag track.gpx *.JPG