Deinterlacing: Difference between revisions

Line 43:

{{Main|Shaders, presets, and filters#Full Signal & Cable Emulation}}

==== High Refresh-Rate Insertion ====

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

Modern low-latency renderers (such as [[PlayStation_2_emulators#Emulation_issues|paraLLEl-GS]]) experiment with bypassing traditional software deinterlacing shaders entirely. 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.

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

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

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

|+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 ~~Frame~~ !! ~~Display State~~ !! ~~Purpose~~

! Host Cycle !! 120Hz Monitor (2x) !! 180Hz Monitor (3x) !! 240Hz Monitor (4x) !! 360Hz Monitor (6x) !! 480Hz Monitor (8x) !! 600Hz Monitor (10x)

|-

| '''Frame 1''' || 100% Brightness || ~~The initial electron gun strike (Odd or Even lines)~~

| '''Frame 1'''

| 100% Brightness

|-

| '''Frame 2''' || 50% Luminance || ~~Simulating the natural decay of the CRT phosphor~~

| '''Frame 2'''

| {{Black}} 0% (Black Frame)

| 40% Luminance

| 50% Luminance

| 70% Luminance

| 80% Luminance

| 85% Luminance

|-

| '''Frame 3''' || 15% Luminance || ~~Deepening the fade~~

| '''Frame 3'''

| {{Gray}} —

| {{Black}} 0% (Black Frame)

| 15% Luminance

| 45% Luminance

| 60% Luminance

| 70% Luminance

|-

| '''Frame 4''' || 0% (Black Frame) || ~~Total blanking before the next field arrives~~

| '''Frame 4'''

| {{Gray}} —

| {{Black}} 0% (Black Frame)

| 20% Luminance

| 40% Luminance

| 50% Luminance

|-

| '''Frame 5'''

| {{Gray}} —

| 5% Luminance

| 20% Luminance

| 35% Luminance

|-

| '''Frame 6'''

| {{Gray}} —

| {{Black}} 0% (Black Frame)

| 8% Luminance

| 20% Luminance

|-

| '''Frame 7'''

| {{Gray}} —

| 2% Luminance

| 10% Luminance

|-

| '''Frame 8'''

| {{Gray}} —

| {{Black}} 0% (Black Frame)

| 4% Luminance

|-

| '''Frame 9'''

| {{Gray}} —

| 1% Luminance

|-

| '''Frame 10'''

| {{Gray}} —

| {{Black}} 0% (Black Frame)

|-

! style="text-align: left;" | Verdict

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

| {{Green}} '''Great.''' Excellent balance of decay granularity and brightness.

| {{Green}} '''Excellent.''' Ultra-smooth simulation, lowest perceived flicker.

| {{Green}} '''Reference Grade.''' Absolute parity with authentic CRT phosphor decay dynamics.

| {{Green}} '''True Analog Simulation.''' Flawless, near-continuous lighting decay curve with maximum brightness retention.

|}

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 \div 60 = 2.4$, or $280 \div 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, emulator can leverage advanced display APIs (`EXT_present_timing`) to handle regional guest variations (~59.94Hz NTSC / 50Hz PAL) automatically via two distinct paths:

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.

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 \div 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) ====

@@ Line 43: / Line 43: @@
 {{Main|Shaders, presets, and filters#Full Signal & Cable Emulation}}
 ==== High Refresh-Rate Insertion ====
-Modern low-latency renderers (such as [[PlayStation_2_emulators#Emulation_issues|paraLLEl-GS]]) experiment with bypassing traditional software deinterlacing shaders entirely. Instead, they simulate how a CRT monitor naturally displays interlaced fields by utilizing high-refresh-rate displays and Black Frame Insertion (BFI) techniques.
+Modern low-latency renderers (such as [[PlayStation_2_emulators#Emulation_issues|paraLLEl-GS]]) experiment with bypassing traditional software deinterlacing shaders entirely. 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.
 * '''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).
-{| class="wikitable" style="margin-left: 20px;"
+{| class="wikitable" style="margin-left: 20px; text-align: center;"
-|+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>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 Frame !! Display State !! Purpose
+! 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>
 |-
-| '''Frame 1''' || 100% Brightness || The initial electron gun strike (Odd or Even lines)
+| '''Frame 1'''
+| 100% Brightness
+| 100% Brightness
+| 100% Brightness
+| 100% Brightness
+| 100% Brightness
+| 100% Brightness
 |-
-| '''Frame 2''' || 50% Luminance || Simulating the natural decay of the CRT phosphor
+| '''Frame 2'''
+| {{Black}} 0% (Black Frame)
+| 40% Luminance
+| 50% Luminance
+| 70% Luminance
+| 80% Luminance
+| 85% Luminance
 |-
-| '''Frame 3''' || 15% Luminance || Deepening the fade
+| '''Frame 3'''
+| {{Gray}} —
+| {{Black}} 0% (Black Frame)
+| 15% Luminance
+| 45% Luminance
+| 60% Luminance
+| 70% Luminance
 |-
-| '''Frame 4''' || 0% (Black Frame) || Total blanking before the next field arrives
+| '''Frame 4'''
+| {{Gray}} —
+| {{Gray}} —
+| {{Black}} 0% (Black Frame)
+| 20% Luminance
+| 40% Luminance
+| 50% Luminance
+|-
+| '''Frame 5'''
+| {{Gray}} —
+| {{Gray}} —
+| {{Gray}} —
+| 5% Luminance
+| 20% Luminance
+| 35% Luminance
+|-
+| '''Frame 6'''
+| {{Gray}} —
+| {{Gray}} —
+| {{Gray}} —
+| {{Black}} 0% (Black Frame)
+| 8% Luminance
+| 20% Luminance
+|-
+| '''Frame 7'''
+| {{Gray}} —
+| {{Gray}} —
+| {{Gray}} —
+| {{Gray}} —
+| 2% Luminance
+| 10% Luminance
+|-
+| '''Frame 8'''
+| {{Gray}} —
+| {{Gray}} —
+| {{Gray}} —
+| {{Gray}} —
+| {{Black}} 0% (Black Frame)
+| 4% Luminance
+|-
+| '''Frame 9'''
+| {{Gray}} —
+| {{Gray}} —
+| {{Gray}} —
+| {{Gray}} —
+| {{Gray}} —
+| 1% Luminance
+|-
+| '''Frame 10'''
+| {{Gray}} —
+| {{Gray}} —
+| {{Gray}} —
+| {{Gray}} —
+| {{Gray}} —
+| {{Black}} 0% (Black Frame)
+|-
+! style="text-align: left;" | Verdict
+| {{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.
+| {{Green}} '''Great.''' Excellent balance of decay granularity and brightness.
+| {{Green}} '''Excellent.''' Ultra-smooth simulation, lowest perceived flicker.
+| {{Green}} '''Reference Grade.''' Absolute parity with authentic CRT phosphor decay dynamics.
+| {{Green}} '''True Analog Simulation.''' Flawless, near-continuous lighting decay curve with maximum brightness retention.
 |}
+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 \div 60 = 2.4$, or $280 \div 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, emulator can leverage advanced display APIs (`EXT_present_timing`) to handle regional guest variations (~59.94Hz NTSC / 50Hz PAL) automatically via two distinct paths:
+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.
+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 \div 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) ====