| |
ChristopherJam
Registered: Aug 2004
Posts: 1408 |
Christopher Jam's composite video measurements
I spent a month or two back around the start of 2015 measuring the composite video output of a new luminance c64 using a 100MHz USB oscilloscope, then trying to reproduce the output waveform using a simple predictive model.
Before I started, I had this crazy idea that I could use the fragments of chroma signals from each pixel to manufacture new colours, on the assumption that each pixel would be a well defined slice of a sinewave. Ahahahaha. Nothing so simple. Chroma takes several pixels to start up and shut down again, and the luma signal rings visibly for four or five pixels.
I do now however have a pretty accurate model of the luma behaviour, and my chroma model is not far off.
Some pretty graphs and test images at http://jamontoads.net/p/lumachroma.html
Here's a teaser
and a palette :)
jampal=[000000, ffffff, 7d202c, 4fb3a5, 84258c, 339840, 2a1b9d, bfd04a, 7f410d, 4c2e00, b44f5c, 3c3c3c, 646464, 7ce587, 6351db, 939393] |
|
| |
Krill
Registered: Apr 2002
Posts: 2968 |
Good job!
Apart from the palette, can the model you deduced be (easily) included with emulators to improve render fidelity? |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1408 |
Quoting KrillGood job!
Thanks!
Quote:Apart from the palette, can the model you deduced be (easily) included with emulators to improve render fidelity?
Nontrivial in its current state.
I'm pretty sure I can get the signal reproduction down to four table lookups per pixel, each one indexed by a run of three pixels (or one two-byte lookup indexed by the last five pixel indices), but that just generates a two sample per pixel composite signal that would still need converting to YUV, chroma averaged, then RGB converted.
The composite->YUV filters I'm using at the moment are several pixels wide, so a direct translation would be fairly slow. More maths to be done.. |
| |
lft
Registered: Jul 2007
Posts: 369 |
But graphics cards are fast. Sounds like a straightforward job for a pixel shader. |
| |
Jammer
Registered: Nov 2002
Posts: 1335 |
Splendid! So this or Colodore? ;) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11350 |
did you actually use composite? and if yes, why? =)
it would also be interesting to know what video chip exactly you used... and then re-do the measurements on different chips. i am willing to bet there are quite some differences :) |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
very cool you did that =) in some of the example pictures the "distortion" feels like those on true CRT. |
| |
soci
Registered: Sep 2003
Posts: 479 |
View64's PAL/NTSC mode generates luminance and chrominance "signals" and feeds them it into a decoder. The signal generation part is a bit simplistic currently and this bothered me for a while.
Therefore these measurements are really interesting. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11350 |
the renderers i wrote for testing also work like this... i was lazy though and used some filter implementations i found somewhere on the net which are not really suitable for realtime signal processing so its all really slow =) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1408 |
Quoting lftBut graphics cards are fast. Sounds like a straightforward job for a pixel shader.
Yes I've been wondering about that. Attempting one has been on my todo list for over 18 months now though, so I should just release a slow reference implementation and let someone else have a bash at making it faster..
Quoting Groepazdid you actually use composite? and if yes, why? =)
haha yes! Um, I wasn't getting any signal at all from the chroma pin on the c64 in question. Besides, composite's the only input on the front of my nicest CRT, so it's how I view things anyway..
Quote:it would also be interesting to know what video chip exactly you used... and then re-do the measurements on different chips. i am willing to bet there are quite some differences :)
Yes, differences seem likely. This was a nine luminance one in an assembly where I'd need to unscrew the keyboard to even get to the heatsink/shielding that's covering the chips.. And that c64 has stopped working properly sometime since I took the measurements.. (powers up and displays " OUT OF MEMORY ERROR IN 0" I'm a bit scared to plug my MMC reader into it..)
Quoting sociView64's PAL/NTSC mode generates luminance and chrominance "signals" and feeds them it into a decoder. The signal generation part is a bit simplistic currently and this bothered me for a while.
Therefore these measurements are really interesting.
Ah, nice. Ok, I will try and finish bundling up the code and data for release. |
| |
pepto
Account closed
Registered: Nov 2004
Posts: 35 |
Quoting ChristopherJamI do now however have a pretty accurate model of the luma behaviour, and my chroma model is not far off
These sloppy signal observations are interesting... congrats on finally publishing the results of your experiments. :)
Quoting JammerSplendid! So this or Colodore? ;)
It doesn't really matter that much, as colodore isn't really ONE EXCLUSIVE palette. You may tune it by altering the brightness, contrast and saturation sliders, just like on real equipment. This way you should be able to match captured palettes (there are small lot-to-lot variations). For example here's a quick attempt to tune colodore (47/85/66 - top) by eyesight to somewhat match Christopher's palette (bottom).
 |
... 11 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 - Next |
