I love ExifTool! So many options. If you want a SQLITE database I wrote a program that uses ExifTool to scan folders. ExifTool has this functionality built in to some extent but I just thought I'd mention it here in case someone wants to replicate the functionality in python for whatever purpose they want
Practical use, before uploading files publicly, I often want to remove some important metadata. exiftool makes it really easy:
# 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.mp3
Re the last example, is there a way to distinguish between functionally extraneous metadata and “meta”data that is used for presentation? I wouldn’t want to carelessly drop e.g. image orientation or the color profile.
If you prefer you can preserve those individually with command line arguments, but I’d say that takes us out of the territory of “clear out all metadata”.
What 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.
It would be nice. Currently, I have exceptions for the orientation and ICC profile tags in my static site generator for my photography website, but I could be missing something.
Not OP -- while I do not know of a tool that can do that off-hand it seems that it _should_ be possible as this is not applied at the hardware level:
> 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.
It would have been best have to have that table randomly generated for each photo at the source and perhaps that's possible with smartphones, but for photos taken with an ad-hoc camera (point and shoot, mirrorless, etc.) I'd guess it's not option unless maybe if you'd flash a modified firmware.
This is a power tool. I recently needed to edit metadata on an MP4 file. All the other tools would corrupt the data so that the app reading it did not load it anymore. But ExifTool handled this format correctly, and I was amazed by the wealth of other options.
I see a few people using this to scrub metadata, which is great. If you're on Mac and don't mind having a UI, there's a tool I've been using for all my images that both scrubs metadata and uses the latest compression techniques. Supports most image formats too: https://imageoptim.com/mac
Microsoft, Google, camera companies and Dublin core fanatics. Put them in a battle royal and lock in ONE way to specify approximate date of an image, distinct from when it was taken or scanned, and distinct from the file modification time...
Exif itself defines three main times: DateTime, DateTimeOriginal, DateTimeDigitized.
To add insult to injury, each has an additional SubsecTime*
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.
you stopped your quote a bit too soon. "when it was taken or scanned"
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.
This. Maybe it's from about 1870. Maybe it's Easter, because of the clothes but I only know its before 1940. Maybe it's in august, who knows what day or year. But i scanned it last Tuesday and I played with the image file yesterday. So it now has at least two and probably three or more date-time values, none of which relate to what it is actually "about" in metadata space.
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 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/
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"
I like the idea of edtf or gedcom. Given that the date tags are just specified as "string", if exiftool won't write a partial date, even with the -n option, pick a different tool.
Ah, copy images. The date on the copy image would be the date the copy was made. The date of the original image would be metadata about the subject. I've been scanning a lot of my negatives from as far back as the 70s, and that's the convention. Date scan creation is one thing, the image in the the scan has metadata like subject, location, and date.
EXIF has almost 500 fields, but look at 0x9003 DateTimeOriginal,
0x9004 CreateDate.
Like I said: it's complicated. How do the different systems handle the competing fields, which take primacy and how do you represent approximate knowledge? "It depends"
Well, I'm not an archivist, I don't need an official taxonomy. I understand that museums, libraries, and such need to adhere to convention for cataloging reasons. For myself, I just don't care beyond my personal needs.
I submitted this since the "clean" link to ExifTool was missing. I re-discovered ExifTool while looking for an eaey way to rename DSLR photos based on EXIF metadata info via "Advanced Renamer" https://www.advancedrenamer.com/user_guide/exiftool
Quite nice, it does PDF metadata also, pdfinfo dictionary and XMP metadata, individual attributes or xml bundle. In win metadata are searchable installing an ifilter implementation, and appear in file explorer with a shell extension such as free https://coolsoft.altervista.org/en/pdfpropertyextension
I love ExifTool. Inspired me to create tone[1] - just because I did not find out how to edit/dump audio chapters as I wanted :-)
Great piece of software! Keep up the good work.
the -s command lists metadata, but from my explorations with the bytecode using ruby std tools and grep I've found there is likely a lot more than is shown from this command.
How might I use the tool for editing geodata? Their forum seems to point to the use of other tools.
I’ve added exif functionality to my own programs, but still use exiftool relatively frequently.
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.
I use exiftool almost as much as I use curl. It is almost always the first thing I install on every new computer I set up. I've never used it to edit metadata, it's just insanely useful for diagnosing weird issues with files. Definitely put it on your list of utilities to check out, if you haven't.
I recently wanted to give this a try, but realized that it doesn't support the editing of .doc files. The fact that this isn't supported probably indicates that it's somewhat difficult to implement? I was looking for a way to replace the author meta info for all my old .doc files.
Nice to see it now supports HEIF. I just wrote a Python script to file my photos and videos by date with Pillow plugins and the ffmpeg bindings to get at the metadata because I thought exiftool wasn’t that up to date (for some reason, likely a distro packaging issue).
The exiftool seems to be a 4MB download, and exiv2 seems to be around 8MB. What connection are you on that these kinds of download sizes are a consideration?
IIRC exiftool requires a scripting language, the install for which is more than 8MB.
It 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.
> Any sample photos we can try to reproduce these errors.
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?
exiftool is one of the greatest tools in my box. I use it almost daily working in multimedia production, both professionally and personally. It's insanely useful.
