While I was browsing my library by date, I found a group of 62 assets, all tagged by the exact same date: Dec 8, 2002, 12:00 PM
These files have the correct date information inside the metadata and on the name, yet PhotoStructure still tagged them incorrectly.
Looking through the files, there doesn’t seem to be a pattern to them.
The dates vary between 2014, 2015 and 2016.
All were taken with my old Motorola XT1022 and uploaded to Google Photos using Picasa, but I have loads of other photos that fulfill these conditions that were tagged properly.
I am using PhotoStructure for Desktops 0.9.1 on Arch Linux.
Any logs I could provide to help debug this issue? I’ll be mailing a sample of the affected pictures to email@example.com shortly.
If this is a common issue in your library, would it be helpful to have the CapturedAtTags be a setting (so you could, say, remove CreateDate if you knew it was always going to be wrong)?
(How did it get set in the first place, I wonder?)
The current list is:
const CapturedAtTags = [
// By the specification, DateTimeOriginal should be the time of the
// shutter actuation, and CreateDate should be the time that the file
// was written to the memory card (but not all mfrs follow the spec)
// First "*original*"
"SubSecDateTimeOriginal", // (fractional seconds for DateTimeOriginal)
"SubSecTimeDigitized", // (fractional seconds for CreateDate)
"DateTimeOriginal", // (date/time when original image was taken)
// Then "*create*"
"CreateDate", // (called DateTimeDigitized by the EXIF spec)
"DateCreated", // XMP tag
// Then *modify*
"SubSecTime", // (fractional seconds for ModifyDate)
"ModifyDate", // (called DateTime by the EXIF spec)
// "HistoryWhen", // This is when history records happen, NOT when the file was captured!
// Google Takeout (not really reliable, though)
// This is the Google Photos upload time. That's not something we want, so
// it's commented out. DON'T ADD IT BACK, FUTURE ME!
Given that @Lars_Noschinski saw this issue too, and in both cases, there were other tags that had good contents, I think it’s safe to just remove CreateDate from the list of tags that PhotoStructure looks at by default. (see below)
For extra credit, the list of tags will be configurable via the new capturedAtTags library setting:
# | capturedAtTags |
# The following tags are examined to parse a file's captured-at time. The
# earliest valid tag is returned. See
# <https://photostructure.com/faq/captured-at/> for details.
This change will be in -alpha.3, which is a couple days out (I need to finish search).
Dates look correct and they match the file names. Looks good to me!
When this fix makes it’s way into a release, I’ll try making a new library containing the affected files to make sure they get tagged correctly.
I’ve just started using Photostructure and imported a fairly large library of photos. I’m using the Windows version V0.9.1 Beta. I’m very impressed with it.
I noticed a whole bunch of photos (>1000) ended up with their dates at the 8 Dec 2002 when they were taken much later (2013-2015).
Using windows filemanager the correct date/time shows, but using Exiftool the Create date field is 8 Dec 2002 12:00pm but the Date/Time Original field shows the correct date/time.
From what I can see on the forums there is a common theme to the camera that took the photos when this problem appears. They all appear to be Motorola phones. In my case it is a Motorola XT1068.
So now I know what has happened, do I just remove the create dates from all of the 1000+ photos and then go through each photo in Photostructure one by one and tell it to resync or is there a way I can do this in a batch?
If I need to remove the create date, do I do this on the file in the Photostructure library or do I remove it in the original location(s)? Some of these photos are in several locations and Photostructure has done a great job of deduping them .
Does the fix you mention above make any of this easier, and can it be applied to just the photos in the Photostructure library on this date or do I need to re-import all of my photos? It took about 4 days to do the initial import so I am hoping this will not be the case.
Thanks for your really quick reply. Much appreciated.
Being new to Photostructure I am not sure of all the features, but is it possible to define a small part of the Photostructure library to rescan without scanning the rest? Perhaps a way to scan a particular date range or by a particular tag or EXIF field?
I have quite a few scanned images. They have DateTimeOriginal set but it appears it was not used by PS. I estimated the dates on these old pictures after scanning and set them using Photoshop elements which I no longer use. Sometimes they have parts of the date missing. With exiftool it shows my DateTimeOriginal is “1998: : 00:00:00”. That’s two spaces after the first colon and three spaces after the second colon. I don’t see any messages about this being a bad format in the debug but PS doesn’t use it. I’m going to script something to fix this with exiftool since I have the date I want in the filename, but I just wanted to mention in case you want to take a look at see if it ps could handle partial dates better. Photoshop Elements is a popular product even though I no longer use it so you could hit this again. If you want I can mail you a bad file.
I made the fixes and I’m trying to quickly check the files. Syncing seems to miss some or maybe is still running I can’t tell. I’m using docker and I connect to the container usually using portainer. When I try to run the manual sync commands as described at PhotoStructure | PhotoStructure Tools I always get:
Interesting, I’ve never seen that format before: it’s always been something like “1998:0:0” if only the year is set.
I’ll add this as a format that PhotoStructure knows how to parse. Thanks for sharing!
Are you attaching to a currently running container by using docker exec? If you’re using docker run, you need to remember to include the bind mounts.
Also: make sure you’re using a :prealpha build (just for now, until I get this release out and set to :stable)–it should have much better error messages when things aren’t set up as it expects, thanks to the new health check system.