Deinterlacing: Difference between revisions
No edit summary |
No edit summary |
||
| Line 43: | Line 43: | ||
{{Main|Future of CRT simulation#Full Signal & Cable Emulation}} | {{Main|Future of CRT simulation#Full Signal & Cable Emulation}} | ||
==== High Refresh-Rate Beam Insertion (Hardware Deinterlacing) ==== | ==== High Refresh-Rate Beam Insertion (Hardware Deinterlacing) ==== | ||
Modern low-latency renderers (such as [[ | Modern low-latency renderers (such as [[paraLLEl-GS]]) experiment with bypassing traditional software deinterlacing shaders (like Bob, Blend, or motion-adaptive deinterlacing) entirely.[https://themaister.net/blog/2026/05/09/emulating-old-junk-from-yesteryear-or-my-obsession-making-native-resolution-ps2-emulation-look-good/] Instead of filtering frames in a buffer, they simulate how a CRT monitor's electron gun naturally draws interlaced fields sequentially by utilizing high-refresh-rate host displays and variable refresh rate (VRR) timing hooks. | ||
* '''Pros:''' Achieves a completely authentic CRT "hardware" deinterlacing appearance; preserves native interlaced motion characteristics without software ghosting or interpolation artifacts; eliminates sample-and-hold motion blur along moving edges because odd and even lines are physically drawn on alternating host refresh cycles. | * '''Pros:''' Achieves a completely authentic CRT "hardware" deinterlacing appearance; preserves native interlaced motion characteristics without software ghosting or interpolation artifacts; eliminates sample-and-hold motion blur along moving edges because odd and even lines are physically drawn on alternating host refresh cycles. | ||
* '''Cons:''' Extremely high display and timing accuracy requirements; can cause minor line-flicker on sharp high-contrast patterns (mirroring original CRT hardware behavior); requires precise synchronization with display presentation timing APIs. | * '''Cons:''' Extremely high display and timing accuracy requirements; can cause minor line-flicker on sharp high-contrast patterns (mirroring original CRT hardware behavior); requires precise synchronization with display presentation timing APIs. | ||
Latest revision as of 13:24, 10 July 2026
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
[edit | edit source]Algorithms
[edit | edit source]Bob Deinterlacing
[edit | edit source]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
[edit | edit source]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)
[edit | edit source]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)
[edit | edit source]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
[edit | edit source]Automatic
[edit | edit source]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
[edit | edit source]Modern emulators can now automatically toggle deinterlacing based on their index/compatibility database.
No-Interlace Patches
[edit | edit source]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
[edit | edit source]- Main article: Future of CRT simulation#Full Signal & Cable Emulation
High Refresh-Rate Beam Insertion (Hardware Deinterlacing)
[edit | edit source]Modern low-latency renderers (such as paraLLEl-GS) experiment with bypassing traditional software deinterlacing shaders (like Bob, Blend, or motion-adaptive deinterlacing) entirely.[1] Instead of filtering frames in a buffer, they simulate how a CRT monitor's electron gun naturally draws interlaced fields sequentially by utilizing high-refresh-rate host displays and variable refresh rate (VRR) timing hooks.
- Pros: Achieves a completely authentic CRT "hardware" deinterlacing appearance; preserves native interlaced motion characteristics without software ghosting or interpolation artifacts; eliminates sample-and-hold motion blur along moving edges because odd and even lines are physically drawn on alternating host refresh cycles.
- Cons: Extremely high display and timing accuracy requirements; can cause minor line-flicker on sharp high-contrast patterns (mirroring original CRT hardware behavior); requires precise synchronization with display presentation timing APIs.
- How it works: The emulator separates the incoming interlaced video into its native, independent odd and even fields. Instead of stacking or combining them digitally, it leverages high host refresh rates and `EXT_present_timing` to instantly scan out each field on alternating screen updates, manually blacking out only the inactive scanline rows for that field. Because the host display updates rapidly enough, human persistence of vision naturally weaves the alternating line passes together, executing native hardware deinterlacing without any artificial full-frame black insertion.
Understanding the Spatial Beam Timing Mechanics: Unlike software-based "Scanline Overlays" (which simply layer a static 2D grid over a progressive image) or full-frame BFI (which flashes the entire screen on and off), hardware-driven beam insertion utilizes extra host refresh cycles to simulate the fast temporal decay of individual illuminated lines:
- Luminance Percentages (%) represent the simulated light decay curve of an active scanline row before the alternating field pass occurs. Rather than holding its brightness statically until the next master frame, the shader decays individual lines to mimic analog phosphors.
- The Granularity Threshold: On a basic 120Hz setup, the emulator can only switch sharply between the odd and even line grids (100% to 0% line state per pass). Higher host refresh rates (240Hz, 360Hz, or higher) allow the shader pipeline to slice a single guest field's duration into multiple micro-steps, letting the active scanline set smoothly phase down its brightness before the next field lines illuminate.
- Perceived Image Stability: Because the global screen is never blanked out as a solid black block, there is no aggressive stroboscopic flashing. On VRR-enabled high-refresh displays, the fast alternating line-swapping results in an incredibly stable, fluid image where the classic "interlacing flicker" is confined strictly to fine horizontal details, exactly like a high-end CRT presentation monitor.
| Host Cycle | 120Hz Monitor (2x Container) |
180Hz Monitor (3x Container) |
240Hz Monitor (4x Container) |
360Hz Monitor (6x Container) |
480Hz Monitor (8x Container) |
600Hz Monitor (10x Container) |
|---|---|---|---|---|---|---|
| Slice 1 (Beam Strike) | 100% Line Brightness | 100% Line Brightness | 100% Line Brightness | 100% Line Brightness | 100% Line Brightness | 100% Line Brightness |
| Slice 2 | 0% (Line Blanked) | 40% Line Glow | 50% Line Glow | 70% Line Glow | 80% Line Glow | 85% Line Glow |
| Slice 3 | — | 0% (Line Blanked) | 15% Line Glow | 45% Line Glow | 60% Line Glow | 70% Line Glow |
| Slice 4 | — | — | 0% (Black/Blank) | 20% Line Glow | 40% Line Glow | 50% Line Glow |
| Slice 5 | — | — | — | 5% Line Glow | 20% Line Glow | 35% Line Glow |
| Slice 6 | — | — | — | 0% (Black/Blank) | 8% Line Glow | 20% Line Glow |
| Slice 7 | — | — | — | — | 2% Line Glow | 10% Line Glow |
| Slice 8 | — | — | — | — | 0% (Black/Blank) | 4% Line Glow |
| Slice 9 | — | — | — | — | — | 1% Line Glow |
| Slice 10 | — | — | — | — | — | 0% (Black/Blank) |
| Motion Verdict | Passable. Stutter-free motion, but raw transitions can cause slight raw line-crawling artifacts on fixed patterns. | Good. Decent transition blending, but line decay timeline is slightly truncated. | Excellent. Flawless analog tracking. The high sub-frame refresh ceiling completely masks individual line transitions. When running at 240Hz+ paired with VRR, the spatial interleaving simulates authentic CRT motion clarity without full-screen strobe fatigue. | |||
- HDR Luminance Compensation & Linear Mastering
To counteract the minor average brightness drop caused by keeping inactive scanline rows unlit, 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 skews color curves), 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, handing direct control of the hardware backlight headroom to the shader pipeline.
- Because high-refresh environments spread individual line decay characteristics smoothly across multiple sub-frame updates instead of cutting them to black instantly, linear HDR luminance management completely counteracts any perceived dimness penalty. The result is a vibrant, perfectly balanced analog simulation that accurately reconstructs authentic CRT phosphor color profiles and wide-gamut historical profiles (like Japan's legacy NTSC 1953 standard) without crushing fine highlight detail.
- 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.
- 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 synchronous beam techniques break down:
- Temporal Judder: Because a single 60Hz guest frame cannot be sliced evenly 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.
- Line Alternation Artifacts: If timing slices slip out of alignment, the alternating odd/even field order desynchronizes from the panel's physical refresh cadence, resulting in severe combing artifacts and image splitting.
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 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 alternating field scanlines 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)
[edit | edit source]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
[edit | edit source]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)
[edit | edit source]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.
Gallery
[edit | edit source]-
Interlaced Artifacts
Example of "combing" during high-motion scenes without deinterlacing. -
Bob Deinterlacing
Eliminates combing but introduces vertical jitter/shimmer. -
Motion-Adaptive (MAD)
Modern standard that preserves detail on static objects without shimmer. -
High Refresh-Rate Insertion
120Hz capture on 144Hz host display.
Links & Resources
[edit | edit source]- PCSX2 Motion-Adaptive PR: Pull Request #7376 Details
- Deinterlace (Bob): Basic method for low-spec hardware.
- No-Interlace Patches: PCSX2 patches repo for 480p/240p forcing.
- Theimaster's CRT sim with ParaLLEl-GS.