mirror of
https://github.com/storytold/lightcraft.git
synced 2026-10-28 12:08:10 -06:00
LR-IMP-PREVIEW-READ: an unedited raw's grid thumbnail is its embedded JPEG
The grid already showed the camera's embedded preview first, then queued a render of the whole raw to replace it. For a 512 px thumbnail that render decodes 50 of a 56 MB Fuji RAF's bytes for a picture the 4 416 × 2 944 embedded JPEG already covers — 45 s a photo on the 1.2 MB/s share this was measured on, 8.3 GB of traffic for a 149-photo folder, and a queue that delayed the render the user was actually waiting for (measured: the first loupe render of a cold photo finished 174 s after the click, most of it spent behind thumbnails). Idle for a minute afterwards, the same folder read 12 previews (26.9 MB) and decoded zero raws for thumbnails, against 638 MB of whole-file reads before. - `Session::embedded_thumb_is_final` answers whether a photo is an unedited raw whose camera JPEG the viewer is showing — the same `has_import_look` gate the preview path uses. - `grid::skips_the_real_render` is the decision (unit-tested): a cached render as stand-in, an edited photo and a raw without an embedded JPEG all still render, because their thumbnail must show the pipeline's output rather than the camera's. - `Renderer::remember_embedded_thumb` records the quick render's key and the bucket, and `thumb_quick_is_final` / `thumb_quick_pending` let the per-frame grid request stop at the embedded preview instead of rebuilding the render job (and its cache key) every frame. - The thumbnail key still follows the settings hash, so editing a photo re-renders its thumbnail through the ordinary background path. `docs/raw-preview-reads.md` and the `LR-IMP-PREVIEW-READ` parity row record the behaviour and the numbers. Co-Authored-By: DeepSeek V3.2 <noreply@deepseek.com>
This commit is contained in:
co-authored by
DeepSeek V3.2
parent
ab438b05ca
commit
bc2cbf41db
@@ -1212,6 +1212,23 @@ impl crate::Session {
|
||||
}
|
||||
}
|
||||
|
||||
/// Whether `p`'s thumbnail can be the camera's own JPEG, so a frontend can skip the sensor
|
||||
/// decode behind it.
|
||||
///
|
||||
/// The grid shows this JPEG first in any case ([`QuickJob`]: "grid thumbnails of unedited raws
|
||||
/// likewise start from the embedded preview"), and then paid for a render of the raw to replace
|
||||
/// it. That render decodes the whole sensor — 50 of a 56 MB Fuji RAF's bytes — for a 512 px
|
||||
/// thumbnail the 4 416 × 2 944 embedded JPEG already covers, and on a share at 1.2 MB/s it is
|
||||
/// 45 s a photo: a 149-photo folder spent 8.3 GB of traffic on thumbnails, and the queue behind
|
||||
/// it delayed the render the user was waiting for.
|
||||
///
|
||||
/// Only unedited raws answer `true`: any edit must be rendered, and `has_import_look` is what
|
||||
/// says the photo still looks the way it did at import. A photo the user edits re-renders
|
||||
/// through the ordinary path, because its thumbnail key (settings hash) changes.
|
||||
pub fn embedded_thumb_is_final(&self, p: &Photo) -> bool {
|
||||
self.embedded_of(p).is_some()
|
||||
}
|
||||
|
||||
/// The camera's embedded preview of a raw file, for the face scan. Faces are read from the unedited picture, so the
|
||||
/// photo's edits do not matter, and the camera's own JPEG (oriented, display-ready) costs a fraction of decoding the
|
||||
/// raw. `None` for anything else, and where the host installed no loader.
|
||||
|
||||
Reference in New Issue
Block a user