marqs85 / ossc

Open Source Scan Converter
http://junkerhq.net/xrgb/index.php/OSSC
GNU General Public License v3.0
469 stars 63 forks source link

Feasability of "Composite Blending" filtering ? #103

Open Ybalrid opened 1 year ago

Ybalrid commented 1 year ago

Hi there!

I recently got myself an OSSC, and I am extremely happy about the result I am getting on an Amiga 500 + SCART RGB cable, and on a Sega Megadrive

The megadrive RGB signal is surprisingly crisp at least to me (despite it being a model 1 console). The results I am getting on a modern 4K TV, I could mistake them for the output of an emulator. Super sharp pixels!

Delving a bit into FPGA technology used in retrogaming, I was looking at what the MiSTer project is doing (I know, totally different thing, they are running systems on an FPGA, not doing extra low latency line doubling), and I got a bit curious about what the Genesis/MegaDrive has an option called "Composite blending". I have no first-hand experience with that option myself, but I find the idea interesting.

A lot of games on that system exploit dithering patterns and alternating pixels on foreground sprites to simulate wider color gamut and transparency. 2 things that the hardware is not technically able to do.

I know the OSSC's goal is to digitize the signal and increase resolution by just processing one line at a time and that the filtering options available in that scenario are extremely limited (basically, I understand how we can do the scanlines and the bob de-interlace methods in that scenario). I do not know how the filter is implemented on Mister, but I am wondering if, in a single line of the pixel, there is a way to try to apply that sort of "signal degradation" and to dose it somewhere in the middle between

Here's a video with a timecode that showcases some of the natural artifacts these low-quality video outputs are producing https://youtu.be/x0weL5XDpPs?t=314

I legitimately have no idea if there's space on the FPGA of the OSSC to try to add that sort of filtering after the DAC/sampling stage; I also do not know how it could be implemented exactly. I have a "vague" idea of how a post-processing shader would be able to blend colors like that. I have no clue how you would implement that with straight-up logic gates.

Any thoughts ? 🤔

marqs85 commented 1 year ago

Most likely that wouldn't need additional block RAM and could just utilize data from a couple previous samples stored in registers. The end result would probably depend on sampling rate (i.e. lineX mode), though. I can check at some point how that is implemented on the MD core, but it might take a while to get that on OSSC as the project is in its twilight years and thus not very high priority.

Ybalrid commented 1 year ago

It was just a silly thought passing in my head, and I was like "I fell like that sort of processing is doable just in one scanline?". It may be a bit counter to what the goal of this project is to try to "un-crisp" a signal because it is "too clean" 🙂

alanbork commented 1 year ago

for sure doable in just one scanline, as the blending is almost 100% horizontal. Has to do with how hard it is to change the amplification of the cathode ray gun on a per-pixel basis.

that doesn't mean the OSSC can do it, just that the effect is fundamentally a horizontal one. It's well known in the vision science community, who care if the sharpness of their test images are the same in the horizontal and vertical directions, and for various reasons continued to rely on CRTs well into the 2010s.

On Tue, Apr 25, 2023 at 3:43 PM Arthur Brainville @.***> wrote:

It was just a silly thought passing in my head, and I was like "I fell like that sort of processing is doable just in one scanline?". It may be a bit counter to what the goal of this project is to try to "un-crisp" a signal because it is "too clean" 🙂

— Reply to this email directly, view it on GitHub https://github.com/marqs85/ossc/issues/103#issuecomment-1522511268, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANPGZ5JOSLF3VW72NSSJU3LXDBHQRANCNFSM6AAAAAAWXOZ3HA . You are receiving this because you are subscribed to this thread.Message ID: @.***>