Jasna Is a Selective Reconstruction System
Jasna is a GPU-based application and command line for restoring mosaics in videos and images. The important question is not simply whether its model can make a covered area look plausible. It is how the system decides what to change, how it keeps that change stable over time, and how it returns the result to a usable media file. That makes Jasna a useful case study in selective, hardware-aware reconstruction: quality comes from a chain of decisions, not from a model name alone.
The distinction matters because Jasna is deliberately narrow in one sense and ambitious in another. It aims to alter the mosaic area while leaving the rest of the picture alone. That protects the source around the target and avoids spending the full cost of restoration on every pixel. But the same design makes the boundary important. A missed detection means the restorer never receives the region. A weak or uncertain mask can shape the blend. A temporal break can make neighboring frames disagree. And a result that looks convincing is still a model-generated reconstruction, not proof that the hidden original pixels have been recovered.
What Jasna actually does
For video, Jasna first looks for mosaics, then follows those regions across frames, restores them, and blends the resulting patches back into the original picture. Its free default video model is BasicVSR++, a temporal restoration model designed for speed. Supporter workflows add LTX, a slower NVIDIA-only option that the project presents as capable of more detail. Optional secondary restorers can enlarge a restored patch when a large mosaic, close-up, or 4K source makes the primary 256-by-256 result look soft.
The project is not limited to one kind of file or one interface. A graphical application provides a queue, previews, a segment editor, and a video player. The command line can process a video, an image, or a folder. The segment editor can restrict work to chosen ranges instead of restoring a whole video. Jasna also documents a VR180 path, where a side-by-side frame is treated as two eyes, and a separate still-image path based on Stable Diffusion 1.5. Those features are related by the goal of selective restoration, but they are not interchangeable implementations.
That difference between media types is easy to underestimate. A video offers repeated observations over time, so the system can use a tracked region and a clip of frames. A still image has no temporal neighbors and therefore follows another restoration path. A side-by-side VR180 frame has two linked views whose geometry must be handled per eye. The shared product idea is “change the selected area,” but the evidence available to the model and the risks at the boundary change with the format.
The same product can therefore be understood at two levels. At the user level, it is a way to queue media, choose a workflow, preview or process selected material, and receive an output. At the system level, it is a sequence of interpretations: identify a target, preserve enough context to process it, generate a patch, and put that patch back into the source. The first level explains why people use Jasna; the second explains why its settings and limitations matter.
That scope already suggests a better mental model than “unmosaic button.” Jasna is a media pipeline with several decisions in the middle. It has to interpret the input, select a region, preserve temporal or geometric context where available, generate a patch, composite it, and write or stream the result. Each decision creates a different kind of success condition and a different way to fail.
Why changing only part of the frame matters
Suppose a video contains a mosaic over a small area of a face or object. A whole-frame enhancer would be free to alter texture, edges, and color everywhere, even where the source was already clear. Jasna instead extracts a context crop around a detected region, prepares that crop for the restoration model, and pastes the restored result back through a mask. The surrounding frame remains the reference rather than becoming another output of the model.
This locality has two practical benefits. First, it reduces collateral change. If the detector and mask are accurate, the system does not need to reinterpret the background simply because one region needs work. Second, it concentrates computation. A long video may contain only brief scenes with mosaics; selecting patches lets the system spend model time where the task exists.
Locality also changes how a reader should inspect an output. The question is not only “does the target look sharper?” It is also “does the transition remain coherent?” A patch can be plausible in isolation yet reveal a mismatch in scale, lighting, motion, or edge shape when placed beside the original pixels. A system that promises to leave the rest of the frame alone makes that join visible as a quality boundary. Preserving the source is valuable, but it means the generated region must meet a real, unchanged neighborhood.
Locality is not the same as certainty. A 256-by-256 primary output places a fixed spatial ceiling on the first restoration stage. Large targets may need an optional enlargement stage, which adds its own time, memory, and visual trade-offs. The mask also matters: the output can be locally generated while the transition to original pixels remains visible if the region is poorly selected or changes abruptly. The architecture protects untouched content; it cannot supply evidence that the source no longer contains.
The selected region is therefore both a quality boundary and a responsibility boundary. Detection determines where Jasna is allowed to act. The crop determines how much surrounding context the model sees. The temporal path determines whether consecutive frames can inform one another. The blend determines how the new patch is introduced. Looking only at the final restorer hides these earlier decisions, even though they determine much of what the restorer can possibly do.
For that reason, the word “restore” needs a careful reading. Jasna's documentation uses comparative language such as “more detail,” “more natural,” and “experimental,” and it allows different seeds or variants in some modes. Those are descriptions of model behavior and user choice, not a universal accuracy guarantee. The responsible interpretation is that Jasna reconstructs a selected region from the visible crop and, for video, from temporal context. The closer that evidence is to the missing content and the more stable the selection is, the more useful the result may be. Plausibility alone does not establish historical accuracy.
The constraints are part of the product
Jasna's behavior also depends on the machine that runs it. The documented baseline is a supported GPU, a recent driver, and a local disk path whose characters and filesystem meet the application's requirements. NVIDIA hardware provides the broadest feature set; AMD support is described as experimental, and LTX and secondary restoration are NVIDIA-only. A reader who sees an option in the documentation cannot assume that the option is available on every supported accelerator.
This is more than a compatibility footnote. Hardware changes the available decision space. A machine that can run BasicVSR++ may not be able to run LTX, a secondary enlargement model, or a large temporal clip with the same input. A workflow that is reasonable for a short 1080p scene may be impractical for a long 4K video. The system's promise is consequently conditional: Jasna can coordinate the stages only within the memory, acceleration, storage, and media limits of the environment running them.
The same principle applies to distribution. The public application source is AGPL-licensed, and the public-source workflow can run the free BasicVSR++ path. Supporter models such as LTX, UNet 4x, and SD 1.5 require the official release and activation. The project documents a separate protection component for supporter-key validation and encrypted model handling, so the public checkout is not identical to the official supporter-enabled executable. This is not a minor purchasing detail; it marks the boundary between what the public code can reproduce and what the packaged product adds.
A first job may also behave differently from later jobs because NVIDIA models are prepared for the exact GPU and then reused. In other words, “how fast is Jasna?” has no single answer independent of hardware, model, media, and cache state. The system's practical identity includes those operating conditions. A useful evaluation must therefore name the media type, restoration branch, accelerator, and delivery goal instead of treating a speed number as a property of the name Jasna alone.
The questions that define a trustworthy result
The rest of this series follows four connected questions. First, what counts as a mosaic, and how does a frame-by-frame decision become a stable track? Second, how are those tracks divided into clips so that temporal continuity improves without consuming more VRAM than the machine has? Third, what changes when the reader chooses BasicVSR++, LTX, secondary restoration, selected ranges, VR180 handling, or the still-image path? Finally, how do encoding, streaming, licensing, and troubleshooting affect the result that actually reaches the reader or viewer?
These questions keep Jasna in view while avoiding a flag-by-flag manual. They also give the reader a way to interpret failure. If a mosaic is missed, the problem begins before restoration. If a seam appears, temporal tracking, scene boundaries, clip overlap, or masking may be more relevant than the model choice. If a job is too slow or runs out of memory, the right response may be to change scope or clip size rather than demand a sharper model. And if a patch looks impressively detailed, the right next step is still to ask what evidence the system had for that detail.
Jasna's central promise is therefore best understood as controlled change: select a region, use the available temporal or image evidence, generate a bounded patch, and preserve the rest of the media as far as the workflow allows. The next step is to follow that promise through the complete path from an input frame to a finished file, where each boundary becomes concrete.