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 support@photostructure.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)
// http://u88.n24.queensu.ca/exiftool/forum/index.php?topic=2568.0
// <https://exiftool.org/TagNames/EXIF.html>
// First "*original*"
"SubSecDateTimeOriginal", // (fractional seconds for DateTimeOriginal)
"SubSecCreateDate",
"SubSecTimeDigitized", // (fractional seconds for CreateDate)
"SubSecMediaCreateDate",
"DateTimeOriginal", // (date/time when original image was taken)
// Then "*create*"
"OriginalCreateDateTime",
"CreateDate", // (called DateTimeDigitized by the EXIF spec)
"DateTimeCreated",
"DateCreated", // XMP tag
"DateTimeDigitized",
"MediaCreateDate",
"DateTime",
// Then *modify*
"SubSecTime", // (fractional seconds for ModifyDate)
"ModifyDate", // (called DateTime by the EXIF spec)
// Lightroom:
// "HistoryWhen", // This is when history records happen, NOT when the file was captured!
// Google Takeout (not really reliable, though)
"photoTakenTime"
// 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!
// "creationTime"
]
Thanks for the fast replies, theyāre highly appreciated!
That would be very helpful, yes.
When PhotoStructure gains the ability to edit tags, it would be great if we could remove tags using the UI, bonus points if we could do it in bulk!
Quick question: Is the āCreate Dateā tag a frequently utilized in peopleās libraries?
Maybe it should be weighted less than the āImage Date/Timeā tag by default?
I wonder too. I have no idea of what could have caused this, other than a obscure bug inside Picasa (RIP!) or my old phoneās firmware.
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.
#
# PS_CAPTURED_AT_TAGS="[\"SubSecDateTimeOriginal\",\"SubSecCreateDate\",\"SubSecTimeDigitized\",\"SubSecMediaCreateDate\",\"DateTimeOriginal\",\"OriginalCreateDateTime\",\"DateTimeCreated\",\"DateCreated\",\"DateTimeDigitized\",\"MediaCreateDate\",\"DateTime\",\"SubSecTime\",\"ModifyDate\",\"photoTakenTime\"]"
This change will be in -alpha.3, which is a couple days out (I need to finish search).
Would it be better to just include CreateDate at the end of the list? It would appear earlier it was midway in the list, but if it was ālastā then itās kind of an āif all else failsā.
Flip side, I can add it back if I want it, no biggie, just thought I would toss it out there.
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?
Always feel free to ask if you canāt find something: more content on the forum makes it more likely for the Users Of Tomorrow to search and find an answer.
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:
Using either root or node acct I get the same error. Is there some environment I need to set up using docker after Iāve connected to info photostructure commands?
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.
Iām connecting using exec to the existing container. Using portainer actually so Iām at the bash prompt as root. āsu node -cā doesnāt change the error.
.