Jump to content
IGNORED

RGBY - interleaved chroma-luma in 4 colors modes


R0ger

Recommended Posts

I can't really remember when I first saw the "256" color mode on Atari .. the basic interleave of GTIA mode 9 and 11. One line added the color, the other line added brightness. It was magic !

And later many demos came up with flickering modes where 2 different frames were being swapped on the screen, to improve resolution, using different tricks and different names.

I wasn't satisfied with how much it flickered though. So I tried my own experiments. And I think I had some good results using 4 color modes. I've showed some of the results here and there, but recently several people asked about it, so I want to finally start a proper thread.

 

Over the time many smaller and bigger tricks layered over each other, and the final "technology" is somewhat complex. So let me start nice and slow, step by step.

 

1. PAL mixing

So first there is the idea of mixing hue information on one line with brightness information on the next line. This thing exactly is part of PAL TV signal norm. More specifically the hue is encoded as phase of carrier signal, and the phase has the opposite meaning on even and odd lines. In the final image the hue of two subsequent lines is averaged together. This system is used to eliminate effects of signal reflection induced phase shifts. That doesn't bother us today, but the function is still there.

So if we use the darkest possible colors on one line, and just shades of gray on the next line, then what we will see is mostly the brighter gray line, but being colored by the colors from previous line. And it's not that it just "looks like it". It's not optical illusion. Any PAL TV actually mixes the colors together. And not just PAL TV. Many TVs do that even for NTSC signal, it's worth trying !

 

While usually these modes use interleaving of GTIA modes, I started experimenting with 4 color modes. I don't have to do anything with GTIA, but I have to switch colors in the palette between lines. All 4 of them. Which is just about how much time you have in 40 character mode. So let's have 4 different hues on one line, and 4 different shades of gray on the next line. It looks something like this .. on the left without PAL mixing, on the right with PAL mixing (how it's intended to look):

 

pal-mixing.png.06e574685bd65c0360045e925304beb4.png

 

For the 4 hues I chose red, green, blue and yellow. Originally I was using black instead of yellow, but gray is not that important, and yellow improves the colors a lot. One of the disadvantages is that on hue lines, there is no black now. Which means there is also no black in the screen border. I chose blue to be there, as it's the least intrusive. I could hide it with PMG, but I have better use for them (later).

So now I have RGBY on even lines, and 4 grays on odd lines. This together creates 16 different colors, in logical resolution 160x100, with logical pixels of size 2x2 hires pixels. 16 colors is not much, but square pixels are surely nice. This is the basic mode which I call simply 4x4. But there's more.

 

2. Character modes + PMG

I tried to use different dithering methods for this mode .. and I soon realized those 4 hues are quite enough. But those 4 brightness levels are not. So how could I get more ? Well we have character modes, which have 1 extra color. I can only change it per character. It would only be used for brightness lines, I don't have time to switch more colors in the kernel code anyway. Also how would I select combination of brightness and hue ? And as I said, 4 hues is surprisingly enough. So that would give 5 shades of gray, and for every character I can swap one. Obvious choice would be choosing between dark character and bright character, leaving the 3 middle colors the same, and exchanging the darkest one for the brightest one. And it actually looks way better !

But remember about those PMGs ? I can basically use them in the same way. I can spread PMG over the whole screen, with one pixel cover 1 character. And it also works like color replacement .. it replaces color 0 with color of the PMG object. For now let's ignore the fact that PMG have better vertical resolution than 1 character. I can simply treat characters like individual units of 4x4 logical pixels, and I can choose 1 of 4 sub-palettes, each carrying 4 shades of gray out of 6. It looks something like this:

 

palettes.png.ee5c65c16a2ba93f1ba739a986737dfa.png

 

You can see there is a dark palette, a middle palette, and a bright palette .. and much later I realized that the 4th palette is very useful too ! I call it high-contrast palette. During image conversion, for every character I have to choose which brightness levels best matches the image in that area, select one of these 4 brightness palettes, and set inversion bit and PMG data accordingly. That alone is quite complex problem, and I don't want to go into it now, but it's one of the areas I'm still fiddling with. Anyway, I call this mode 4x6. It gives 24 colors, still just 16 per character, but that's not a problem most of the time.

 

3. Flickering

So ok, 24 colors .. not bad for little Atari .. but that other one mode has 256. Guess I have to try the flickering. But where the old GTIA based modes used flickering to increase resolution, I would use flickering to increase color depth. I would only flicker colors very close to each other .. and it's actually way less visible, even on CRT.

I would flicker 2 frames, with 2 different images. Different color would be average of both pictures. One of the way how to look at it is that the hue lines create new hues by flickering .. and brightness lines create new brightness levels by flickering .. and it all then mixes together. It looks something like this:

 

flickering.png.729d684a1c65c1b30a2bbfb18ce06223.png

 

As you can see, I only flicker neighbor brightness levels, so the flickering is as little noticeable as possible. As for the hues, I mostly combine each with each .. there are obvious new hues on the outside of the "color wheel", but there is also very useful combination of blue and yellow, which gives gray. It's not super important, as I can get decent gray with dithering, but this helps. There is also extra brown as combination of red and green, it's mostly same as the yellow, I count it as new color anyway.

So the old 4x4 mode becomes 10x7F. 10 hues, 7 brightness levels, with flicker. That's 70 colors.

The character mode 4x6 then becomes 10x11F. There are still per character limitations, and the different gray levels mix in complex ways, but for simplicity I call it just 10x11F, and I understand the combinations as 110 different colors. That's quite enough for decent dithering.

There is one more important detail. Since I assign colors into individual frames based on their brightness, there is very common situation, where one of those two pictures is one shade darker, and the other one is one shade brighter. Or there are big area which are like this. That drastically increases perceived flickering of the image. To prevent that I mix the 2 final frames in checkerboard pattern, so on average their brightness is the same. You can see that in emulator if you pause the emulation, the stopped single picture will look very checker-boardy.

 

4. Modes comparison

Let's see some examples of individual modes (click to enlarge):

face.thumb.png.521c71b88fa7c7111cf6ba5419e3e08a.png

 

From left to right there are 4x4 and 4x6 non flickering modes, followed by 10x7 and 10x11 flickering ones. 2nd and 4th modes are character modes with PMG underlay, where I have to select proper palette for each character, the 1st and 3rd modes have total freedom of every pixel. Note the blue border, and general improvement in smoothness with increasing color count.

 

Another example:

lambo.thumb.png.df3ae7c368c4b45ed61681cdd9c3e669.png

 

Here you can see how 1st and 2nd picture do not really have gray hue .. they use other colors to dither "around" it. Also note how especially the reflection in the windshield improves.

 

And yet another, just for fun:

ww.thumb.png.aa8996a1560de56d3a25239ae2e5e555.png

 

4. Conversion

OK, now that I have you all interested in the topic, let me disappoint you with the fact I am not releasing the conversion utility today. It's a mess. There are several other sub modes and variants, each mode has like 20 parameters, there are different 6502 codes to go with each mode .. it simply needs some more work. But at least I mostly finished the experimental stage.

The conversion itself is obviously done on PC. Based on the mode I build the palette of all logical colors, and I know what hue-brightness combination is needed for each of them. For character modes I build the 4 sub palettes, and pick the best one for each character. Then variant of Floyd-Steinberg dithering is used to use only colors available at that character. Data for fields, character sets, character maps and PMG are generated, and then they are linked together with simple 6502 code, resulting in the XEXes I'm showing here.

 

5. Other uses and ideas

I've been working on this for few years now, gradually improving and adding new ideas. Over the time I used the technology in some productions. Mainly there are few photos in FLOP magazine, the last one has whole commemorative disc for our late friend.

It was also used in infamous Prodigy demo by 1NG, Poison and me. It used 6 colors only .. no PAL mixing .. in what I call B&W mode .. but the same character mode with PMG underlay and all the knowledge for subpalette selection and dithering. Final palette was then manually adjusted so it's not just black & white.

prodigy.png.241c52628226e4e99fdcd68f2a6a89a3.png

 

I also experimented with bigger screen and scrolling of this mode. I quickly dropped the idea of scrolling flickered mode .. but here I scroll character mode without PMG .. ie. 4x5. The hue palette is modified, as the source picture doesn't contain any green, so I swapped it with orange for better skin tones. Looks decent, especially on the move. Maybe it will be a game one day. It's the program named pong.xex in the ZIP.

pong.png.9156e6b1d0cd3b5d34fbc467736461c3.png

 

I also now have stand-alone image viewer, which can load the pictures from straight from disk, make a slide show with fade-in and fade-out, but that too is not ready for release just yet.

 

6. More pictures !

So here are some more picture examples. All is included in a ZIP file: rgby.zip

pic1.thumb.png.db164e9c6003ab10d311522521855705.png

 

pic2.thumb.png.793df3c10a9fcd4e951d920ade9a0613.png

 

Don't forget to turn on the PAL color mixing in the emulator ! And let me know if you use NTSC and if it by a chance works.

Edited by R0ger
  • Like 18
  • Thanks 6
Link to comment
Share on other sites

This is incredible to say the least.

 

Could I ask a favour of the utility that you create?
 

Could the utility either:

 

a] Provide a Command line interface for all modes which will dump the output to file, with an xex and an averaged image?
or

b) Have a mode that tries every single setting in different ways?
 

I would be willing to create a brute force utility that tries all different modes, with different settings. Then a user could run it, go to work and come back and there may be several thousand images they could look through and find their favourite.

 

By the way, what is the memory usage? Is it 4x8k?

Link to comment
Share on other sites

There isn't really much guessing in the conversion. There are some approaches to palette allocation, and even to dithering, and you sometimes need to fine tune the contrast and brightness to get decent results .. but it's all quite straightforward. I choose different modes based on memory requirements, if I want flicker or not, if I have PMG available or not, thing like that. If I just want to have nice picture, I use the best option.

 

As for memory requirements, it's two screens and two PMG sets .. the screens are charsets (1kB each 3 lines) and charmaps (40x25 chars), and there is some empty space in between for alignment. As you can see the XEX takes about 22kB, and there is very little code in it, it's mostly the picture data. I think about it as 2x 8kb + some extra. But it can be somewhat compressed. I used simple compression on that commemorative disc in FLOP66 and the pictures are from 8 to 18kb.

Of course, non-flickering modes should be about half of that. They are not in these examples, for simplicity I use the same XEX and just generate the same frame twice in the conversion utility :-D

Also bitmap modes are somewhat smaller, but not much.

 

 

  • Like 1
Link to comment
Share on other sites

One other tidbit from using flickered modes:  Colors on opposite sides of the color wheel will always produce a gray.  This is especially useful when doing a double Graphics 9 interlace where you swap the background using such colors (i.e. blue-yellow or magenta-green or red-cyan).

 

Interesting effects can also be had in Graphics 0 or 8 when you take artifacting into account ... swap your background between these two colors, and depending on your artifacting hardware, you end up with the 16 color IBM CGA palette (red green yellow blue magenta cyan and grey)

Link to comment
Share on other sites

I just tried these out myself ... and they are brilliant.  Even the full frame flicker on these is not bad!

 

Some other thoughts ...

 

I wonder what these would be like on the new Sofia card which lets you vary the shading by 16 steps instead of 8.

 

Also ... What would potentially be the result if you used Graphics 11 for the chroma lines, atop Antic 4, and then flicker them every frame, I wonder ... basically you would have almost a 256 level chroma atop a high res picture, so I think it would be potentially close to true color resolution.

  • Like 1
Link to comment
Share on other sites

1 hour ago, Synthpopalooza said:

I just tried these out myself ... and they are brilliant.  Even the full frame flicker on these is not bad!

 

Some other thoughts ...

 

I wonder what these would be like on the new Sofia card which lets you vary the shading by 16 steps instead of 8.

 

Also ... What would potentially be the result if you used Graphics 11 for the chroma lines, atop Antic 4, and then flicker them every frame, I wonder ... basically you would have almost a 256 level chroma atop a high res picture, so I think it would be potentially close to true color resolution.

 

Hm .. could solve some issues with chroma, like the blue border. And lower res in chroma might be no problem. Might try it. Amount of colors would be mind boggling .. 15x15 chromas ..

  • Like 1
Link to comment
Share on other sites

Would be a bit less on char mode... maybe like 13x13 or so.

 

Reason why:  activating GTIA 11 in Antic 4 reorders the chromas.  #11 and #14 cannot be used, the others are used alternately depending on ATASCII>127 ... I named this mode Graphics 12.11.

 

Off my own memory:  chromas 0 (BG),1,4,5 are universal

 

Chromas 2,6,8,9,10 are only for ATASCII<128

 

Chromas 3,7,12,13,15 are only for ATASCII>127

 

I have a chart for these somewhere that has the bit patterns needed for these colors... 

Link to comment
Share on other sites

51 minutes ago, Synthpopalooza said:

Would be a bit less on char mode... maybe like 13x13 or so.

 

Reason why:  activating GTIA 11 in Antic 4 reorders the chromas.  #11 and #14 cannot be used, the others are used alternately depending on ATASCII>127 ... I named this mode Graphics 12.11.

 

Off my own memory:  chromas 0 (BG),1,4,5 are universal

 

Chromas 2,6,8,9,10 are only for ATASCII<128

 

Chromas 3,7,12,13,15 are only for ATASCII>127

 

I have a chart for these somewhere that has the bit patterns needed for these colors... 

 

Ah, you're right ! That complicates things quite a bit.

Anyway I remembered I did actually try it some time ago .. but I wasn't able to adapt the dithering algorithm to the fact pairs of pixels share chroma. Now I think the solution is obvious .. treat chroma and luma as separate channels and process them separately. But that means rewriting the convertor from scratch. On the other hand it could simplify some thing ..

 

Edited by R0ger
Link to comment
Share on other sites

The reason you lose some values in Antic 4 and 5 is due to the fact you can only have PF2 or PF3 generated per colour cell, not both.

Which equates to AN0-1 pairings 10 and 11 (AN2 is disregarded re graphics data in GTIA modes)

 

So you lose certain bit pair possibilities.  But really, there's little point doing GTIA modes when you can equally do so in Antic 2 aka Gr. 0

The only application I see where you'd want Antic 4 is if you were alternating GTIA mode with normal mode 4 to get extra chunky colour on one line then 4 of 5 lumas in 160 res on the other line.

Edited by Rybags
Link to comment
Share on other sites

10 hours ago, Synthpopalooza said:

That is the application here I think ... doing the striping across character mode to get the PAL blending effect.

 

Which brings me to another suggestion:  Jittering the display up and down a scan line helps with the color mixing for NTSC machines using this technique.

 

That wouldn't work really .. first the chroma lines would have to be brighter, you can't really tell what color they are at 0 brightness .. and the whole concept of minimizing flicker would be thrown out of the window. Also the frame averaging relies on the bright pixels to be on the same place.

 

Link to comment
Share on other sites

On 8/14/2022 at 10:16 AM, tebe said:

R0ger are you using the 480i method from Rybags ?

No. I don't see how it could help. This mode suffers from scanline look, as every other line is dark. But shifting it up and down half a line wouldn't improve it much. And shifting it up and down whole line wouldn't work either, see my previous response.

 

Link to comment
Share on other sites

Just now, Gunstar said:

I bet the RGBY colors of these modes would look even more incredible on an RGBY TV!

Links for anyone who has been living under a rock concerning RGBY TV's.

 

https://www.pcmag.com/encyclopedia/term/rgby

 

https://en.wikipedia.org/wiki/Quattron

 

 

Link to comment
Share on other sites

On 8/11/2022 at 1:24 AM, R0ger said:

So first there is the idea of mixing hue information on one line with brightness information on the next line. This thing exactly is part of PAL TV signal norm. More specifically the hue is encoded as phase of carrier signal, and the phase has the opposite meaning on even and odd lines. In the final image the hue of two subsequent lines is averaged together. This system is used to eliminate effects of signal reflection induced phase shifts. That doesn't bother us today, but the function is still there.

So if we use the darkest possible colors on one line, and just shades of gray on the next line, then what we will see is mostly the brighter gray line, but being colored by the colors from previous line. And it's not that it just "looks like it". It's not optical illusion. Any PAL TV actually mixes the colors together. And not just PAL TV. Many TVs do that even for NTSC signal, it's worth trying !

Actually, this is not quite how PAL is working. PAL uses 4:2:0 sampling, which means that the chroma signal is subsampled in both horizontal and vertical direction, the latter due to phase inversion and averaging as you say. However, that means that you can only mix hues, not luminances. In other words, if you have gray of one intensity one line, and a saturated color of another intensity in the next line, then surely both lines will share the same color (namely, the average of the two lines, a half-saturated color), but the luminances of the two lines will still be different: The luminance of the gray in the first line, and the luminance of the saturated color in the second line. Hence, this scheme works only well without distortions if the luminance values of the colors to be mixed are identical, or otherwise you see some false contrast.

Link to comment
Share on other sites

11 hours ago, thorfdbg said:

Actually, this is not quite how PAL is working. PAL uses 4:2:0 sampling, which means that the chroma signal is subsampled in both horizontal and vertical direction, the latter due to phase inversion and averaging as you say. However, that means that you can only mix hues, not luminances. In other words, if you have gray of one intensity one line, and a saturated color of another intensity in the next line, then surely both lines will share the same color (namely, the average of the two lines, a half-saturated color), but the luminances of the two lines will still be different: The luminance of the gray in the first line, and the luminance of the saturated color in the second line. Hence, this scheme works only well without distortions if the luminance values of the colors to be mixed are identical, or otherwise you see some false contrast.

Yes, that's the idea. Chroma is shared, luma is not. The even lines have constant, lowest possible luma, and are basically black. But they still carry to color information, and pass it to next line. Then next line then carries the luma.

Link to comment
Share on other sites

16 hours ago, thorfdbg said:

Actually, this is not quite how PAL is working. PAL uses 4:2:0 sampling, which means that the chroma signal is subsampled in both horizontal and vertical direction, the latter due to phase inversion and averaging as you say. However, that means that you can only mix hues, not luminances. In other words, if you have gray of one intensity one line, and a saturated color of another intensity in the next line, then surely both lines will share the same color (namely, the average of the two lines, a half-saturated color), but the luminances of the two lines will still be different: The luminance of the gray in the first line, and the luminance of the saturated color in the second line. Hence, this scheme works only well without distortions if the luminance values of the colors to be mixed are identical, or otherwise you see some false contrast.

This description of PAL blending is good but I'm not sure it's accurate to describe analog PAL as produced by the Atari as 4:2:0 or subsampled vertically. It is true that some PAL digital formats sample 4:2:0, but analog PAL video still transmits U and V at full resolution on each scanline, just that V inverts every other scanline so the display can cancel phase errors if it wants to. However, there are PAL displays and capture devices that don't do this averaging and can display full vertical chroma resolution. One of the results is that people notice the quirk of the PAL GTIA where the hues are encoded imperfectly between even and odd lines and see stripes on what should be solid areas of color. This wouldn't be possible with vertically subsampled chroma.

 

SECAM, on the other hand, is actually encoded at half vertical chroma resolution, with chroma red/blue alternating on each scanline. True FGTIA-based systems are so rare, though, that we have very little evidence of the actual displays produced by these systems.

 

  • Like 1
Link to comment
Share on other sites

It'd be more accurate to say that's how most PAL compatible DVDs are encoded.

 

Most recording schemes throw away some information vs what you could perfectly produce - the old home video tape formats for a start.

Chances are not much footage would exist any more on the other formats like UMatic - anything worth keeping would have been digitized years ago.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...