NTSC - PAL - color matching (Altirra default palettes)

[simonh]

I've just spent a little time messing with toggling between PAL and NTSC modes for the Atari emulator in Altirra, and realized what I wanted was a reference chart for "matching" colors between the two palettes. For my next assembler project, I want to write some nifty code that checks the Atari mode (PAL or NTSC), and switches color palette appropriately. The idea being that the colors used are "close enough" the same in either mode.   

 

After carefully capturing all possible colors for both modes (with a little test program), I extracted their RGB values (using a paint program), and wrote a Python program to automatically compute the minimum distances between pairs of colors (think minimum distance between two 3D points in a "color cube" with R, G, B axes -- yay, Pythagorus). The result is a standalone HTML page that gives the closest matches between the NTSC and PAL palettes which can be used to select pairs of Chroma-Luma codes.

 

Perhaps someone else might find this useful in the future... 

 

  

ntsc-pal-match.html

[+MrFish]

4 hours ago, simonh said:

I've just spent a little time messing with toggling between PAL and NTSC modes for the Atari emulator in Altirra, and realized what I wanted was a reference chart for "matching" colors between the two palettes. For my next assembler project, I want to write some nifty code that checks the Atari mode (PAL or NTSC), and switches color palette appropriately. The idea being that the colors used are "close enough" the same in either mode.   

 

After carefully capturing all possible colors for both modes (with a little test program), I extracted their RGB values (using a paint program), and wrote a Python program to automatically compute the minimum distances between pairs of colors (think minimum distance between two 3D points in a "color cube" with R, G, B axes -- yay, Pythagorus). The result is a standalone HTML page that gives the closest matches between the NTSC and PAL palettes which can be used to select pairs of Chroma-Luma codes.

 

Perhaps someone else might find this useful in the future... 

 

ntsc-pal-match.html 21.61 kB · 7 downloads

 

TBH, most of what's shown here can already be computed by simple transposition (which is how I basically do it); so, no need to consult any chart; and for the few that may need some hand-choosing, I can do a better job than what I'm seeing here. I find some of the choices to be a bit questionable; although that may be due -- in part -- to the particular palettes being used here (which might differ somewhat from what I personally use in emulation; but I will say that I've also used the same method I mention here to choose colors on real hardware for both, as well).

 

Edited October 5, 2021 by MrFish

[Wrathchild]

Also having looked into colourspace distances, e.g. think 'Rasterconverter', the Delta-E 1994 is better

 

[manterola]

Yep i was about to write that.. Rgb space distances aren't probably the best option. 

Check this Wikipedia article for some background. Delta E is also mentioned there. 

https://en.m.wikipedia.org/wiki/Color_difference

Edited October 5, 2021 by manterola

[+MrFish]

On 10/5/2021 at 4:02 AM, Wrathchild said:

Also having looked into colourspace distances, e.g. think 'Rasterconverter', the Delta-E 1994 is better.

 

Speaking of RasterConverter... a nice update for it would be the ability to produce PAL & NTSC versions for a single image. Failing that, some type of simple command-line conversion tool that could produce one from the other would suffice.

 

[Xuel]

On 10/6/2021 at 2:57 PM, MrFish said:

 

Speaking of RasterConverter... a nice update for it would be the ability to produce PAL & NTSC versions for a single image. Failing that, some type of simple command-line conversion tool that could produce one from the other would suffice.

 

A simple conversion would not be possible since color register values may be reused as player positions and vice versa. For example, if the program determines that the optimal 6502 instruction stream at some point in the middle of the screen for NTSC is as follows:

 

...

LDA #$3C

STA COLPF1

STA HPOSP3

...

 

Then, you can't simply change the LDA #$3C to LDA #$2C for PAL because that will also change the position of player #3.

 

You pretty much have to rerun from scratch to target a different palette. I suppose the tool could have an option to work on PAL and NTSC versions simultaneously but it will double the amount of computation necessary, so it would anyway be comparable to running the tool twice.

[+MrFish]

1 hour ago, Xuel said:

A simple conversion would not be possible since color register values may be reused as player positions and vice versa. For example, if the program determines that the optimal 6502 instruction stream at some point in the middle of the screen for NTSC is as follows:

 

...

LDA #$3C

STA COLPF1

STA HPOSP3

...

 

Then, you can't simply change the LDA #$3C to LDA #$2C for PAL because that will also change the position of player #3.

 

You pretty much have to rerun from scratch to target a different palette. I suppose the tool could have an option to work on PAL and NTSC versions simultaneously but it will double the amount of computation necessary, so it would anyway be comparable to running the tool twice.

 

You know, I've seen similar things in older games that I've hacked on: sometimes a value loaded into the accumulator would be used to populate a player and then one of the playfield colors. I assumed -- in some cases -- it was done to enable a game to fit on a certain smaller-size ROM cartridge (8K or 16K); this would be a situation where even a few saved bytes could be important.

 

So, I guess in RastaConverter's case it's more of a cycle-saving measure. Now I can see why fiddling with the *.MCH file in Graph2Font sometimes produces strange results.

 

Alright, so, scrap that. Thanks for the info.

 

[+MrFish]

@Xuel

BTW... good to see you posting here. I hope your health is improving.