Default RGB palette

[IanSB]

Do you have any recommended RGB values for a default C64 palette? With my Raspberry Pi scaler I'm currently using these values: https://www.c64-wiki.com/wiki/Color However that does look rather light (or retrotink is too dark!). Here is the output of my C64: On the left is S-Video via Retrotink 2x, On the right is c0pperdragon's interface via RGBtoHDMI (RGBtoHDMI is generating the palette for the 16 logical colours)

Also do you have any documentation on PAL artifact generation as I will add that to RGBtoHDMI

[Hojo-Norem]

I can't speak for NTSC, but what I'd consider a decent 'default' synthesised PAL palette would be when pepto's Colodore algorithm generates using default settings: https://www.pepto.de/projects/colorvic/

Doesn't the RGBtoHDMI have button controls? Perhaps it may be worthwhile implementing the algorithm directly into the RGBto HDMI and let users alter the brightness/contrast/saturation settings on the fly.

That being said, the colours on the page you linked are really off in some cases. Funny thing is that the thumbnail image on the same page has a much more faithful rendition (to my eyes). Those make a good starting point if colorore isn't a priority for you ATM. The RetroTink does look a little dark and saturated, but that's more down to the fact that the retrotink has no image adjustment abilities and it's creator has no interest in implementing them. Practically told me just a such when I asked him. He pointed me at the decoder chip's dev board and told me to do it myself...

As for PAL artefacts, the main one I would consider looking into is delay line mixing. When I calculate the palette in the editor, I actually do it three times. First time is the 'pure' form, the second time adds odd line hanover bar adjustments and the third does even line hanover bars. The mixed colours are generated from the pairs of colours that have equal luma values. The mixing is as simple as averaging the U and V components of the two colours. This is enough for a rudimentary simulation, but for a little more accuracy you don't mix the pure versions of the colours, but the hanover versions based on which colour is on the odd scanline and which is on the even scanline. This has the effect of generating a different colour based on the order of the alternating colours. https://github.com/c0pperdragon/C64-Video-Enhancement/issues/7#issuecomment-513997866

I will admit that at the end of the day I don't really understand much of the theory behind it all. All I really did was translate pepto's javascript algorithm into 6502 assembly. I got the hanover colour part from scrutinising the source code of his page at https://www.colodore.com/ (more specifically, the part starting at line 1480).

I'm curious of the aspect ratio of the RGBtoHDMI's output. Is that because of using a pure integer scaler?

[IanSB]

I can't speak for NTSC, but what I'd consider a decent 'default' synthesised PAL palette would be when pepto's Colodore algorithm generates using default settings: https://www.pepto.de/projects/colorvic/

Thanks

Doesn't the RGBtoHDMI have button controls? Perhaps it may be worthwhile implementing the algorithm directly into the RGBto HDMI and let users alter the brightness/contrast/saturation settings on the fly.

Yes, I already do that with NTSC artifact colours

I'm curious of the aspect ratio of the RGBtoHDMI's output. Is that because of using a pure integer scaler?

The aspect ratio will not be exact because only certain ratios will be possible with integer scaling. However in the above case I set it to output 5:4 integer pixel scaling which is closer to 525 aspect ratio:

Setting to 4:4 integer pixel scaling looks more like 625 but it is still a little wider than real 625 scaling.

You can also select interpolated scaling, then it looks exact but will have softer edges like other scalers although it will still be much cleaner with zero noise or ringing etc.

[Hojo-Norem]

For another perspective on interpolated scaling it may be worth taking a look here: https://forums.nesdev.com/viewtopic.php?f=3&t=10811 Unless of you are already scaling using a method similar to the one described there. It's hard to tell from the photos.

[IanSB]

Unless of you are already scaling using a method similar to the one described there. It's hard to tell from the photos.

Yes I'm already "doubling the image size with nearest-neighbor interpolation before performing any additional resizing" which makes it far sharper that just interpolating from the original size but not as sharp as integer only.

[IanSB]

Now with colodore algorithm with default contrast, saturation and brightness. Much better:

Thanks for your help!

[Hojo-Norem]

Nice! Is the palette pre-calculated or generated at run-time?

I noticed on your wiki that you do have a mechanism for uploading palettes to the RGBtoHDMI. If you are pre-calculating then I can't see it being too difficult adapting my palette editor to be compatible. You could then skip having to implement delay line mixing as long as you implemented the same palette system and behaviour that c0pperdragon's mod uses.

[IanSB]

Nice! Is the palette pre-calculated or generated at run-time?

It's pre calculated: On first startup of a clean install the software checks for files in a palette folder and if they are missing it generates for all supported computers. The palette folder is then scanned on every startup and the palette files are then selectable as a menu option so you can switch to alternate palettes that have been added to the folder or overwrite one of the existing default palettes with a customised version.

I'll look to see if it's possble to implement something like c0pperdragon's palette system when I have the time.

[IanSB]

Do you know if there is an equivalent to colodore for the Atari home computers?

[Hojo-Norem]

Sorry. I'm not really an Atari person. To be honest, beyond Google I wouldn't know where to start looking.