Hi, first post here.
Just my 2c: I love the fact that PS is an organized view of my photo library. But, at least in the beginning, I don’t think editing should be pursued that much. It’s good to have a best-in-class read-only experience while leaving the editing work to something else.
In my case all the editing is done via DigiKam and PS syncs with it nicely (sidecar files included).
DigiKam date editing is pretty powerful too.
1 Like
I’m not terribly concerned about date editing in particular. However, I think the BEST time to add titles and descriptions is when you’re browsing the files organically like I often do with Photostructure. If I know that in order to add a title or description I have to find that file and open it in another piece of software, then I’m not going to bother.
The same goes for manual tagging, which is by far the feature upgrade I am most looking forward to.
With respect, I think making Photostructure read-only would be a hindrance to adoption, especially as a paid product.
1 Like
Just for the sake of completeness I wasn’t suggesting to keep PS read-only (that’s why I said “at least in the beginning”). I could definitely see value in that were PS can write back to sidecar files (or EXIF or both) but being able to share and view via a web interface is still very high in my (personal) priorities. That’s mainly because I found that editing/tagging on a different software (and having the freedom to do so) it’s a huge deal. I’m sure that from the PS point of view more features will attract more (paying?) user so all is good (I’m using 0.9.1 since a few weeks so my experience is limited).
Can’t wait to see what’s coming out for 1.0 
Oh man, I can’t tell you how many assets in my library are borked due to this.
In fact, I changed how PhotoStructure stores captured-at time in the database, (back in v0.6), to be time-zone agnostic, rather than storing everything in UTC, which caused issues due to (most) videos and many images not having reasonable timezone offsets.
The “local centiseconds” is an actual numeric value but with base-10-positional values. Right now, in my time, it’s 2021032818361231, or 2021-03-28 at 6:36pm.
Please note, that if you want to modify file’s EXIF dates via ExifTool, for mov/mp4 files you have to set the setting -api QuickTimeUTC=1 otherwise it will process timezones incorrectly QuickTimeUTC. For other files such setting has no effect, so it’s harmless to use it all the time.
BTW, it’s not datetime related but I remembered also for video files it makes sense to set another ExifTool setting -api LargeFileSupport=1. Otherwise you won’t be able to set EXIF tags for files over 2gb (or maybe 4gb, I didn’t check exactly) LargeFileSupport
1 Like
@mnaoumov thanks for those tips!
I hadn’t been bit by either of those as I write to sidecars by default, but there is a setting to directly write to originals that should include these flags. I’ll fix this in a future release.
1 Like
Meh, it was a handful of lines to add this support, so I just did it now.
3 Likes
Given that this is a prerequisite to Support for manually editing tags, are you prioritizing this in spite of the lower vote count?
1 Like
Yup, this feature is a prerequisite, and it’s a much better defined task.
What I’m getting at is that this has only 8 votes, while Support for manually editing tags has 13 votes and is the 4th-highest open feature request. I’m wondering if you’re going to skip working on this until it’s closer to the top of the requested features, or if you’re taking into account that the other request is already close to the top.
Basically I REALLY want this and I’m curious how long I’m going to be waiting for it 
There are several features hiding in this one topic:
- editing the captured-at time
- showing and editing the title
- showing and editing the description
Editing the captured-at time is a bit of a bugaboo: if there are any assetfile variants that aren’t currently mounted, PhotoStructure can’t update their sidecar with the new date, and on next sync, it may shove the variant into a new asset.
Title/description/caption support is a prerequisite for full-text asset search (currently search only looks at a couple asset flags and the captured-at time).
I think it was a mistake to have them all in one topic: oops!
I’ll split out the title/description support into a new topic.
Gotcha… so which of these is a prerequisite for manually editing tags?
Any/all of these features require me to build out “asset transform” support, where each “transform” is
- the time of transform
- the transformed field
- what transform was applied (insert, delete, replace)
- the previous value(s) and
- the new value(s)
With this information, PhotoStructure can then aggregate and “replay” the transforms at sync time to a given asset.
We need insert, delete, replace to handle fields that are arrays, like keywords.
We need the previous value to detect if the asset has been changed by another tool. If the value isn’t what PhotoStructure expects as per the existing transforms, it won’t apply that transform.
This mechanism allows PhotoStructure to reliably determine what value “wins” for a given set of asset file variants, and allows external apps to “override” what’s been done in PhotoStructure.
(I had an initial version that just wrote the title to a sidecar, but then when I plugged in an older hard drive with a bunch of higher-resolution originals and RAW files, those were picked as the “primary” variant, and they didn’t have my changes, so it “removed” all that work).
I see. With that in mind, how are you prioritizing the “asset transform support” since it’s not an actual feature request, just an underlying prerequisite? Do you tackle it when the first feature request that requires it bubbles to the top of the list? Do you aggregate the votes for all feature requests that require it and use that as your prioritization metric? Should we create a feature request for “asset transform support” and direct people to vote for that in order to get these other requests off the ground?
Infrastructure will never be voted on: I build stuff out when it’s required.
As far as prioritization, I’m not going to be able to strictly follow top-voted features, given that so many features actually require other features: I’m using it as a general guideline to judge interest.
Another example of prerequisite features: if I want to implement sharing, I need album support. Albums will be implemented as hierarchical keyword tags, so manual keyword editing needs to be done. Ideally, bulk asset selection will be supported as well, but it’s not a hard prereq for sharing.
2 Likes
@mrm this discussion has me questioning the very foundation of my workflow!
I’ve indeed discovered photostructure re-adding photos that were already there–because I retroacively tagged version A of the photo in the ps library with digikam.
Ps circled back at some time later and found a different sha of that image and brought it in as *-1.jpg. I have 6035 of these now!
I’m trying to figure out how to keep photostructure in my workflow–I love its deduplication and presentation style. Digikam is great for deep management, but not great for displaying.
It would be neat to confg PS to overlook exifdata when deduplicating, but I imagine that would take an entirely different approach than just hashing the file. I’ve seen some python modules that do funky math magic to create some sort of common-pixel fingerprint on just the image data… that dedup work was able to identify the same image even if it were resized.
Do you have any suggestions on a sequence or strategy that allows retroactive tagging of things in a ps library?
Oof, sorry for PhotoStructure adding those duplicates!
Unfortunately, v2.1.0-alpha.7 only had one image hash algorithm (a “mean hash” triplet in L*a*b colorspace), which (by design) would collide with very similar image content.
Prior versions just looked at the image hash, which resulted in quite-differently-timestamped images being aggregated together if the shot was basically the same.
The next build includes two new image hash algorithms–DCT and gradient/diff hashes–so if all three hashes match, it’s very similar image content.
So–what would be the “clever” solution for PhotoStructure to not just generate more duplicates in your library? Basically–how do I do the right thing if one variation of a photos’ captured-at time was edited to be correct, but there are other variations with the old (incorrect) time?
Approach 0: PhotoStructure edits the captured-at time, and therefore knows what’s going on, and can do the right thing.
Approach 1: I could SHA just the image content (basically SHA’ing the image after stripping all tags), but this can be “tricked” by editing the image contents.
Approach 2: Some software applies a unique identifier (a “uuid”) to all images–and all edits, as long as the uuid persists, are considered the “same” image. The issue with this approach is it hopes that other external software will retain these UUID tag values when editing/re-saving. Some image formats (like Apple’s live-photo HEIC) already include UUIDs.
Can you think of another approach? I’m happy to talk through that (either here or on discord).
I think approach 1 seems the most reasonable among the three because:
- ps already has a sha hashing framework in place so regression testing would be brief
- exif is generally standardized in its placement and structure, so an exif stripper ought not be too difficult to implement in a way that it doesn’t damage sync durations
- I think if the image itself changes (and thus the image sha), it would be reasonable to consider it a different photo. Even something relatively ordinary as a whitebalance correction would produce an image that looks different from its parent. Despite that, bloating a date with 10 near-alike pictures because a user was tinkering with filters will feel burdensome later when they’re just looking through the album with friends. Having a ps option to group very-similar items together and visually display the most recent/oldest/biggest/exif-heaviest might be a nice way to coexist with such duplicates and reduce visual clutter while retaining recognition of their differences, should that level of distinction be desired now and then.
- I think most users would find being able to retroactively edit the metadata of their library useful. Ps is a very fine cataloging and displaying application that stakes no claim on classification. This leaves a complimentary place open for such a thing (like digikam).
One thing I forgot to mention is that I’m still using v 1.1.0. I’ve tried 2.* versions with snapshots of this library and both times ended in ruin (though I no longer remember the specifics). If it would be of interest to you, I can give it another go if there’s a particular chunk of telemetry you’d be interested in seeing when ps 2.x is placed in front of 180,000 pictures.