Emulation General Wiki

Deinterlacing: Difference between revisions

← Older editNewer edit →
undoAhayri (talk | contribs)
24,008 edits
VisualWikitext
Ahayri (talk | contribs)
24,008 edits
Ahayri (talk | contribs)
24,008 edits
Line 43: Line 43:
{{Main|Shaders, presets, and filters#Full Signal & Cable Emulation}}
{{Main|Shaders, presets, and filters#Full Signal & Cable Emulation}}
==== High Refresh-Rate Beam Insertion (Hardware Deinterlacing) ====
==== 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 and filters 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 processing frames through a software blend or motion filter, they simulate how a CRT monitor naturally scans out interlaced fields by utilizing ultra-high-refresh-rate host displays, VRR and other techniques.
Modern low-latency renderers (such as [[PlayStation_2_emulators#Emulation_issues|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 look; bypasses the need for soft interpolation filters; eliminates sample-and-hold motion blur entirely because odd and even fields are drawn natively 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:''' High computational and display requirements; causes a drop in native screen brightness on standard SDR panels; any missed frames or micro-stutter causes severe, 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, 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). By alternating odd and even scanline fields at high speed and dropping the light values over time, your eyes naturally merge the fields together: achieving authentic CRT hardware deinterlacing.
* '''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 Hardware Timeline Mechanics:'''
'''Understanding the Spatial Beam Timing Mechanics:'''
Unlike software-based "Scanline Breathing" (which is a 2D color filter layered over a standard 60Hz progressive frame), hardware-driven beam insertion utilizes the host monitor's extra refresh cycles to mimic the physical temporal decay of a CRT phosphor:
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 residual glow of a CRT phosphor after the initial electron beam strike. Instead of cutting off instantly like flat-panel LCD pixels, real CRT phosphors fade along a rapid mathematical decay curve.  
*'''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:''' At lower refresh rates (like 120Hz), the emulator can only cut the image sharply to black (100% to 0%), causing a harsh stroboscopic flicker. Higher refresh rates (240Hz, 360Hz, or higher) break a single 60Hz guest field into smaller temporal slices, allowing to smoothly step down the brightness to mirror a true analog decay timeline.
*'''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 Global Brightness:''' Human eyes integrate these rapidly flashing frames over time (persistence of vision). A higher monitor refresh rate creates a much higher "integrated duty cycle"—meaning the screen spends more time emitting varying levels of light and less time in total darkness, drastically reducing perceived dimness and eye strain.
*'''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><small>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.</small>
|+ 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 129: Line 129:
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| 1% Luminance
| 1% Line Glow
|-
|-
| '''Frame 10'''
| '''Slice 10'''
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
| {{Gray}} —
Line 137: 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 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.
| 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.
|}
|}


;[[HDR]] Luminance Compensation & Linear Mastering
;[[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.  
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.
* 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.
* 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 [[Shaders,_presets,_and_filters#Aspects_to_prioritize|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.
* '''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
;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:
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 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.
* '''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.
* '''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.
* '''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.


Retrieved from "https://emulation.gametechwiki.com/index.php/Deinterlacing"