FEATURE: Various! We need Collections/Albums and a grid/compare/loupe view (drag-and-drop would be nice too).

[Scottua25]

Feature Description

I’d like to request that the official RapidRAW repo add the Collections workflow and expanded library viewing modes that I’ve implemented in my fork.

Summary

The feature set adds a more complete photo culling and organization workflow directly inside RapidRAW:

• Collections for grouping images independently of their folder location
• A persistent custom order for collection contents
• Drag-and-drop support for adding images to collections
• Library presentation modes: Grid, Loupe, and Compare
• Keyboard shortcuts for quickly switching views

Together, these make RapidRAW much stronger as a full photo review and editing tool, especially for users working through shoots, selects, edits, client picks, or themed groups of images.

Collections

Collections allow users to create named groups of images inside the current RapidRAW session without physically moving the original RAW files. This is useful because folder structure is not always the same as editing intent.

Examples:

• “Portfolio Picks”
• “Client Selects”
• “To Export”
• “Black and White Candidates”
• “Needs Retouching”
• “Final Delivery”

Images can be added to collections from the library/editor context menus or by dragging images into a collection. A collection stores references and metadata sidecars rather than duplicating the RAW files themselves, so it behaves more like a lightweight virtual grouping system.

The implementation also supports virtual-copy-style entries, preserves edit metadata, tracks missing source files, and supports manual ordering through a saved collection order manifest.

Why this should be added:

• It gives users a non-destructive way to organize selects.
• It avoids forcing users to duplicate files or restructure folders.
• It fits naturally into RAW editing workflows where one image may belong to multiple working sets.
• It helps RapidRAW compete better with library-management features found in other photo tools.

Grid / Loupe / Compare library views

The fork also adds three library presentation modes:

Grid

Grid remains the standard thumbnail browsing view. It supports the existing browsing workflow, thumbnail sizing, sorting, filtering, recursive folder browsing, selection, ratings, and context menus.

Loupe

Loupe view shows the active or selected image in a larger inspection view directly from the library. This is useful for culling because users can inspect an image more carefully without fully entering the editor.

It also supports zoom behavior, making it easier to check sharpness, focus, expression, noise, or small details while reviewing images.

Why this matters:

• Faster culling.
• Less context switching between library and editor.
• Better single-image inspection from the library.

Compare

Compare view displays selected images side by side. This is especially helpful when choosing between similar frames, burst shots, portraits, exposure variants, or virtual copies.

Users can select multiple images in the library, switch to Compare, and visually evaluate them together.

Why this matters:

• Makes select/reject decisions much easier.
• Supports practical photography workflows like choosing the sharpest frame or best expression.
• Reduces the need to open external viewers for comparison.

Keyboard shortcuts and workflow

The fork includes quick presentation-mode switching:

• G switches to Grid view
• C switches to Compare view
• L switches to Loupe view

These shortcuts make the library much faster to use during high-volume review sessions.

Why this belongs in the official repo

RapidRAW is already a fast, GPU-accelerated RAW editor, but these additions make the library side much more powerful. Collections and comparison tools are core workflow features for photographers, not just convenience features.

Adding them would make RapidRAW better for:

• Culling large shoots
• Building export sets
• Comparing similar frames
• Managing virtual copies
• Organizing edits without changing folder structure
• Moving between browse, inspect, compare, and edit workflows smoothly

My fork has a working implementation that demonstrates the intended behavior:
https://github.com/Scottua25/RapidRAW

I’d love for these ideas to be considered for the official RapidRAW roadmap, whether by reviewing the fork, adapting the implementation, or using it as a reference for a cleaner upstream version.

Additional Context

You can see these features in action here:
https://github.com/Scottua25/RapidRAW

This is not intended as a PR request yet, but my fork can serve as a working reference for the behavior, UI flow, and implementation details.

Similar feature requests

• I have searched existing issues and discussions and didn't find a duplicate

[mmadesignerunknown]

@Scottua25 ,
Thanks for this, but if you want to get it implemented, you will first have to open a Pull Request.

I know that it's stated that this is not intended as a PR, but I think instead of creating all this again, it will be better if the existing implementation gets merged. What do you think.

Regards,

[Scottua25]

@mmadesignerunknown ,
I would but i don't think i have the github knowledge necessary to do that in a way that would benefit the project or make it straightforward for @CyberTimon to merge cleanly. My fork example was for just that, an example. I was done originally on 1.5.2 and again on 1.5.3 when it was released. The changes would require multiple prs but that would make merging a mess. Same if i did one big pr. I was hoping Timon would take a look and maybe get inspiration for a way to add these features in his next release. I would be willing to work with him or whoever to get a good pr added but the extent of my coding/git knowledge is limited to telling codex what to change in vscode.

[mmadesignerunknown]

Ohh, okay, as you wish :)

[Flohhhhh]

I agree with many things here, this is just a very broad issue haha.

1. Related issue here FEATURE: Improve Culling Support #1057
2. Agreed on folder movements by dragging images
3. For what it's worth, I have a personal vendetta against both the library and edit views having a full screen image preview (regarding your loupe view idea), feels very redundant, not sure what the solution is
4. Collections sounds like a good addition, but I wonder does color labels solve this already?

[Scottua25]

@Flohhhhh ,

Thanks for the feedback. Let me attempt to address those points.

1. Thanks, i searched but that didn't come up.
2. This one is KEY for folder based organization and prevents you from having to leave the ui to organize.
3. I think a way to see an image full size (or at least with a zoom interface) lets you verify focus without having to switch into the edit ui to do so. This functionality is in almost all major raw processing softwares.
4. I don't think color labels solves this since there are a finite amount of colors to use and that's more of a culling feature. One use case for collections (and the one i use it most for) would be to have multiple collections where the same image could exist (as virtual copies) each with their own edit (crop, color, treatment, etc) without affecting the original raw image. In my implementation each folder that's opened as the "home folder" can have it's own set of collections and the app would only see the collections in home folder that's open. So if you have a main archive but open a subfolder the collections would only display for that subfolder. Likewise, if you open the main archive folder you would only see the collections there. It opens up an ton of organizational potential without adding very much overhead.

Thanks again for the feedback and i hope my rambling made some tiny bit of sense.