Hello, as you can see I have a photo taken in 2004 with 2004 in the filename and in the folder name. However, I think the last modified date of the file is 2020. Therefore PhotoStructure seems to have designated it a 2020 photo. Is there a way to fix this?
My first take was omg what did PhotoStructure do to your poor baby’s face
The captured-at heuristics are pretty involved:
The proper solution would be to have PhotoStructure support editing metadata, but that’s not done yet. Until that happens, follow these (manual) steps: https://photostructure.com/faq/captured-at/#what-should-i-do-with-scanned-photos
This topic will track this feature:
If you edit an asset’s captured-at in PhotoStructure, and the asset is in a datestamped directory PhotoStructure will move the asset into a correct datestamped directory (if some setting has enabled this feature).
Haha no problem. I myself didn’t expect the blur tool to do that either.
So I assume there is no EXIF date on these photos or they’re screwed up. In that case it’ll go by an ISO compliant folder name. So I’m guessing “2004” is not ISO compliant. Looks like the advice is to strip exif data and place them in YYYY-MM-DD folders. I can get working on that.
Could the fuzzy date recognition (Step 5) be expanded to just YYYY folders, or YYYY-MM?
Related question, what if I don’t know the exact date? I think you addressed this in a doc, but I can’t find it at the moment.
If you’ve got PhotoStructure for Node or PhotoStructure for Docker handy, you can see exactly where tags are coming from: use photostructure info $path/to/file and look at the capturedAt object.
More info about info: https://photostructure.com/server/tools/#file-information
Yeah, YYYY-MM is supported by v0.9.1 if fuzzyDateParsing is enabled.
The next version (v1.0.0!) will support YYYY parsing if fuzzyYearParsing is enabled.
But really the best solution will be proper date editing from within PhotoStructure (with optional month, day, hour, minute, … fields).
A quick update on this issue: PhotoStructure’s date parsing has had several improvements since this issue was opened, and this bug should be resolved. @chris, if you want to DM me the original image, I can verify.
More details are here: