What Jasna Can—and Cannot—Restore
Jasna can be understood as a system for controlled change: it selects a suspected mosaic, carries that selection through time or media geometry, generates a regional reconstruction, and places the result back into a usable output. The final judgment is not whether one model sounds more advanced. It is whether the chosen workflow fits the media, the evidence, the hardware, the delivery goal, and the uncertainty that remains after inference. This conclusion turns those conditions into a practical decision rule and states clearly what the architecture protects—and what no model result can prove.
The shortest defensible rule is this: choose the narrowest Jasna workflow that gives the selected region enough evidence, enough resources, and enough output compatibility for the intended use; validate a representative sample; then describe the result as a bounded reconstruction rather than as guaranteed access to the hidden original. That rule is short, but each part matters. Remove any one of them and a reasonable-looking output can become misleading, wasteful, or impossible to reproduce.
Start with the media, not the model
The first choice is the media type and geometry. Ordinary flat video can use the main detection, tracking, clip, restoration, and blending path. A side-by-side VR180 video needs per-eye detection and projection-aware compositing, and LTX is not supported for that geometry. A still image goes through a separate Stable Diffusion 1.5 path because it has no temporal neighbors. A live or browser workflow uses BasicVSR++ and H.264 rather than the offline LTX path. These are not cosmetic modes; they define what evidence the system can use and which engines are available.
For ordinary video, the next question is scope. If the entire video needs attention, a full run may be simplest. If only known scenes matter, selected ranges can avoid restoration work elsewhere while keeping the result as a full video. If the reader has a folder of long videos and wants the expensive model reserved for large mosaics, LTX auto-split can use approximate scans and a size rule to create mixed BasicVSR++ and LTX ranges. The scope choice is also a file choice: selected ranges must be stitchable, auto-split cannot be combined with selected ranges or fragmented MP4, and nearby frames may be re-encoded at keyframe boundaries.
The third question is whether the selected evidence is trustworthy enough to justify model work. A missed target is a detection problem, not an invitation to choose a more elaborate restorer. A false patch may require a threshold or minimum-duration change, not a sharper secondary stage. A gap or seam may require a temporal test. In VR180, geometry and projection must be checked before model quality can be compared. The simplest useful workflow is the one that first establishes that the correct pixels and frames are entering the pipeline.
Only then should the reader choose an engine. BasicVSR++ is the broad, fast, free path for supported GPUs. LTX is a slower, supporter-enabled NVIDIA path that Jasna presents as capable of more detail, but it requires a qualifying GPU, system memory, model storage, and a much larger time budget. Secondary restoration can enlarge BasicVSR++ patches, but it adds cost and is not used with LTX. A large-canvas LTX option is a different way to handle large mosaics, with its own free-VRAM requirement. The engine is an operating point inside the quality chain, not a replacement for the chain.
Finally, define how the result will be consumed. A persistent offline file has one set of requirements for codec, CQ, audio, metadata, and size. A growing fMP4 is useful for early inspection but has container and duration limitations. HLS streaming gives immediacy but uses BasicVSR++ and H.264 and produces no ordinary saved output by itself. The GUI Video Player is an inspection path rather than an export. A delivery choice that is made after rendering can invalidate an otherwise good model choice.