More then 4096 colours on OCS/ECS possible?

[TroyWilkins]

I know that technically it isn't possible, but I know that a technique has been used where they rapidly cycled between 2 of the "normal" colours, and because of persistence of vision, another colour appears to be on the screen which is a mix of the 2 colours.

While I don't think that this technique could be used in HAM mode, could it be used in say 16 colour mode to simulate colours that aren't possible with the 12-bit colour pallette on OCS/ECS, or am I overlooking something obvious, in which case, I apologise.

[robinsonb5]

Originally Posted by TroyWilkins

While I don't think that this technique could be used in HAM mode, could it be used in say 16 colour mode to simulate colours that aren't possible with the 12-bit colour pallette on OCS/ECS, or am I overlooking something obvious, in which case, I apologise.

It's certainly possible - I've done this myself, alternating two copperlists to make a gradient smoother.


It can be done with images too, but it gets more resource intensive then, since you need two copies of the image! (If you have the RAM to spare there's no reason why you couldn't use it to improve a HAM image, either.)

[no9]

Lionheart game uses this for backgrounds.

[alexh]

The intro screen to Thalion's leaving teramis also simulates more colours using interlaced dithering

[TroyWilkins]

Originally Posted by robinsonb5

It can be done with images too, but it gets more resource intensive then, since you need two copies of the image! (If you have the RAM to spare there's no reason why you couldn't use it to improve a HAM image, either.)

Could it be done by just changing the colours in the CLUT (Colour Look Up Table), and so only needing to be done with the colours you want to change, thus saving on the RAM needed to have two copies of the image? Obviously this couldn't work for all display modes, but I can't see why it couldn't work for say a 32 colour low res non interlaced screen.

I apologise if this is a stupid idea, as I admit I'm not much of a programmer.

[thellier]

This not stupide it will works: you will have 32 colors that are not in the 4096 palette
But you will still have only 32 colors on screen so not much usefull

If you use the technique with 2 HAM pictures you will have new colors too but also more colors on screen: anyway finding a good algorithm to generate those 2 HAM pictures wont be easy

[thellier]

I had thought a few about the 2 ham pictures méthode
With ocs/ecs we have 16 levels of red,16 of green,16 of blue so 16x16x16 RGB colors
So if we were using a color like R 4 G 6 B 8
And want a more precise non existing color like
R 4.5 G 5.5 B 8
We can average (alternate the pictures) those colors (and obtain the new color)
R 4 G 6 B 8 and R 5 G 5 B 8
But due to HAM limitations it is not sure we can generate exactly those 2 pixels/color at this place on the screen
It is a very complex problem so I doubt that this 2xHam method was ever used...

[robinsonb5]

Originally Posted by thellier

It is a very complex problem so I doubt that this 2xHam method was ever used...

It's an interesting puzzle, isn't it?
Where it might actually be useful, is in reducing HAM fringing, since by overshooting each correction it would potentially be possible to correct two channels per pixel rather than just 1.

[TroyWilkins]

Originally Posted by thellier

This not stupide it will works: you will have 32 colors that are not in the 4096 palette
But you will still have only 32 colors on screen so not much usefull

If you use the technique with 2 HAM pictures you will have new colors too but also more colors on screen: anyway finding a good algorithm to generate those 2 HAM pictures wont be easy

Yes, but my interest is in seeing colours that wouldn't otherwise exist on that hardware.

Originally Posted by thellier

I had thought a few about the 2 ham pictures méthode
With ocs/ecs we have 16 levels of red,16 of green,16 of blue so 16x16x16 RGB colors
So if we were using a color like R 4 G 6 B 8
And want a more precise non existing color like
R 4.5 G 5.5 B 8
We can average (alternate the pictures) those colors (and obtain the new color)
R 4 G 6 B 8 and R 5 G 5 B 8
But due to HAM limitations it is not sure we can generate exactly those 2 pixels/color at this place on the screen
It is a very complex problem so I doubt that this 2xHam method was ever used...

Yes, this would be very interesting.

I think I may have to try some experiments in deluxe paint...

[thellier]

Originally Posted by robinsonb5

It's an interesting puzzle, isn't it?

Yes really :-)


If you have the first picture then obtaining the second is simple
for example if you have a pixel with red 5 and want red 5.5 then the second one must be red 6
But you can also choose an other value as red 2 so red 9 that will give red 5.5 too ... but with blinking ... but giving more latitude for choosing pixels in both pictures
In fact if you choose 2 pixels with an r g b distance of 1 then then 2 pixels must be in color cube of 2x2x2 that surround the wanted color value
So giving 8 possibilities for pixel1 and 8 for pixel 2
So 64 combinations to choose
If the r g b distance can be 4 without too much blinking then 4x4x4 cube so 4096 combinations ...arghh

[robinsonb5]

Originally Posted by thellier

Yes really :-)


If you have the first picture then obtaining the second is simple
for example if you have a pixel with red 5 and want red 5.5 then the second one must be red 6

Yes indeed, however with HAM the error of 0.5 you get from wanting 5.5 is probably smaller than the error you get from not being able to adjust green and blue at the same time. So a more interesting possibility here is, for example:
You currently have red 4 and want red 5. Set red to 6 in the first frame and leave it at red 4 for the second. The two frames now average to red 5, and you're free to adjust green or blue in the second frame!

[thellier]

Of course
From my own experiments propagating the RGB error (error=error + wantedRGB - obtainedRGB) give the better results for HAM: i mean reducing the colors to 4096 or Floyd dithering it before the conversion to HAM proved to ne a bad idea
http://aminet.net/package/gfx/conv/DatatypeToHam
Anyway having .5 value for a R G B component would mâle sense for gradients in a single RGB direction
Typically photos with sky gradient (so in blue) may looks better

[thellier]

Note: even if we obtain 0.5 colors it will be only a 8192 colors picture so far away from true colors

[TroyWilkins]

Originally Posted by thellier

Note: even if we obtain 0.5 colors it will be only a 8192 colors picture so far away from true colors

Yes, well, less than that, but even still, I think in this case the law of diminishing returns applies. What do I mean by that? Well, lets compare the difference that just increasing the number of colours, without changing resolution. If we go from 16 colours up to 256, it can make a HUGE difference. If we then go up to 4096 it makes a difference again, but it's not as huge as the difference between 16 and 256. Once we get up to 16-bit vs 24-bit the difference is even smaller.

If we can get colours in between the 4 bit colours in the OCS/ECS palette and gain a few more colours with this method, it will make a difference, depending on the picture of course.

[grond]

Originally Posted by thellier

Note: even if we obtain 0.5 colors it will be only a 8192 colors picture so far away from true colors

I don't think this is correct. You can get twice as many shades of each R, G, and B component. This means that instead of a 12 bit palette we should get a 15 bit palette, hence, 32768 colours which is Mac hicolor. I suspect the eye will be able to spot the flickering of the green component, though, as the eye is most sensitive for greens.

[TroyWilkins]

Originally Posted by grond

I don't think this is correct. You can get twice as many shades of each R, G, and B component. This means that instead of a 12 bit palette we should get a 15 bit palette, hence, 32768 colours which is Mac hicolor. I suspect the eye will be able to spot the flickering of the green component, though, as the eye is most sensitive for greens.

Good point. Also perhaps we could get a 0.25 increment by using more than a single increment or decrement. So maybe 0000FF and 0000CC, which should give something like 0000E3 in theory, although the chance of flicker being more perceivable with a larger difference between the two colours being alternated between.

[grond]

Originally Posted by TroyWilkins

Also perhaps we could get a 0.25 increment by using more than a single increment or decrement.

I'm not sure what you mean. All possible differences between two 4bit values are either odd or even. The even differences will always average to one of the original 4bit values and no new value. The odd differences will bring the one extra bit of precision. However, many odd differences will coincide in the same output value. E.g. 5 and 6 will be averaged to 5.5 but so would 4 and 7. Hence you only get the one extra bit of precision per colour channel.


However, in theory you could use some PWM scheme with a higher temporal resolution. E.g you could create four different colours out of the colour values 5 and 6 if you used three consecutive frames: 5,5,5 (old); 5,5,6 (new); 5,6,6 (new); and 6,6,6 (old). Obviously with just 50 or 60 Hz framerate this would visibly flicker and not really blend.

[roondar]

Flashing between two colours every frame is an oft-used technique in the C64 world to add extra perceivable colours to the palette. On the C64, there are 136 combinations you can make based on the 16 base colours. Many of those cause a large amount of visible flicker.

However, colours that are close (better yet: identical) in luminance fare a lot better. Colours that are also close in chroma value get best results, with in some cases barely perceivable flicker.

The question is mostly whether or not it's worth it on the Amiga. On the C64, these kind of effects where best suited for smaller areas of the screen (such as a few sprites here and there). Though there were some exceptions (Dragon Breed on the C64 famously uses a non-existent colour using this technique for the big dragons you fly past on level 3). It also tends to look better on a real CRT as in many cases the phosphors will blend together between frames ever so slightly.

My guess is that doing this full-screen will be a lot more distracting that choosing to do it for some smaller elements. Then again, on the Amiga the differences between two colours can be made a lot smaller than on the C64, which might mitigate most of the flicker.

[robinsonb5]

Originally Posted by roondar

The question is mostly whether or not it's worth it on the Amiga.

My guess is that doing this full-screen will be a lot more distracting that choosing to do it for some smaller elements. Then again, on the Amiga the differences between two colours can be made a lot smaller than on the C64, which might mitigate most of the flicker.

I did try it once with a chequerboard floor fading to a fog colour - I used 6-bit colour resolution, mapping bits 5:2 to the Amiga's standard 3:0 bits, then mapping bit 1 to a pixel-based dither and bit 0 to a temporal dither. It looked OK on real hardware (as long as that hardware's fast enough to run the demo at 50Hz!) but obviously looks awful on a emulator that's not frame-synced.

[thellier]

Yes you are right it will give a 15 bit palette, hence, 32768 colors
Even if I am not sure this method can access all those colors as the second picture can only Modify (HAM) a single R G B channel at a time
I mean
to obtain RGB 4.5 8.5 2.5
with
pixel pic1 RGB 4 8 2
and
pixel pic2 RGB 5 9 3
is probably not possible and certainly we will have only
pixel pic2 RGB 4 9 2 due to ham limitations ...

Perhaps a (not so complicated) method to create those 2 pictures would be to use an error propagation method to create simultaneously pic1 and pic2 pixels

for each pixel add the pic1 error to pic2 error to compensate in pic2 what have missed in pic1