Ability to quickly favorite a photo while browsing

Feature Requests
6

i think you should have both, a page for favourites and the search filter.

3 Likes
7

I definitely am onboard with the multi selection and being able to set a tag.

However I think a simple favorite or not with a page showing all favorites would be welcome too. Just a star, a heart, maybe just double tap the image. Then they all show up in a library called favorites. Simple and fast.

8

Totally understand the desire, and don’t disagree… I do strongly wish for the data to be stored somewhere in the normal EXIF/IPTC fields so that it’s mobile across platforms. If it’s “just” in the PhotoStructure database, then it’s “vendor lock-in” and I’ll avoid using it - which I would rather not :slight_smile:

9

Absolutely: this is a big design goal of PhotoStructure from the beginning.

I’ve been completely sunk by prior abandoned apps that squirreled stuff into places that were hard to extricate.

I wanted to test the favorited:true search query, so I just added a tag parser that sets assets as favorited if the “best” variant has a rating of >= 4. This will land in -alpha.3. UI to do mark assets as favorite (and save a sidecar or file metadata with a value of Rating) will come in a future release.

1 Like
10

And just to be clear… unless you go off in left field, I’m saying that I would avoid using that feature, not avoid PhotoStructure :slight_smile:

1 Like
11

I suggest to start using custom EXIF hierarchical subject/keyword to store any PhotoStructure specific metadata, so it’s available to view even outside of the PhotoStructure app itself if needed. Such as

!!!PhotoStructureInternal > Favorited

Or

!!!PhotoStructureInternal > Rating > 5

Or

!!!PhotoStructureInternal > Collections > !!!QuickCollection

This model will allow you to store any textual metadata but being available to view via ExifTool or any other DAM with hierarchical subject support

1 Like
12

Interesting idea!

As far as I understand, EXIF tags don’t support arbitrary keys.

All of the metadata the PhotoStructure extracts or modifies should be able to be encoded in standard tags.

I’m hoping to be able to encode all user operations into the XMP history struct: https://exiftool.org/TagNames/XMP.html#ResourceEvent

13

The reason I suggested to keep the metadata in the HierarchicalSubject tag rather than custom XMP tags because most of the software I’ve used don’t have a nice way to view those. From the other hands, hierarchical keywords are visible even in standard Windows File Properties window (in a flat form, though)

1 Like
14

Alternatively, I suggest you to use both custom XMP tags with the fallback to the hierarchical keywords.

Personally, I even use keywords like Albums > Album1 in addition to putting my photos to Album1 album in my DAM, so this information is not vendor-locked and I can easily switch my DAMs if needed

1 Like
15

I think a heart and/or a 5 star or even 3 star system would be good. 10 star is too much.

I also agree with what was said about multi-selection being key and the overlay for various actions to do on the multiple images.

I think this ability is very closely related to albums.

16

Since I saw the link to the initial release on the 2.0.0-alpha build I was re-reading this thread and thought of something- not asking for a change, just pointing out a different use case fir future thought.

Up the chain @mnm mentioned looking for items with >4 of whatever as favorites… makes sense and I don’t object.

But… I use stars differently… it’s a system I saw recommended somewhere and really clicked for me.

Good pictures get 1 star… then the best of those might get 2… and the best of the two’s get a three- I don’t think I have any (yet) above that.

So instead of seeing a really good picture and saying “that’s a five” I say “that’s a star”. And then if I’m browsing starred pictures and one really stands out somehow, it gets another star.

Maybe it’s just a weird mental thing for me :slight_smile:

Again, just a random thought.

1 Like
17

I actually made the rating for what :heart: means be configurable, so we can handle 1 star. It’s just a toggle for now, though, so the “super star” isn’t handled (yet).

18

Sure: it’s a bit involved!

  1. If a user has liked (or un-liked) an asset via PhotoStructure, and the asset file variations nor their sidecars have not been touched since that action was made, that value wins.

  2. Otherwise, PhotoStructure looks for a number between -1 and 5 associated to the Rating metadata tag (see the XMP specification: (this supports a value from 0 to 5, or -1 for “rejected”) in both files and sidecars. “First one in wins”: PhotoStructure first looks at the “best” asset file variation and sidecars. If that file doesn’t have a value, it looks at the first file with a value in order of last-modified time. If no value is found, it looks at the RatingPercent tag (which is only rarely used) and converts it to a value between 0 and 5.

    Given that we find either a Rating or RatingPercent, the asset will be considered “liked” if the value is equal to or greater than the new-in-version 2.0 likeRating setting, which defaults to 3.

  3. If we still don’t have a value yet, we’ll look for a Google Takeout JSON file associated to any asset file variation. If any are found, and a favorited value is set, we’ll use that.

1 Like
19

You probably have it somewhere, but a single “reference document” of which metadata fields are used by Photostructure would be a great resource.

Feel like I’ve asked (and probably had this answered) before, sorry if it’s a repeat :slight_smile:

2 Likes
20

Nope: I’m afraid I’ve done pretty much all of it on-demand.

When I get a chance, I’m wanting to convert the docs at photostructure.com (and more reference docs from the forum) into a proper manual: Migrate all PhotoStructure documentation to a "manual"

21

I’m happy to see this feature in the latest alpha release! I wanted to highlight one thing I noticed in hopes to prevent somebody from having to do a lot of double work.

By default, Photostructure stores a “favorite” as a 3-star rating (out of 5 stars). This is configurable via the likeRating settings.toml entry. You can set likeRating = 5 if you want your favorites to have 5 stars, for instance.

I went ahead and set likeRating = 5, but only after favoriting a few photos under the default like rating. After restarting Photostructure, the photos that I had previously favorited were no longer favorites. I favorited them again, and the files were updated with a five-star rating.

The moral of the story: make sure you set your desired likeRating BEFORE you start favoriting photos in Photostructure, otherwise you may have to re-favorite after making a change.

1 Like
22

Sorry for reviving this thread, but I wonder if that got finally solved and how.

I remember using Google Picasa and just tagging any picture as favorite while browsing with a simple press of the spacebar (if you pressed it back, the “star” dissapeared with a cool animation, it was great), and I’d like to be able to do something like that in Photostructure.

There is no shortcut for marking a picture as favorite. My vote here would be to clone Picasa’s system: a simple boolean (a ‘star’ or a ‘heart’) and then a ‘Liked’ or ‘Favorites’ category with all those pictures tagged with that ‘star’.

This old video shows the thing, but the user clicks on the star icon instead of just pressing the spacebar. Anyway, I loved this feature and I’d love to see it in PhotoStructure :slight_smile:

23

Version 2.1 (currently in alpha) implements this feature: PhotoStructure | How to archive, remove, and delete photos and videos in your PhotoStructure library

The keyboard shortcut is L (for “like”) or *. Making the spacebar be fave is interesting, I’ll try that and see what breaks.

1 Like
24

Point 1:
Search abbreviation faved is past tense whereas the full favorite is present tense. You can keep faved, but intuitively I would expect to be able to use abbreviation fave and/or fav.

Point 2:
How should it work once PhotoStructure supports multiple users? I suspect different users will want different favorites/ratings. Perhaps in addition to the Rating / RatingPercent metadata tag which stores the most recent rating, PhotoStructure could add/update a hierarchical tag based on which user is making the edit?

Alice wants to view Bob’s favorite pictures, so searches for:
fave kw:favorite/bob:>=4

Eve wants to view pictures of Alice with a rating from Bob or Carol of at least 4, so searches for:
fav who:alice (kw:favorite/bob:>=4 OR kw:favorite/charlie:>=3)

25

Good point! I’ll fix it.

My current thinking is that an asset has an inherent rating that is assignable by “library owners.” That’s what the fave button assigns currently.

Once there are users, they can add “reactions” to an asset (presumably with an emoji). If you think in SQL, this new reaction table is asset-id, user-id, reaction, and timestamps.