ChitraMaya - GPU-accelerated mosaic restoration studio for video — with a real-time visual editor

[mei2]

I have not looked at sehuatang site - did they modify code or are they using their own models? Either way, if they "selling" stuff, I suppose they have negotiated some sort of licensing.

Sehuatang allows users to exchange points against user generated content. In my earlier post I used the word "buy" , and I think that might have created the wrong understanding.

 

[seatv]

@mei2, thank you for the clarification.

 

[seatv]

ChitraMaya v1.60.00 — Release Notes​

This is the responsiveness release — in both senses. The TensorRT restoration engines were rebuilt on a fixed-batch scheme, so one compile now serves every Max Clip Length setting and the old “engine set reserves VRAM for its compiled size” rule is gone — the same 8 GB card that used to fail at Max Clip 120 now runs Max Clip 300 with the full quality stack. And updating stops costing you a full re-download: this release introduces patch updates — v1.50.00 users can move to v1.60.00 with a download under 100 MB instead of ~2.9 GB.

This is an NVIDIA edition release. The AMD (ROCm) and Intel Arc editions remain at their current versions; the robustness work in this release applies to them too and lands in their next refresh.

Updating from v1.50.00 — use the patch (new!)​

If you have v1.50.00 installed, you do not need the full installer:

1. Download tiny 96MB

   ChitraMaya-patch-1.50.00-to-1.60.00.zip

   from this release page

• Extract it anywhere and run

  Powershell -ExecutionPolicy Bypass -File .\Apply-Patch.ps1

• The script finds your install (or asks), then runs four phases, stopping at the first problem: VERIFY every file it would touch matches v1.50.00 (a modified install is refused with nothing changed), BACKUP everything it will replace, APPLY, and SELF-CHECK the patched install.

Your models, compiled engines, and settings are never touched — patches exclude the models folder and your config by design. Re-running a patch is safe (already-updated files are skipped). If anything goes wrong, your pre-patch files are in the

backup-1.50.00

folder it created.

Installing fresh​

Caution​

If the release lists THREE ChitraMaya-install.* files, you need ALL THREE.

The .exe by itself is not the program — it is the unpacker for the
other two parts. Download all the ChitraMaya-install.* files into the
same folder, then run ChitraMaya-install.exe

One compile, any clip length​

TensorRT restoration engines are now built on a fixed-batch scheme: the compiled engines are independent of clip length, so a single compile serves every Max Clip Length setting — the Manage Models “Max Clip” choice is gone, and the Restoration panel’s Max Clip Length dial is free from 30 to 720 on the Tensor path.

What this means in practice, measured on our own hardware:

• The engine-set VRAM rule is dead. Engines no longer reserve VRAM for the clip size they were compiled at. On the same 8 GB card and settings where a v1.50 run had 385 MB of VRAM free after models (and failed mid-encode), v1.60 has ~2,023 MB free — and completed. We have since run Max Clip 300, at 4K, with RTX Super-Res and Temporal Stability, on 8 GB cards, to completion — twice, on different cards.
• Faster, too. On the same machine, same 2.5-hour 4K test file, same settings, restoration time dropped ~30% and total wall time ~20–24%. Part of that is the engines; part is that the freed VRAM lets the frame store live on the GPU again instead of round-tripping through system RAM.
• Identical output. With the same detection model, the v1.60 pipeline reproduces the v1.50 run’s results to within single-digit frame counts on every statistic we track (restored frames, misses, clip formation). This is a speed and memory change, not a quality change.
• Zero recompile for most users. If you compiled restoration engines in v1.50, the loader recognizes your existing files as the new canonical set — no recompile needed. Very old engine sets still load with a per-file cap and a hint to recompile when convenient.

Credit where due: the fixed-batch engine scheme is ported from Kruk2’s Jasna (v0.9.1), as the source headers note — both projects are AGPL-3.0, and this port continues the lineage the README acknowledges prominently.

New rule of thumb: clip length now costs RAM, not engine sets​

With engines out of the equation, the one resource long clips consume is memory for the frames in flight — and at high Max Clip on high-resolution, high-framerate content, that is system RAM (the host frame store). A 4K/60fps run at Max Clip 300 must hold ~300 frames ≈ 8 GB of RAM behind the encoder; the same run at Max Clip 60 needs ~2 GB.

v1.60.00 manages this for you instead of letting a run die at the worst moment:

• A RAM plan at startup. When the host frame store is used, the console now computes what your machine can safely hold — accounting for what is already in use, how much a run grows, and the free-RAM floor the OS and the encoder need — and, if your Max Clip does not fit, says so before the run, names the numbers, and prints the largest Max Clip that fits.
• A RAM guard during the run. If free RAM ever falls to the floor mid-run (heavy scenes, other apps), ChitraMaya now pauses decode-ahead and lets the encoder drain instead of running the machine out of memory. The run gets slower for a stretch; it does not die. This closes a failure class we chased for a week — a mid-encode “NVENC error 8” on very dense long-clip runs that turned out to be system RAM exhaustion, confirmed by full telemetry and then cured by exactly this intervention.
• Memory is released on failure. A failed run used to leave its frame store resident until you closed the app; it is now freed immediately, so a retry starts clean.

Honest results when a run fails: PARTIAL​

When a long run hits a hard error, ChitraMaya has always tried to flush and remux everything encoded so far — but then reported plain “Error”, as if you had lost it all. Now it tells the truth: “PARTIAL: encoded M of N frames — the output file is playable up to that point.” The progress modal shows the real percentage saved, and the console names the playable file. (A recent 2.5-hour field run salvaged 37 minutes of finished video this way; v1.60 is the release where the UI finally says so.)

Quality of life​

• Compile log: selectable + Copy button. The Manage Models compile log can now be selected with the mouse, and a Copy button puts the whole log on the clipboard — pasting a compile log into a bug report no longer involves screenshots.
• Stable ETA. The progress ETA now blends the run’s average speed with recent speed, so hitting a dense section no longer whipsaws the estimate from “2 hours” to “250 hours” and back. ETAs also read as

  1h 23m

  instead of a raw second count.
• PCIe watchdog: flap suppression. On eGPU/riser setups the link legitimately downshifts and recovers while the GPU waits on heavy work. The watchdog now prints the first alarm and first recovery in full, then summarizes repeats (“link flapping: N cycles”) at most once a minute — while a down-train that does not recover (the serious signal) still alarms immediately and loudly.
• A dead console can no longer kill a CLI run. A Windows console handle going bad mid-run (it happens) used to crash

  ChitraMaya-cli

  with a cryptic

  OSError 22

  — even though the compile or restore underneath was healthy. Console writes are now guarded: if the console dies, the run continues and the log files keep the record.
• Cleaner logs. The garbled first line of every console log (a raw-bytes artifact of the embedded server’s banner) now renders as proper text, and ANSI color codes from third-party libraries are stripped from the log file and Console panel.

Acknowledgements​

ChitraMaya’s fixed-batch TensorRT engine scheme is ported from Kruk2’s Jasna (v0.9.1) — the second major piece of Jasna lineage in ChitraMaya’s TensorRT path, after the original sub-engine split. Both projects are AGPL-3.0; the license that makes building on each other’s work possible. As always, see the README’s acknowledgements for the full list of shoulders this project stands on: HypoX64, ladaapp, Kruk2, zelefans, pifroggi.

Upgrade notes​

• v1.50.00 users: take the patch (top of this page). Full installer works too, of course.
• No recompile needed if your restoration engines were compiled under v1.50 — the existing files are recognized as the new canonical set. Pre-v1.50 engine sets load with a cap and a recompile hint.
• Manage Models no longer asks for Max Clip Length when compiling restoration engines — one compile covers everything. Detection engine compiles are unchanged (Image Size still applies).
• The “8 GB VRAM rule” from the v1.50 notes is retired. Max Clip is a free dial on Tensor; watch the new RAM plan line in the console instead when you push high Max Clip on 4K+ content. Encoder preset advice is unchanged (P5 on 8 GB cards).
• No breaking changes. Models, engines, and configs carry forward as-is.

Download​

▶ ChitraMaya Releases: github.com/seatv/ChitraMaya/releases

 

[seatv]

ChitraMaya — official SHA-256 checksums

Official downloads live only on GitHub:
NVIDIA edition (+ patches) · AMD ROCm edition

Got the files from a mirror, a forum re-upload, or a friend? Verify before running. In PowerShell:

Get-FileHash <file> -Algorithm SHA256

Compare against the values below. If a hash does not match, do not run the file — download from GitHub instead. ChitraMaya is open source (AGPL-3.0); mirrors are allowed, but only matching hashes are my builds.

NVIDIA — Release-1.60.00 page (installer + update patches)

f93f10f90a5eb3442dd8f44b191ee49d3ff4ab2ca6c64a8f46b8f6f57f6a8d73  ChitraMaya-install.7z.001
f31a4cba8655cb966f138b63759835bd12a741c435707dee7bb930fde50c397e  ChitraMaya-install.7z.002
ab414abd475df73e58c97ba211d06c1b2decf74bc68808013cd1223cd23e1bc9  ChitraMaya-install.exe
3b357164d1e58263f08f8978ef4d000ecc54e88771c756c2fdc99d541a4445ba  ChitraMaya-patch-1.50.00-to-1.60.00.zip
62e8a8c8eb95cf51eb01c3ff544f7bbd93edc6e05eb088d82967e61db62041ea  ChitraMaya-patch-1.60.00-to-1.60.01.zip

AMD ROCm — Release-1.40.02

565467995dca611c25d122d6e2c1187b7c42c39ff57e203d09464ffce0f0fe81  ChitraMaya-rocm-install.exe

Intel Arc — Release-1.41.00

55a39bc5b557839f9c014f5baf59adc4c8807d7fcde3559b8f7fa04299dd29a9  ChitraMaya-XPU-Install.exe

(Checksums for these releases as of 2026-08-23. Future releases carry their own checksums on their GitHub release pages.)

 

[seatv]

ChitraMaya 1.61.00 -- stream-rip audio desync fixed (re-run affected files) + Intel/AMD editions in their own repos

ChitraMaya 1.61.00 is out. Headline: files captured from streaming sites (MPEG-TS streams, usually named .mkv) were silently losing ~5 seconds of video at the head on the GPU decode path, producing a constant audio desync in the output -- plus a smaller ~67ms offset error on all TS sources. 1.61.00 detects TS sources, losslessly remuxes them before decode (you'll see a temporary

<name>.cm120-tsremux.mp4

beside the source while it runs), and recovers the dropped frames. Outputs made from TS captures on older versions cannot be repaired -- re-run the source files on 1.61.00.

Also in this release: the encoder can no longer fail silently (a dead NVENC session now aborts loudly within seconds, with your already-encoded frames preserved next to a ready-made recovery script), the finalize step no longer times out on slow disks (it now watches disk progress instead of a wall clock), and an 8K VR crash on pre-RTX-50 cards is fixed.

Updating: two patches on the release page -- pick the one matching your VERSION.txt:

ChitraMaya-patch-1.60.00-to-1.61.00.zip

or

ChitraMaya-patch-1.60.01-to-1.61.00.zip

Full installer for everyone else. SHA-256 checksums for every asset are on the release page.

NVIDIA: https://github.com/seatv/ChitraMaya/releases

The Intel Arc and AMD editions now live in their own repos:
Intel Arc (XPU): https://github.com/seatv/ChitraMaya-Intel-ARC/releases
AMD (ROCm): https://github.com/seatv/ChitraMaya-AMD-ROCM/releases
Both are rebuilt on the 1.61.00 codebase (they never had the TS head-drop bug -- different decode path -- but they pick up the TS offset fix and the finalize hardening).

Intel Arc news from this release's testing: the Arc edition now has a second validated configuration -- a Core Ultra 7 256V laptop (Lunar Lake, Arc 140V iGPU, 16GB). On the same 4K test clip: RTX 3060 58s, Arc 140V iGPU 2m41s, desktop A580 with Resizable BAR 2m37s. A 30W integrated GPU matching a desktop Arc card, at roughly 3x an equivalent NVIDIA card. Two hard-won tips for Arc users:

• Update your Intel graphics driver first. On a factory 2024-vintage driver the GPU enumerates but compute fails -- self-check reports "device enumerates but kernels do not launch". A current driver fixes it. Run

  ChitraMaya-cli.exe -self-check

  after any driver change; it tests exactly this. (Intel's driver installer can also stall if run unattended or over a remote session -- run it at the machine and watch it finish.)
• Discrete Arc needs Resizable BAR ON -- without it the same A580 ran ~20x slower. iGPUs are exempt (unified memory). On 16GB laptops expect the RAM guard to engage on 4K content; the run completes at reduced pace.

AMD: known issues unchanged (detection FP16 suppression -- untick Detection FP16 as the interim workaround; fast-motion artifacts under investigation, in-house AMD hardware arrives this week).

As always: no explicit content in bug reports, per the issue template. Attach

ChitraMaya-console.log

and the

*.misses.json

beside your output.

 

[seatv]

Same-movie benchmark - one 2h41m 1080p60 file (578,704 frames), same models, five configurations:

GPU	Path	Settings	Encoder	Wall time	Speed vs video length
RTX 3060 12GB desktop	TensorRT	conf .15 @ 800, Max Clip 300	NVENC HEVC	3h 11m	0.84x
RTX 4060 8GB desktop	TensorRT	conf .25 @ 640, Max Clip 300	NVENC AV1	3h 45m	0.72x
RTX 3060 Mobile 6GB (~$100 ex-mining board)	PyTorch	conf .25 @ 640, Max Clip 310	NVENC HEVC	6h 22m	0.42x
RTX 4060 8GB desktop	PyTorch	conf .25 @ 640, Max Clip 310	NVENC HEVC	6h 44m	0.40x
Intel Arc 140V iGPU (Core Ultra 7 256V laptop, 16GB)	PyTorch	conf .15 @ 640, Max Clip 300	QSV AV1	15h 44m	0.17x

Notes:

• All times are end-to-end: decode, detect, restore, encode, and full audio remux with faststart.
• All benchmarks used lada_mosaic_detection_model_v2.pt & lada_mosaic_restoration_model_generic_v1.2.pth, movie ID shall be provided on request (DM)
• TensorRT is worth ~1.7x over PyTorch on the same card - compile your engines.
• The $100 ex-mining 3060 Mobile BEAT the desktop 4060 on the PyTorch path with identical settings. Restoration is memory-bandwidth-bound: the mining board's 192-bit bus (336 GB/s) outruns the 4060's 128-bit bus (272 GB/s). Those cheap boards remain the budget king for this workload.
• The two NVIDIA PyTorch runs, on different machines, produced identical detection results (328,657 detected frames on both) - the pipeline is deterministic.
• The Arc row is a 30W integrated laptop GPU finishing a full movie overnight on 16GB of shared memory - not fast, but it completes, unattended, on a machine with no discrete GPU at all.
• AMD 9060XT benchmark will be posted once hardware is procured

 

[seatv]

RTX 5060Ti 8GB joins the table - same 2h41m 1080p60 file (578,704 frames), ChitraMaya 1.61.01, TensorRT engines, Max Clip 300, on a Ryzen 5 3600XT (PCIe 4.0 x8).

Fastest configuration so far: v4_fast @ 640, threshold .25, Temporal Fix off, RTX Super-Res 4x, NVENC AV1 - 1h 34m end-to-end, 1.70x faster than the video runs. First arm in this series to finish faster than realtime, on an 8GB card.

Three lada detectors, one configuration (everything else identical: @ 640, threshold .25, Max Clip 300, restoration generic v1.2, RTX Super-Res 4x + denoise ultra, HEVC):

Detector	Frames with detections	Frames restored	Detect stage	Wall time	Speed vs video length
v2	328,651	331,388	45m	2h 31m	1.07x
v4_accurate	329,833	332,806	48m	2h 26m	1.10x
v4_fast	331,320	333,625	25m	1h 54m	1.41x

Notes:

• All times end-to-end: decode, detect, restore, encode, full audio remux with faststart.
• The three detectors agree on 98.7-99.2% of all 578,704 frame-level restore/pass decisions; 327,691 frames were restored by all three, and only 1.65% of the movie is decided differently by any of them. On this content, coverage is not what separates detector generations - pick by speed.
• v4_fast is a much smaller network (8 MiB engine vs 46 MiB for v2 and v4_accurate): detect stage -45%, GPU load 51% vs 69%, wall time -24%. v2 and v4_accurate cost the same and cover the same on this title.
• Denoise ultra costs about 21% of wall time on the v4_fast configuration (1h 34m without, 1h 54m-1h 55m with, measured twice). A quality/speed choice.
• 8GB is enough for 1080p at Max Clip 300, but it is full: VRAM sat at 7.8-7.9GB throughout all three runs. 4K at Max Clip 300 does not fit an 8GB card - use a lower Max Clip there, lada default is 180, jasna is 90.
• Movie ID and methodology on request (DM).

 

[seatv]

ChitraMaya v1.70.00 is out

Short version: every AMD build until now was encoding on the CPU because
of a bug in our start-of-run encoder check, and a second bug made long
runs with the default blend mask crawl for hours while the GPU sat idle.
Both fixed and measured on our own RX 9060 XT on full-length titles.
All editions

• The wrong edition tells you so. A startup check probes the GPU
  before anything loads; if this edition cannot run on this machine it
  names the GPUs Windows sees and the edition that matches. No more
  vanishing window. The title bar says which edition is running.
• Named saved configurations. Save the whole current setup
  (controls + folders) under a name from the gear menu; the names appear
  in the menu and one click loads one and makes it active. Files copy
  between machines.
• Real-ESRGAN 4x next to RTX Super-Res (NVIDIA only). Same clip,
  same restoration: RTX is the smoother look, ESRGAN keeps texture. Pick
  by eye.
• Honest fps / ETA - counts completed frames, and the console
  prints the true running average every 500 frames.
• Engine-size check before the run - a modal instead of a
  silent PyTorch fallback.
• 8 GB cards at 4K: set Store backend to host (the frame
  store lives in system RAM). A 3h55m 4K30 title completed on an 8 GB
  3060 Ti over an x4 link in 4h26m that way; the automatic choice can
  still pick VRAM with too little headroom and die in a dense section.
  Automatic fix planned.
• Fixed: very long filenames; interrupted stream-capture remux; ffmpeg
  9; 16 GB Intel Arc laptops. Known: outputs above ~20 GB can lose the
  final remux to a watchdog during ffmpeg's faststart pass - the
  -RECOVER.ps1 next to the output rebuilds it, nothing is lost; fixed
  next release.

AMD (ROCm) edition - measured, not estimated

• Hardware encode actually works now. The probe tested the AMF
  encoder with a frame smaller than its minimum, got a rejection, and fell
  back to libx265 on the CPU - every AMD machine, every run. A 3-minute
  1080p60 clip: 27m44s -> 10m25s, CPU 95% -> 19%, GPU 13% -> 90%.
• The blend mask no longer compiles per region. On Windows the
  ROCm math library compiles a fresh kernel for every unseen convolution
  shape, and the default blend mask changed shape with every region of
  every frame - minutes each, thousands of times per title. Rewritten as
  a box filter (same output to within float rounding). The benchmark
  title with Max Clip 180 + Real-ESRGAN + FP16: ~22 hours projected on
  the previous build, ~7 hours on this one.
• The number that matters: the benchmark title at the standard
  settings (v2 detector, Max Clip 90, FP32, HEVC via AMF) restored in
  6h51m-7h06m = 0.38-0.39x realtime on the 9060 XT, two runs.
  Detection decisions within 16 frames of the NVIDIA fleet over 578,704
  frames - same model, same decisions, different vendor. Put plainly:
  in PyTorch a 9060 XT runs like an RTX 4060 in PyTorch (6h44m on
  the same title). The NVIDIA edition's TensorRT path is 2-3x faster than
  any PyTorch path, ours included (3060 12GB 3h11m, 5060 Ti 2h31m) - and
  Windows ROCm has nothing like TensorRT today.
• What is still slow: decoded frames reach the app through a
  pipe capped near 35 fps at 1080p; that transport is ~63% of the wall
  clock. We measured every layer (the GPU decoder itself does 447 fps -
  the pipe is the wall); fix identified, next release. Expect ~5h50m on
  this card when it lands.
• Detection FP16 is off on AMD, on purpose - measured, it stops
  detecting after the first frames. The app forces FP32 detection and
  greys the box. Restoration FP16 stays your choice.
• Real-ESRGAN 4x secondary upscaler - the AMD edition's first.
• First run after installing into a new folder is slow, once
  (kernel compile). The console says so at start; the cache now survives
  updates (copy the miopen-cache folder to a new install to skip it).

Intel Arc edition

• The benchmark title on an Arc 140V laptop iGPU: 14h14m = 0.19x
  (Max Clip 180, FP16, Real-ESRGAN, AV1 via Quick Sync), zero retries. A
  start-it-before-bed machine; roughly 2x an RTX 3060 Mobile in PyTorch,
  4-5x a desktop 3060 on TensorRT. Same decode transport as AMD (60% of
  the wall clock there), same fix coming. The blend-mask rewrite helps
  here too: 15% off restore time on a dense clip.

Downloads - one edition per GPU vendor, they are separate:

• NVIDIA: github.com/seatv/ChitraMaya (three files: .exe + .7z.001 +
  .7z.002; or the 1.61.00 -> 1.70.00 patch zip)
• AMD: github.com/seatv/ChitraMaya-AMD-ROCM (single .exe, install into
  a new folder)
• Intel Arc: github.com/seatv/ChitraMaya-Intel-ARC (single .exe)

Full release notes and the README's per-edition sections are on the
release page; the AMD and Intel rows join the benchmark table above.
Custom models are in progress and will be published with measurements -
restoration, not generation. As always: AGPL, no money, if it is useful
to you give something to Save the Children.

 

[stryder1]

@seatv
what happened to the github repo? 404 error

 

[seatv]

The GitHub pages are temporarily returning 404 while GitHub reviews an automated flag on my account. Nothing is lost; We are working with GitHub resolve the matter.

I'll post here as soon as they're back, and 1.80.00 follows right after.

 

[seatv]

ChitraMaya v1.80.00 is out - whole-frame upscaling, custom models (with TensorRT engines on NVIDIA), one-click model setup, a User Guide, and a new home: get.chitramaya.org

Short version: a feature release for all three editions. Whole-frame
upscaling arrives as its own mode (Real-ESRGAN on every GPU, RTX
Super-Res on NVIDIA), any community super-resolution model drops into a
folder and shows up in the scaler dropdowns - and on NVIDIA compiles to
TensorRT engines - Manage Models fetches and compiles the standard model
set with one button, and a fresh install now starts on the settings we
have been recommending. On NVIDIA the 8 GB / 4K story is closed. On AMD,
Temporal Stability works for the first time. There is a User Guide behind
a Help button. Interface in Simplified and Traditional Chinese and Thai.

How to get it

• Download: https://get.chitramaya.org - one edition per GPU
  vendor (NVIDIA / AMD Radeon / Intel Arc), every file with its SHA-256.
• NVIDIA is three files (ChitraMaya-install.exe + .7z.001 +
  .7z.002) - download all three into one folder, then run the .exe. AMD and
  Intel are one .exe each.
• Install into a new, empty folder; never extract over an old
  version. Then Manage Models -> Get Models (and on NVIDIA, Compile Models).
• Fresh install for everyone this time - no patch zip (see Downloads at
  the end). Copy your models\ folder and ChitraMaya-config.json across
  from the old install.
• Source, release notes and the issue tracker:
  https://gitlab.com/seatv/chitramaya. The GitHub repositories
  are mirrors and may lag; if you linked the old release pages anywhere,
  point the link at get.chitramaya.org - it always carries the current
  release.

The defaults changed - a fresh install (or Reset Defaults) starts
with Secondary = RTX Super-Res 4x on NVIDIA / Real-ESRGAN 4x on AMD and
Intel, Detection Batch 8, Score 0.20, Temporal Stability 1, Max Clip
Length 180 with Overlap 8 + Crossfade, Feather auto. Your saved settings
still win. A built-in VR 4K configuration (gear menu) sets Image
Size 800, Max Clip 180 and Split SBS in one click.

New: Upscale - whole-frame upscaling

• Output Upscale (Encoder panel) takes a factor (2x, 4x) or a target
  (1080p, 1440p, 2160p) and scales the finished frame before encode -
  inside a restoration run, or on its own in the new Upscale mode
  (decode -> scale -> encode, no models) for SFW content you just want
  bigger. Save Segment writes a marked segment as its own file so you can
  judge a scaler on a minute before committing a title.
• What it costs, measured: a 1080p title restored AND upscaled
  to 2160p with RTX Super-Res on an RTX 3060 Ti: 6h30m for 2h03m;
  upscale-only on a 5060 Ti: 10h02m for 2h41m (61 ms per 4K frame).
  Real-ESRGAN whole-frame on the 3060 Ti: 2.1 fps - about 29 hours for
  the same title. A 720p title to 2160p with a custom SPAN model on an RX
  9060 XT: 10h00m for 2h25m. On the Arc 140V laptop, 4K output runs at
  about 1 fps.
• Put plainly: whole-frame upscaling is a clip feature, or an
  overnight one. RTX Super-Res is the title-scale path on NVIDIA;
  everything else is clips and segments, and on AMD/Intel it is
  start-it-and-leave-it. The Scaling Guide (shipped next to the app) has
  the full table and recipes.

New: custom super-resolution models - and their engines

• Drop any .pth / .safetensors super-resolution model into
  models\upscalers\ - Real-ESRGAN, SPAN, PLKSR, DAT, HAT, OmniSR and some
  forty other architectures, identified automatically - and it appears in
  both scaler dropdowns. Manage Models has a Custom scalers section (Add /
  Rescan / Open / Remove) and names what it could not identify, with a
  reason.
• As a Secondary the built-ins remain the recommendation - none of the
  community models we measured beat them clearly. The one worth trying is
  Philip Hofmann's 4xNomos8k_span_otf_strong: to our eyes a touch
  better on skin, and on AMD and Intel it is faster than the
  built-in Real-ESRGAN (9% less restore time on a 9060 XT, 18% on an Arc
  140V) - SPAN models now run at the speed they were designed for (their
  layers are fused once at load; the reference code re-fused them every
  frame).
• NVIDIA: compile it once. From the install folder,
  ChitraMaya-cli.exe -compile-sr 4xNomos8k_span_otf_strong.pth
  --secondary --bench builds TensorRT engines beside the weights and
  the app uses them from then on. Measured 2.1x on the whole-frame
  upscale: a 66-minute 1080p title restored and upscaled to 2160p on a
  3060 Ti, 5h04m with the SPAN engines against 3h42m with RTX Super-Res -
  and the SPAN run used 72% of the VRAM where Maxine sat at the ceiling.
  Engines are per GPU model; built elsewhere, the model simply runs in
  PyTorch.

New: Manage Models does the first setup

• The header button says what comes next: green Get Models on an
  empty install (one click fetches lada's and zelefans' models - Hugging
  Face or the mainland-China mirror), amber Compile Models on NVIDIA
  when an engine is missing for your Image Size / Detection Batch, grey
  when everything is in place. On AMD/Intel the compile section is greyed
  with the reason.

New: a User Guide - installed next to the app, opens from the
Help button (also at get.chitramaya.org/userguide.html): installing,
models, the workflow, the dials that matter, Process Folder, VR/SBS,
upscaling, Add Mosaic, the output files, memory, what to expect from your
card, troubleshooting. The README is a front door now.

NVIDIA: the 8 GB / 4K story, closed

• Re-decode frame store: no frames are stored between detection
  and paste-back; a second NVDEC pass produces each frame when it is due,
  so Max Clip Length costs no VRAM or RAM.
• Right-sized detector engines: ~0.4 GB of VRAM instead of
  1.6-3.1 GB. Recompile once to get it (Manage Models turns amber until
  you do). Detection Batch above the engine's profile is clamped with a
  console line, not a crash.
• Result: a 2h20m 4K60 title completes on an 8 GB RTX 3060 Ti over
  an x4 link in 5h53m. The "8 GB at 4K" known issue is gone. Crop Cap
  (off by default) is the remaining lever for 3,000-px close-ups on small
  cards.
• Max Clip Length, measured (10-min 4K60 cut, RTX 3060 12 GB,
  six runs): restore time per frame is flat from 90 to 240; a short clip
  only costs the join re-work (23% at 90, 12% at 180, 10% at 240), and 300
  hit the memory ceiling and slowed the whole run 18%. Same residuals in
  every run. Rule: Max Clip = about 3x the frame rate - the new
  default 180 at 60 fps, 90 at 30.
• A Process Folder batch of four 1080p titles overnight on an RTX 5060
  Ti: 12.4 h, 40-46 fps, four done, no errors.

AMD (ROCm) edition

• Temporal Stability works now. Every previous AMD build ran the
  stabilizer in half precision, which on ROCm returns garbage - black
  rectangles and waviness in restored regions on some runs. It runs in
  fp32 on ROCm now and checks every window it produces; measured clean at
  strength 3 on the 9060 XT. On by default at strength 1 like every
  edition.
• A guard against damaged frames from the hardware decoder. The
  D3D11VA decode path on our 9060 XT (Adrenalin 26.9.1) occasionally
  hands over a frame that was never finished - black from a row down, or
  green/magenta - right after the decoder had been waiting on a full pipe.
  Not our bug, but our picture: the app now checks every decoded frame,
  completes an unfinished one from the frame before it, lists the frames
  in the run report and ends the run "with warnings". The sure fix is the
  new Hardware Decode = Off switch (CPU decode, ~9% slower on our
  box). If your earlier AMD outputs had the odd black or green frame, this
  was it.
• Restoration FP16 is clean and ~15% faster - your choice. Detection
  stays FP32 on this edition by design. Real-ESRGAN is the default
  Secondary; the SPAN model above is faster. Custom-scaler engines are
  NVIDIA-only.
• Measured on the 9060 XT: the full quality stack on a 17 s 1080p cut,
  42-51 s (11.8-14.3 fps); a dense 1080p60 clip of 7,883 frames,
  13m34s. [[THE FULL TITLE ON 1.80.00 - or drop]]

Intel Arc edition

• The benchmark title on the Arc 140V laptop iGPU with the full stack
  (Temporal Stability 3, Real-ESRGAN, AV1 via Quick Sync): 10h08m =
  0.265x realtime, up from 14h14m in 1.70 - about 1.6x a desktop RTX
  4060 in PyTorch. The pace held all night on a laptop. 4K output runs at
  ~1 fps there (the frames' trip to the encoder is the wall), so keep
  titles at native resolution on the iGPU.

All editions

• Overlap + Crossfade at Max Clip cuts - a clip cut by Max Clip
  continues in the next with its last frames re-restored as a lead-in and
  the seam faded (Jasna's idea, on our tracker). Face Swap blend
  feathers outward - every mosaic pixel fully replaced, soft edge into
  clean skin; the edge-irregularity known issue is gone.
• The VRAM preflight asks before the run: if the estimate says
  it will not fit, the dialog offers to set the levers that do (Crop Cap,
  Async off, Detection Batch, Max Clip, Secondary) in plain view and start.
• Runs that need your attention say so: DONE WITH WARNINGS in
  the console, "Complete - with N warnings" in the app, the reasons in the
  run report. A clean run is unchanged. The output is read back and
  verified before "Done"; the salvage files stay until it is.
• Run report <name>.run.json beside every output: what was asked
  vs what actually ran (which decoder, encoder, scaler, precision),
  timings, VRAM ledger, counts, the frames the guards touched, and a
  residual scan - the detector looks at the output and reports any
  mosaic still visible. Output suffix and a Run Files switch are yours.
• Fixed: a source with a picture glued in front of the stream lost
  its audio. Some captures carry a tiny PNG header ahead of an intact
  MPEG-TS; ffprobe calls the file an image, finds no audio, and every
  earlier version wrote a silent output (and your player says "no audio"
  on the source too). The container is now forced from the extension and
  the audio is kept.
• Scaler Quality for RTX Super-Res; Region Margin under Detection;
  watchdog GPU sampler with a paging detector; one-pass finalize (the
  "large outputs lose the remux" issue is gone); timestamped console logs;
  the 29.97-stamped-as-30 audio drift fixed.
• Interface in Simplified Chinese, Traditional Chinese (community
  translations) and Thai (machine draft, marked). Model downloads via
  hf-mirror.com for mainland China.
• Image Size rule of thumb from a 640-vs-800 benchmark: 800 for 4K
  and VR/SBS, 640 for 1080p - at 1080p it changed nothing at 15% more
  detection time.

Known issues: the AMD decode-guard item above (Off is the sure
fix); the RTX whole-frame scaler takes its Quality/Denoise from the
Secondary's controls (leave them at high/none for upscaling, own controls
planned); AMD/Intel 4K transport still slow; a thin mosaic sliver at the
frame edge can be missed (the residual scan reports it); a zero-frame
run self-grades complete; HEVC sources may show a black in-app player
(install the HEVC Video Extensions); three run-time button texts not yet
translated.

Downloads - https://get.chitramaya.org, one edition per
GPU vendor, they are separate, SHA-256 beside every file:

• NVIDIA: three files (.exe + .7z.001 + .7z.002, all into one folder).
  Fresh install for everyone this time - no patch zip (patches are
  built against the previous release's download, which the GitHub outage
  took with it; they return next release). Copy models\ and
  ChitraMaya-config.json from the old folder; recompile the detection
  model once afterwards.
• AMD: ChitraMaya-rocm-install.exe (single file, install into a new
  folder; Adrenalin 26.2.2+).
• Intel Arc: ChitraMaya-xpu-install.exe (single file).

Full release notes on the GitLab Releases page (gitlab.com/seatv/chitramaya);
the User Guide and the Scaling Guide ship with every edition and are on
the download page. Bugs: the GitLab issue tracker - attach the run.json
and the console log, never frames. Custom models are in progress and will
be published with measurements - restoration, not generation. As always:
AGPL, no money, if it is useful to you give something to Save the
Children.