Jasna is a JAV mosaic restoration tool with a simple GUI, a CLI, a GPU-only processing pipeline, NVIDIA TensorRT and experimental AMD ROCm support, optional secondary restoration models, still-image restoration, and streaming support.
Jasna is free. Supporters get a key that unlocks the extra models trained for this project: the unet-4x secondary upscaler and the experimental SD 1.5 image restoration model. See Supporting the project.
A modified build on top of upstream Kruk2/jasna v0.8.1, adding frame generation (
--frame-gen2x/4x), an experimental torchcodec video backend, an experimental FP8 restoration backend, SeedVR2 primary restoration, and FlashVSR secondary restoration, among other improvements.
- Source (this fork/branch): sh202603/jasna @
modi- Full list of changes vs upstream: docs/en/changes_vs_upstream.md
- Scope — public (free) features only. The supporter models (unet-4x and SD 1.5 image restoration) ship as encrypted checkpoints unlocked by a supporter key, and the decryption code lives in a private submodule that is not part of this public fork — so those models cannot be downloaded, decrypted, or run here. The upstream code for them rides along but stays inert. If you want the supporter models, use upstream Kruk2/jasna and become a supporter. Everything else (detection, video restoration, RTX/TVAI secondary, the segment editor, VR180, post-export actions, frame generation) works normally.
- What Jasna Does
+modiAdditions- Community
- Requirements
- Quick Start
- First Run
- Learn More
- Benchmarks
- Supporting the Project
- Acknowledgments
- TODO
- Restores mosaics in video files.
- Restores mosaics in still images with the experimental SD 1.5 image model.
- Detects mosaics with the fast
rfdetr-v6model by default; the larger RF-DETR variant and Lada and ZeLeFans YOLO models are also available. - Processes side-by-side VR180 videos per eye and automatically picks the best mosaic restoration handling for each studio; the Segment Editor can preview the options.
- Supports frame-accurate ranges on NVIDIA and AMD GPUs, restoration previews, and zoom/pan inspection in the Segment Editor.
- Reduces clip-boundary flicker with temporal overlap and crossfade.
- Detects hard scene cuts and ends tracked clips at the boundary, so restoration never blends content across a cut.
- Can further improve quality with optional secondary restoration models — unet-4x, RTX Super Resolution, or Topaz Video AI — which sharpen restored regions, especially large mosaics, close-ups, and 4K video.
- Includes a native GUI video player with full-screen playback and seeking through restored frames without creating an output file.
- Can stream restored video to the built-in browser player or a supported Stash fork.
These features are exclusive to the +modi fork. See docs/en/changes_vs_upstream.md for the full list of changes against upstream.
--frame-gen {2x,4x} raises the output frame rate by inserting AI-interpolated frames (RIFE) between the source frames. File output only (not --stream, not --segments); audio timecodes are kept, so duration and sync are preserved. Runs fp16 by default — measured ~1.9x faster than fp32 (1080p 2x, RTX 5060 Ti) with visually identical output.
jasna --input input.mp4 --output output.mkv --frame-gen 2xBackend via --frame-gen-backend {rife,rtx} (rife is the default and available now; rtx is pending NVIDIA's nvidia-vfx release).
A standalone jasna-framegen command applies only frame generation to an already-restored video (no detection/restoration) — handy for a two-pass workflow (restore first, e.g. with the official binary, then up-convert). It also supports folder input/output with an --output-pattern naming template (videos only):
jasna-framegen --input restored.mkv --output out2x.mkv --factor 2x
jasna-framegen --input in_dir --output out_dir --factor 2x --output-pattern "{original}_2x.mkv"Details: docs/en/frame_generation.md.
Jasna decodes and encodes through PyAV (NVDEC/NVENC) by default (--video-backend native). An experimental torchcodec backend is available as an alternative:
jasna --input input.mp4 --output output.mkv --video-backend auto--video-backend {native,auto,torchcodec} (default native, i.e. unchanged behavior): auto uses torchcodec for decode where available and falls back to native otherwise; torchcodec forces it. --decode-backend / --encode-backend override each side independently. Since v0.8.0 the native encoder always outputs 10-bit HEVC/AV1, which torchcodec's 8-bit NVENC cannot match, so torchcodec encode runs only when forced (--encode-backend torchcodec), and only for 8-bit sources with mappable NVENC settings; streaming, --segments, --retarget-high-fps, and frame generation stay on native. Colorspace metadata is preserved either way. Requires the optional dependency (pip install "torchcodec>=0.15.0" from the cu130 wheel index). Details: docs/en/torchcodec_backend.md.
--fp8-recon runs the BasicVSR++ upsample stage as cuDNN FP8 convolutions instead of the TensorRT FP16 sub-engine:
jasna --input input.mp4 --output output.mp4 --fp8-reconThe main benefit is VRAM: the TensorRT upsample engine's load-time arena (~2.2 GB at the default --max-clip-size 90) is never allocated, measured as 1.2–1.7 GB lower peak VRAM across 480p–4K clips. The stage itself also runs ~1.5x faster, though end-to-end fps is unchanged because the pipeline is detection-bound. Output stays visually indistinguishable from the FP16 engine and is bit-deterministic across runs. Requires an FP8-capable GPU (sm89+, i.e. RTX 40 series or newer; the speedup is validated on Blackwell only) and fp16 mode; falls back to the TensorRT engine on any failure. Verified on both Linux and Windows. Details: docs/en/fp8_recon.md.
--restoration-model-name seedvr2 replaces the BasicVSR++ primary restorer with SeedVR2 3B one-step diffusion + a custom LoRA trained to remove mosaic itself — a quality mode at ~6x the wall clock:
jasna --input in.mp4 --output out.mp4 --restoration-model-name seedvr2 --seedvr2-repo ~/seedvr2_videoupscalerInference runs in a resident worker inside the checkout's own venv (nothing is installed into jasna's), sliding a 33-frame window with cross-faded overlaps over each clip. Needs a 16 GB card; you supply the ComfyUI-SeedVR2_VideoUpscaler checkout (base weights auto-download, ~7.3 GB) and the ~90 MB LoRA from sh202603/lada-seedvr2-lora. Not compatible with VR modes / --frame-gen / flashvsr-inline; composes with the offline flashvsr mode into the maximum-quality stack. The LoRA is at its best on low-resolution, heavily degraded sources, where the diffusion prior rebuilds detail BasicVSR++ can only smooth over; being generative it adds plausible detail rather than recovering signal, so it complements rather than fully replaces the default basicvsrpp: pick the restorer per source. Details: docs/en/seedvr2.md.
--secondary-restoration flashvsr upscales each restored 256px mosaic crop to 1024px (4x) with FlashVSR diffusion VSR, recovering texture the primary model leaves blurry on large mosaics, close-ups, and 4K:
jasna --input in.mp4 --output out.mkv --secondary-restoration flashvsr --flashvsr-repo ~/FlashVSR_plusFlashVSR peaks at 12–16 GB VRAM on its own, so it cannot co-reside with the ~9 GB primary pipeline. It runs offline in three subprocesses whose peak VRAM never overlaps: (1) primary restoration → serialize crops to a disk bundle, (2) FlashVSR under its own venv, (3) re-blend + encode the final output. You supply the FlashVSR_plus checkout, its v1.1 weights, and a Python venv whose base Python ships the dev headers (FlashVSR's Triton attention kernel is JIT-compiled at runtime). File-output only; not compatible with --stream / --frame-gen. A single-pass variant, --secondary-restoration flashvsr-inline, runs FlashVSR inside the streaming pipeline with no intermediate files (needs a 16 GB card and a checkout with the tiny-long multi-chunk patch); it is the mode for the basicvsrpp primary, while the offline mode is the one that composes with the SeedVR2 primary. Both modes process at 1024px (4x) or, with --flashvsr-scale 2, at 512px (about 5x faster, a few GB less VRAM, same output resolution), and always color-correct the restored crops against the primary output. Details: docs/en/flashvsr.md.
Installing the nvidia-rtx extra instead of nvidia switches the TensorRT stack to TensorRT-RTX (JIT compilation): first-run engine builds finish in a fraction of the time (RTX 5060 Ti: RF-DETR 118 s → 16 s, BasicVSR++ sub-engines 143 s → 52 s; RTX 5080: 36 s → 5 s / 55 s → 16 s), at the cost of slightly slower processing (steady-state throughput about −10% on a long 1080p video). Engines are cached under .rtx-tagged names, so both flavors can share one model_weights directory. One venv holds one flavor. Details: docs/en/tensorrt_rtx.md.
Join the SLS Discord for examples, support, and settings discussion. Please don't be too weird.
- An NVIDIA GTX 16-series / RTX 20-series or newer GPU. GTX 10-series and older cards (GTX 1050/1060/1070/1080) won't work. Not sure about yours? Check NVIDIA's GPU table — compute capability 7.5+ is required.
- Nvidia driver 610 or newer on Windows, 580 or newer on Linux.
- AMD support is experimental and needs a ROCm-supported GPU.
- Install Jasna into a folder whose path contains only English letters and numbers.
Jasna manages VRAM automatically: when it runs low, waiting frames are temporarily moved to system RAM. No configuration needed.
- Download the release package for your OS and GPU vendor.
- Unzip it into a folder with only English characters in the path.
- Start the app:
- Windows: double click
jasna.exe. - Linux NVIDIA: run the
jasnafile. - Linux AMD: run
run_jasna_amd.sh.
- Windows: double click
- Add a video or image, choose settings, and start processing.
Every setting in the GUI has a tooltip — hover the ⓘ icon next to it. The GUI guide tours the rest: full-queue reruns, queue reordering, media actions, player shortcuts, presets, output patterns, and more.
Prefer the command line?
# Single video
jasna --input input.mp4 --output output.mkv
# Still image
jasna --input photo.png --output restored.png
# Whole folder
jasna --input input_folder --output output_folderRun jasna --help for all options, or read the CLI reference.
The first run is slow because Jasna prepares GPU-specific files for your exact card. On NVIDIA this usually takes 15-60 minutes; on AMD the preparation is much shorter. It only happens once — the results are cached in model_weights and reused on every later run. You can copy them from an older Jasna version to a newer one.
Close other applications, including browsers, and avoid using the PC while this runs.
If you run out of VRAM during processing, reduce max clip size first, for example from 180 to 60. See Tuning VRAM and GPU usage.
- Using the GUI — the restored video player, queue, presets, output patterns, file conflicts, and other easy-to-miss features.
- Choosing models — which detection model to pick, sharper results with secondary restoration (unet-4x / RTX Super Resolution / Topaz), and SD 1.5 still-image restoration.
- Restoring only parts of a video — the Segment Editor, built-in mosaic scanning, A/B comparison of detection/restoration models, suggesting better masks, and the
--segmentsCLI flag. - VR180 videos — how Jasna handles side-by-side VR and picks the right settings per studio.
- Tuning VRAM and GPU usage — clip size, temporal overlap, model compilation, and what to do when VRAM runs out.
- Advanced processing — denoising, 60→30 FPS export, color LUTs, sharpening, literal encoder CQ controls, custom encoder settings, and queue-wide or per-video post-export actions.
- Streaming — watch restored video on the fly in your browser or through Stash.
- CLI reference — every command-line option, including
--cq, encoder settings per codec, and post-export actions. - Running from source — developer setup and build notes.
+modibuild guides: this fork builds the native GPU libraries and runs Jasna from source — there is no public packaged/frozen binary (the packaging tooling lives in the privatejasna/protectionsubmodule, same as upstream). Step-by-step guides covering the CUDA 13.0 toolchain, native libraries, ffmpeg 8, and TensorRT engine setup:
- Linux: docs/en/building_linux.md（日本語）
- Windows: docs/en/building_windows.md（日本語）
+modi feature guides:
- Frame generation — RIFE 2x/4x frame-rate up-conversion and the standalone
jasna-framegentool. - Video backend — the experimental torchcodec decode/encode backend.
- FP8 restoration backend — the cuDNN FP8 upsample stage with lower peak VRAM.
- SeedVR2 primary restoration — diffusion+LoRA mosaic removal replacing BasicVSR++.
- FlashVSR secondary restoration — offline and inline diffusion 4x upscaling.
- Frozen build — the experimental Nuitka standalone build.
- Changes vs upstream — the full delta of this fork.
End-to-end restoration measured on Linux with an RTX 5090 (driver 595.84) and
i9-13900K.
Jasna used its default models with --max-clip-size 180 --temporal-overlap 15 --secondary-restoration none. Lada Flatpak 0.11.0 used the accurate v2
detector, CUDA FP16, --max-clip-length 180, and its NVIDIA HEVC HQ preset.
Frozen-release and Lada times are one measured run after a discarded warmup;
v0.9.0 and v0.9.1 times are medians of three interleaved runs after warmup.
Parenthetical ratios use Lada as the baseline; because Lada was not run on 8K,
that row uses v0.9.0 as its baseline. The SONE clips contain 6,056 frames
(3:22) each and the 8K VR clip 900 frames (15 s).
Only the releases where speed or GPU memory actually moved are listed, and one input per resolution. Every version and every codec is in the full benchmark report.
| Input | Lada 0.11.0 v2 | v0.4.1 | v0.5.0 | v0.9.0 (4a171c9) | v0.9.1 (18add8a) |
|---|---|---|---|---|---|
| 720p H.264 8-bit | 01:47 (baseline) | 01:35 (1.1x faster) | 00:45 (2.4x faster) | 00:34 (3.1x faster) | 00:32 (3.4x faster) |
| 1080p H.264 8-bit | 02:02 (baseline) | 01:46 (1.2x faster) | 00:47 (2.6x faster) | 00:39 (3.2x faster) | 00:34 (3.6x faster) |
| 2160p H.264 8-bit | 04:56 (baseline) | 03:23 (1.5x faster) | 01:22 (3.6x faster) | 01:15 (3.9x faster) | 01:03 (4.7x faster) |
| 8K VR HEVC 8-bit 60 fps | — | — | — | 00:34 (8K baseline) | — |
GPU memory is median/peak GiB for the measured benchmark target; — means
not run. Parenthetical ratios compare the median against v0.4.1, or against
v0.9.0 on the 8K row that v0.4.1 never ran. Lada is left out of the comparison:
it uses less GPU memory than any Jasna build.
| Input | Lada | v0.4.1 | v0.5.0 | v0.9.0 | v0.9.1 |
|---|---|---|---|---|---|
| 720p H.264 8-bit | 1.8/3.1 | 17.6/19.9 (baseline) | 8.6/9.0 (2.0x less) | 8.6/9.1 (2.0x less) | 4.2/4.6 (4.2x less) |
| 1080p H.264 8-bit | 2.0/3.3 | 18.9/21.4 (baseline) | 9.5/10.2 (2.0x less) | 9.3/10.1 (2.0x less) | 4.8/5.6 (3.9x less) |
| 2160p H.264 8-bit | 2.6/4.1 | 26.0/30.5 (baseline) | 12.9/15.0 (2.0x less) | 11.4/15.4 (2.3x less) | 7.2/10.9 (3.6x less) |
| 8K VR HEVC 8-bit 60 fps | — | — | — | 17.1/18.3 (8K baseline) | — |
The v0.9.1 drop in GPU memory comes from building the restoration sub-engines at fixed batch sizes instead of at the clip size — see the engine batch report. For median/peak RAM, methodology, raw data, and performance-commit comparisons see the full benchmark report.
The original Linux results are retained below and enriched with the new v0.7.2 and v0.9.0 runs. They used the same RTX 5090 and i9-13900K; the listed clip size was preserved for each input.
| File | Clip (s) | Lada 0.10.1 | Jasna 0.3.0 | Jasna 0.5.0 | Jasna 0.6.2 | Jasna 0.7.2 | Jasna 0.9.0 (7d9cc8c) |
|---|---|---|---|---|---|---|---|
| ABF-017 (4K, 2h 25min) | 60 | 02:56:26 | 01:20:49 (2.2x faster) | 01:10:00 (2.5x faster) | — | — | 42:17 (4.2x faster) |
| HUBLK-063 (1080p, 3h 10min) | 180 | 01:34:51 | 44:21 (2.1x faster) | 37:57 (2.5x faster) | 30:58 (3.1x faster) | 23:38 (4.0x faster) | 18:01 (5.3x faster) |
| DASS-570_2m | 30 | 01:08 | 00:30 (2.3x faster) | 00:24 (2.8x faster) | 00:20 (3.4x faster) | 01:05 (1.0x faster) | 00:22 (3.1x faster) |
| NASK-223_Test | 30 | 03:12 | 01:18 (2.5x faster) | 01:02 (3.1x faster) | 00:58 (3.3x faster) | 01:07 (2.9x faster) | 01:01 (3.1x faster) |
| test-007 | 30 | 01:16 | 00:41 (1.9x faster) | 00:28 (2.7x faster) | 00:22 (3.5x faster) | 00:27 (2.8x faster) | 00:27 (2.8x faster) |
Support pays for training extra models, mainly GPU rental and compute time for larger datasets. Supporters get a key that unlocks:
- unet-4x secondary upscaler for sharper 256->1024 restoration.
- SD 1.5 image restoration, the experimental still-image model.
Example results:
- unet-4x / secondary restoration examples on SLS Discord
- SD 1.5 image restoration examples on SLS Discord and more SD 1.5 examples
How to get a key:
- Contribute $15 USD or more in total, across any number of contributions and at any time.
- After your contribution is processed, your supporter key is sent automatically:
- Unifans: sent by platform message. There might be a slight delay.
- Buy Me a Coffee, including crypto: sent to the email or handle used for the contribution. The key is tied to that email or handle.
- Lada (Codeberg) — Jasna is inspired
by, and in some places based on, Lada. The
mosaic_restoration_1.2restoration model used by Jasna was trained by ladaapp, the Lada author. - ZeLeFans — for the VR detection model and the in-depth analysis of mosaic shapes and VR projection.
Current TODO:
- SeedVR support?
- Continued performance and VRAM improvements.
- Better restoration model.
- Better detection model.