Emulation General Wiki

Deinterlacing

Revision as of 15:13, 13 June 2026 by Ahayri (talk | contribs) (→Also see)

Deinterlacing methods are used to process interlaced video signals (480i/576i), common in high-resolution modes for Sega Saturn, PlayStation, and PlayStation 2. Without deinterlacing, movement causes "combing" or "judder" artifacts on progressive displays. PlayStation 2 Graphics Synthesizer, used unique internal video output modes to handle or disguise interlacing. Emulators must handle these behaviors natively before applying any external deinterlacing method. While there are some attempted shader-based solutions, emulator's built-in deinterlacing methods provide better results on image quality.

Before diving in

Main article: Displays#The Analog Output Bottleneck in Software Emulation

Algorithms

Bob Deinterlacing

The most common and fastest method. It separates the two fields of an interlaced frame and scales them to full height.

  • Pros: Zero lag; preserves the "flicker" look of original hardware used for transparency effects (e.g., shadows in Silent Hill 2).
  • Cons: The image "bobs" or shimmers vertically because lines are offset between fields.

Weave / Blend

Combines two consecutive fields into a single frame.

  • Pros: High detail on static images.
  • Cons: Severe "combing" artifacts during horizontal movement; generally not recommended for gaming.

Motion-Adaptive (MAD / YADIF / BWDIF)

This algorithm analyzes pixels across multiple fields to determine if they are static or in motion. These are more complex shaders that attempt to detect which parts of the image are moving. They use "weave" for static areas and "bob" or interpolation for moving areas. As of 2022, PCSX2 and high-end shader suites use Motion-Adaptive Deinterlacing. BWDIF (Bob Weaver Deinterlacing Filter) is a modern evolution of this, providing sharper edges than YADIF.

  • Pros: Uses "Weave" for static areas (preserving full vertical resolution) and "Bob" or interpolation for moving areas. Effectively eliminates shimmering on text and UI while removing combing on moving objects.
  • Cons: Can introduce a small amount of input lag and requires more GPU resources. Moving objects may appear slightly "softer" than static ones since they rely on interpolation.

Motion-Compensated (MC)

The most advanced deinterlacing approach at this moment. Unlike adaptive methods that just "switch" techniques, MC uses "Motion Estimation" to track objects moving across the screen and "reconstructs" the missing data by looking at where those pixels were in previous/future fields.

  • Status: Primarily found in video post-processing (e.g., QTGMC, FFmpeg). Not yet viable for real-time emulators due to extreme GPU demand and the necessity of "looking ahead" at future frames, which causes significant input lag.
  • Pros: Near-perfect reconstruction of moving images; provides full vertical resolution even during high-speed motion (the "holy grail" of image quality).
  • Cons: High computational cost; prone to "hallucinating" or warping artifacts if the motion estimation tracking fails.

Other approaches

Automatic

Modern emulators can now automatically toggle deinterlacing based on the game's internal state.

  • How it works: Instead of a "one-size-fits-all" shader, the emulator detects when a game switches from 480i (interlaced gameplay) to 240p (progressive menus) or 480p (progressive scan) and disables deinterlacing automatically to prevent unnecessary blurring.

Index/compatibility database

Modern emulators can now automatically toggle deinterlacing based on their index/compatibility database.

No-Interlace Patches

A popular alternative to shaders. These are community-made patches that modify the game's code to render in progressive mode internally.

  • Pros: The cleanest possible image; removes the need for deinterlacing shaders entirely.
  • Cons: May cause graphical glitches in specific titles or break FMV playback.

CRT Simulation

Main article: Shaders, presets, and filters#Full Signal & Cable Emulation

High Refresh-Rate Insertion

Modern low-latency renderers (such as paraLLEl-GS) experiment with bypassing traditional software deinterlacing shaders entirely.[1] Instead, they simulate how a CRT monitor naturally displays interlaced fields by utilizing high-refresh-rate displays and Black Frame Insertion (BFI) techniques.

  • Pros: Achieves a completely authentic CRT "deinterlacing" look; bypasses the need for soft interpolation filters; eliminates sample-and-hold motion blur.
  • Cons: High computational and display requirements; causes a severe drop in native screen brightness; any missed frames or micro-stutter causes severe, highly visible flickering (epilepsy hazard).
  • How it works: The emulator simulates each interlaced field independently with scanlines (interlacing flicker). By leveraging high-refresh-rate host displays, the emulator queries display timings (`EXT_present_timing`) to insert a calculated number of "gentle falloff" or blank frames during a single guest field's duration (~60Hz NTSC / 50Hz PAL).
  • HDR Luminance Compensation & Linear Mastering: To counteract the massive average brightness drop inherent to black frame masking, modern implementations render natively inside an HDR10 colorspace. Instead of brute-forcing average luminance via a crude software brightness multiplier (which crushes shadow detail and causes aggressive strobe fatigue), the emulator performs 3×3 matrix color transformations inside a truly linear mathematical space. By passing precise Maximum Content Light Level (MaxCLL) metadata targets directly to the OS compositor and display engine, the emulator instructs the host monitor to disable its automated internal tone mapping. This hands direct control of the hardware backlight headroom to the shader pipeline.
    • For 120Hz, this precision prevents severe color clipping and gamma distortion during the harsh 50% total blackout cycle. For 240Hz or higher, it unlocks the full potential of native HDR10 rendering; because high-refresh environments spread the phosphor decay across multiple frames instead of a sudden drop to black, the direct backlight management seamlessly neutralizes the historical BFI brightness penalty. The result is a vibrant, perfectly balanced analog simulation that accurately reconstructs authentic CRT phosphor decay dynamics and wide-gamut historical profiles (like Japan's legacy NTSC 1953 standard) without a dim picture or highlight clipping.
    • Color Primaries: Accurate simulation also uses 3×3 matrix transformations to map retro SDTV color spaces (such as BT.601 or historical NTSC 1953 primaries) into modern sRGB (BT.709) or wide-gamut HDR spaces, preventing washed-out or improperly saturated tones.
Comparative Phosphor Decay Timelines per 60Hz Guest Field
On a 240Hz monitor, a single 60Hz guest field spans across 4 host refresh cycles. The emulator uses these extra cycles to phase out the image smoothly, accurately mimicking the natural temporal decay of CRT phosphors.
Host Cycle 120Hz Monitor
(2x)		 180Hz Monitor
(3x)		 240Hz Monitor
(4x)		 360Hz Monitor
(6x)		 480Hz Monitor
(8x)		 600Hz Monitor
(10x)
Frame 1 100% Brightness 100% Brightness 100% Brightness 100% Brightness 100% Brightness 100% Brightness
Frame 2 0% (Black Frame) 40% Luminance 50% Luminance 70% Luminance 80% Luminance 85% Luminance
Frame 3 — 0% (Black Frame) 15% Luminance 45% Luminance 60% Luminance 70% Luminance
Frame 4 — — 0% (Black Frame) 20% Luminance 40% Luminance 50% Luminance
Frame 5 — — — 5% Luminance 20% Luminance 35% Luminance
Frame 6 — — — 0% (Black Frame) 8% Luminance 20% Luminance
Frame 7 — — — — 2% Luminance 10% Luminance
Frame 8 — — — — 0% (Black Frame) 4% Luminance
Frame 9 — — — — — 1% Luminance
Frame 10 — — — — — 0% (Black Frame)
Verdict Passable. Judder-free, but suffers from extreme flicker and harsh 50% duty-cycle brightness loss. Good. Clean motion, but low overall brightness and high flicker. Great to Excellent. Superb balance of decay granularity. When running at 240Hz or higher on an HDR display, the hardware peak-nit headroom fully counteracts the stroboscopic luminance drop, resulting in a flawless analog simulation.
Note on Asymmetric Refresh Rates and VRR Automation

When using host displays where the maximum refresh rate is not a perfect mathematical integer multiple of the guest field rate (e.g., 144 / 60 = 2.4, or 280 / 60 = 4.66), traditional high refresh-rate BFI techniques break down:

  • Temporal Judder: Because a single 60Hz guest frame cannot be sliced into fractional monitor refreshes, a fixed-refresh display must cycle unevenly between frames (e.g., a 3:2 or 5:4 pulldown pattern). One field stays on screen longer than the next, translating to jarring stutter during camera pans.
  • Erratic Stroboscopic Flicker: Because the physical duration of the phosphor simulation sequence varies from field to field, the display's global brightness levels constantly modulate up and down. This induces violent, highly irregular flicker that causes severe eye fatigue.

To resolve this, emulators leverage advanced display APIs (`EXT_present_timing`) to handle regional guest variations (~59.94Hz NTSC / 50Hz PAL) automatically via two distinct paths:

1. Variable Refresh Rate (VRR / G-Sync / FreeSync) Automation

If the host monitor supports VRR, the emulator does not need to force the display into a rigid, lower desktop refresh rate. Instead, it dynamically constrains the monitor's maximum refresh ceiling to match an exact integer multiple of the incoming guest signal:

  • NTSC Guest (~59.94Hz): The emulator instructs the graphics pipeline to sync the display to exactly 119.88Hz (on a 144Hz panel) or 239.76Hz (on a 280Hz panel). The phosphor decay states map perfectly into a flawless 2x or 4x container with zero motion judder.
  • PAL Guest (50.00Hz): The monitor dynamically drops its refresh rate down to exactly 100.00Hz or 200.00Hz. This entirely bypasses the asymmetric limitation of the panel's maximum spec, offering automated, stutter-free region switching.
2. Fixed Refresh Rate Fallbacks

On legacy displays or setups where VRR is disabled, the monitor operates at a rigid, unyielding clock (e.g., a flat 120Hz or 144Hz). The emulator must handle this via software adaptation:

  • The 0.05% NTSC Speedup: To align a standard 59.94Hz NTSC game with a static 120Hz display container (120 / 59.94 = 2.002), the emulator subtly adjusts the internal emulation speed (audio and video) upward by roughly 0.05% to hit a flat 60.00Hz. This aligns the fields perfectly with a 120Hz refresh grid without perceptible distortion.
  • The PAL Asymmetry Issue: Running a 50Hz PAL title on a static 120Hz container results in the same severe 2.4x frame-slicing judder as running NTSC on 144Hz. In this scenario, the emulator must actively call a display mode-switch to alter the hardware's EDID profile to a fixed 100Hz environment, or the user must manually adjust their display control panel.

FRAME Mode (The Flicker Filter)

To avoid the harsh flickering typical of interlaced video, many PS2 games rendered internally at a progressive resolution (e.g., 448p @ 30 FPS) but programmed the console's dual CRTCs (Cathode-Ray Tube Controllers) to blend two frames vertically with a 1-pixel offset. Shifting this offset every field scanned out a smoothed 60 FPS interlaced image.

  • Emulator Handling: Modern renderers can detect this pattern and scan out the full, unblurred 480p progressive frame directly. Emulators often include an "Anti-Blur" toggle to disable this original hardware blending filter for a sharper image.

FIELD Mode

Used by titles aiming for a true 60 FPS. These games sacrificed half of their vertical resolution and jittered the rendering pipeline to stay perfectly in sync with the interlaced output fields.

  • Emulator Handling: These titles absolutely require a deinterlacing solution to look acceptable on progressive screens.

Hardware Masking (SCANMSK)

Certain complex software setups natively break when forced into progressive scan. Games like King's Field IV utilize the hardware `SCANMSK` feature to intentionally discard pixels on every other line during rendering, relying on the console's `FRAME` scanout mode to accurately display only the unmasked lines. Forcing progressive scan on these titles results in severely broken or missing graphics.

References

Also see

Retrieved from "https://emulation.gametechwiki.com/index.php?title=Deinterlacing&oldid=144560"