`for file in *; do touch -mt "$(exiftool -p '$CreateDate' -d '%Y%m%d%H%M.%S' "$file")" "$file"; done`
Our family uses Apple Photos as the primary photos App. I also try to have a backup exported from it in yearly folders. Whenever I export from Photos, the date of the files are defaulted to the exported date. The above command resets back to the date it was taken.
I thought this article would go into how exif data is stored in different image formats, different value types, interesting peculiarities with the format etc. This article is not interesting enough to be on hn.
Generally not. I guess you could insert a poem into an EXIF field, which would be covered by copyright. But the data inserted by cameras is straight facts, not artistic expression. Thus it isn't covered by copyright.
Photos are full of creative decisions of the photographer (framing, timing, etc) so we consider them a work of art. But if a painter draws a bridge the thing that copyright protects is the painting, not the info which bridge it was out when it was painted.
You could make a compelling case that CCTV footage is just information without artistic input. That argument has a Wikipedia section discussing it:
I generally agree that Metadata does not fall under copyright, with these aspects. But it is more nuanced.. the Geotag, for instance: It was the photographers choice to move to this location, as it was the photoraphers choice to trigger the shutter at exactly that date_taken_time, as it was his/her decision to upload at specificly that upload_time. All of these aspects reflect individual choices, and individual choices are a reflection of our identity and creativity (ask Susan Sontag).
I don't recall correctly but there was this patent/paper discussing how Facebook (& perhaps a few others) use the EXIF data to confirm and expand your social graph. I guess processing the pictures already gives them everything they need to identify different people who were at the same place at around the same time. But all that meta data like timestamps, geolocation, camera make and model etc. must definitely provide them a great deal more info to be sure about that.
And if one company can do it, I don't see how others can't or won't do it in the future. And only God knows in what all other ways this information can be exploited.
I recommend everyone to clean up EXIF data before they send out files to friends and family or upload backups to the cloud.
I found the CLI tool at https://exiftool.org/ to be very useful. It helps remove EXIF data from a wide variety of file types and comes with tons of filters and features to observe and selectively manipulate & remove EXIF data.
ImageOptim seems like a proprietary SaaS, not something you want to trust your EXIF data with. mat2 is a locally installed tool so it doesn't have that problem (there is a web interface you can setup too).
Not mentioned are things like sidecar files with expanded exif data.
An example of that is Panasonic Lumix cameras would take a JPEG+raw. The raw is a .rw2 file that is pure metadata, but carries enough information about the camera and lens ability and parameters used to allow effective transformation of the JPEG as if you truly had the raw.
In those cases you had two files with exif data: the JPEG with basic exif and then the sidecar file with a really rich exif.
Raw drivers for Windows by Panasonic Lumix were really just sidecar parsers.
rw2 is a proprietary raw image format based on TIFF. It’s not a metadata sidecar but contains the actual image data, just (far) less processed than the JPEG.
Actual metadata sidecar files are generally in the XMP format.
Hmmm. For whatever reason, that's not true for my camera.
The jpeg has dimensions 4592x3448 and a light amount of exif, and comes with a paired rw2 file which has dimensions 160x128 and only contains an embedded jpeg thumbnail of that smaller dimension and a rich amount of exif. The jpeg is 6.31MB on disk, whereas the rw2 is only 1.76MB on disk (clearly not an uncompressed TIFF + metadata). The photos were taken by a Lumix GX1 between 2012 and 2017. Looking through the hundreds of directories of images, that pattern is clear that the jpeg is 4x the paired rw2 on disk.
I can no longer use the official Lumix codec as it is no longer supported ( https://av.jpn.support.panasonic.com/support/global/cs/dsc/d... only installs on Windows 7 and below), and DX Photolab doesn't know what to do with it. FastStone Image Viewer reports the smaller file size, and reveals some of the exif (interestingly the values in the rw2 are more accurate, the values in the jpeg are rounded). The Adobe DNG converter produces a 160x128 jpeg from the rw2.
The things I read only agree with you, the files on disk do not.
My bike cameras, Cycliq (https://cycliq.com) when I view the clips on a file system have the right date/time "Get info" on macOS, but when imported in to Apple Photos are 10 hours in the past and I need to manually correct it. It seems like they're importing as the time, but UTC+0 (I'm in +10)
I've never had this problem importing photos/videos before.
EXIF is the greatest thing about photos and videos. It makes every photo a tiny portable database of itself. A library of photos is a collection of these tiny databases which share a schema. Doesn’t matter what device takes the photo - and it’s been like this for decades.
I wrote a program that’s been organizing my photos based on EXIF for 7+ years [1].
I’ve also blogged about my reasoning (have co-founded 2 photo startups prior) [2, 3, 4, 5]. I’ve since moved off Google Photos to Synology Photos but haven’t written about that yet. Relying on EXIF makes that super easy.
I have been working on a program to organize photos by EXIF. My main dilemma has been what to do with photos that do not have an original date/time or create date.
I have a similar personal project. In that case, I default to create date on the file. I am interested if there’s something more clever (that can be automated). I have a set of photos from 2005 from a digital camera that I know have the wrong dates but am unsure the exact correct ones.
It seems like EXIF data isn't used enough in machine learning; for instance if you want your model to know what color something "actually" is, it would help to feed it the white balance and exposure values, not just the pixels.
(Doesn't help they're all trained on low dynamic range sRGB images and not real camera data.)
If you're writing a program that relates to image (really, just JPEG and TIFF since they're all that support it) metadata, also check out IPTC which is more directly related to metadata that isn't about the image. Both EXIF and IPTC come from the TIFF standard.
I remember years about trying to organise my photos by year and month in respective folder with a shell script using exiftool to get the year and month for folders.
I failed to get it to work, my lack of knowledge with bash scripting. I might try again some time. I'm convinced it's a one liner.
EXIF came in handy when I purchased a puppy from an out-of-state breeder. I used the GPS data to verify where he said he lived before I sent off the deposit. Oddly enough, I turn off this location data for my own photos due to privacy.
33 comments
[ 3.6 ms ] story [ 42.9 ms ] thread`for file in *; do touch -mt "$(exiftool -p '$CreateDate' -d '%Y%m%d%H%M.%S' "$file")" "$file"; done`
Our family uses Apple Photos as the primary photos App. I also try to have a backup exported from it in yearly folders. Whenever I export from Photos, the date of the files are defaulted to the exported date. The above command resets back to the date it was taken.
You could make a compelling case that CCTV footage is just information without artistic input. That argument has a Wikipedia section discussing it:
https://en.m.wikipedia.org/wiki/Threshold_of_originality#Pre...
And if one company can do it, I don't see how others can't or won't do it in the future. And only God knows in what all other ways this information can be exploited.
I recommend everyone to clean up EXIF data before they send out files to friends and family or upload backups to the cloud.
I found the CLI tool at https://exiftool.org/ to be very useful. It helps remove EXIF data from a wide variety of file types and comes with tons of filters and features to observe and selectively manipulate & remove EXIF data.
https://0xacab.org/jvoisin/mat2
Compressed images efficiently and also removes EXIF data.
An example of that is Panasonic Lumix cameras would take a JPEG+raw. The raw is a .rw2 file that is pure metadata, but carries enough information about the camera and lens ability and parameters used to allow effective transformation of the JPEG as if you truly had the raw.
In those cases you had two files with exif data: the JPEG with basic exif and then the sidecar file with a really rich exif.
Raw drivers for Windows by Panasonic Lumix were really just sidecar parsers.
Actual metadata sidecar files are generally in the XMP format.
The jpeg has dimensions 4592x3448 and a light amount of exif, and comes with a paired rw2 file which has dimensions 160x128 and only contains an embedded jpeg thumbnail of that smaller dimension and a rich amount of exif. The jpeg is 6.31MB on disk, whereas the rw2 is only 1.76MB on disk (clearly not an uncompressed TIFF + metadata). The photos were taken by a Lumix GX1 between 2012 and 2017. Looking through the hundreds of directories of images, that pattern is clear that the jpeg is 4x the paired rw2 on disk.
I can no longer use the official Lumix codec as it is no longer supported ( https://av.jpn.support.panasonic.com/support/global/cs/dsc/d... only installs on Windows 7 and below), and DX Photolab doesn't know what to do with it. FastStone Image Viewer reports the smaller file size, and reveals some of the exif (interestingly the values in the rw2 are more accurate, the values in the jpeg are rounded). The Adobe DNG converter produces a 160x128 jpeg from the rw2.
The things I read only agree with you, the files on disk do not.
My bike cameras, Cycliq (https://cycliq.com) when I view the clips on a file system have the right date/time "Get info" on macOS, but when imported in to Apple Photos are 10 hours in the past and I need to manually correct it. It seems like they're importing as the time, but UTC+0 (I'm in +10)
I've never had this problem importing photos/videos before.
What's going wrong here?
Phones can do this because they have gps and know which time zone the photo was taken. Your bike camera may not.
1. https://indieweb.org/Exif#Timezone_Issues
I wrote a program that’s been organizing my photos based on EXIF for 7+ years [1].
I’ve also blogged about my reasoning (have co-founded 2 photo startups prior) [2, 3, 4, 5]. I’ve since moved off Google Photos to Synology Photos but haven’t written about that yet. Relying on EXIF makes that super easy.
1. https://github.com/jmathai/elodie
2. https://medium.com/@jmathai/understanding-my-need-for-an-aut...
3. https://medium.com/@jmathai/introducing-elodie-your-personal...
4. https://medium.com/@jmathai/my-automated-photo-workflow-usin...
5. https://medium.com/@jmathai/one-year-of-using-an-automated-p...
(Doesn't help they're all trained on low dynamic range sRGB images and not real camera data.)
I failed to get it to work, my lack of knowledge with bash scripting. I might try again some time. I'm convinced it's a one liner.