CorridorKey 1.0.0-dev.9

• TensorRT is now a checklist, and nothing builds until you say so. Engine settings → TensorRT lists each size
  with a tick per window, up to N frames: every window a clip of that size can pick on your graphics card. The
  sizes your clips use start ticked, built windows are marked (built), and a running total shows how many builds
  that is, about how many GB on disk and about how many minutes. Build ticked builds them; Remove deletes a
  size's engines (it asks first). The dev.8 button that built every size at once is gone, so no more surprise hours of
  builds or gigabytes of engines.
• Scan a clips folder. It reads only each clip's width and height, from the folder you choose and two folders
  under it, at most 500 clips. Nothing is keyed, copied, changed or sent anywhere. The sizes it finds are added and
  ticked. Clips you add to the queue are remembered the same way.
• No more "the graphics card is busy". When another program held part of the card, a clip could pick a shorter
  window than its size was built for and fall back to CUDA. Every window now has its own build in the checklist, so
  the clip runs on TensorRT. When a clip still can't use TensorRT, its page says exactly why, and offers Build it
  now when a build fixes it. A clip's window is never shortened, so its mattes stay the same.
• The whole engine log, and Save log…. The clip's page shows every line of the engine log, not just the last 12,
  and follows the newest line while the job runs. Save log… saves it wherever you choose, beside Copy log.

This is a development build: newer than the stable release and less tested. The app offers it only with Update channel set to Development.

CorridorKey 1.0.0-dev.8

• One press builds TensorRT for every size. Engine settings → TensorRT → Build for every size builds every size
  TensorRT can take (720p up to 4K), each covering every window your graphics card runs, so every clip you key after it
  runs on TensorRT, whatever its size or length. Build once, and again only after an engine or model update. The button
  is always there (dev.7 hid it once something counted as built). Sizes your card can't build say so, and their clips
  key on CUDA. Builds never start by themselves and never make a job wait.

This is a development build: newer than the stable release and less tested. The app offers it only with Update channel set to Development.

CorridorKey 1.0.0-dev.7

• One TensorRT build per size now covers your card. A build used to size itself from the graphics memory free at
  that moment, so a size built while another program used the card covered only short windows, and later clips of
  that size ran on CUDA. Each build now covers every window a job of that size can pick on your card, worked out from
  the card's total memory: the same every time on one card. Its working memory comes from the card's total too. No
  build goes past what was measured to build for its size: 4K up to 8 frames and HD (1920×1080) up to 24 built and
  ran on an RTX 5080 (16 GB) on 2026-10-25, and 1280×1080 up to 48 built on 2026-10-24, so on that card every clip
  of those sizes runs on TensorRT, except a 1280×1080 clip of 49 to 64 frames (it runs all its frames at once, more
  than the 48 measured, so it runs on CUDA and says so). Other sizes stay within the nearest measured build (not
  measured themselves); on a 16 GB card with nothing else on it that means 2560×1440 clips longer than 15 frames, and
  2560×1080 and 1920×1440 clips longer than 19, run on CUDA (and say so) until a build of their size is measured. A
  clip that runs more frames at a time than its size's build (on any card where its automatic window is longer, such
  as a 32 GB card, which is not measured) runs on CUDA and says so; a job's window is never shortened to fit a build.
  A job uses a size's engines at any window up to the one they were built for, but only when the engines' own memory
  need fits what it has: on a busy card the clip runs on CUDA and its page says "the graphics card is busy", and
  under a memory limit too small for them it says the limit is (a TensorRT run that still runs out of memory goes on
  on CUDA at once, saying so).
  Whether a shorter window on longer engines gives exactly CUDA's mattes is not measured yet. Sizes built by an earlier
  version keep working where their window reaches; for the rest, see the next point. TensorRT is on Linux today,
  Windows coming.
• A clip that ran without TensorRT offers to build it. When no TensorRT engine fits a clip, its page now says
  "TensorRT isn't built for this clip yet, so this run used CUDA" with a Build it now button: one click starts
  the same background build Engine settings, TensorRT runs, for that clip's size. The next run of the clip uses it.
  A build that runs short of graphics memory says so in plain words, with the memory that was free and any other
  program that was using the card, and offers Build it again when another program was; it is never shown as
  built. No button where a build wouldn't help (a busy card), and none while TensorRT is off (the page says
  how to turn it on).
• The app no longer lists itself as another program using the graphics card. The notice showed CorridorKey's own
  graphics process ("corridorkey-desktop — 0.6 GiB"); the app's own processes are now left out, by process ID.

This is a development build: newer than the stable release and less tested. The app offers it only with Update channel set to Development.

CorridorKey 1.0.0-dev.6

• TensorRT no longer says "built" for engines it can't use. Engine settings, TensorRT called a size built whenever
  its engine files were there, but the engine only uses engines built from the model files it runs with now. TensorRT
  engines built before the model set changed (from 2.0.0-onnx.4's files, now running 2.0.0-onnx.5) showed as built
  while every job of that size said "TensorRT for this resolution range isn't built yet" and ran on CUDA. The app now
  decides "built" exactly as the engine does, so such a size says built for other models · needs a rebuild (the
  model set changed), and its tick or Build now rebuilds it: rebuild the size once and its clips run on TensorRT
  again.

This is a development build: newer than the stable release and less tested. The app offers it only with Update channel set to Development.

CorridorKey 1.0.0-dev.5

• Faster keying, the same mattes. The engine keeps the graphics card busier and copies less: a clip's first frames
  decode while the models load; in the normal mode on CUDA with the automatic window and at least 10 GB for the job, three of the five models
  load while the first pass runs; in the normal mode each temporal window's results are blended while the card already
  works on the next window, and C-RADIO and MoGe run once per frame instead of once per window a frame is in (CUDA and
  CPU); the networks' results are read where ONNX Runtime made them instead of being copied out; in the normal mode
  stage 2 reuses stage 1's already converted frames; and the first pass resizes its inputs without a full-size copy.
  On the RTX 5080 (CUDA fp16, model set 2.0.0-onnx.5, the automatic window, alpha and foreground as float EXR), against
  dev.4, the median of three alternating runs each: the 4K EXR shot 04_5h (4096×2160, 120 frames, 8/4 normal mode)
  keys in 152.5 s instead of 165.7 s (−8.0 %), the HD clip walking_sitting (1280×1080, 314 frames, 48/24
  low-memory mode) in 56.0 s instead of 57.6 s (−2.8 %). Every output file of those runs is byte for byte dev.4's
  (cmp). That is what was checked: the RTX 5080 only, those two windows, float EXR; other cards, other windows, the
  CPU provider and Core ML were not compared with dev.4. The timing runs used the build before the last change (the
  resize); the final build was checked byte for byte against dev.4 in one run at HD and, before the last load-order
  fixes, one at 4K; not timed. TensorRT (on Linux today, Windows coming): not measured. The cost, at the 4K peak on
  the RTX 5080: 0.27 GB more graphics memory (11.08 → 11.35 GB) and about 0.9 GB more RAM (7.8 → 8.6-8.7 GB); with
  less than 10 GB for the job (an 8 GB card) the models load as in dev.4, and the graphics-memory cost there is not
  measured. On the Mac mini M6 (16 GB), a 12-frame 1920×1080 Core ML job peaked at 2.74 GB (one run; dev.4 wasn't
  measured there). Windows' memory: not measured. In the normal mode a job that is stopped or fails part-way writes
  one window's frames fewer than dev.4 did (backlog row 182; docs/ENGINE_RUST.md, "The pipelining pass").

• The README is a short page for artists: what the app is, how to start, what your computer needs, and the
  highlights; the speed tables, test machines, methods and "what we got wrong" moved, word for word, to
  ENGINEERING.md (backlog row 181). The Windows notes now include Edge's "isn't commonly downloaded"
  warning and how to keep the installer.

This is a development build: newer than the stable release and less tested. The app offers it only with Update channel set to Development.

CorridorKey 1.0.0-dev.4

• Windows and macOS: the app now tells you when a new version is out, like on Linux: the same signed check, channels
  and "1.0.0 Dev N is available" notice with Not now. Download opens that version's release page on GitHub in
  your browser; nothing is downloaded or installed by the app there (backlog row 180).
• Choose the model set: Engine settings, ONNX Runtime engine, Model set offers 2.0.0-onnx.5 (the default, as
  before) or 2.0.0-onnx.4 on Linux and Windows, each marked installed or with its download size. Picking one that isn't
  on the computer downloads it with the setup's own checked, resumable download, next to the one you have; from then on
  the Models folder's Automatic runs it (a Models folder chosen by hand goes back to Automatic when you pick a set).
  TensorRT installs into the chosen set's folder: onnx.4 gets its own 2.0.0-onnx.4-trt, and onnx.5 keeps
  2.0.0-onnx.4-trt as in dev.2 and dev.3 (onnx.5's own TensorRT set isn't measured yet). macOS names its one set,
  2.0.0-onnx.5 with its Core ML set (there is no onnx.4 Core ML set) (backlog row 168).
• AMD cards on Linux, on by default and not yet tested on a real AMD card: AMD support is new; we're testing it
  ourselves next, and if it doesn't work on your card, please tell us on GitHub issues. The setup and the Engine page
  say so. With no NVIDIA driver loaded (NVIDIA comes first when a PC has both), the setup finds an AMD card ROCm 10.1's MIGraphX
  supports (Radeon RX 7000 and 9000, Radeon AI PRO R9700, Ryzen AI graphics, Instinct MI200/MI300/MI350), says when
  your user needs the render and video groups, and downloads ONNX Runtime with AMD's ROCm 10.1 and MIGraphX
  libraries (1.02 GB for an RX 7900, each wheel pinned by size and SHA-256) and MIGraphX's two extra model files from
  the published onnx.5 TensorRT release (0.61 GB; the mix parses in MIGraphX at four sizes, checked offline). The GPU
  readout reads the amdgpu driver, a job's first load says it is preparing for the card, and with the AMD runtime installed the engine's
  "no graphics card" message on Linux names AMD too. NVIDIA, Windows, macOS and a Linux PC without an AMD card are
  unchanged; CK_AMD=0 in the app's environment turns the AMD path off (backlog row 166, docs/AMD.md).
• The Engine page's Graphics card is now laid out like NorthXL's GPU card: the card's name in the header, usage and
  memory as bars, then the card's temperature, fan, clock and power. NVIDIA reads them from nvidia-smi, AMD (untested on
  a real card yet) from the amdgpu driver's files; a reading the card doesn't give is left out, never
  shown as 0. As before it is read only while a job runs and the window is shown, and a Mac shows no readout (backlog
  row 171).

This is a development build: newer than the stable release and less tested. The app offers it only with Update channel set to Development.

CorridorKey 1.0.0-dev.3

The foundation build: the Mac on par with Linux and Windows, and the checks running on every change.

• 4K on the Mac. The Core ML model set gains 4096×2160 (padded to 2176×4096), next to 1280×1080 and 1920×1080:
  model set 2.0.0-onnx.5-coreml.1. On the 16 GB M6 Mac mini, 04_5d at 4K keys at 0.38 fps steady (12 frames, window
  4/2), peak 9.8 GB (it fits, tight: 0.8 GB swapped), every pixel of every frame within 1/255 of CUDA's matte (alpha
  MAE 1.32e-5). The Mac setup is 5.74 GB (was 4.76); a Mac with dev.2's set downloads only the 4K files and a new
  coreml.json, never the rest again (backlog rows 60, 174).
• On a Mac the corridorkey command line keys without --device coreml: auto, the default, is Core ML there (the
  app always started it so; backlog row 174).
• The Mac disk image itself is signed and notarized, its ticket stapled: Gatekeeper accepts the downloaded image
  before it is opened (dev.2's image was unsigned, only the app inside it was; backlog row 174).
• Windows: Ctrl+C on corridorkey run stops the script at once, cleanly ("cancelled", exit 130). Before, the app
  never read the command line's stop request there, so the script ran on until a second Ctrl+C ended it (backlog
  row 175).
• Releases: every release, development builds too, is a full GitHub release marked Latest (the repository page shows
  the newest build); the update feeds tell Stable from Development by the version, as before (backlog row 173).
• Development: Windows, macOS and Linux CI run on every push to main, each starting the packaged app's
  corridorkey run with a time limit (Windows and macOS also the app's first page), so release day finds nothing new
  (backlog row 170).

This is a development build: newer than the stable release and less tested. The app offers it only with Update channel set to Development.

Models 2.0.0-onnx.5 (Core ML, fp16)

CorridorKey 2.0 prepared for Apple's Core ML, for CorridorKey Desktop on Macs with Apple Silicon: model set 2.0.0-onnx.5-coreml.1, fp16, fixed shapes (one file per network and frame size: the sizes listed in coreml.json, e.g. 1280×1080, 1920×1080 and 4096×2160 clips, padded to 1152×1280, 1152×1920 and 2176×4096), every node on ONNX Runtime's Core ML provider (docs/ENGINE_RUST.md, --device coreml). The files keep their weights in model set 2.0.0-onnx.5's .onnx.data files, so they go into that set's folder. The app's setup downloads these on a Mac and checks every file's SHA-256 (listed below). You don't need to download them by hand.

CorridorKey is by Corridor Digital: designed and trained by Zachary Harris with Niko Pueringer and Corridor Digital. Converted from corridorkey_v2.safetensors (https://huggingface.co/nikopueringer/CorridorKey2.0) with this repository's engine-rs/export/coreml/build_coreml_models.sh (docs/ONNX_EXPORT.md, "Core ML set"). Licensed under the CorridorKey licence (a CC BY-NC-SA 4.0 variant with additional terms; LICENSE in this repository): free to use, never sold.

Foundation models inside: C-RADIO by NVIDIA (NVIDIA Open Model License), MoGe by Microsoft (MIT), RVM by Google DeepMind (code Apache 2.0, weights CC-BY 4.0).

Licence and attribution files: ATTRIBUTION.md, NOTICE and the LICENSE files here are model set 2.0.0-onnx.5's, unchanged. The per-file rewrites ATTRIBUTION.md lists "in manifest.json" are in that set's manifest.json (https://github.com/MarcelineVPQ/corridorkey-desktop/releases/tag/models-2.0.0-onnx.5); this release has none: its own files are listed in coreml.json, and what it changes is above.

SHA-256:

af243db4a174056b0f906a622e6c48853d8bc4bba8ec22b7f74caeb56da76b39  ck2-cradio-fp16-coreml-1152x1280-t4.onnx
e099acda2cb243e97f380a025f704552b8a5b226f4aeef43f915c4c8d7396870  ck2-cradio-fp16-coreml-1152x1920-t4.onnx
883db40f101442820c69ab424b4397ce0ba1ff2b268c6ccafcc5dd22334c854a  ck2-cradio-fp16-coreml-2176x4096-t4.onnx
e04b8594da157a56fe2b9c52e0e47077e2773d0e4f7a30bc60ed848d3dc76666  ck2-moge-fp16-coreml-1152x1280-t4.onnx
8ccdf7f6bcdd33bde510f93e809196b75735d338c12d74f31cfba671592b3d6f  ck2-moge-fp16-coreml-1152x1920-t4.onnx
ac67867ac8874642911bf6cad7ad483b95b74a7dcf64305a1ce91af37940c8b5  ck2-moge-fp16-coreml-2176x4096-t4.onnx
c0cedf0b9d11eff3ea156153b6df22834412946f38f0a2a2f5f1a3d9304b1d08  ck2-rvm-fp16-coreml-1152x1280-t1.onnx
76b39dea389e31dd4238cf9db8e186982ba1f008c37a91d8c172d2cfdace7d27  ck2-rvm-fp16-coreml-1152x1920-t1.onnx
d7395d9c9aa0520a4d31cb02b3ed0ffa385150e7572aeb3df5cb8c0ffdabd649  ck2-rvm-fp16-coreml-2176x4096-t1.onnx
a3b37d4342eaa8746bd2f47c841c47b4f95f2589d8448121a4393000980bf91b  ck2-stage1-fp16-coreml-1152x1280-t4.onnx
e4d0e2910f4684a2a82fbb9748d366104fa2e4b94f5cdf54dee23356a3e40d64  ck2-stage1-fp16-coreml-1152x1280-t8.onnx
4398803f02824e835f895876ce40d2d6ad3d74349c286efe4fe488cb13a77050  ck2-stage1-fp16-coreml-1152x1920-t4.onnx
0bad604eeaaa2426c7322fd4bb3aa8ea5c09bea0be7ff796a88f951acc00c547  ck2-stage1-fp16-coreml-1152x1920-t8.onnx
59afbf039b6daa032439306849c1bc67d3ac2c80ff16d7920877906cfbf72474  ck2-stage1-fp16-coreml-2176x4096-t4.onnx
06467b130bd997fa0e145c49bf4f2ad4c4200bb9d2639ac76ab721b7c885ad29  ck2-stage2-fp16-coreml-1152x1280-t1.onnx
ae6bdc9c0afcfaa9029f7d30bea9ad7533c3e20f185bfe8de2b5d47d6807777e  ck2-stage2-fp16-coreml-1152x1920-t1.onnx
6d83947a0e86b6c8386b7e1b2a2b520262e57770c737d9fa7ef5c9c49d302086  ck2-stage2-fp16-coreml-2176x4096-t1.onnx
e7bccacf9f93f543b83812deb7e2c318a797b56d23717e93e4c586c5c9b704a0  coreml.json
406eaf7769336187763d1dacfbf11298e68183555f35034b8bc895ed7eb3bb91  ATTRIBUTION.md
c92ce56f64162b231c7ce08ce3ed7d8cae15f01a560ca05a8e8db67878eb0065  LICENSE
c3463f1606e575b80753cb6ebbbca07c0376ea5cd7c60012952579aab0efd773  NOTICE
cfc7749b96f63bd31c3c42b5c471bf756814053e847c10f3eb003417bc523d30  LICENSE-Apache-2.0.txt
ad7d951c80c5fc2b2bce035f2041bc0a0dbf9028c8ecc4c9a8e1fba8130b6b59  LICENSE-MIT-MoGe.txt
396d7de220f6b0e6fcfe33836f1b99a9943769b97c56330444f8efe1b441f607  LICENSE-NVIDIA-OPEN-MODEL-2024-06.pdf
4723d9551c54a3babcab53d53c058c373358ce10e2dc5184c5fa7131709768b2  LICENSE-NVIDIA-OPEN-MODEL-2024-06.txt

CorridorKey 1.0.0-dev.2

The second development build of 1.0: the corridorkey command line for render farms and power users, example
submitters for the common farm schedulers, the Console, a command line inside the app, and model set 2.0.0-onnx.5
(a smaller download). Linux and Windows on NVIDIA as dev.1, and the first macOS build: Apple Silicon through Core ML,
1280×1080 and 1920×1080 clips (4K comes later).

The Electron security fix. dev.1 runs on Electron 45.0.0-beta.3, whose Node (24.21.0) carries CVE-2026-111497,
fixed in Node 24.22.1 (dev.1's release page says so). This build runs on Electron 45.1.0 (released 2026-10-27, Node
24.22.1, Chromium 156.0.8078.49), the first stable Electron with the fix. The packaged app's Electron fuses are now
set: it ignores NODE_OPTIONS and --inspect, and loads the app only from its app.asar (checked against its
integrity hash on macOS and Windows; not yet run in a Windows or Mac build). Node mode is off: corridorkey run
starts the app with its own --ck-headless script runner.

The command line, corridorkey (docs/CLI.md; the wiki's Command line page):

• Keys clips without the app's window, with the app's own engine built in: a whole shot keyed with it is bit for bit
  the app's matte (tested end to end on the CPU against the engine). It ships next to the engine in every package.
  render, verify (is every frame there and whole; the missing ones as ranges to re-render), prepare (checks a
  worker before a farm's tasks; builds TensorRT for a size once) and info.
• Frames as Nuke (-F 1001-1100x2, lists) and Blender (-s / -e) give them, numbered as the shot is; outputs to a
  folder or a pattern (key.####.exr, %04d, $F4); --preroll / --tail warm-up frames for chunks of a shot.
  How many warm-up frames make chunk seams invisible isn't measured yet, so whole shots per task are the advice.
• Output safety: a run writes into a hidden folder of its own and renames the frames into place only at the end,
  all or nothing; each EXR frame is written whole and renamed (the app's jobs too). A killed run never leaves a frame
  at a final name. Frames already there are refused unless --overwrite or --skip-existing.
• Exit codes that say whether a retry can help, progress lines for OpenJD, Deadline, plain text or JSON, a JSON
  report of the run, a clean stop on SIGTERM / SIGINT (Windows' console close, log-off and shut-down are handled
  too, but not yet run on Windows).
• Without --models / --ort it uses the app's own installed models and ONNX Runtime, so the Queue's Copy as
  command line runs in a terminal as it is (tested with a fake install; not yet on a graphics card).
• Frame folders are read as the app starts them: scene-linear when the first frame is EXR, display-coded otherwise;
  --linear / --no-linear choose, and the report says which was used and why. Copy as command and farm export
  write an EXR folder's choice both ways (--no-linear when the box is off); the OpenJD templates' scene-linear
  parameter and the Flamenco job type's setting gain a "by the first frame" default.
• corridorkey __spec --json describes the whole command line for tools; on Windows it never loads a library from
  the current folder (not yet run on Windows).
• Fixes from the farm review (2026-10-26) before anything shipped: a stepped -F keys to the end of its range,
  -s / -e past the shot are refused like -F's, an absurd preroll is refused instead of overflowing, the final
  renames are all or nothing, a stop during a TensorRT build ends prepare cleanly, run folders are unique per
  machine and swept once their run is over, the Deadline plugin quotes Windows paths correctly.

Render farm submitters (farm/README.md; the wiki's Render farm page): OpenJD / AWS Deadline Cloud job bundles
(per shot, and chunked), a Deadline 10 plugin, an OpenCue submit script, a Flamenco job type and a shell loop for a
studio without a scheduler. Each keys one whole shot per task by default and checks it with verify. None has run on
a real scheduler yet; what was tested, and how, is listed per submitter.

The Console (docs/GUIDE.md "Console"; the wiki's Console page), a command line inside the app for power users,
on its own rail icon. Not a system shell: its own commands only, each parsed and checked.

• render, verify, prepare and info with the command line's own flags, output and exit codes, plus help,
  apropos, cd, ls / dir, history, open, version and Tab completion from the command line's own
  definitions.
• Safety: it reads anywhere and writes only into the results and cache folders, the queued clips' folders and folders
  you allow; a command that replaces files runs only as sudo … after a dialog showing what it replaces, elevated
  for 5 minutes (each elevated command extends it, never past 15), dropped on sleep or quit and meant to drop on a
  screen lock too (on Linux it reads systemd-logind's lock state; not yet tried with a real lock); every elevated command is logged before it runs. The renderer's security policy is
  stricter, and a gate forbids shells and exec in the app's code.
• allow refuses /, a drive's root and the system's folders (also through a link), and warns before allowing the whole home folder.
• On Windows the Console opens a network path (\\server\…) only after allow-server <server>, until the app quits (Windows sends your sign-in to every server it opens).
• For the pipeline: frame sequences shown and completed as one item (sh010.####.exr 1001-1100 · missing 1047);
  every job the queue starts appears as its exact corridorkey render … line, and the Queue's Copy as command
  copies it, quoted for a terminal; farm export writes the queued clips as OpenJD, Deadline 10, OpenCue, Flamenco
  or shell jobs with their settings; doctor checks the whole machine with each problem's fix; -o …_v###/ picks the
  next free version.
• For people who live in a shell: history shortcuts (!!, !$, ^a^b, sudo !!), readline keys, bookmarks
  (cd @sh010), j (jump by frecency), pushd / popd, ${name} variables (set -p keeps one) and lists, a small
  script language (;, &&, ||, for, if, time, run for .ckcmd files; no pipes), and read-only cat,
  head, tail, wc, du, tree.
• Built in phases, each followed by an independent senior review and a command-line / VFX pipeline expert's review;
  every finding they marked must or should was fixed with a test before this build (docs/REVIEW_CONSOLE_*.md), the
  rest are backlog rows.

Changed

• Model set 2.0.0-onnx.5 on Linux and Windows (docs/ONNX_EXPORT.md "onnx.5"; backlog row 165): our own export of
  stage 1 and stage 2, made so AMD's MIGraphX and Apple's Neural Engine can take them. Stage 2's shifted windows are
  one masked attention per Swin block, stage 1's regions are taken by one gather each in the original's frame-major
  token order (no empty tensor at any size), the RMS norms are written in plain operations, and C-RADIO's weights are
  stored in fp16 (ONNX Runtime converted them to fp16 on load before, so the graphics card holds the same weights).
  Corridor's code and weights are unchanged. The models download drops from 3.30 to 2.48 GB (the setup: 4.03 GB on
  Linux, 3.81 GB on Windows, was 4.86 / 4.64). Mattes against onnx.4: all 10 test clips within 0.25-0.50/255 at the
  most, no pixel over 1/255, and no more sizzle. Speed on CUDA (RTX 5080, one run per set): 0.3-3.5 % faster on every
  clip (HD 1280×1080 about 15.5 fps, 4K 0.78 fps), about the size of the run-to-run spread; the same graphics memory
  (one 960×720 clip peaked 0.9 GB lower; README, Speed, "0.0.9-dev"). The setup
  downloads onnx.5 next to an installed onnx.4, whose folder stays as it is.
• macOS moves to onnx.5 too, with its own Core ML set 2.0.0-onnx.5-coreml (1280×1080 and 1920×1080, every node on
  Core ML): the setup is 4.76 GB, was 5.51. Gated on the Mac mini (M6, 16 GB) against CUDA on both sizes: alpha MAE
  2.1-2.5e-5, 0.002 % of pixels over 1/255 at 1280×1080 and none at 1920×1080 (README, Speed, "Apple Silicon (Core ML)").
• TensorRT (Linux, opt-in) keeps dev.1's TensorRT set, 2.0.0-onnx.4-trt (onnx.5's own TensorRT set isn't measured
  yet; choosing the model set comes in dev.4). Its C-RADIO weights (fp32) are no longer in the normal set, so they are
  copied from an installed onnx.4 folder when there is one (5.53 GB in all, as before) and downloaded otherwise
  (7.26 GB).
• AMD graphics cards, engine only, untested on real hardware: the engine can run on an AMD card on Linux through
  AMD's MIGraphX provider (--device migraphx, ROCm 10.1; docs/AMD.md). It has never run on an AMD card, and the app
  doesn't download an AMD runtime, so the app still needs an NVIDIA card on Linux and Windows. Without AMD's provider
  plugin installed the engine chooses its device exactly as before (NVIDIA, Mac and CPU setups are unchanged). With
  onnx.5, MIGraphX's own parser takes all five networks (their TensorRT-form files) at every size tried (offline
  check, no AMD card).
• An app update now shows itself (it was said only in App settings → Updates): pinned above every page when one is available (Download), downloading, ready (Restart now) or its install failed, and as a dot on App settings whose press opens Updates; Not now hides that step of that version until the next step or a newer one.
• A shipped copy has no developer tools and none of Electron's default reload and close shortcuts (Ctrl+Shift+I, Ctrl+R, F5, Ctrl+W); npm run dev keeps them.
• The app runs only its Rust + ONNX Runtime engine: the PyTorch engine is gone from it (the Engine page's
  "Benchmark reference" section, its CorridorKey2.0 folder setting, and the PyTorch-only limits on a clip's codec,
  internal resolution and input precision). A settings file that still names the folder loads as before; the key is
  dropped. Comparisons with Corridor's ori...

Models 2.0.0-onnx.5 (TensorRT, fp16)

CorridorKey 2.0 prepared for TensorRT, for CorridorKey Desktop's optional TensorRT mode (Linux): model set 2.0.0-onnx.5-trt, fp16, strongly typed (FP32 islands for weight GEMMs and convolutions; docs/ENGINE_RUST.md "TensorRT"). The app downloads these when you switch TensorRT on and checks every file's SHA-256 (listed below). You don't need to download them by hand.

CorridorKey is by Corridor Digital: designed and trained by Zachary Harris with Niko Pueringer and Corridor Digital. Converted from corridorkey_v2.safetensors (https://huggingface.co/nikopueringer/CorridorKey2.0) with this repository's engine-rs/export/build_trt_models.sh (docs/ONNX_EXPORT.md, "TensorRT set"). Licensed under the CorridorKey licence (a CC BY-NC-SA 4.0 variant with additional terms; LICENSE in this repository): free to use, never sold.

Foundation models inside: C-RADIO by NVIDIA (NVIDIA Open Model License), MoGe by Microsoft (MIT), RVM by Google DeepMind (code Apache 2.0, weights CC-BY 4.0).

SHA-256:

6276830bfeaa0226819f27064eb22c29e1fdad6ae5e4b16d2ed7daa4347b8cb9  ck2-cradio-trt-fp16-ctx.onnx
1e6acbb7e9bd5f5fffe19fab97fbb5df3e9627b7082b4b7846b239f77ecfbe7a  ck2-cradio-trt-fp16.onnx
8f76c92ddf779b70745fc985820e7e312f7eb07ec82b4e20119062798f952b9f  ck2-cradio-trt-fp16.onnx.data
9de6063abe191b1ad7ddac7415a9207f4e95101efdb89e7c2be83a296b2ac313  ck2-moge-trt-fp16-ctx.onnx
0c94de749d02f1982c26f72f96c5392a0396b6b1c6a27ae2917ffc61776d4eff  ck2-moge-trt-fp16.onnx
067bcdbfca7cf91d434dc9709451c264eaef747848ac63d5b043912315d59796  ck2-moge-trt-fp16.onnx.data
a98773246f4b9c031a483795248ff2f4cd1a1dace4b1be9ede490a2f9d9ae228  ck2-rvm-trt-fp16-ctx.onnx
845019115d9871e1101f6af1f4af5b6378fb3f9c043b453f4aa89369095c9be3  ck2-rvm-trt-fp16.onnx
5ebbca207937d92ef6fab97f165db4f68a3d7363df4e11e3023e872c7d7fa6ab  ck2-rvm-trt-fp16.onnx.data
c9f6e12355339fade564f9c9f55d94d04670089c5e7fc6e7dcb62f6c9fcf5716  ck2-stage1-trt-fp16-ctx.onnx
52fe3c19d1c3cb66fd6bcde0b26c041dd29c5bf95e2dbb102a5cf20a0c94f2b6  ck2-stage1-trt-fp16.onnx
0b12d2ed73521fa63dafaafbdaea0a0c5d6c5507b0d28b60bd4c56918b6e9683  ck2-stage1-trt-fp16.onnx.data
d05a7d085eea3de18261ea1f7de0bda9be94cc2ebea891833d427bfb738c213b  ck2-stage2-trt-fp16-ctx.onnx
dceba38fc853cf93bb35d73d5791b8654d082324efe28519d89e3d9a29b6f006  ck2-stage2-trt-fp16.onnx
ab6eae0f8c68a5056514f1e4a542a0bdefacc58ba9ef9bd9727f9577e1e38668  ck2-stage2-trt-fp16.onnx.data
c5d65827ad8043fd67915d9cc37ff2110c559ce60450da86742de8c81eb74643  models.json
406eaf7769336187763d1dacfbf11298e68183555f35034b8bc895ed7eb3bb91  ATTRIBUTION.md
c92ce56f64162b231c7ce08ce3ed7d8cae15f01a560ca05a8e8db67878eb0065  LICENSE
c3463f1606e575b80753cb6ebbbca07c0376ea5cd7c60012952579aab0efd773  NOTICE
cfc7749b96f63bd31c3c42b5c471bf756814053e847c10f3eb003417bc523d30  LICENSE-Apache-2.0.txt
ad7d951c80c5fc2b2bce035f2041bc0a0dbf9028c8ecc4c9a8e1fba8130b6b59  LICENSE-MIT-MoGe.txt
396d7de220f6b0e6fcfe33836f1b99a9943769b97c56330444f8efe1b441f607  LICENSE-NVIDIA-OPEN-MODEL-2024-06.pdf
4723d9551c54a3babcab53d53c058c373358ce10e2dc5184c5fa7131709768b2  LICENSE-NVIDIA-OPEN-MODEL-2024-06.txt