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.