NTSC vs PAL colour palette

[wfriedrich]

Hello VLSI team,

I have my video display shield working in PAL and NTSC mode (see initial thread viewtopic.php?f=14&t=2161).

I am generating the same colour pattern (16x16 tiles, byte value 0 to 255 in YUV422) in both modes but the lines have different base colours. To me, that means that the RGB->YUV conversion would not work the same way in both modes. Do you have any advise how to match those 2 colour palettes?
Conversion code from your pal.h file:

Code: Select all

#define YRGB(r,g,b) ((76*r+150*g+29*b)>>8)
#define URGB(r,g,b) (((r<<7)-107*g-20*b)>>8)
#define VRGB(r,g,b) ((-43*r-84*g+(b<<7))>>8)

Attached are the 2 images I am getting (sorry the image quality is not great because of the cheap display).

Also you can see the artifact at the start row of the PAL image which I could not remove, even with the hints from the datasheet and code from your pal video example.

And one more: Under what license do you publish your demo code? Would I get permission to use the ntsc.h and pal.h files and some functions from your Arduino demo, when I start selling my hardware shield and offer a software library that includes those files and functions? Of course I would add comments about the origin of those files.

Thank you,
- Wolfgang.

[Panu]

Hi!

Please see the post "Same palette for PAL and NTSC" at viewtopic.php?f=14&t=1813&p=9013#p9013 where this problem is discussed extensively.

Basically, because you can select the color burst orientation freely in NTSC, whereas in PAL you are restricted to 45 degree angles, you must first pick a colorburst orientation for PAL and then transform that to NTSC.

The PAL Video Player demo has the exactly correct microcode and burst value that produces exactly correct YUV colors from normal source, e.g. normal avi video files.

It's been a couple of years since I did those, but I worked out the PAL video player palette settings from the PAL video player demo source code using the palette editor. For PAL the proper hicolor yuv video palette is P:C4:B44:A44:Y84:N04, which results in colour burst amplitude 5.7, phase 135.0 degrees, microcode C4 BC 1C 5C. That can be translated to NTSC and becomes N:B0:B44:A44:Y84:N04, which has colour burst amplitude 5.0, phase 180.0 degrees, and the same microcode PROG: C4 BC 1C 5C. If you want stronger colors, reduce the color burst amplitude but keep phase the same (click on the colorburst vector in the palette editor to experiment).

As with the default 8-bit palette, with these settings the same bitmap memory contents will result in similar picture colors in PAL and NTSC, and as the microcode program is the same, only the BURST_LEVEL (colorburst pixels UV bits in prototype lines) needs to be changed when switching between PAL and NTSC. This mode is UVY448, 16 bits per pixel.

Have you figured out how to use these values in your program or do you need help in deciphering what they mean?

And one more: Under what license do you publish your demo code? Would I get permission to use the ntsc.h and pal.h files and some functions from your Arduino demo, when I start selling my hardware shield and offer a software library that includes those files and functions? Of course I would add comments about the origin of those files.

Of course you can use them! Please see that there is a link to here and to VLSI webpage in the source code. But I'd like to insist that for 8-bit (256 color) mode you should use the "Default palette" (PAL:EE:A22:B22:Y44:N10, NTSC:0D:B22:A22:Y44:N10), which is described in the aforementioned post, by default. And for AVI video, please follow the microcode settings in the PAL video player demo.

As our revenue comes from selling ICs and not software, we're not enforcing any specific license and our traditional answer has been that our source codes are at least free to use with whatever license as long as one of our chips is used in the product. If you need something else, please ask.

-Panu

PS. Do you want the AVI video encoder? We're hesitant to distribute mencoder publicly at our web pages due to all kind of potential licensing issues, but you can do it. Mencoder as well as my additions to it (lcd1.c) is GPL.

[wfriedrich]

Hello Panu,
Thank you very much for the information. This is very helpful.
My NTSC palette is already looking like the default palette as the values for microcode and burst level where set already.
My PAL palette is still looking different, almost like green and red are swapped. I will send an image soon.
What I don't quite understand yet how the color burst phase gets adjusted in addition to the amplitude? The microcode is identical to the example in the post about the same palette in NTSC and PAL.

Thank you very much for confirming that I am allowed to use your .h files and other functions. I will certainly add the comments that point to your website and the forum.
Thanks for the offer for the AVI video encoder, but I don't think I will be able to run this on an Arduino Uno.

Also I just noticed your newest addition, the VS23S040, this looks really interesting as a follow up project.
- Wolfgang.

[Panu]

Hi!

What I don't quite understand yet how the color burst phase gets adjusted in addition to the amplitude? The microcode is identical to the example in the post about the same palette in NTSC and PAL.

That comes from the color of the colorburst. That's defined in the picture prototype lines in memory.

There are two parts to defining the color: the microcode and the colorburst. The microcode you already know. The colorburst is defined in the protoline, e.g. the part of the picture line which is not part of any normally visible pixels.

Please see this post: Understanding Protolines and Line Pointers. There you will find a picture, copied below:The color burst phase and amplitude comes from the most significant 8 bits of each color burst pixel, e.g. the purple "B5" in the above picture. Instead of the "B5" you'd have 0x0D for the default palette in NTSC and 0xEE for PAL. And for the hicolor video player modes, you'd have 0xB0 for NTSC and 0xC4 for PAL. That's the first number from the palette editor's palette definition such as "P:C4:B44:A44:Y84:N04"

I found the following picture from http://www.piclist.com/images/www/hobby ... clock2.htm.. maybe it is helpful to understand what the colorburst is... It's basically just a piece of 3.58 MHz or 4.43 MHz sine wave, the TV synchronizes and locks on to that piece sine wave to lock onto what the colors are in the composite signal. If you chance the phase of the burst, the color hue changes. If you change the amplitude of the burst, the color saturation changes.


I drew one more illustration to help you understand the protoline:

vs23s010 protoline illustrated.png (33.77 KiB) Viewed 10155 times

-Panu

[wfriedrich]

Hello Panu,
Thank you very much for this excellent explanation. This helped a lot to understand the details and find my error. A memory dump showed that I was not using the value for the burst level I thought I was using. Fixing that finally gives me beautiful identical default colours in PAL and NTSC.

Does the RGB to YUV conversion formula work with the default palette?

I am still seeing an artifact vertical line at the left side of the PAL image only, but I will investigate this further before I post/ask any more details about it.

Thanks for now,
- Wolfgang.

[Panu]

Hi!

The left edge artifact comes from a small hardware bug in the image logic. When it switches from protoline region to picture region, the bias level changes from zero (sync_level) to 102 decimal (DVD standard black level). Unfortunately the bias changes one or two clocks too early, momentarily adding 102 decimal to the black level of the last protopixel before first picture pixel. (the exact failure mechanism is that the bias level changes instantly when switching to picture region, but the first luminance bits from the video memory take a couple of clock cycles to arrive)

In my tests, I've located, through trial and error, the location of this protopixel in memory and reduced its black level to mitigate the effect down to a tolerable level. Another alternative would be to make the picture region wide enough to hide it completely in the left edge, but this would waste some memory.

Sorry about it, such things happen when you're designing on raw silicon

Does the RGB to YUV conversion formula work with the default palette?

It works in the videoplayer hicolor palette, but not in the 8-bit default palette. In the default 8-bit palette the color constellation is rotated 180 degrees so that the corner that has the maximum color saturation points towards red instead of cyan, making more hues available. For YUV that means some operation of something like swapping U and V, perhaps, or changing sign of V. or U. Or both. Or something (The constellation is rotated because in the default 8 bit palette mode U and V are 2 bit entities, so both can reach values -2, -1, 0, and 1. And rotating the constellation makes the strongest color vector of UV=(-2, -2) point towards red, which would not be well reachable otherwise.)

Here's a picture of what I mean, hopefully it can clarify a little:

4bit hue constellations-2.png (83.58 KiB) Viewed 10125 times

-Panu

[wfriedrich]

Hello Panu,

Thanks, very good information again. I somehow thought that the phase change would cause a flip o the U and V bit indices, but it is a rotation.

So to mitigate the artifact pixel, I have to find the memory location of the blank pixel just before the image area (see updated picture of your protoline) which is black in the protoline0 definition and reduce it as much as possible. I will do some peeks and pokes.

No need to apologize, silicon development is really hard, there is not easy way for fixes until the next tape-out.

- Wolfgang.