Deinterlacing: Difference between revisions

Line 45:

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.

* '''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 drop in screen brightness; any missed frames or micro-stutter causes severe, highly visible flickering.

* '''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 ([[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 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).

* '''[[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 [[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.

{| class="wikitable" style="margin-left: 20px; text-align: center;"

|+ 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

|+ 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)

Line 55:

Line 59:

| 100% Brightness

| 100% Brightness (HDR Boost Available)

| 100% Brightness

| 100% Brightness (HDR Boost Available)

| 100% Brightness

| 100% Brightness (HDR Boost Available)

| 100% Brightness

| 100% Brightness (HDR Boost Available)

|-

| '''Frame 2'''

Line 135:

Line 139:

| {{Orange}} '''Passable.''' Judder-free, but suffers from extreme flicker and harsh 50% duty-cycle brightness loss.

| {{Yellow}} '''Good.''' Clean motion, but low overall brightness and high flicker.

| colspan=4 {{Green}} '''Great.''' ~~Excellent~~ balance of decay granularity ~~and brightness~~.

| 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.

|}

Note on Asymmetric Refresh Rates and VRR Automation

;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.

Line 147:

Line 152:

* '''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:

@@ Line 45: / Line 45: @@
 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.
 * '''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 drop in screen brightness; any missed frames or micro-stutter causes severe, highly visible flickering.
+* '''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 ([[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 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).
+* '''[[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 [[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.
 {| 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 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>
 |-
 ! 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>
@@ Line 55: / Line 59: @@
 | 100% Brightness
 | 100% Brightness
-| 100% Brightness
+| 100% Brightness<br><small>(HDR Boost Available)</small>
-| 100% Brightness
+| 100% Brightness<br><small>(HDR Boost Available)</small>
-| 100% Brightness
+| 100% Brightness<br><small>(HDR Boost Available)</small>
-| 100% Brightness
+| 100% Brightness<br><small>(HDR Boost Available)</small>
 |-
 | '''Frame 2'''
@@ Line 135: / Line 139: @@
 | {{Orange}} '''Passable.''' Judder-free, but suffers from extreme flicker and harsh 50% duty-cycle brightness loss.
 | {{Yellow}} '''Good.''' Clean motion, but low overall brightness and high flicker.
-|  colspan=4 {{Green}} '''Great.''' Excellent balance of decay granularity and brightness.
+| 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.
 |}
-Note on Asymmetric Refresh Rates and VRR Automation
+;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.
@@ Line 147: / Line 152: @@
 * '''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: