I’m sorry if these are vague or too general questions, but I’m working through whether Aspect fits with how I normally work and manage my library.
I am a hobby photographer who shoots mostly snapshots, but also a few events (parties, portraits, travel, etc.). Mostly, I shoot a handful of photos each day, only some of which merit inclusion in an “event” folder. This means my Photo Stream is going to be a long list of 1-10 photos, divided by day. It works, but may not be the most efficient layout for my sort of library.
Is there anything planned for condensing the Photo Stream view? Perhaps something that doesn’t break things up into “Paragraphs” at all. Something like Apple Photos “All Photos” view of just one long grid of photos. Perhaps this goes too far against the grain of what Aspect is trying to do, but it still seems like it would be useful.
EDIT: I just found and tested a few of the Sorting Mode options and several of those get me close. Probably “Import time”. It would be helpful if I could also use “Capture time” but sort it reverse-chronologically, if that’s possible. The ideal thing for me would be the default sort, but without dividing photos into paragraphs by day. Doesn’t hurt to ask, right?
Another thing. I shoot a fair amount of film. I average maybe 2 or 3 rolls per week. I’m curious if anyone has thoughts about how I might manage those scans. I store them in separate folders for each roll. If I make each of them an event, that’s going to be a long list of events in the UI. This may never be a real problem, but are there plans to have additional levels of organization of events? I could use collections, but it feels like I should use events.
Thanks for any insight here. Aspect has some really nice ideas, so I’m happy to alter my workflow to work how it expects, but the more I don’t have to do that, the better!
We’ve talked a bit about this today and reviewed this in the context of our own libraries and came to basically the same conclusion - a more coarse grouping would be better fit. The problem is that a coarser grouping would make a fundamental issue in the current ordering a lot more pronounced — while the general order is descending in date, the order within each day paragraph/section is ascending in time of day. For single days that is often not really noticeable, but for spans of multiple days that would result in some very strange jumps back in time when going through the photos.
Ultimately, we decided that we need to revert a decision that was made a long time ago and completely revert the sorting so that the newest photos are at the bottom. The photo stream header will then need to keep a fixed size to compensate for the default scroll position being at the bottom, but that would fix another request at the same time — keeping the library statistics visible while scrolling through the photos.
I’ll try to put out a new RC tomorrow or on Monday that will have the new order and, for now, will use a monthly grouping, which worked pretty well in the libraries we have tested. We’ll then see whether there is demand to make this more configurable or whether we can get away with less complexity.
There is a plan to allow assigning custom properties to events that can then be used to control the path pattern for the file system, as well as forming the event list/tree within the application. The UI for this hasn’t been fully worked out, yet, but this is one of the things to be tackled next year.
Edit: BTW, at least the crash that was happening when deleting an event with moving the included files to the photo stream will also be fixed. Unfortunately the crash report quality on macOS is very limited at the moment due to a compiler issue (missing proper stack traces), so I couldn’t reproduce/diagnose all of the reports so far.
This sounds like a good solution. I don’t envy having to think of every side effect of every change!
Sounds useful. Will this include something like an “official” Event Date for each event? One behavior in Aspect that surprised me was that after editing a (jpg) file in an existing (older) event, the event moves to the top of the list. I assume this is because it’s now considered “newer”. I looked for a way to quickly restore the date of the original file, but didn’t see one. If I could figure out how to prevent the date from updating, that would be good, too.
Definitely noteworthy how often seemingly simple changes can have massive hidden complexities! (Even if in this case it’s not so much hidden complexity, but rather unexpected visible changes…)
Does the original image have an explicit capture time in its metadata? The only case I can think of where this should be expected is when an event only contains a single image that doesn’t have metadata. In that case it would take the modified time of the file instead. The event date is computed as the median date of all images in the event, preferring the newer date in case there is an even number of images. So in that case the modification time of the edited image would be chosen.
If this was not the case here, it could maybe be some timing related issue. Does the event eventually go back to its previous date or does it stay that way indefinitely?
The event does not go back to its previous date. The original files do have exif dates.
I’ve tried this in several more events, and it seems to only affect the film scans, when I do “Edit a copy” (Photoshop). It could be something to do with the way I set the date with exiftool after scanning. The behavior does not happen with other files. I’ll see if I can figure out what’s different. Thanks again for the reply.
