| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
colodore is the new pepto
Hey guys, I remeasured the video-signals of my VIC-II's and slightly updated my 15 year old attempt at calculating an rgb-clone. While at it, I also measured VIC & TED and made a little website about it, that allows you to adjust brightness, contrast and saturation as you like and then save your own custom palette to a png-file.
http://www.colodore.com
I took extra care to make sure, that the brightness, contrast and saturation sliders behave the same way as my 1084s.
While closely comparing my LCD to the 1084s, I found that making the transparency of scanlines dependent on YUV's Y (so they are less visible for brighter colors) looked a lot more like the real thing. I also noticed that the phase-shift on odd-lines happens for YUV's V only and there's even a name for it in video-lingua: hanover bars.
After implementing this, I'm happy to say that the images on my LCD and 1084s are remarkably close.
I will write a more detailed article about it in January, but seriously need a christmas-break first...
Cheers,
pepto |
|
| |
chatGPZ
Registered: Dec 2001 Posts: 11350 |
cool! just a little bit too late for VICE3.0 - but hey, smart people use the nightlies anyway :=) can't wait for your article, i am curious what exactly has to be changed in VICE :)
edit: please also add PAL/NTSC ... ie the "tuned" sony decoder matrix, it makes a huge difference for NTSC colors :) |
| |
Moloch
Registered: Jan 2002 Posts: 2924 |
NTSC/PAL would be a great addition |
| |
Jammer
Registered: Nov 2002 Posts: 1335 |
It surely resembles Lemming's recordings more than before. Good work! :) |
| |
chatGPZ
Registered: Dec 2001 Posts: 11350 |
btw, iirc VICE currently uses U only for the hanover bars... dont recall why :)
i really like how cranking up the color intensity doesnt make blue red-ish anymore. \o/ |
| |
MagerValp
Registered: Dec 2001 Posts: 1074 |
Fantastic news, can't wait for the details! |
| |
Oswald
Registered: Apr 2002 Posts: 5086 |
changing the output while the slider is dragged would be so much better. now its bleehh :P |
| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
@Oswald: The output changes for me while the slider is dragged, on Chrome, Safari, Firefox, Internet Explorer 9+ and Edge. What browser are you using? |
| |
ChristopherJam
Registered: Aug 2004 Posts: 1408 |
Good to see you back, pepto!
I too have been doing some video signal measurements. I really need to get my arse into gear about publishing the results of my experiments from back in January; it'll be interesting to compare them to yours. |
| |
Oswald
Registered: Apr 2002 Posts: 5086 |
Quote: @Oswald: The output changes for me while the slider is dragged, on Chrome, Safari, Firefox, Internet Explorer 9+ and Edge. What browser are you using?
ah now I see, it does change, bout only every 1.5 seconds :D |
| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
Quote: ah now I see, it does change, bout only every 1.5 seconds :D
It does calculate 64000 rgb-values from yuv on each slider-tick in Javascript, which works "pretty fluid" on my 6 year old laptop. 1.5 seconds sounds really lousy though. :-/
Good news is that I plan to port the "yuv to rgb" code to WebGL in the future, which should make things snappy, in case you have some sort of GPU in your machine that is. |
| |
Oswald
Registered: Apr 2002 Posts: 5086 |
dunno what causes it, this lappy happily runs skyrim otherwise. FF v 50.
ah, much faster in chrome roughly 10 fps. |
| |
v3to
Registered: Feb 2005 Posts: 150 |
Excellent :) In addition to Moloch, I'd love to see old vic2 lumas too. |
| |
hedning
Registered: Mar 2009 Posts: 4720 |
Really great! Exactly how the C64 emulation and all screenshots on csdb should be. |
| |
JackAsser
Registered: Jun 2002 Posts: 2014 |
Quote: Excellent :) In addition to Moloch, I'd love to see old vic2 lumas too.
There is a checkbox in options if you choose VIC-II. |
| |
v3to
Registered: Feb 2005 Posts: 150 |
@Jackasser: Found :) Thanks |
| |
Carrion
Registered: Feb 2009 Posts: 317 |
wow
and I'm honoured that my TED pics are used for this.
hopefully it can be implemented in C+4 emulators too.
great job. |
| |
ptoing
Registered: Sep 2005 Posts: 271 |
Awesome. I would love if you could also input the numbers, not just drag them, as that can be a bit fiddly on slower systems. |
| |
Bitbreaker
Registered: Oct 2002 Posts: 504 |
Can i ask for an upload function for own .prgs to check the boob compatibility? :-D Also: Why no NUFLI? |
| |
Carrion
Registered: Feb 2009 Posts: 317 |
Quote: Can i ask for an upload function for own .prgs to check the boob compatibility? :-D Also: Why no NUFLI?
well. DK's Deus Ex Machine is probably NUFLI because of no Flixor.
If not then pls change the screenshot to proper one ;) |
| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
Quote: Can i ask for an upload function for own .prgs to check the boob compatibility? :-D Also: Why no NUFLI?
...boob compatibility sure sounds like a crowdpleaser, noted... ;o)
I picked some of my fav "recent" pics from artists whose work I admire... didn't really look at the formats they were done in... |
| |
Mirage
Registered: Jan 2003 Posts: 113 |
Nice to see more progress in this area. Thank you! |
| |
saimo
Registered: Aug 2009 Posts: 36 |
This is so utterly cool. Many thanks for the great effort, pepto!
Be aware that you just made me spend a whole night remapping *all* the graphics I ever produced (admittedly not much, but some were a real pain) - after, of course, updating the VICE, Personal Paint, and Gimp palettes, and my own custom conversion tools. (I shiver at the thought of when v2 will be out.) |
| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
Thanks for the kind words! :)
It runs completely client-side btw. (even creating the png-files), so BitBreaker - if you want to check boob-compatibility, you could just put any pixels into images.js locally and drag the index.html into your browser-window...
http://www.colodore.com/colodore_v1.zip
Images are just base64 encoded streams of palette indices (4 bits per pixel for VIC and VIC II, 8 bits for TED) in either 160 or 320 pixels width and for 200 lines. |
| |
STE'86
Registered: Jul 2009 Posts: 274 |
On behalf of all the oldschool artists who have ever crossed swords with the "palette mafia" on here...
"WE TOLD YOU SO!"
sometimes I think there may be a God afterall. |
| |
MagerValp
Registered: Dec 2001 Posts: 1074 |
|
| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
Well, you could crank up brightness & contrast and turn off the scanlines and colodore would look a lot more like ste... :) |
| |
v3to
Registered: Feb 2005 Posts: 150 |
'Fire' by Joe, 'Still Waiting' by Carrion:
left PEPTO
right COLODORE (new vic with 50% saturation)
'Deadlock Loader' by Robin Levy:
top left PEPTO
down left STE'86
top right COLODORE (new vic with 50% saturation)
middle right COLODORE (new vic with 70% saturation)
down right COLODORE (old vic with 70% saturation)
|
| |
Digger
Registered: Mar 2005 Posts: 427 |
@Pepto: Superb work! It seems even more accurate than your previous one, especially with luminance order for the "PAL" color pairs. Also quite interesting how you came up with realtime re-calculation on each slider change.
I can now "rip" and update the palette for https://og2t.github.io/retro-palette-explorer/ (that uses your luma values for sorting)
I'd suggest opensourcing Colodore on http://github.com for ppl to contribute features (i.e. download the palette as .act or .json format, display the image 1:1 pixel size etc.) |
| |
chatGPZ
Registered: Dec 2001 Posts: 11350 |
Quote:Also quite interesting how you came up with realtime re-calculation on each slider change.
that btw was possible in VICE since years.... except in the win32 port :) |
| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
I just added the ability to save palettes as .act files as well. This should help some Photoshop users that had problems handling palettes in png-format, who contacted me via pm.
You may have to refresh your browser-cache to see the new menu-funtion. |
| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
Quote: @Pepto: Superb work! It seems even more accurate than your previous one, especially with luminance order for the "PAL" color pairs. Also quite interesting how you came up with realtime re-calculation on each slider change.
I can now "rip" and update the palette for https://og2t.github.io/retro-palette-explorer/ (that uses your luma values for sorting)
I'd suggest opensourcing Colodore on http://github.com for ppl to contribute features (i.e. download the palette as .act or .json format, display the image 1:1 pixel size etc.)
Thanks for your feedback.
I'm not sure I would want it on github. It is open-source already (just view source in your browser) and everyone's invited to implement their own version, if they feel like it. Additionally, I will write a small technical document, about how it basically works, in January.
I think I would hate if other ppl just implemented new features in strange places. I would get lost in my own source-code and also my aim was, to have a clean ui that doesn't get in your way. I'm not sure everyone would respect that, if it's a project on github.
But thanks for the suggestion, I will certainly give it some further thought. |
| |
Digger
Registered: Mar 2005 Posts: 427 |
@Pepto: If you opensource on github, ppl can only fork it and make their own versions. Then it's always up to you to merge their changes only if:
1) they've specifically sent you a pull request
2) you liked their contributions
But I know that GitHub culture is not very popular amongst C64 scene folk, and that's quite understandable :-)
Looking fwd to your tech doc in Jan. |
| |
Mr. SID
Registered: Jan 2003 Posts: 424 |
With the default settings, it seems like the white on the webpage is actually #ffffff, but when I save the PNG, white is #fefefe. Any idea why? Screwed by color space, or just a rounding error?
Also, saving to ACT doesn't actually work for me, nothing happens when I click it (Safari, macOS Sierra). |
| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
Quote: With the default settings, it seems like the white on the webpage is actually #ffffff, but when I save the PNG, white is #fefefe. Any idea why? Screwed by color space, or just a rounding error?
Also, saving to ACT doesn't actually work for me, nothing happens when I click it (Safari, macOS Sierra).
Ah, I parseInt() it in the png-writer, maybe I should Math.round() it... i will investigate. I'm running Safari on macOS Mavericks and it works just fine, I'll have to see how I'm able to check what Sierra's problem is. Maybe a suspicious file-suffix? Is there an option to download only "safe" files or something stupid like that? As far as I can see, I'm building it the same way as the png-file -- it doesn't have it's own mime-type like png (image/png) though, it's an "octet-stream"...
Thanks for the feedback! |
| |
Mr. SID
Registered: Jan 2003 Posts: 424 |
I have no idea, but it doesn't even try to download. Works fine in e.g. Firefox. FWIW, the .act also has #fefefe for white. |
| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
Quote: I have no idea, but it doesn't even try to download. Works fine in e.g. Firefox. FWIW, the .act also has #fefefe for white.
...should be #ffffff now... |
| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
Quote: ...should be #ffffff now...
Don't tell @saimo though, noone will notice anyway... ;) |
| |
saimo
Registered: Aug 2009 Posts: 36 |
Quote: Don't tell @saimo though, noone will notice anyway... ;)
Too late.
I feel idiot. No, wait: superidiot. I guess that the palette download option has been up there all the time, right? Guess what? I had not even noticed there was a menu. So I had grabbed the palette manually. And I did notice that black was #000100 and white was #FCFFFB, but I thought that the measuraments had revealed that the actual output isn't perfectly pure.
OMG, if I think that I have to redo it all again (I had gone as far as redefining the colors also in webpages like https://retream.itch.io/quod-init-exit-iim)... 8o |
| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
Quote: Too late.
I feel idiot. No, wait: superidiot. I guess that the palette download option has been up there all the time, right? Guess what? I had not even noticed there was a menu. So I had grabbed the palette manually. And I did notice that black was #000100 and white was #FCFFFB, but I thought that the measuraments had revealed that the actual output isn't perfectly pure.
OMG, if I think that I have to redo it all again (I had gone as far as redefining the colors also in webpages like https://retream.itch.io/quod-init-exit-iim)... 8o
Dude, chillax... this whole thing is all about that there is not ONE ULTIMATE rgb-clone of the VIC II palette. The defaults you see when the page is loaded, are what I feel looks like MY Commodore 1084s. If you move one of the sliders for one pixel, you will have several colors go off in all kinds of directions while it is rounded into 8 bit rgb-values again.
colodore is about what YOU feel looks right. Set the sliders so you like the result, that's what ppl with real equipment do and EVERYONE does this differently, as it's a matter of personal taste.
There's no one-fits-all palette and I only have defaults, because you have to start with something. Please don't write the rgb-values somewhere and think "this is colodore". It should be different for everyone else. It's important that the colors are generated on the same underlying logic, so their relation fits.
Besided, the luma-values in the calculation are exactly the same as in my research from 2001. The reason they may appear a bit different now, is that there's a contrast-slider here and I scrolled it a tiny notch to the right for the defaults, as this looks more like on my 1084s. Contrast affects the luma-values of course.
Sorry if this was in any way misleading, maybe you should wait for the tech-doc in January. :-/ |
| |
saimo
Registered: Aug 2009 Posts: 36 |
Hehe... Sure, pepto ;) It's just that your study defines a (new) virtual standard, and I like the idea of sticking to something that everyone can refer to. Practical case: if I see someone playing the game on an emulator with terribly sick colors (like, red darker than brown), I can provide a respectable reference for him/her to enjoy.
The rest is only my sick perfectionism (which now just pushed me to update again also my FB profile picture) :p |
| |
chatGPZ
Registered: Dec 2001 Posts: 11350 |
what he said is THE big problem with "the pepto palette" :) a lot of people dont understand that such thing does not exist, and that you are supposed to adjust it to your liking.
VICE btw uses the luma values from marko makälas measurements, and they will be different depending on what videochip you are emulating - just like different C64s look different too. and if you dont like it - adjust it :) |
| |
Hein
Registered: Apr 2004 Posts: 942 |
Thanks, added the default to my PS swatches, let's see how creating mock-ups goes. |
| |
willymanilly Account closed
Registered: Jan 2016 Posts: 27 |
Nice work Pepto! I've already peeked at your source code and have started using some of that logic in my emulator Z64k. I look forward to your article in the new year. Enjoy the Christmas break. :) |
| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
Thank you... :)
OK, after getting some vibes via pm, that it might be upsetting for some guys that there isn't one ultimate "answer" to the urge to finally have one set of rgb-values to rely on, I decided to write down some thoughts - sorry for getting in tl:dr territory.
I do realize people like standards and a settled environment. I also get perfectionism (can you tell from the colodore-ui, that I like pairs of three and aligned things?), but even if this might make things more complicated in some situations, I think getting BACK the freedom to tweak things like on a real setup, is actually a relief - something I really missed when using emulators and such.
The perfectionist in me actually doesn't like "Hanover Bars" that much, they f*ck up yellow so that it looks greenish. The reason I included them (even by default) is, that they are a "display setting" and don't affect the palette colors at all. Yellow actually looks different depending if you are on even or odd lines and you can't depend on that either, because someone might scroll your graphics. Some TV sets even have built in hardware to further mix the color-portion of even and odd lines, in order to hide Hanover Bars. You may just deactivate them in the colodore-options, if you don't want them to be part of your display.
If there's one thing I can say obout my original C64 and C1084s, it's that graphics look GREAT on it - I really LOVE how it looks <3. I also never stop tweaking the color, brightness and contrast knobs, depending on how bright the surrounding daylight is. Everything about this feels right, this is like Commodore's engineers intended and how it has always worked and the reason I use the real machines to this day.
Do the Hanover Bars make yellow look greenish on it? Hell yeah they do, but why complain if there's so much else to like about its appearance? VIC chips output an analogue signal, that gets distorted in a gazillion kind of crazy ways.
Regarding palettes with different amount of saturation, I like to compare that to bass in music. I know people who tweak their audio-equalizers in such ways, that music is so bass-heavy that I can't enjoy it any longer - but they love the f*ck out of it. I also know peeps who want music to sound natural, linear and realistic - I sometimes think they should really dial more bass in. They surely can't agree on what the "standard way" of listening to music is.
I received a pretty large amount of mails throughout the years, from people who had something to complain about my exemplary calculation. It's "too dull", "too dark", "saturation is too low", etc. It's not that surprising, as people know the colors from when they were able to equalize them for themselves. What I suggested to most of them, is to follow the example and calculate with their own amount of saturation or add some brightness. It's after all just an example and I didn't think people would just take and run with it.
My goal is simple, I want C64 graphics to look as good when looking at them on a tablet-device, as they look on the real thing and I think this goal is more close with colodore, that's the one reason I'm sharing it. I'm not in it for fame or money... ;^D
I'm sorry if this introduces more variables into some specific workflows, especially for some of my favourite pixel-artists, but you can just keep using the "pepto palette" if you're happy with it. The reason I actually chose a name this time, is that I certainly don't want to make anything obsolete. What is different from the 15 year old research to colodore, is that I tweaked the purple/green angle slightly and phase-shifted all colors a tiny notch in the underlying logic as my new measurements suggest, that this is more accurate.
Also my luma-values have always been based on Marko Mäkelä's measurements (a fact I never hide), I just tried to reduce them to a common denominator - a somewhat quantized version that I feel represents the different chips I tested personally very well, even if every one of them looks slightly different.
I hope this clears up some confusion. |
| |
chatGPZ
Registered: Dec 2001 Posts: 11350 |
the bass/music analogy is a very good one, thanks for coming up with that - must remember.
VICE also phase shifts all colors a bit (4.5 degrees iirc) already :) |
| |
jailbird
Registered: Dec 2001 Posts: 1578 |
No offence towards Pepto, as the old palette seemed to me as the golden ratio and it is just fabulous, but this new thingie looks like someone got wild on the color settings of a TV set and set it to the highest value. Or maybe I am just going blind as I get older... Dunno. I get it that it is measured and technically more correct but for some reason it doesn't feel right to me... |
| |
chatGPZ
Registered: Dec 2001 Posts: 11350 |
i just hacked it into chameleon.... and what can i say? looking at the VGA and 1701 side by side, they look surprisingly similar now. although the yellow _IS_ SCREAMING YELLOW =D
edit: one thing i noticed - it looks a lot less SCREAMING when you actually configure the output how it should be, ie enable scanlines and everything else. |
| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
Quote: No offence towards Pepto, as the old palette seemed to me as the golden ratio and it is just fabulous, but this new thingie looks like someone got wild on the color settings of a TV set and set it to the highest value. Or maybe I am just going blind as I get older... Dunno. I get it that it is measured and technically more correct but for some reason it doesn't feel right to me...
Have you tried setting the sliders to something more pepto-like? For example brightness 50, contrast 85, saturation 40 (these are no scientific numbers, I just quickly tried by hand to come up with a pepto-ish look)...
And to get even less scientific... Here's the real 1084s vs. colodore on iPad, photographed with a phone, which has a hard time as brightness of crt vs. lcd-backlight is pretty different for the lense and the original image is also interlaced...
Great image btw., also loved it on the bigscreen at Breakpoint... :) |
| |
v3to
Registered: Feb 2005 Posts: 150 |
I am quite pleased of the Colodore colour approach. It is not because of discussing which saturation is right, it is because the control bars lead to an result comparable to my 1084s. Dark blue stays dark blue even with extreme settings.
The PEPTO palette is a similar basis, but if I try to adjust saturation or brightness this tends to unwanted undertones. |
| |
ilesj
Registered: Jun 2012 Posts: 27 |
Awesome! Thanks for this - this here addresses many issues around (especially) C64 colors and picture reproduction. And what Groepaz said, the bass analogy is excellent. With these dials both the bass-heads and audiophiles can set up a palette that looks right.
I have been using the classic pepto palette always when working on C64 graphics. Sure, its dim and muted, but it represents very well how the colors relate to each other. If colors of a picture looks balanced with pepto, it looks balanced with real HW. Some of the more saturated and bright palettes around have the colour relations off sometimes in wild proportions. That makes any well crafted picture look like a dog barf and at least my eyes bleed. This is a proper way to crank up brightness and saturation!
And whoever is seeking one true palette theres also the catch that any two random displays wont look the same. Colour reproduction between different displays just wont be the same - that would call for colour profiles, calibration etc. So no, those default COLODORE colors may not be anywhere near a good match with 1084 on _your_ display, even though for pepto it is.
And by the way, I think not many laptop displays, for example, can reproduce the spot brightness of a small CRT display, no matter whats the brightness and contrast setting. Only recently dynamic range has become a thing with HDR standards for UHD TVs. |
| |
chatGPZ
Registered: Dec 2001 Posts: 11350 |
Quote:And by the way, I think not many laptop displays, for example, can reproduce the spot brightness of a small CRT display, no matter whats the brightness and contrast setting. Only recently dynamic range has become a thing with HDR standards for UHD TVs.
color gamut is another thing - VGA can not reproduce all colors that a PAL-CRT can (and the other way around) |
| |
Oswald
Registered: Apr 2002 Posts: 5086 |
I was satisfied with the 'pepto' palette, but if this would make it into vice, in a user friendly way (realtime manipuation) that would be nice. |
| |
soci
Registered: Sep 2003 Posts: 479 |
Quoting peptoGreat image btw., also loved it on the bigscreen at Breakpoint... :)
This picture has several errors (on the right) compared to the compo version I know (on the left). The most noticeable is a group of purple pixels near the upper left corner. |
| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
Quote: Quoting peptoGreat image btw., also loved it on the bigscreen at Breakpoint... :)
This picture has several errors (on the right) compared to the compo version I know (on the left). The most noticeable is a group of purple pixels near the upper left corner.
Interesting, I wonder how that happened... thanks for noticing!
I just ripped a fresh copy - you might have to clear your browser-cache if you don't see it immediately. |
| |
Oswald
Registered: Apr 2002 Posts: 5086 |
iirc that picture was converted to nufli, so you might have used the nufli version for the tft. |
| |
Dr. TerrorZ
Registered: Oct 2013 Posts: 12 |
In my image, the Imjärvi UFO Incident - BTW I'm honored that it's included :) - for some reason the guy on the left lacks the light brown area on the hat that's in the original, instead it is replaced with dark brown?
Interesting project! I have a 1084S, I'll have to do comparisons. |
| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
Quote: In my image, the Imjärvi UFO Incident - BTW I'm honored that it's included :) - for some reason the guy on the left lacks the light brown area on the hat that's in the original, instead it is replaced with dark brown?
Interesting project! I have a 1084S, I'll have to do comparisons.
Sorry, that's a little embarrassing... ^^ I remapped some colors from pre-made screenshots by eye-sight in order to be done faster. This will be a lesson for me to be more careful...
I just fixed it, but you may have to clear your browser-cache just in case you don't see it immediately.
I like the image a lot - the sensation of glowing light in the snowy forrest and the mystery-aspect, I even did research on the real incident because of this... :D |
| |
Jammer
Registered: Nov 2002 Posts: 1335 |
Quoting Groepazjust a little bit too late for VICE3.0
That one has drawn my attention. Was that a hint of nice Christmas gift? :P |
| |
chatGPZ
Registered: Dec 2001 Posts: 11350 |
who knows |
| |
Oswald
Registered: Apr 2002 Posts: 5086 |
only now realised there are more pics to be seen in there. played around a bit, and yeah it has a much more CRTish feeling than anything I've seen so far. |
| |
jailbird
Registered: Dec 2001 Posts: 1578 |
Quote: Interesting, I wonder how that happened... thanks for noticing!
I just ripped a fresh copy - you might have to clear your browser-cache if you don't see it immediately.
Maybe the left one was DeeKay's "Why no NUFLI?" alteration from Crest Slide Story? That version butchered my anti-aliasing and was ridden with silly color-clashes :)
Anyhow, you guys are reasoning quite smoothly, so I'm gradually starting to convert, even though the new palette still feels odd... o_O |
| |
chatGPZ
Registered: Dec 2001 Posts: 11350 |
turn down saturation a bit, that helps a lot to adjust :) |
| |
LogicDeLuxe
Registered: Jun 2011 Posts: 3 |
Great to see the colors improved.
However, wouldn't a slider instead of a switch make sense for Hanover Bars?
And shouldn't be there a hue slider for NTSC simulation as well? Maybe as a norm switch, which activates either the delay line or the hue slider?
And for further taking different monitor behaviors into account, I guess, gamma sliders for YUV and also for RGB would make sense.
Furthermore, sliders for offset and gain for YUV and RGB. Those advanced settings can be hidden in a "service menu", like it was the case in most CRT TVs since the mid 90's. |
| |
soci
Registered: Sep 2003 Posts: 479 |
Checked the pictures, nice, also the algorithm, simple enough. But I'm not fully convinced yet ;)
So I'm looking forward to read the promised article with the supporting measurements/traces. Especially the part about the choice of black level and uniform colour saturation. |
| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
Unfortunately I'm far more busy at work right now, than I had planned.
Anyway, I managed to write most stuff down today, so I decided to put it up at http://www.pepto.de/projects/colorvic/ |
| |
soci
Registered: Sep 2003 Posts: 479 |
I expected some lab equipment involved in this. Things like measurements taken after the decoder in a 1084s and such.
But don't get me wrong, it's still cool ;) |
| |
chatGPZ
Registered: Dec 2001 Posts: 11350 |
mmmh somehow i expected some more details =) |
| |
JackAsser
Registered: Jun 2002 Posts: 2014 |
Quote: mmmh somehow i expected some more details =)
Maybe you think it's more complicated than it really is? :D |
| |
chatGPZ
Registered: Dec 2001 Posts: 11350 |
perhaps =) |
| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
Well, where I come from, simple solutions are actually preferred, as long as they get the job done (see "KISS principle"). :D
I kinda like how little code is needed for a convincing result. In fact, I spent extra time rearranging it, for more clarity.
This means, that more xplat-tools could incorporate brightness, contrast and saturation sliders in the future - in a painless way... \o/ |
| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
Quoting LogicDeLuxeAnd for further taking different monitor behaviors into account, I guess, gamma sliders for YUV and also for RGB would make sense.
Furthermore, sliders for offset and gain for YUV and RGB. Those advanced settings can be hidden in a "service menu", like it was the case in most CRT TVs since the mid 90's.
Hmm, I never came across CRTs with Gamma, Offset and Gain dials. I will think about adding "advanced" settings to colodore.com though - thanks for feedback. |
| |
soci
Registered: Sep 2003 Posts: 479 |
Just a few more steps and there will be separate RGB sliders for each colour for maximum flexibility ;) |
| |
chatGPZ
Registered: Dec 2001 Posts: 11350 |
i'd be most interested in seeing the algorithm applied to NTSC (using the sony decoder matrix).....
did a quick test in VICE with the hannover bars stuff as you implemented them.... now everything is pink. knoekicolors =) i think the renderer cant be reused as is and must be rewritten. sux ;_; |
| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
Quoting Groepazi'd be most interested in seeing the algorithm applied to NTSC (using the sony decoder matrix).....
If I didn't f*ck it up, like this I guess (only tested in Chrome): http://www.pepto.de/groepaz.html |
| |
chatGPZ
Registered: Dec 2001 Posts: 11350 |
hard to tell (for me anyway) without a test picture and CRT emulation attached.... but thanks :) (incase you want to add some pictures for ntsc, check the work of DocJM - awesome stuff. and pics like this can tell you if you got the aspect ratio right :)
oh and i almost forgot, i have a feature request.... could you add an option to download the palette in VICE format? converting them by hand is a bit annoying =) |
| |
ilesj
Registered: Jun 2012 Posts: 27 |
Btw why the delay line doesn't seem to have any effect on the hanover bars? |
| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
Quote: Btw why the delay line doesn't seem to have any effect on the hanover bars?
Good question, I'm wondering this myself... looking at the output though, both effects are definitely present. Chroma blending with the previous line, and phase-shift for the v-component. |
| |
chatGPZ
Registered: Dec 2001 Posts: 11350 |
oh it doesnt? i guess thats the problem with the vice renderer. are you sure it actually doesnt? does joes "play with colors" work correctly with your stuff? |
| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
Quote: oh it doesnt? i guess thats the problem with the vice renderer. are you sure it actually doesnt? does joes "play with colors" work correctly with your stuff?
How do I know if it works? I'm actually cooking dinner right now, but I will look into this later... ;-) |
| |
chatGPZ
Registered: Dec 2001 Posts: 11350 |
Play With Colors 2 should look like this |
| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
Quoting Groepazdoes joes "play with colors" work correctly with your stuff?
This is really interesting! I didn't know about this test before.
I would say 90% of the fields look correct (I'm comparing colodore to the real C64 on the 1084s) and this is because of delayline-style chroma-blending.
A few adjacent fields however, which only differ by one color being on even lines in one field and on odd lines in the other, blend differently on the 1084s compared to colodore.
Which means the color-generation described on http://www.pepto.de/projects/colorvic/ works just fine and also the delay-line on colodore, but the way I do hanover bars doesn't seem to work 100% yet, even though it looks like a perfect match on solid colored fields, so it definitely is the phase-shift on v, just like it should be.
I'm puzzled for the moment and need to get some sleep.
At which point do you guys inject hanover-bars into the signal in Vice? I do it after the delayline, that's why a field with (lgrn/yel) looks the same as (yel/lgrn) before the hanover bars are added. |
| |
chatGPZ
Registered: Dec 2001 Posts: 11350 |
VICE uses two yuv palettes, one for odd and one for even lines, and both go into the delay line stuff. this is pretty much required to get those mixed colors 100% right (hence my question before)
you could also use this little test image, it shows all the mixed colors - the important bit is that some of them are different depending on what colors are in odd and even lines. |
| |
ilesj
Registered: Jun 2012 Posts: 27 |
Quoting peptoAt which point do you guys inject hanover-bars into the signal in Vice? I do it after the delayline, that's why a field with (lgrn/yel) looks the same as (yel/lgrn) before the hanover bars are added.
Should it be the other way around? Your article links to this Wikipedia article https://en.wikipedia.org/wiki/Hanover_bars that says
Quoting wiki
To suppress Hanover bars, PAL color decoders use a delay line which repeats the chroma information from each previous line, and blends it with the current line
|
| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
Quoting wiki
To suppress Hanover bars, PAL color decoders use a delay line which repeats the chroma information from each previous line, and blends it with the current line
You are correct, a delay-line would be the weapon of choice to suppress hanover bars, but they are a clearly visible artefact, along with delay-line style vertically blended chroma.
Something doesn't seem to add up in the crt-emu/video-signal portion (e.g. detached from the general palette color generation). I came to the same conclusion originally, but unfortunately reality still differs.
Quoting GroepazVICE uses two yuv palettes, one for odd and one for even lines, and both go into the delay line stuff.
Hmm, but shouldn't this cancel out hanover bars completely?
I have a first idea on how to get "play with colors" to blend right. I have a feeling it's something simple. I will try to find some time this weekend to investigate. |
| |
chatGPZ
Registered: Dec 2001 Posts: 11350 |
Quote:Hmm, but shouldn't this cancel out hanover bars completely?
apparently not... they are only completely gone if the phase difference between odd and even lines is exactly 180 degr. |
| |
JackAsser
Registered: Jun 2002 Posts: 2014 |
Quote: Quoting wiki
To suppress Hanover bars, PAL color decoders use a delay line which repeats the chroma information from each previous line, and blends it with the current line
You are correct, a delay-line would be the weapon of choice to suppress hanover bars, but they are a clearly visible artefact, along with delay-line style vertically blended chroma.
Something doesn't seem to add up in the crt-emu/video-signal portion (e.g. detached from the general palette color generation). I came to the same conclusion originally, but unfortunately reality still differs.
Quoting GroepazVICE uses two yuv palettes, one for odd and one for even lines, and both go into the delay line stuff.
Hmm, but shouldn't this cancel out hanover bars completely?
I have a first idea on how to get "play with colors" to blend right. I have a feeling it's something simple. I will try to find some time this weekend to investigate.
Keep me informed so that I can update the webgl-port. (will release soonish). |
| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
Quoting JackAsserKeep me informed so that I can update the webgl-port. (will release soonish).
Cool! No worries, I will keep you updated... |
| |
Kabuto Account closed
Registered: Sep 2004 Posts: 58 |
Great work!
There is another effect that was mentioned in an old demo, I think it was made by Crest when they introduced NUFLI or something similar:
The video chip is slower at changing the voltage level from black to white than the other way round. This means that a sequence of for example black and white pixels appears darker than one would expect (even when considering gamma level effects on a slightly blurred output). This effect also is less prominent on later video chips, probably because their internal transistors work faster.
I didn't find this being mentioned in this thread before, so I just thought I'd mention it.
Also, is the phase of the chroma carrier fixed? If I remember correctly it's chosen randomly on every power cycle. But I totally understand that this one would be a bit nasty to emulate, but I still wonder how much this affects the appearance of pictures. |
| |
chatGPZ
Registered: Dec 2001 Posts: 11350 |
the so called black bleeding is NOT caused by the VIC as suggested in that crest demo - it completely disappears when removing the modulator, so its basically the result of the shitty video circuit. |
| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
Quoting peptoYou are correct, a delay-line would be the weapon of choice to suppress hanover bars, but they are a clearly visible artefact, along with delay-line style vertically blended chroma.
Oh snap, the 1084s seems to have a delay-line for YUV's U only. This explains a lot of things, especially why the phase-offset for YUV's V still is perfectly visible on screen after passing the delay-line and why more modern TVs manage to hide the hanover bars so much better, as they delay-line both YUV's U & V...
Quoting peptoI have a first idea on how to get "play with colors" to blend right. I have a feeling it's something simple. I will try to find some time this weekend to investigate.
The solution is simple indeed. I have an internal version of colodore.com now, that renders every single field of "play with colors 2" precisely like the real VIC II and solid single-colored fields still look identical to the original version... \o/
I will try to find time tomorrow to tidy up my code, update the website and tell you how it appears to work tomorrow. |
| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
Considering how important it is, that a color ends up on an even or odd line, for this effect to work: Is the first line of the 200 line high main-field (without borders) considered an even or odd line, if you start counting at 1? |
| |
chatGPZ
Registered: Dec 2001 Posts: 11350 |
you can scroll it.... so... :) i think you should start counting from the actual first scanline |
| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
Quoting Groepazyou can scroll it.... so... :) i think you should start counting from the actual first scanline
Yeah well... unscrolled, freshly booted C64... Vice shows 35 pixels of upper-border for me. But as far as I understand, the first line in Vice isn't the first scanline, right? Isn't Vice's view masked to a sane value to hide overscan? |
| |
chatGPZ
Registered: Dec 2001 Posts: 11350 |
to bei honest.... not sure how exactly VICE determines that... alankila write those renderers, i just improved some bits here and there.
but isnt it just a matter of trying both options and check against a real monitor which one is correct? :) |
| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
Quoting Groepazbut isnt it just a matter of trying both options and check against a real monitor which one is correct? :)
Yes, it's easy to check with a test-image like "play with colors 2", there are just two ways to do it... I just wanted to use correct terminology for variables, that's all... :) |
| |
chatGPZ
Registered: Dec 2001 Posts: 11350 |
as said, count from the first actual scanline, then its obvious what is odd and what is even :) |
| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
I updated http://www.colodore.com
Changes:
- do hanover-bars before delay-line
- added option to delay-line YUV's U only -- 1084s style (default for now)
- added Ed's "Play With Colors 2" at bottom of image-list
None of the changes affect the palettes.
In order for hanover-bars to work correct, there's a phase-shift (hue-rotation) needed for both U & V of 22.5 degrees on even lines, and -22.5 degrees on odd lines, before going into the delay-line.
To check if you have the even/odd stuff in the right order, make sure that the two fields in "Play With Colors 2", look like this (greyish on left, greenish on right)...
|
| |
Oswald
Registered: Apr 2002 Posts: 5086 |
scanlines are too strong imho |
| |
chatGPZ
Registered: Dec 2001 Posts: 11350 |
delay line only for U is interesting. i think 1701 does the same....
perhaps that finally explains why so many ppl complain about scanlines being too strong - they are used to displays that have delay line for U and V? |
| |
ChristopherJam
Registered: Aug 2004 Posts: 1408 |
Quote: Great work!
There is another effect that was mentioned in an old demo, I think it was made by Crest when they introduced NUFLI or something similar:
The video chip is slower at changing the voltage level from black to white than the other way round. This means that a sequence of for example black and white pixels appears darker than one would expect (even when considering gamma level effects on a slightly blurred output). This effect also is less prominent on later video chips, probably because their internal transistors work faster.
I didn't find this being mentioned in this thread before, so I just thought I'd mention it.
Also, is the phase of the chroma carrier fixed? If I remember correctly it's chosen randomly on every power cycle. But I totally understand that this one would be a bit nasty to emulate, but I still wonder how much this affects the appearance of pictures.
Not only is the rise slower than the fall (even without using the RF modulator), but luma changes overshoot then continue to oscillate for around four pixels. More later this week; Pepto's most excellent posts here have reminded me I've a post of my own I've been meaning to write for a while now.
And yes, sadly the chroma phase is random every power cycle :( |
| |
ChristopherJam
Registered: Aug 2004 Posts: 1408 |
Quote: the so called black bleeding is NOT caused by the VIC as suggested in that crest demo - it completely disappears when removing the modulator, so its basically the result of the shitty video circuit.
Regardless of which circuit causes it, it's still worthy of emulation, no? |
| |
chatGPZ
Registered: Dec 2001 Posts: 11350 |
sure... unfortunately however, its not practical (read: slow like hell) when done in software - pretty much needs shader support (micro64 can do it). it will still take a while until VICE is ready for this :) |
| |
Slajerek
Registered: May 2015 Posts: 63 |
Great work! And source is clean too.
Funny though that in the demo graphics selection there's no standard C64 Basic screen after kernal reboot :-) |
| |
Copyfault
Registered: Dec 2001 Posts: 474 |
Great investigations! Never thought that pepto would pop up again one day to continue with his video emulation stuff. Don't find any proper words for it, I'm just happy seeing this happening right now;)
Wondering if this quest for the perfect colour representants could be sensefully connected to the CIELab-colour model which was brought up by Ghostrider (iirc) some month ago. As far as I understood the CIELab approach is to model the colours as they are perceived under (configurable) circumstances (like i.e. kind of light, viewing angle, ...). The investigations posted here seem to aim at the same, with the difference of sticking to the YUV colour scheme whereas the CIELab model uses its own calculation components. Maybe I'm all wrong but for me it seems it could be a good idea to "port" the insights of this thread to the CIELab model. |
| |
ptoing
Registered: Sep 2005 Posts: 271 |
Noticed a small bug with the delay line stuff as far as U only goes. I have a 1084S and solid colors display hanover bars, but when mixing luma pairs they get pretty much eliminated.
So in Joe's "Playing With Colors 2", the light red/green mixes look nothing like that on a real 1084S, they are much more uniform, pretty much like with the "on U only" thing off. |
| |
pepto Account closed
Registered: Nov 2004 Posts: 35 |
Quote: Noticed a small bug with the delay line stuff as far as U only goes. I have a 1084S and solid colors display hanover bars, but when mixing luma pairs they get pretty much eliminated.
So in Joe's "Playing With Colors 2", the light red/green mixes look nothing like that on a real 1084S, they are much more uniform, pretty much like with the "on U only" thing off.
Thanks for noticing!! This really gave me some sleepless nights, since mid-june... ;P
I have a fix coming... \o/ it really only affects hanover-bars for certain color-combinations (like the red/green you mentioned) when not having delayline for both U and V).
"Play With Colors 2" is by Ed of Wrath Designs btw, not Joe...
I spent the whole day comparing the 1084S to the output of experimental colodore-versions and I think that I finally found a solution that looks very similar to the real thing. It seems that the "transparency" of the effect that the delayline of the V signal creates, is dependant on the phase of the color-angle.
I'm not sure how this translates to electronics though... O_o ...like U has a solid delayline-effect in monitors like the 1084S, but V's delayline-effect is only visible the more you get away from the center of the V-axis? It certainly looks like it, but where's the logic in that? Is this some weird way to multiplex two signals into one delayline or some signal-bleed crosstalk?
This is basically what I have now, in pseudo-code:
delayLine_v[ x,y ].alpha = parseInt( Math.abs( Math.sin( screenPixel[ x,y ].colorAngle ) * 0xFF ) );
My current implementation is full of debug-output in weird places though. I will tidy this up and write a small section about it on the website before the year is over (unfortunately I'm a lil' busy at work right now)... just wanted to give you a heads-up... |
| |
ptoing
Registered: Sep 2005 Posts: 271 |
Nice, glad to be of help :) |