Emulation General Wiki

Deinterlacing: Difference between revisions

← Older edit
undoAhayri (talk | contribs)
24,008 edits
VisualWikitext
Ahayri (talk | contribs)
24,008 edits
Ahayri (talk | contribs)
24,008 edits
No edit summary
 
(12 intermediate revisions by the same user not shown)
Line 1: Line 1:
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 [[Shaders,_presets,_and_filters|shader-based solutions]], emulator's built-in deinterlacing methods provide better results on image quality.
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 [[Shaders_and_filters#Deinterlacing|shader-based solutions]], emulator's built-in deinterlacing methods provide better results on image quality.


==Before diving in==
==Before diving in==
Line 41: Line 41:


=== CRT Simulation===
=== CRT Simulation===
{{Main|Shaders, presets, and filters#Full Signal & Cable Emulation}}
{{Main|Future of CRT simulation#Full Signal & Cable Emulation}}
==== High Refresh-Rate Insertion ====
==== High Refresh-Rate Beam Insertion (Hardware Deinterlacing) ====
Modern low-latency renderers (such as [[PlayStation_2_emulators#Emulation_issues|paraLLEl-GS]]) experiment with bypassing traditional software deinterlacing shaders entirely.[https://themaister.net/blog/2026/05/09/emulating-old-junk-from-yesteryear-or-my-obsession-making-native-resolution-ps2-emulation-look-good/] Instead, they simulate how a CRT monitor naturally displays interlaced fields by utilizing high-refresh-rate displays and [[Black_frame_insertion|Black Frame Insertion]] (BFI) techniques.
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 "deinterlacing" look; bypasses the need for soft interpolation filters; eliminates sample-and-hold motion blur.
* '''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:''' High computational and display requirements; causes a drop in screen brightness; any missed frames or micro-stutter causes severe, highly visible flickering.
* '''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 simulates each interlaced field independently with scanlines ([[Shaders,_presets,_and_filters#Aspects_to_prioritize|interlacing flicker]]). By leveraging high-refresh-rate host displays (e.g., 120Hz, 240Hz, or 360Hz), 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).
* '''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.
 
{| class="wikitable" style="margin-left: 20px; text-align: center;"
{| class="wikitable" style="margin-left: 20px; text-align: center;"
|+ Comparative Phosphor Decay Timelines per 60Hz Guest Field<br>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
|+ Comparative Scanline Field Decay Timelines per 60Hz Guest Field<br><small>Shows the simulated light decay behavior of an active scanline row across consecutive host refresh cycles before the alternating field takes over.</small>
|-
|-
! Host Cycle !! 120Hz Monitor<br><small>(2x)</small> !! 180Hz Monitor<br><small>(3x)</small> !! 240Hz Monitor<br><small>(4x)</small> !! 360Hz Monitor<br><small>(6x)</small> !! 480Hz Monitor<br><small>(8x)</small> !! 600Hz Monitor<br><small>(10x)</small>
! Host Cycle !! 120Hz Monitor<br><small>(2x Container)</small> !! 180Hz Monitor<br><small>(3x Container)</small> !! 240Hz Monitor<br><small>(4x Container)</small> !! 360Hz Monitor<br><small>(6x Container)</small> !! 480Hz Monitor<br><small>(8x Container)</small> !! 600Hz Monitor<br><small>(10x Container)</small>
|-
|-
| '''Frame 1'''
| '''Slice 1 (Beam Strike)'''
| 100% Brightness
| 100% Line Brightness
| 100% Brightness
| 100% Line Brightness
| 100% Brightness
| 100% Line Brightness
| 100% Brightness
| 100% Line Brightness
| 100% Brightness
| 100% Line Brightness
| 100% Brightness
| 100% Line Brightness
|-
|-
| '''Frame 2'''
| '''Slice 2'''
| {{Black}} 0% (Black Frame)
| {{Black}} 0% (Line Blanked)
| 40% Luminance
| 40% Line Glow
| 50% Luminance
| 50% Line Glow
| 70% Luminance
| 70% Line Glow
| 80% Luminance
| 80% Line Glow
| 85% Luminance
| 85% Line Glow
|-
|-
| '''Frame 3'''
| '''Slice 3'''
| {{Gray}} —
| {{Gray}} —
| {{Black}} 0% (Black Frame)
| {{Black}} 0% (Line Blanked)
| 15% Luminance
| 15% Line Glow
| 45% Luminance
| 45% Line Glow
| 60% Luminance
| 60% Line Glow
| 70% Luminance
| 70% Line Glow
|-
|-
| '''Frame 4'''
| '''Slice 4'''
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| {{Black}} 0% (Black Frame)
| {{Black}} 0% (Black/Blank)
| 20% Luminance
| 20% Line Glow
| 40% Luminance
| 40% Line Glow
| 50% Luminance
| 50% Line Glow
|-
|-
| '''Frame 5'''
| '''Slice 5'''
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| 5% Luminance
| 5% Line Glow
| 20% Luminance
| 20% Line Glow
| 35% Luminance
| 35% Line Glow
|-
|-
| '''Frame 6'''
| '''Slice 6'''
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| {{Black}} 0% (Black Frame)
| {{Black}} 0% (Black/Blank)
| 8% Luminance
| 8% Line Glow
| 20% Luminance
| 20% Line Glow
|-
|-
| '''Frame 7'''
| '''Slice 7'''
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| 2% Luminance
| 2% Line Glow
| 10% Luminance
| 10% Line Glow
|-
|-
| '''Frame 8'''
| '''Slice 8'''
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| {{Black}} 0% (Black Frame)
| {{Black}} 0% (Black/Blank)
| 4% Luminance
| 4% Line Glow
|-
|-
| '''Frame 9'''
| '''Slice 9'''
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
Line 122: Line 129:
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| 1% Luminance
| 1% Line Glow
|-
|-
| '''Frame 10'''
| '''Slice 10'''
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
Line 130: Line 137:
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| {{Black}} 0% (Black Frame)
| {{Black}} 0% (Black/Blank)
|-
|-
! style="text-align: left;" | Verdict
! style="text-align: left;" | Motion Verdict
| {{Orange}} '''Passable.''' Judder-free, but suffers from extreme flicker and harsh 50% duty-cycle brightness loss.
| {{Orange}} '''Passable.''' Stutter-free motion, but raw transitions can cause slight raw line-crawling artifacts on fixed patterns.
| {{Yellow}} '''Good.''' Clean motion, but low overall brightness and high flicker.
| {{Yellow}} '''Good.''' Decent transition blending, but line decay timeline is slightly truncated.
| colspan=4 {{Green}} '''Great.''' Excellent balance of decay granularity and brightness.
| colspan="4" {{Green}} '''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.
|}
|}
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:
;[[HDR]] Luminance Compensation & Linear Mastering
* '''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.
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.
* '''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.
* 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:
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
;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:
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 phosphor decay states map perfectly into a flawless 2x or 4x container with zero motion judder.
* '''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.
* '''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
;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:
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:
Line 168: Line 182:
File:Bob_Deinterlace_Example.png|'''Bob Deinterlacing'''<br>Eliminates combing but introduces vertical jitter/shimmer.
File:Bob_Deinterlace_Example.png|'''Bob Deinterlacing'''<br>Eliminates combing but introduces vertical jitter/shimmer.
File:Yadif_Deinterlace_Example.png|'''Motion-Adaptive (MAD)'''<br>Modern standard that preserves detail on static objects without shimmer.
File:Yadif_Deinterlace_Example.png|'''Motion-Adaptive (MAD)'''<br>Modern standard that preserves detail on static objects without shimmer.
File:ParaLLEl-GS - 1x + CRT sim with High Refresh-Rate Insertion - WE9.webm|'''High Refresh-Rate Insertion'''<br>120Hz capture on 144Hz host display.
</gallery>
</gallery>


Line 183: Line 198:
*[[Shaders, presets, and filters]]
*[[Shaders, presets, and filters]]
*[[Black frame insertion]]
*[[Black frame insertion]]
*[[High dynamic range]]


[[Category:FAQs]]
[[Category:FAQs]]
Retrieved from "https://emulation.gametechwiki.com/index.php/Deinterlacing"