From 2a8ff8e1c869924ea49883304e21233169a16550 Mon Sep 17 00:00:00 2001 From: Manav Rathi Date: Sat, 24 Aug 2024 15:30:12 +0530 Subject: [PATCH] [docs] Mention FS times --- docs/docs/photos/faq/photo-dates.md | 62 +++++++++++++++++++++++++++-- 1 file changed, 58 insertions(+), 4 deletions(-) diff --git a/docs/docs/photos/faq/photo-dates.md b/docs/docs/photos/faq/photo-dates.md index 506f24f566..cf2ea54b47 100644 --- a/docs/docs/photos/faq/photo-dates.md +++ b/docs/docs/photos/faq/photo-dates.md @@ -1,17 +1,22 @@ --- title: Photo dates -description: Ensuring correct metadata and dates in Ente Photos +description: Handling of metadata, in particular creation dates, in Ente Photos --- # Photos dates +This document describes Ente's handling of metadata, in particular photo +creation dates. + +## Import + Ente will import the date for your photos from three places: 1. Exif 2. Metadata JSON 3. File name -## Exif +### Exif Normally, Ente app tries to read the date of the photo from the Exif and other metadata (e.g. XMP, IPTC) embedded in the file. @@ -21,7 +26,7 @@ metadata (e.g. XMP, IPTC) embedded in the file. > You can see all of the Exif metadata embedded within a photo by using the > "View all Exif data" option in the info panel for the photo in Ente. -## Importing from Google takeout +### Importing from Google takeout In case of photos exported from Google Photos, the metadata is not embedded within the file itself, but is instead present in a separate sidecar ".json" @@ -41,7 +46,7 @@ importing that folder into Ente**. This way, we will be able to always correctly map, for example, `flower.jpeg` and `flower.json` and show the same date for `flower.jpeg` that you would've seen within Google Photos. -## Screenshots +### Screenshots In case the photo does not have a date in the Exif data (and it is not a Google takeout), for example, for screenshots or Whatsapp forwards, Ente will still try @@ -51,3 +56,52 @@ and deduce the correct date for the file from the name of the file. > > This process works great most of the time, but it is inherently based on > heuristics and is not exact. + +## Export + +Ente guarantees that you will get back the _exact_ same original photos and +videos that you imported. The modifications (e.g. date changes) you make within +Ente will be written into a separate metadata JSON file during export so as to +not modify the original. + +> There is one exception to this. For JPEG files, the Exif DateTimeOriginal is +> changed during export from web or desktop apps. This was done on a customer +> request, but in hindsight this has been an incorrect move. We are going to +> deprecate this behavior, and will instead provide separate tools (or +> functionality within the app itself) for customers who intentionally wish to +> modify their originals to reflect the associated metadata JSON. + +### File creation time. + +The photo's data will be preserved verbatim, however when it is written out to +disk on a new machine a new file gets created. This file will not have the same +file system creation time as the file that was uploaded. + +1. "Creation time" is not a universal concept, e.g. Linux does not support it. + From the man page of [fstat](https://linux.die.net/man/2/fstat), we can see + that this information is just not recorded by the file system on Linux. + +2. The isn't a way to set it even on Windows and macOS for files downloaded from + the browser, or for files saved from the mobile apps. + +We have considered modifying our desktop and CLI clients to write back the +photo's creation time into the creation time of the filesytem file during +export. But it is not clear if this would be less or more confusing. There are +two main downsides: + +1. It will be inconsistent. This behaviour would only happen on Windows and + macOS, and only when using the desktop or CLI, not for other Ente clients. + Learning from our experience of modifying DateTimeOriginal, we feel + consistency is important. + +2. It will require workarounds. e.g. for the desktop app, Node.js doesn't + natively support modifying the creation time (for similar reasons as + described above), and we will have to include binary packages like + [utimes](https://github.com/baileyherbert/utimes). + +We will also note that Ente is a photos app, not a file system backup app. The +customers for whom the creation time of the file on disk is paramount might be +better served by file backup apps, not a photos app. + +All this said though, nothing is set in stone. If enough customers deem it +important, we will prioritize adding support for the workaround.