![]() With these pieces, it should be possible to add TZ metadata contained within the file to photoprism. So it is pretty simple to coax exiftool into providing the bare timezone from file metadata. $ exiftool -s -Model -DateCreated -SubSecDateTimeOriginal -SubSecCreateDate -DateTimeOriginal -CreateDate -TimeZone 2022/-32_455c68.dng 2021/-10_493FjF.dng 2022/-18_235Pil.heic SanDisk SSD PLUS 1000GB (as reported by lsblk -do NAME,SIZE,MODEL).Intel(R) Core(TM) i7-8700 CPU 3.20GHz (as reported by lscpu).On what kind of device is PhotoPrism installed? I can provide sample files if asked to, but I don't think I have anything especially rare that you couldn't create by just using exiftool to change the dates on a file or using a DSLR with its clock set to another TZ. Can you provide us with example files for testing, error logs, or screenshots? If TZ data from the file is ignored, then we have chronological sort problems and incorrect metadata showing up in photo detail views. If TZ data is available in the file and is used, then photoprism can gracefully deal with the photographer's mistake. This is especially important for people who travel because they often forget to change the TZ on their camera, and end up shooting a bunch of photos with the clock set to the wrong timezone. These fields are less ubiquitous than the TZ naive fields, but they are quite common in modern cameras, and if the TZ data is included in the exif then it should certainly be used. So my suspicion is that the import of photo metadata into Photoprism is ignoring fields that have more rich datetime data that includes the TZ. $ exiftool -s -SubSecDateTimeOriginal -SubSecCreateDate -DateTimeOriginal -CreateDate 2022-32_455c68.dng However, the camera that took that photo was set to GMT (because who wants to mess with TZ's every time you travel?) We can see in the exif data that it was taken at 10:01 GMT (+00:00): The details view of that photo does indeed show that it is in America/New_York TZ. The photo was taken in EST, but clearly it is not 10pm EDT since it's daytime. For example, the following photo shows 10:01 PM EDT. This column appears to be the result of some changes that take into account the location of the photo and the photo exif data. ![]() The DB does not appear to store TZ data, although there is a photos.taken_at_local column. It looks like there may be multiple things going on. I expect photos that include the TZ in their exif data to be shown with correct times and sorted correctly among other files from different TZs. Notice the photoprism miscalculates the date as being taken within the geotagged timzeone, not what is shown in an exif tag that contains the TZ.Geotag this photo into a non-GMT timezone.Photo details views show incorrect TZ and time when the TZ of the camera body does not match the photo geolocation. It appears that the location of the photo may be interfering with correct interpretation of the time. Photos from two separate cameras set to the same objective time but with a different timezone will not correctly sort chronologically. When viewing collections of images, timezones are not considered when sorting photos. Chronological sort is incorrect in some circumstances.Photo detail views have incorrect datetimes in some circumstances.What does not work as described in the documentation?
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |