• DarkRoom 0.24.0
    Benchmarks / CPU and I/O (per commit) (push) Successful in 8m56s
    Benchmarks / Frame budget (on demand) (push) Skipped
    Traceability / Requirement traces (push) Successful in 1m27s
    Build and test / Desktop (Linux) (push) Successful in 1h33m5s
    Build and test / Layer separation (push) Successful in 32s
    🐳 Android image / Build and push (push) Successful in 3s
    Build and test / android-image (push) Successful in 4s
    🐳 Windows image / Build and push (push) Successful in 1s
    Build and test / windows-image (push) Successful in 2s
    Build and test / Android (aarch64) (push) Successful in 45m54s
    Build and test / Windows (x86_64, cross) (push) Successful in 55m18s
    Build and test / Publish the release (push) Successful in 1m33s
    Stable

    dtourolle released this 2026-10-07 11:27:59 +00:00 | 0 commits to master since this release

    AI denoise with Best now takes about a second for a 20-megapixel photograph on a laptop's graphics card instead of three, with a new Best network and the whole frame denoised at once.

    A new Best. Best is now a single network, taught by the pair of networks that was Best until now, with a quarter of its training drawn from the sharp edges of real photographs. On real photographs it keeps edges as sharp as the old Best, a little sharper at high ISO, and its detail measures within 0.04–0.06 dB of it; the one place it falls short is smooth areas at the very highest ISO (25600), by 0.27 dB. It does a third of the old Best's work.

    Medium is gone. The methods are Bilinear, Fast and Best. A photograph last edited with Medium or the old Best opens with the new Best; nothing needs converting.

    The whole frame at once. On an NVIDIA graphics card, AI denoise now runs over the whole photograph in one or two large pieces instead of dozens of small tiles whose overlapping borders were computed and thrown away. The result differs from the tiled one by less than one step of an 8-bit image. Measured on a laptop's RTX 3050 with a 20-megapixel Canon 6D raw, network time:

    • old Best in tiles (0.23): 2.60 s
    • new Best in tiles: 0.95 s
    • new Best, whole frame: 0.51–0.54 s — about a second with reading the file

    First launch takes longer on NVIDIA. The graphics card prepares the whole-frame network once after installing, in the background — about 12 minutes on the RTX 3050 — while photographs are denoised the old way meanwhile. A card with less than 6 GB of memory cuts the photograph into more pieces, and a photograph that does not fit is planned again in smaller ones rather than failing.

    Other graphics cards and the tablet keep the tiled way, with the new network: Intel, AMD and Apple graphics, the processor alone, and the tablet's NPU, whose form of the new network measured lossless in simulation and is not yet confirmed on the tablet itself.

    The APK, the desktop binary, the Windows installer and SHA256SUMS are built by CI from this tag's commit.

    Downloads
  • DarkRoom 0.23.0
    Benchmarks / CPU and I/O (per commit) (push) Successful in 8m42s
    Benchmarks / Frame budget (on demand) (push) Skipped
    Traceability / Requirement traces (push) Successful in 1m22s
    Build and test / Android (aarch64) (push) Successful in 47m15s
    Build and test / android-image (push) Successful in 3s
    🐳 Android image / Build and push (push) Successful in 2s
    Build and test / Desktop (Linux) (push) Successful in 1h31m5s
    Build and test / windows-image (push) Successful in 3s
    🐳 Windows image / Build and push (push) Successful in 2s
    Build and test / Layer separation (push) Successful in 53s
    Build and test / Windows (x86_64, cross) (push) Successful in 55m3s
    Build and test / Publish the release (push) Successful in 1m58s
    Stable

    dtourolle released this 2026-10-05 02:28:44 +00:00 | 9 commits to master since this release

    The neural models — face indexing, AI denoise, scene grading, masks, the panorama fill — now run on an Intel GPU, try any other GPU through WebGPU, and use every processor core on Windows and in the Flatpak, where until now they ran on one.

    Intel graphics run the models. On an Intel integrated or Arc GPU the models now run through OpenVINO. Measured on a Raptor Lake laptop's Iris Xe, model by model against the same laptop's processor: 2.5× faster face detection with the thorough detector, 3.4× faster scene grading, 4× faster AI denoise with Fast and nearly 6× faster panorama border filling. The app itself chose the Iris Xe there at first launch, in its own log. The first launch prepares each model for the GPU in the background, a few seconds each, and the processor serves meanwhile. Linux needs Intel's OpenCL driver (intel-compute-runtime on Arch). Windows has that driver with the graphics driver, and the installer carries the runtime, but the Windows path has not yet run on Windows hardware.

    Any other GPU is tried through WebGPU. A graphics card no vendor-specific path covers — an AMD card on Windows or without ROCm, a phone's Mali GPU — is tried through WebGPU, on Vulkan or Direct3D 12. The app times it against the processor at first launch and keeps whichever is faster. It is unmeasured on that hardware so far; where it loses, nothing changes.

    Every core on Windows and in the Flatpak. The Windows installer and the Flatpak now carry ONNX Runtime, so even without a usable GPU the models run on every core — 8 to 10 times faster than the single core they had before. The Arch package carries it too and no longer needs onnxruntime-cpu. Each desktop package grows by about 110 MB for the two runtimes it ships.

    The right runtime when several are installed. A machine can now hold the bundled Intel and WebGPU runtimes beside a CUDA runtime fetched for an NVIDIA card or the distribution's ROCm build for an AMD one; the app loads the one that fits the graphics card, so an NVIDIA or AMD card keeps its own faster path.

    Phones without a Qualcomm chip. The APK carries a second, generic runtime (32 MB) for phones the Hexagon path cannot serve, and tries their GPU through WebGPU — untested on such a phone so far. A Qualcomm device never loads it, and a phone that does not say who made its chip is treated as Qualcomm's, as before.

    A steadier choice of accelerator. The first-launch timing now warms the GPU up before measuring it — a cold integrated GPU lost to the processor in two tries of three — and Settings names the accelerator that lost to the processor, not one the runtime was never built with.

    Install over 0.22.1 as usual; the first launch re-measures the accelerators once.

    The APK, the desktop binary, the Windows installer and SHA256SUMS are built by CI from this tag's commit.

    Downloads
  • DarkRoom 0.22.1
    Benchmarks / CPU and I/O (per commit) (push) Successful in 8m35s
    Benchmarks / Frame budget (on demand) (push) Skipped
    Traceability / Requirement traces (push) Successful in 1m22s
    Build and test / Android (aarch64) (push) Successful in 46m43s
    Build and test / android-image (push) Successful in 2s
    🐳 Android image / Build and push (push) Successful in 2s
    Build and test / Desktop (Linux) (push) Successful in 1h4m43s
    Build and test / windows-image (push) Successful in 2s
    🐳 Windows image / Build and push (push) Successful in 2s
    Build and test / Layer separation (push) Successful in 34s
    Build and test / Windows (x86_64, cross) (push) Successful in 29m53s
    Build and test / Publish the release (push) Successful in 1m24s
    Stable

    dtourolle released this 2026-10-05 00:41:07 +00:00 | 21 commits to master since this release

    The tablet's NPU, for real this time: the app could never reach it, so every model ran on the processor, and AI denoise took half a minute or more a photograph.

    The tablet runs its models on the NPU. The app never declared the system library that carries its requests to the NPU, and recent Android versions refuse such a library to an app that does not ask for it by name. The NPU could not start, and the models meant for it — AI denoise, face detection, face landmarks, segmentation, scene recognition, keypoints and the panorama border fill — ran their NPU forms on the processor instead, in every release that claimed otherwise. The app now declares it. On the tablet AI denoise with Best takes about 10 s a 20-megapixel photograph instead of 30 s to two minutes, and the other models move to the NPU with it.

    A failed NPU no longer sticks. At launch the app checks which hardware runs its models fastest. When the NPU could not start, that check timed the processor standing in for it, judged the NPU slower, and kept the verdict for good. The check now fails cleanly when the NPU cannot take a model, and a verdict that fell back to the processor is checked again on the next few launches before it is kept. A tablet left on the processor by 0.22.0 checks again once this version is installed; nothing needs clearing.

    Faster release builds. The interface crate compiles on sixteen threads instead of one, which cuts about ten minutes from a release build. Nothing changes in the app.

    The APK, the desktop binary, the Windows installer and SHA256SUMS are built by CI from this tag's commit.

    Downloads
  • DarkRoom 0.22.0
    Benchmarks / CPU and I/O (per commit) (push) Successful in 8m36s
    Benchmarks / Frame budget (on demand) (push) Skipped
    Traceability / Requirement traces (push) Successful in 1m31s
    Build and test / Android (aarch64) (push) Successful in 48m34s
    Build and test / android-image (push) Successful in 4s
    🐳 Android image / Build and push (push) Successful in 3s
    Build and test / Desktop (Linux) (push) Successful in 1h32m33s
    Build and test / windows-image (push) Successful in 2s
    🐳 Windows image / Build and push (push) Successful in 2s
    Build and test / Layer separation (push) Successful in 29s
    Build and test / Windows (x86_64, cross) (push) Successful in 31m14s
    Build and test / Publish the release (push) Successful in 1m9s
    Stable

    dtourolle released this 2026-10-04 12:13:39 +00:00 | 25 commits to master since this release

    Correction: in 0.22.0 the tablet's NPU is not used. The app could not load the NPU's driver library on Android, so every model, AI denoise included, ran on the tablet's processor (Best takes 30 seconds to two minutes there). 0.22.1 fixes this; the NPU timings below apply from 0.22.1 on.

    AI denoise becomes how every raw is developed, with three networks to choose from and its result kept on disk; the tablet runs it on its NPU; colours are richer by default; and presets follow you between devices.

    AI denoise is how raws are developed. It now heads the Adjust panel, and every Bayer raw develops through it unless you choose otherwise. A Method control replaces the on/off switch: Best (the default), Medium, Fast, or Bilinear for the ordinary conversion. On a laptop GPU a 20 MP photograph takes about 2.5 s with Best, 0.8 s with Medium and 0.6 s with Fast, plus about half a second to read the file. The ordinary conversion shows while it works. Strength eases it off, putting some of the removed noise back as fine grain. The networks are new: two specialists blended per pixel for Best, trained on several times more photographs, with sharper edges and less false colour, and stuck photosites are repaired before the network sees them. Results are kept on disk, so a photograph reopened or exported does not wait again. The first launch prepares each network for the graphics card in the background, which takes a few minutes.

    On the tablet, AI denoise runs on the NPU. A 20 MP photograph takes about 9 seconds with Best, the default, about 2 with Medium and about 1 with Fast — against more than half a minute on the processor — with no measurable loss of quality, confirmed on the device. The other models that run on the tablet — face landmarks, segmentation, scene recognition, the panorama border fill and keypoints — move to the NPU too, and face detection finds faces it missed before at small sizes. The APK is about 85 MB larger, for the new networks and the NPU's forms of the models.

    Richer colour by default. The camera profile's look table is now off by default; its strength is still under Camera Profile. The colour mixer's saturation now acts on muted colours such as skies and shadowed snow, where it used to do almost nothing. The Vivid presets and Punch are retuned to measured amounts of colour on the new rendering.

    Earlier edits come across more faithfully. A photograph opened with the edit its file already carries now brings its tone sliders and per-colour saturation at measured strengths, with each saturation band spread over the colours it really affects.

    Presets sync. Your develop presets travel with each library to your other devices. Saving a preset now works on Android and Windows, where it failed before.

    Sensor health groundwork. The app can now find stuck and hot photosites without repairing them, the first step to tracking a camera's sensor over time. Nothing in the app shows it yet.

    Every raw looks different from 0.21.0 — the denoise network, the look table and the colour mixer all changed. Previews made before refresh when a photograph is rendered again. Update tablet and desktop together: the catalog's schema is unchanged, but two versions render the same raw differently. An older build reading an edit saved by this one ignores the new Method setting and uses its own network.

    The APK, the desktop binary, the Windows installer and SHA256SUMS are built by CI from this tag's commit.

    Downloads
  • DarkRoom 0.21.0
    🐳 Android image / Build and push (push) Successful in 4s
    Build and test / android-image (push) Successful in 5s
    Build and test / Desktop (Linux) (push) Successful in 1h27m54s
    🐳 Windows image / Build and push (push) Successful in 5s
    Build and test / windows-image (push) Successful in 5s
    Build and test / Layer separation (push) Successful in 33s
    Build and test / Android (aarch64) (push) Successful in 24m50s
    Build and test / Windows (x86_64, cross) (push) Successful in 55m19s
    Build and test / Publish the release (push) Successful in 1m20s
    Stable

    dtourolle released this 2026-10-04 06:49:54 +00:00 | 42 commits to master since this release

    Photographs keep the style they were made with: raws open with the edit they already carry, render through a tone measured against the photographer's own earlier exports, and gain an AI denoise. Camera profiles now follow the library to every device.

    Photographs open with the edit they already carry. A DNG holds the develop settings it was given before it came to DarkRoom — per-colour saturation, hue and luminance, highlights, blacks, exposure, vibrance and the rest. A photograph DarkRoom has no edit of now opens with that edit translated, as one undoable step named "Earlier Edit", so a library keeps its look. From there it is an ordinary edit, saved with the photograph; Undo shows the photograph without it. Export does the same for a photograph never opened. It is applied only when DarkRoom is sure there is no edit of its own — offline, or with the server unreachable, nothing is applied, so a real edit that failed to arrive is never written over.

    A new default tone for raws, measured against the library's own exports. Raws now render through the DNG reference curve — a camera profile's own tone curve, or the DNG specification's default where it has none — at contrast 1.5. On held-out photographs the difference from the library's earlier exports fell to about an eighth of what 0.20.0's tone gave. The previous curve stays one click away under Tone Mapping → Curve → Sigmoid. Every raw looks different from 0.20.0; previews made before refresh when the photograph is rendered again.

    Baseline exposure. A DNG's BaselineExposure (+0.25 EV on many cameras) is now applied, and a camera profile copied from a DNG carries it, so the same camera's CR2s land at the same brightness.

    Vibrance delivers what its value says. It measured saturation on linear values and halved its effect on every warm colour, so it gave about a third of its nominal strength. It now judges saturation as the eye sees it, protects skin hues specifically, and is scaled against measured exports. Edits that use vibrance, and the Vivid presets, are stronger than before.

    AI Denoise. Bayer raws offer an AI Denoise switch in develop: a learned demosaic and denoise that runs in the background while the ordinary render shows, with a Keep grain control, and is used when exporting. The model ships in the Arch package, the APK and the Windows installer.

    Camera profiles sync. A profile saved with "Use this profile for every " now travels with the library, so the tablet and the desktop render that camera's raws the same.

    The DNG reference curve can also be chosen per photograph, and a profile's own tone curve is used when it has one.

    Grid thumbnails offline. A zoomed grid no longer goes blank offline where the small thumbnail was already stored — it stands in while the larger one is fetched. And reading dates stops at the first sign the server is unreachable, with the offline banner, rather than waiting out every image.

    Inference is safer. A hardware provider that crashed the app during start-up twice is not tried again until the device or the runtime changes. ONNX Runtime's own log goes into the app's log.

    macOS groundwork. A CoreML rung for inference, debug-level logs in ~/Library/Logs, and a container that links the inference engine for Apple silicon. There is no macOS build in this release.

    Update tablet and desktop together: the catalog's schema is unchanged, but the two versions render the same raw differently.

    The APK, the desktop binary, the Windows installer and SHA256SUMS are built by CI from this tag's commit.

    Downloads
  • DarkRoom 0.20.0
    Benchmarks / CPU and I/O (per commit) (push) Successful in 9m1s
    Benchmarks / Frame budget (on demand) (push) Skipped
    Traceability / Requirement traces (push) Successful in 1m25s
    Build and test / Android (aarch64) (push) Successful in 48m24s
    Build and test / android-image (push) Successful in 4s
    🐳 Android image / Build and push (push) Successful in 3s
    Build and test / Desktop (Linux) (push) Successful in 1h22m17s
    Build and test / windows-image (push) Successful in 3s
    🐳 Windows image / Build and push (push) Successful in 2s
    Build and test / Layer separation (push) Successful in 37s
    Build and test / Windows (x86_64, cross) (push) Successful in 55m30s
    Build and test / Publish the release (push) Successful in 1m27s
    Stable

    dtourolle released this 2026-10-03 03:10:48 +00:00 | 78 commits to master since this release

    Camera profiles and more colour: raw files now render through the DNG camera profile they carry, a profile can be copied for every photograph from the same camera, and a new Vivid section of presets gives a richer starting point. A zoomed view now fills the viewport.

    Raw files render through their camera profile. A DNG written by Lightroom or Adobe DNG Converter carries a camera profile — Adobe Standard, for example — whose tables place each hue where Adobe put it for that camera. DarkRoom used to ignore them and render through the colour matrix alone. It now applies them, after exposure and before the other adjustments. A new Camera Profile control can switch the profile off, and Look Amount sets the strength of its look from 0 to 200 %. A profile is applied without being an edit, so an untouched photograph still stores nothing.

    The info panel says which profile is in use. Under the lens line: "Adobe Standard · in the file", the profile file it came from, "off", or "No camera profile · matrix only" — the ordinary case for a camera's own raw format.

    One DNG's profile can serve every photograph from the same camera. When a DNG's profile may be copied and none is installed for that camera, the info panel offers "Use this profile for every Canon EOS 6D →". It saves the profile beside the app's data, and that camera's other raws, CR2s included, use it from the next time they are opened. A .dcp file put in the profiles folder by hand is picked up the same way. No profile is shipped with the app. The profiles folder is per device and does not sync yet, so a photograph can render with a profile on one device and without it on another; the info line says which.

    Vivid presets. A new Vivid section: Vivid, Vivid strong, Vivid landscape, Vivid warm and Vivid portrait. They work on every photograph and change only the settings they name, so a corrected exposure or white balance stays. Landscape and portrait work individual colour bands, so foliage and sky get richer while skin does not.

    A profile is not the same as Lightroom's colour. Measured on the library's own files, Adobe Standard's tables slightly lower overall saturation, because that profile was tuned to sit under Lightroom's default tone curve, which DarkRoom does not apply. The tables fix where colours sit; the Vivid presets are what bring the richer colour.

    A zoomed view fills the viewport. Zooming used to keep the photograph's shape, so a portrait zoomed on a landscape screen stayed a narrow strip with empty space either side. Each side now shows as much of the photograph as the window holds at that magnification.

    Every DNG that carries a profile looks different from before. Previews already made keep the old look until the photograph is rendered again. Update tablet and desktop together: the catalog's schema is unchanged, but two versions render the same DNG differently.

    The APK, the desktop binary, the Windows installer and SHA256SUMS are built by CI from this tag's commit.

    Downloads
  • DarkRoom 0.19.4
    Benchmarks / Frame budget (on demand) (push) Canceled after 0s
    Benchmarks / CPU and I/O (per commit) (push) Canceled after 5s
    Traceability / Requirement traces (push) Canceled after 0s
    Build and test / Desktop (Linux) (push) Successful in 1h21m7s
    Build and test / Layer separation (push) Successful in 46s
    🐳 Android image / Build and push (push) Successful in 4s
    Build and test / android-image (push) Successful in 5s
    🐳 Windows image / Build and push (push) Successful in 1s
    Build and test / windows-image (push) Successful in 2s
    Build and test / Android (aarch64) (push) Successful in 47m42s
    Build and test / Windows (x86_64, cross) (push) Successful in 54m42s
    Build and test / Publish the release (push) Successful in 52s
    Stable

    dtourolle released this 2026-10-03 01:42:17 +00:00 | 89 commits to master since this release

    A bug-fix release: exports to the server respect the "when the name is taken" setting, and stepping through photographs in develop no longer flashes the wrong picture.

    Exports to Nextcloud no longer overwrite files of the same name. An export bound for a server album is queued on the device first, and the queue could not see the server, so every export uploaded under the name it was given and replaced any file already there. "Add a number" and "Skip" behaved like "Replace". The upload now checks the album's folder before sending: "Add a number" saves as name-1.jpg, name-2.jpg and so on, and the album keeps track of the name each file got; "Skip" leaves the existing file alone. Two exports of the same name queued before either had uploaded no longer end up as one file. Exports already waiting in the queue from an earlier version upload under their original name, as before.

    Stepping to the next photograph shows it once. Moving along the roll in develop could show up to four pictures in turn: the thumbnail, the previous photograph again, the new one without its edit, and finally the edited result. The thumbnail now stays up until the new photograph's first frame is drawn, and that frame waits briefly for the stored edit, so it appears with its edit already applied.

    An edit no longer lands on the wrong photograph. If a photograph's stored edit arrived after you had already stepped to the next one, it was applied to the next one. It is now discarded once you have moved on.

    The catalog's schema is unchanged, so tablet and desktop can be updated in either order.

    The APK, the desktop binary, the Windows installer and SHA256SUMS are built by CI from this tag's commit.

    Downloads
  • DarkRoom 0.19.3
    Benchmarks / CPU and I/O (per commit) (push) Successful in 5m26s
    Benchmarks / Frame budget (on demand) (push) Skipped
    Traceability / Requirement traces (push) Successful in 1m9s
    Build and test / Android (aarch64) (push) Successful in 30m44s
    Build and test / android-image (push) Successful in 3s
    🐳 Android image / Build and push (push) Successful in 2s
    Build and test / Desktop (Linux) (push) Successful in 49m45s
    Build and test / windows-image (push) Successful in 1s
    🐳 Windows image / Build and push (push) Successful in 1s
    Build and test / Layer separation (push) Successful in 35s
    Build and test / Windows (x86_64, cross) (push) Successful in 36m12s
    Build and test / Publish the release (push) Successful in 1m12s
    Stable

    dtourolle released this 2026-10-01 02:54:27 +00:00 | 93 commits to master since this release

    Import straight from a camera card on Android, panoramas without ghosts, photographs dated even when their files carry no date, and a Back gesture that no longer closes the app.

    Import from an SD card on Android. An SD card or a USB card reader now appears on the Import page. Photographs already in the library are skipped, and each copy is checked before it is uploaded. Reading a card needs Android's "All files access" permission. Until it is granted, the Import page explains why and offers "Allow access", which opens the page where it is granted. If you refuse, the explanation stays; once access is granted, the card's photographs are listed.

    Panoramas are joined along seams. Overlapping frames used to be averaged together, so the near foreground, grass and anything that moved came out doubled and ghosted. Each overlap is now cut along a seam placed where the neighbouring frames agree, so those parts come out once and sharp. The preview on the merge page shows the seams the merge will use.

    Photographs without a capture date are dated from their name. WhatsApp images, re-exports and some darktable imports have no date in the file. They used to sort at the end of the library. They now take their date from the file name, or from a dated folder. Libraries catalogued by an earlier version are fixed the first time they are opened, without a rescan.

    Back closes the presets menu on Android. In develop, the Back gesture used to close the whole app while the presets menu was open. It now closes the menu.

    The catalog's schema is unchanged, so tablet and desktop can be updated in either order.

    The APK, the desktop binary, the Windows installer and SHA256SUMS are built by CI from this tag's commit.

    Downloads
  • DarkRoom 0.19.2
    Benchmarks / CPU and I/O (per commit) (push) Successful in 5m29s
    Benchmarks / Frame budget (on demand) (push) Skipped
    Traceability / Requirement traces (push) Successful in 1m4s
    Build and test / Android (aarch64) (push) Successful in 31m8s
    Build and test / android-image (push) Successful in 2s
    🐳 Android image / Build and push (push) Successful in 2s
    Build and test / Desktop (Linux) (push) Successful in 50m33s
    Build and test / windows-image (push) Successful in 3s
    🐳 Windows image / Build and push (push) Successful in 2s
    Build and test / Layer separation (push) Successful in 33s
    Build and test / Windows (x86_64, cross) (push) Successful in 36m27s
    Build and test / Publish the release (push) Successful in 59s
    Stable

    dtourolle released this 2026-09-30 01:32:20 +00:00 | 98 commits to master since this release

    Every crop handle can now be grabbed, and a crop can be trimmed from one side.

    The bottom crop corners can be grabbed again. In Compose, the photograph filled the whole canvas, so its bottom handles sat inside the photo roll's strip, which takes every press that lands in it. The bottom-left handle could also sit under the "Done Composing / 1:1 / Before" buttons, which take the press first. Both handles were drawn and did nothing. Which one failed depended on the window's shape and the photograph's, and on a laptop-sized window one of them was usually dead — the likely cause of the report that cropping did not work on macOS, though this build has not been tried on a Mac. While composing, the photograph is now fitted a little inside the canvas and above the buttons and the roll, and shrinks further when the roll is out.

    Trim one edge. Each side of the crop has a bar handle at its middle that moves only that side, in or out. With a ratio locked, the side you drag sets the size and the opposite side stays where it is.

    Building from source. The README now says how to build and install DarkRoom from source, not only how to run it.

    The APK, the desktop binary, the Windows installer and SHA256SUMS are built by CI from this tag's commit.

    Downloads
  • DarkRoom 0.19.1
    Benchmarks / CPU and I/O (per commit) (push) Successful in 5m29s
    Benchmarks / Frame budget (on demand) (push) Skipped
    Traceability / Requirement traces (push) Successful in 1m8s
    Build and test / Android (aarch64) (push) Successful in 30m34s
    Build and test / android-image (push) Successful in 3s
    🐳 Android image / Build and push (push) Successful in 3s
    Build and test / Desktop (Linux) (push) Successful in 48m59s
    Build and test / windows-image (push) Successful in 2s
    🐳 Windows image / Build and push (push) Successful in 1s
    Build and test / Layer separation (push) Successful in 48s
    Build and test / Windows (x86_64, cross) (push) Successful in 35m51s
    Build and test / Publish the release (push) Successful in 51s
    Stable

    dtourolle released this 2026-09-28 23:58:06 +00:00 | 102 commits to master since this release

    A merged panorama now arrives in the library straight away, with a thumbnail developed as it will look in develop, and gets a cell two, three or four columns wide in the grid.

    Panoramas reach the library. When a merge finished, the app started uploading the composite and rescanning at the same moment, and the rescan usually won: it listed the folder before the file was there, recorded the folder as scanned, and nothing looked again until the next sync — and even once found, the composite had no preview, so its cell was blank. Now the composite is catalogued the moment it is written, placed beside its sources by capture time, and the rescan runs after the upload rather than beside it. Two more ways a panorama went missing are fixed: a sync that ran during the merge could upload the first part of the file and mark it done (the composite is now written under a .part name until it is whole), and two uploads could send the 800 MB file side by side (one at a time now). A second merge of the same frames becomes -pano-2 instead of overwriting the first. (#83)

    Thumbnailed during the merge. The merge renders the composite's thumbnails from its finished image, through develop's own first-open path — the scene-referred pipeline, the default Tone Mapping and the as-shot white balance — so the grid shows what develop will, and never decodes a 20,000-pixel DNG to make one. Panoramas merged before this release fall back to the ordinary thumbnail path.

    Wide cells for wide photographs. A photograph of about 2:1 or wider spans two columns, 2.45:1 three, and 3.46:1 or more four, with a thumbnail rendered at that width. A wide cell that doesn't fit the rest of a row starts the next one, so reading order is kept; Up/Down step by rows. With too few columns, and always on the tablet, it takes the whole row. Panoramas from other programs get wide cells too, from the size in their header. Panoramas merged before this release stay one column wide.

    Design draft for learned denoise. docs/dev/denoise.md sets out the plan for FR-DEV-3g; nothing of it is built yet.

    Update tablet and desktop together. The new thumbnail sizes are stored under codes an older build reads as its normal grid size — harmless, but mixed builds show the wide cells on one device only. No catalog schema change (one partial index, created on first use).

    The APK, the desktop binary, the Windows installer and SHA256SUMS are built by CI from this tag's commit.

    Downloads