3 Commits

Include renames

Author	SHA1	Message	Date
dtourolleandClaude Opus 5	151dcc3c02	Make a file out of a photograph ... Export existed as a settings page and nothing else: format, quality, colour space, five sizing modes, a filename template and a metadata switch, all configurable in detail, and no way to produce a single file. dr-export is the other half. **It returns bytes and a name, and writes nothing.** An export has three destinations with nothing in common — a path on Linux, a SAF document on Android where there is no path at all (ARCH §6.9), and a PUT to a Nextcloud folder — so a crate that opened the file itself would serve one of them and be rewritten for the other two. The caller places the bytes. Resize, then sharpen, then encode, in that order and for a reason: output sharpening compensates for the softening the resample introduced, so its strength scales with how much scaling actually happened, and sharpening before shrinking would throw the result away. Lanczos-3, separable, with weights computed once per output row — FR-EXP-4 asks for Lanczos or better because a box filter turns a distant fence into moiré. Collision handling takes the "is this name taken" test as a closure rather than looking at a directory, because there is no directory it could look at that works everywhere. That shape is not politeness toward Linux: Android's createDocument renames on collision by itself and cannot overwrite at all, so all three CollisionPolicy settings need the answer *before* anything is created. Overwrite, Skip and Increment are each tested, and Increment gives up after ten thousand rather than spinning against a destination that reports everything as taken. Three things are honest rather than done: - **Colour space.** sRGB only. The shader encodes and clips to sRGB before this crate sees a pixel, so tagging a file Display P3 would claim a gamut it does not contain. Refused with a typed error instead of mislabelled; honouring it is a pipeline change (FR-EXP-2). - **AVIF and JPEG XL.** No encoder. libaom and libjxl are C, ravif is slow enough to change what a batch feels like, and the settings page offers both because FR-EXP-1 lists them — so asking for one says so rather than writing a JPEG under a .avif name. - **16-bit TIFF** is a real 16-bit file carrying eight bits of information, because AdjustPass renders to Rgba8Unorm. Widened by *257, not <<8, so white lands on 65535 rather than a quarter-percent grey. Making it mean what it says needs the composer told what format to write. Metadata is not written at all, which satisfies the half of FR-EXP-8 that matters most: strip_location defaults to on, and a file with no EXIF block has no GPS tag. Retaining camera and copyright when asked is not implemented and cannot be faked by omission. Also here: - `AdjustPass::export_pixels`, ungated where `read_output` is behind a feature. The two are the same transfer and opposites in intent: reading pixels back to *display* them is what ARCH §6.1 forbids and AC-8 asserts against, while reading them back to encode a JPEG is the only way a file has ever been made. Separate methods so the instrumentation can count one without counting the other. - `ExportTarget`, so a destination can be a folder on the server. On Android that is the only destination needing no platform work whatsoever — a PUT against create_dir, already on the RemoteBackend trait, behaving identically on both platforms. Switching target clears the destination, since a path is not a remote folder and carrying one across would offer to create a folder called `home` at the library root. Verified end to end rather than by unit test alone: `cargo run -p dr-export --example export` decodes a frame, runs the develop chain on the GPU at full resolution, reads it back, and writes all five formats — 27 ms for a full-size JPEG, 165 ms with a Lanczos reduction to 1200px. ImageMagick agrees the 16-bit TIFF is 16-bit. dr-export cross-compiles clean for aarch64-linux-android; all three encoders are pure Rust, which is why they were chosen. 944 tests pass, clippy and fmt clean. Not yet wired to a button. The develop view has no export action, so nothing in the running app can reach any of this yet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-16 22:26:37 +02:00
dtourolleandClaude Opus 5	03326242a1	Make the CI checks say what they mean, and format the workspace ... The Android job's "Verify minimum API level" step has never verified the minimum API level. It took the first `*.so` anywhere under the target directory, which is a host proc-macro from debug/deps — an x86-64 object built by the runner's gcc, whose .comment section cannot mention Android and so can never contradict the expected value. It now reads the artifact under the target triple, compares against MIN_API parsed from the Dockerfile rather than a second copy of the number, and fails on a mismatch. Both sides are checked non-empty first: two failed parses would otherwise compare equal and pass, which is the same silent success in a new costume. The Android image installs one SDK package per layer and keeps the output. sdkmanager is a JVM program that aborts when it cannot get memory, and the single `> /dev/null` step reported that as a bare "exit code 134" while a retry re-downloaded everything that had already succeeded. tools/ci-local.sh runs all four jobs — desktop, android, layering, traceability — against the host toolchain, which is pinned to the same 1.92.0 CI installs. Its matrix check compares regeneration against the working tree rather than against HEAD: CI starts from a clean checkout, so git's answer is the right one there and reports every local run stale here. The rest is rustfmt across the workspace, and the clippy findings that surfaced once it did: manual_contains in dr-thumbs and collections_ui, a map iterated as pairs for its keys, an index loop over a slice, and two runtime assertions on a constant now made at compile time. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-16 12:02:51 +02:00
dtourolleandClaude Opus 5	fa12afed18	Keep originals on this device, by pin and by use ... Fills in `image_cache`, which the previous commit's "On this device" filter read but nothing wrote. Also carries in-flight work that shared these files: the Android TLS root store, the settings page, and a regenerated traceability report. # Two populations, deliberately separate An original is kept here for one of two reasons, and conflating them produces the exact failure the feature exists to prevent. **Pinned** originals were asked for. Pinning a collection before a trip is a promise, so pinned rows are never evicted and never counted against the budget — a cap that could silently delete a pinned trip would make pinning worthless, because it could not be relied on without checking. **Passively cached** originals are a side effect of working: develop already downloads the whole file, so keeping it costs no bandwidth and saves the entire transfer next time. This population is what the budget bounds, evicted least-recently-used, because it otherwise grows until a day of culling fills a disk. Sharing one budget would let a large pin starve the passive cache, or let browsing evict a pin. They are separate. # What was built `dr_catalog::cache` owns the bookkeeping — held tier, size, last use, pinned — and writes the bytes; deciding to download stays with the caller, which is what keeps a crate with no network out of the network's business. Files are written to a temporary and renamed, so a dropped connection cannot leave a truncated file recorded as a complete original. They are named by image id, not filename: `Photos/IMG_0001.CR2` and `Trips/IMG_0001.CR2` are different photographs, and a flat cache keyed on the name would serve one for the other. `spawn_full_fetch` became read-through. A hit is a disk read; a miss stores what it downloads and enforces the budget. A cache that cannot be opened is a miss, not a failure to open the photograph. Pinning writes intent — `tier_desired` — without downloading, so the button responds immediately, and `spawn_pin_fetch` fills it in sequentially afterwards. Sequential because these are tens of megabytes each: the lanes that make the thumbnail sweep fast buy little against one connection's bandwidth and cost a great deal of memory. A pin interrupted by a lost connection resumes from where it stopped. Schema v5 adds `pinned` and `path`. `pinned` is a column rather than something inferred from `pinned_by_rule`, which is ON DELETE SET NULL and so cannot answer for an image whose rule was deleted. A v4 catalog migrates in place; existing rows default to unpinned, the safe direction. The budget and "keep opened originals" come from the settings page rather than a constant, and are applied at startup rather than only on change — a cache capped at 2 GB last session would otherwise spend this one filling to the default. Turning off keeping leaves what is already cached readable: those bytes are paid for, and refusing them would re-download images sitting right there, including pinned ones. Also removes a doubled `#[test]` introduced in the previous commit. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-11 21:12:01 +02:00