feat: Add rejected ratings support

[Flohhhhh]

Description

Implements issue #1057 steps 1-3 by adding first-class rejected ratings backed by -1, wiring a reject toggle into library/editor workflows, and surfacing rejected state in filtering and thumbnail views.

Closes #994

Type of Change

• Bug fix
• New feature
• Breaking change
• Performance improvement
• Code refactoring
• Documentation update
• UI/UX improvement
• Build/CI or Dependency update

Changes Made

• Added signed rating support on the Rust side so .rrdata and XMP sync can persist rating = -1 for rejected images
• Added reject toggling from keyboard (X), culling actions, metadata controls, and context menus
• Added a separate rejected-status library filter alongside existing star-rating filters
• Updated main library and filmstrip thumbnails to fade rejected items and show a minimal neutral X indicator
• Updated shortcut/help text and adjusted culling copy away from the old red-label wording

Screenshots/Videos

Testing

• I have tested these changes locally and confirmed that they work as expected without issues

Test Configuration:

• OS: MacOS Tahoe
• Hardware: Macbook Pro M3 Pro w 18GB RAM

Checklist

• My code follows the project's code style
• I haven't added unnecessary AI-generated code comments
• My changes generate no new warnings or errors

AI Disclaimer:

Please state the involvement of AI in this PR:

• This PR is entirely AI-generated
• This PR is AI-generated but guided by a human
• This PR was handwritten with AI assistance (spell check, logic suggestions, error resolving)
• This PR contains only blood, sweat, and coffee (AI-free)

[Flohhhhh]

I'm still working on this and considering ideas for the UX for bulk selecting files by rating/color.

Let me know your thoughts!

[mmadesignerunknown]

@Flohhhhh can you please add this functionality:
In here:

Add ✓ marks for unrejected images instead of keeping them blank.

[Flohhhhh]

@Flohhhhh can you please add this functionality: In here:
Add ✓ marks for unrejected images instead of keeping them blank.

In my opinion I don't think that's a great move, this would mean every photo either has a check, or X, and would have a check as soon as the folder is opened for the first time

In Lightroom they also have "Flag as Pick" as a contrast so the states would be "Flagged, Unflagged (empty state), Rejected)

Personally, I found the "Flag as Pick" as a bit of a redundancy with ratings though...

My mental model is:
-1 Rating = Rejected = Plan to delete entirely
0 Rating = Empty = Default state, No plan to remove or keep
1-5 Rating = Picked = Picked photos, sort best photos, plan to keep and export

What do you think? @mmadesignerunknown

[mmadesignerunknown]

@Flohhhhh
The mental model you presented looks great in my opinion.

[Flohhhhh]

Alright I added a Select by... button to the library header buttons for now.

I think this spot is starting to become a bit crowded, might want to consider adjusting this soon, but out of scope.

I'm going to leave moving files to folders out of this PR since it seems to be a bit of a larger change that is also out of scope.

So this is considered done from me, added rejection using -1 rating as detailed in my original comment. Also added this batch selection dropdown shown above. Ready for review!

[mmadesignerunknown]

A Feature I think will be good if it gets added to this PR.
Currently the "Select By..." menu is like:

- Rating
    - Not Rejected 
    - Rejected 
    - Unrated 
    - 1 & up 
    - 2 & up 
    - 3 & up 
    - 4 & up
    - 5 only 
- Color Label 
    - Red, Yellow, Green, Blue, Purple 

I think it will be better if it's like:

- Rating
    - Not Rejected 
    - Rejected 
    - Unrated 
    - Rated
        - 1 only 
        - 1 & up 
        - 2 only 
        - 2 & up 
        - 3 only 
        - 3 & up 
        - 4 only 
        - 4 & up 
        - 5 only 
- Color Label 
    - Red, Yellow, Green, Blue, Purple 

What do you think @Flohhhhh

[Flohhhhh]

A Feature I think will be good if it gets added to this PR. Currently the "Select By..." menu is like:

    - Rated
        - 1 only 
        - 1 & up 
        - 2 only 
        - 2 & up 
        - 3 only 
        - 3 & up 
        - 4 only 
        - 4 & up 
        - 5 only 
- Color Label 
    - Red, Yellow, Green, Blue, Purple 

What do you think @Flohhhhh

Hmm, I get the goal of this definitely.
It's just a lot of UI to have for something I think would rarely be used.

I'm trying to think of some way to allow specific starts instead of inclusive with greater stars cleanly.

[Flohhhhh]

@mmadesignerunknown that adjustment to filtering by rating more granularly is maybe out of scope for this PR, we use the same logic in the filters panel, so I think we should have a targeted approach at both of these methods together in the future

[mmadesignerunknown]

A Feature I think will be good if it gets added to this PR. Currently the "Select By..." menu is like:

    - Rated
        - 1 only 
        - 1 & up 
        - 2 only 
        - 2 & up 
        - 3 only 
        - 3 & up 
        - 4 only 
        - 4 & up 
        - 5 only 
- Color Label 
    - Red, Yellow, Green, Blue, Purple 

What do you think @Flohhhhh

Hmm, I get the goal of this definitely.
It's just a lot of UI to have for something I think would rarely be used.

I'm trying to think of some way to allow specific starts instead of inclusive with greater stars cleanly.

Agreed so what do you think of this:

- Rating
    - Not Rejected 
    - Rejected 
    - Unrated 
    - Rated
        - 1 only [Toggle: include images woth more than 1 star] 
        - 2 only [Toggle: include images woth more than 2 stars] 
        - 3 only [Toggle: include images woth more than 3 stars] 
        - 4 only [Toggle: include images woth more than 4 stars] 
        - 5 only 
- Color Label 
    - Red, Yellow, Green, Blue, Purple

Note:
Toggle: include images woth more than N star(s)
Can be replaced with a one or two words

What do you think about this @Flohhhhh

[Flohhhhh]

@mmadesignerunknown yeah i agree that type of method would be ideal, only thing that needs to be figured out with that is how it gets committed, either a "Accept" or "Select" button at the bottom to execute based on selection, or automatically update as you click.

Either way, out of scope for this i think (ref my last comment)

[mmadesignerunknown]

@mmadesignerunknown yeah i agree that type of method would be ideal, only thing that needs to be figured out with that is how it gets committed, either a "Accept" or "Select" button at the bottom to execute based on selection, or automatically update as you click.

I think "Select" button at the bottom will be better.

Either way, out of scope for this i think (ref my last comment)

Well, then let's work on it together @Flohhhhh once this PR gets approved ;)

Regards,

[DomDomonom]

Personally, I found the "Flag as Pick" as a bit of a redundancy with ratings though...

My mental model is: -1 Rating = Rejected = Plan to delete entirely 0 Rating = Empty = Default state, No plan to remove or keep 1-5 Rating = Picked = Picked photos, sort best photos, plan to keep and export

What do you think? @mmadesignerunknown

Just my two cents as a photographer who processes 5-10k images a week, the flag/reject being a separate metadata point is exceedingly useful as ratings can then be kept exclusively for qualitative purposes and flag/unflagged/reject for workflow state purposes. Back when I was on lightroom, I’d use flag to denote what was finished and going to be delivered to the client, while still being able to keep my qualitative ratings intact for other purposes or even just speeding up not having to down rate images that wouldn’t be sent to clients. Easier for me to just pick the photo I wanted rather than down rate the other images. It’s the main thing I miss from lightroom quite frankly.

Honestly, the more metadata surfaces to organise photos, the better, for power users. More flexibility is always preferred so people can have their own mental models and workflows. I’d personally find it more useful if rejects or future consideration for flags did not overwrite star rating metadata.

[Flohhhhh]

I originally limited to rejection since I learned that it just uses the -1 rating which keeps things pretty simple. I'll look into how Lightroom does the flags to see if it's a good fit.

At the end of the day it's just a question of:

Do we just copy every metadata because some people will have used it before? Or do we choose the most reasonable set to have a more opinionated and streamlined workflow?

Personally I'm not sure but I've noticed this coming up very frequently here.

[DomDomonom]

That's definitely an important design consideration, and I understand the desire to keep everything usable, understandable and performant and not add every bell and whistle that everyone has become accustomed to. However, if this project is wanting to reach working photographers, and I don't know if that's even the goal, this is genuinely the kind of small thing that can be a dealbreaker for some people. Problem is when you're working at the sheer volume that myself and my colleagues work at, the slightest inconvenience can lead to hours wasted per month, particularly if there's a couple small hitches adding up, which means less beauty sleep (desperately needed) or less projects I can take on.

A side benefit to emulating competitor metadata is perhaps the future possibility of cross-compatibility/migration with people's existing libraries. This is also a massive sticking point in getting people over. I have over 3 million photos in my library, if none of that critical organisation can come with me, that's a problem. Edits/adjustment cross-compatibility/migration is obviously an insane problem I personally would never expect this project to address, but just having the organisation/metadata compatibility would be enough. I can redo an edit on an image quickly enough, but finding that image in the ocean of my archive from scratch is a much harder task.

Also, there's a lot of people sick to death of subscriptions, so yeah, that's a huge market, particularly in the lower/casual end where budget is a concern but they still want consistent access to their libraries. On the pro end, I'd also feel more secure switching to rapid raw if I know I can switch back to something else if the project goes sideways/whatever.

I'm not saying my needs are RIGHT but I just wanted to add the other end of the conversation from the perspective of someone who absolutely needs all the bells and whistles.

I personally have a lot of budget to spend on software that makes my life easier, as do my colleagues who are all very tech focused. If this project ended up meeting my needs and I was able to unsubscribe from commercial products I would be happily pour that budget into sponsoring this project as I'm sure many of my colleagues would as well. I figure your goals ain't profits, but I would support to make the project more sustainable, not that I'd expect y'all to sell out to shutter gremlins like myself

[Flohhhhh]

@DomDomonom do you think color labels would be a suitable adjustment to your workflow for this purpose?

When I shoot sports events sometimes where I need to categorize the photos into things like:

• Delivered
• Needs edits
• Keep for self/portfolio

I usually will use like red/green/blue colors, and keep rejected as ones to cull.

Personally to me it feels really bad to add a feature which is just the same thing as another feature. Flag would basically just be like a 6th color, which may not be necessary.

I'm thinking:
rejection is "plan to delete"
unflagged is "plan to keep"
flag is also "plan to keep" (or sometimes used as a faux collection/label)

I think flag is arbitrary compared to rejection, it doesn't solve the same problem.
This is my opinion of course, but i think the design of flags in the first place are flawed.

Compatibility with existing image sets is a great goal, but I'd argue a more thought-out and modern UX is more important.

We should hear others thoughts : )

[DomDomonom]

@Flohhhhh

So my main concern here is that star ratings, reject/flags, and colour labels can only ever have one state. An image can only be one or none of those things. So if we just have 2 metadata states, that means there's only two states I can track easily. I personally use colour labels as a tertiary organiser depending on the shoot, sometimes it's for client selects, behind the scenes or for gigantic/live edits I use colour labels to track what point in the workflow the image is in.

I strongly feel that flag/pick and rejected should be a third metadata state. Limiting it to two states stifles further easy organisation. Yeah you could use keywords etc for some of these use cases but because of the volume I have to process, I am basically entirely editing on keyboard and Tourbox, and if I need to mouse over and find the keyword every time, that's another one of these little delays that add up like I was talking about. And for the metadata compatibility I mentioned

I agree a modern streamlined design is preferable. I would suggest these are toggleable and by default only show star ratings. Colour labels are probably even unnecessary for most people. That way the majority of users don't have an intimidating interface that wastes space, but when people need more they can add more.

Basically the need for granular organisation is a spectrum. The average person is happy with a heart on their phone's gallery app, that's all they'll ever need. Hobbyists typically only need one, You need two, I need three and wouldn't say no to more. When someone needs more, they really need more, and it's much more of a problem than onscreen clutter.

I mainly use capture one these days which isn't overall a masterclass in UX, but I massively appreciate that I can tailor my workspace to the type of project I have on hand, simplifying or pulling out all the stops as needed. Obviously wildly out of scope for this PR, but their workspace saving system is very useful and worth checking out if you're not already familiar.

My current workaround since c1 doesn't have flags/rejects either is just moving files around in the session folders (select/trash), which is an ugly workaround, and honestly the flags are what I miss most since my switch.