I often return from a trip with thousands of digital photos to organize. The standard workflow is to import everything into a Lightroom catalog and complete the entire pipeline—culling, star-rating, cropping, denoising, adjusting, and exporting—within Lightroom. However, Lightroom's photo loading speed is not particularly outstanding, and once a catalog grows to tens of thousands of images, startup becomes painfully slow. Therefore, I prefer to use a lighter, faster photo viewer for culling before importing the keepers into Lightroom. Through conversations with others, I've learned this is not an isolated need; it is a common requirement among photographers.
I used nomacs for this step now, but I recently discovered QuickView. Its speed, simplicity, and modern design make it truly ideal for this task. However, like nomacs and many other viewers, QuickView has some friction points when used in this specific workflow. I have listed them below and hope to discuss with the QuickView maintainers which of these might be acceptable. If the maintainers are open to it, I am also willing to contribute code.
1. Pairing same-name RAW and JPG as a single logical photo
When shooting with a digital camera, saving as RAW+JPG (or the newer HEIF option available on recent cameras) is extremely common. This results in one digital photo corresponding to two files. In virtually every photo viewer, these are treated as two independent photos, which causes a series of problems:
- The browsing workload is doubled
- Every RAW file is loaded, which is typically far slower than its JPG counterpart
- Deleting a photo requires two separate actions. After deleting the first file, the next photo shifts into position, a process that easily leads to accidental deletion
Requested feature: Add an option to "Pair RAW with same-name JPG." When enabled, the RAW+JPG pair would be treated as a single photo.
- When the user needs it, a single press could load the RAW file to inspect details, or QuickView's existing excellent comparison tool could be used to compare the JPG and RAW side-by-side
- When performing a delete operation, a dialog would offer the user several options:
- Delete both RAW and JPG as a pair — the photo has no value
- Delete only the RAW — the photo has no post-processing value, but the JPG can be kept as a record
- Delete only the JPG — the photo is part of a panorama stitch or HDR sequence; after stitching, a new JPG will be output, so the individual JPG is no longer needed for browsing
Prior experience: I once forked nomacs to implement this feature. Before submitting a PR, I opened an issue to discuss it with the nomacs maintainers. Their first concern was that in some scenarios, a same-name RAW+JPG pair might not actually belong to the same photo. To address this, I refined the solution: before pairing by filename, the code checks the EXIF data and requires both files to have a capture-time field (e.g., DateTimeOriginal), pairing them only if the timestamps match exactly. In response to this improvement, the nomacs maintainers then stated that they do not consider photographer needs to be a mainstream requirement for a photo viewer. Given their attitude, I did not submit the PR, but this forked version has been in continuous use by me and my friends ever since.
I really hope QuickView can adopt this feature. If needed, I am happy to contribute the code.
2. Info panel size on high-resolution displays
Regarding image information display, nomacs' info panel is quite rudimentary, so I once built a dedicated photographer HUD for it. QuickView's info panel, by contrast, is already excellent. There is just one issue: the panel appears very small on high-resolution displays. Would it be possible to support resizing?
3. Local zoom / loupe function
A local zoom feature: when the user clicks on a point in the photo, overlay a popup at the mouse cursor location that magnifies the local area to 100%. This is useful for quickly confirming focus accuracy while browsing.
4. Thumbnail improvements
a. Progressive thumbnail loading
Thumbnail display is currently quite coarse. I understand this is a trade-off for loading speed, but would it be possible to progressively load higher-resolution thumbnails after the coarse placeholders have loaded?
b. Sidebar thumbnail navigator
While browsing a large image, would it be possible to open a sidebar—like most photo viewers—that displays thumbnails of the photos in the current directory and highlights which one is currently being viewed?
c. "Open Folder" when no image is open
When no image is currently open, the "Open Folder" function appears to be unavailable. Is this a bug or intentional design?
5. Metadata-based features (respecting QuickView's philosophy)
There are also some features that may not fully align with QuickView's philosophy of being a pure viewer that does not edit files. I understand and respect this philosophy: QuickView is not meant to replace Lightroom or Photoshop, but to remain a lightweight, fast browser. However, the existing rotate and mirror functions already involve file modifications. So I understand QuickView's acceptable boundary to be: no pixel-level modifications, but modifications to metadata and pixel arrangement are acceptable. The items below generally follow this principle.
a. Star ratings, color labels, and flag markers
Display, modification, and filtered viewing based on this data. This only involves metadata changes and does not touch the image pixels. It is extremely useful for photo browsing, collection, and culling.
b. GPS information display and modification
Many modern cameras, including smartphones, embed shooting-location coordinates in EXIF data. For reviewing travel photography, being able to display photos on a map would evoke many more memories. I realize this feature might be too heavy for QuickView; if it is hard to accept, perhaps it could be implemented in future plugin system.
c. Crop function
This might lean more toward editing, but cropping is a high-frequency operation. As an image viewer, not supporting cropping feels genuinely inconvenient, forcing users to switch to another tool. Moreover, cropping does not change any pixel values—it only selects and discards pixels—so I believe it should also fall within the acceptable boundary.
Summary
In summary, these are quite a lot of ideas. I felt opening multiple separate issues might be distracting, so I have grouped them together here as they all reflect the needs of a photographer. I am not just asking for features; if the maintainers are interested, I would be happy to submit PRs to contribute this code.
I often return from a trip with thousands of digital photos to organize. The standard workflow is to import everything into a Lightroom catalog and complete the entire pipeline—culling, star-rating, cropping, denoising, adjusting, and exporting—within Lightroom. However, Lightroom's photo loading speed is not particularly outstanding, and once a catalog grows to tens of thousands of images, startup becomes painfully slow. Therefore, I prefer to use a lighter, faster photo viewer for culling before importing the keepers into Lightroom. Through conversations with others, I've learned this is not an isolated need; it is a common requirement among photographers.
I used nomacs for this step now, but I recently discovered QuickView. Its speed, simplicity, and modern design make it truly ideal for this task. However, like nomacs and many other viewers, QuickView has some friction points when used in this specific workflow. I have listed them below and hope to discuss with the QuickView maintainers which of these might be acceptable. If the maintainers are open to it, I am also willing to contribute code.
1. Pairing same-name RAW and JPG as a single logical photo
When shooting with a digital camera, saving as RAW+JPG (or the newer HEIF option available on recent cameras) is extremely common. This results in one digital photo corresponding to two files. In virtually every photo viewer, these are treated as two independent photos, which causes a series of problems:
Requested feature: Add an option to "Pair RAW with same-name JPG." When enabled, the RAW+JPG pair would be treated as a single photo.
Prior experience: I once forked nomacs to implement this feature. Before submitting a PR, I opened an issue to discuss it with the nomacs maintainers. Their first concern was that in some scenarios, a same-name RAW+JPG pair might not actually belong to the same photo. To address this, I refined the solution: before pairing by filename, the code checks the EXIF data and requires both files to have a capture-time field (e.g.,
DateTimeOriginal), pairing them only if the timestamps match exactly. In response to this improvement, the nomacs maintainers then stated that they do not consider photographer needs to be a mainstream requirement for a photo viewer. Given their attitude, I did not submit the PR, but this forked version has been in continuous use by me and my friends ever since.I really hope QuickView can adopt this feature. If needed, I am happy to contribute the code.
2. Info panel size on high-resolution displays
Regarding image information display, nomacs' info panel is quite rudimentary, so I once built a dedicated photographer HUD for it. QuickView's info panel, by contrast, is already excellent. There is just one issue: the panel appears very small on high-resolution displays. Would it be possible to support resizing?
3. Local zoom / loupe function
A local zoom feature: when the user clicks on a point in the photo, overlay a popup at the mouse cursor location that magnifies the local area to 100%. This is useful for quickly confirming focus accuracy while browsing.
4. Thumbnail improvements
a. Progressive thumbnail loading
Thumbnail display is currently quite coarse. I understand this is a trade-off for loading speed, but would it be possible to progressively load higher-resolution thumbnails after the coarse placeholders have loaded?
b. Sidebar thumbnail navigator
While browsing a large image, would it be possible to open a sidebar—like most photo viewers—that displays thumbnails of the photos in the current directory and highlights which one is currently being viewed?
c. "Open Folder" when no image is open
When no image is currently open, the "Open Folder" function appears to be unavailable. Is this a bug or intentional design?
5. Metadata-based features (respecting QuickView's philosophy)
There are also some features that may not fully align with QuickView's philosophy of being a pure viewer that does not edit files. I understand and respect this philosophy: QuickView is not meant to replace Lightroom or Photoshop, but to remain a lightweight, fast browser. However, the existing rotate and mirror functions already involve file modifications. So I understand QuickView's acceptable boundary to be: no pixel-level modifications, but modifications to metadata and pixel arrangement are acceptable. The items below generally follow this principle.
a. Star ratings, color labels, and flag markers
Display, modification, and filtered viewing based on this data. This only involves metadata changes and does not touch the image pixels. It is extremely useful for photo browsing, collection, and culling.
b. GPS information display and modification
Many modern cameras, including smartphones, embed shooting-location coordinates in EXIF data. For reviewing travel photography, being able to display photos on a map would evoke many more memories. I realize this feature might be too heavy for QuickView; if it is hard to accept, perhaps it could be implemented in future plugin system.
c. Crop function
This might lean more toward editing, but cropping is a high-frequency operation. As an image viewer, not supporting cropping feels genuinely inconvenient, forcing users to switch to another tool. Moreover, cropping does not change any pixel values—it only selects and discards pixels—so I believe it should also fall within the acceptable boundary.
Summary
In summary, these are quite a lot of ideas. I felt opening multiple separate issues might be distracting, so I have grouped them together here as they all reflect the needs of a photographer. I am not just asking for features; if the maintainers are interested, I would be happy to submit PRs to contribute this code.