When number of colors are limited

[mr_lou]

The Amiga (OCS) had a 32-entry CLUT (using a 12-bit palette), and the 6th bitplane, when enabled, would halve the brightness of any given pixel (EHB - Extra-Half-Bright).

From that quote, it seems to me that we are switching the terms. You seem to be using color-table to define "the colors chosen", and the palette to define "colors you can choose from".

Hm, I find it confusing.

[Sykobee (Briggsy)]

Yeah, the CLUT defines the chosen colours.


It's a lookup table - e.g., a pixel's value is 68 - the graphics hardware will look up entry 68 in the CLUT to get the actual colour to display.


I'd say the Amstrad CPC has a 16 entry CLUT and a 27 colour full palette (or colourspace?) - using modern terminology.


In the past the term "palette" was used for the chosen colours in the CLUT - as in an artists palette which is a subset of the possible colours the artist could choose to paint with.

[mr_lou]

So.... on the Sony Ericsson Aino cellphone, the specs says it can display 16.7 million colors. That would be the palette then? When coding though, I'm limited to 65536 colors. That would be the color-table then? So this phone has a 65536 entry CLUT and a 16.7 million full palette?

So what do I call the 32 colors I choose to actually work with, picked from the color-table? If "palette" is a term of the past, what is then used nowadays?

[MaV]

mkay, CLUT = Color Lookup Table.

Then it's correct call "the colors chosen" for the palette and "the colors you can choose from" for the color-table?

From http://en.wikipedia.org/wiki/Colour_look-up_table
There it says that the CLUT (color-table) is actually the maximum number of colors which can appear on the screen simultaneously. That fits fine with how I see it.

Then I'd say that the color-table on the CPC consists of the 27 colors. And the palette is whatever 4 or 16 colors we choose to use. The socalled "full palette" is not really interesting in this relation, as far as I can see.

It's always colour look-up table. Colour-table makes no sense. You look up the colour in the CLUT, the value of which points to a colour in the palette (the colours that the machine is capable of showing physically).

So it is the other way around: The aforementioned INKs are equal to the CLUT (CPC: 0-15) while the palette is equal to the colours on the CPC that you can choose from (27 all in all).

The normal VGA can display 256 colours at any moment. This 8-bit value (one of 256 combinations) is used by the CLUT in the VGA card to point to a colour in the palette of 262144.

There we have a term that can (or should) be universally understood (and I've forgotten over time).

[arnoldemu]

The way I think of it is this in mode 0.

0->27 is the palette, you can think of it also as the inks. it is all the possible colours the cpc can use.

0->15 are the pens. these are the number you can have at the same time in the current mode.
then you set an ink for the pen. The ink is one of the numbers from the palette.


In other terms:

the clut are the pens. This "table" says which ink is set for each pen.

the hardware reads a pixel value from memory, this is the pen to use. It then looks up the ink. It shows that on the monitor.

the hardware reads a pixel value, it uses the clut to find the ink. it shows that on the monitor.

The palette would be the total possible inks that can be chosen.


EDIT: Gimp thinks of this as an "indexed" image. Each pixel is an index. The index looks up in the palette. The palette gives the r,g,b value.
Computers do it similar. Each pixel is an index, the index looks up in the colour table, the colour table defines the index of the final r,g,b colour.

The other way to work with images is called "rgb". Here each pixel is the r,g,b. You may be restricted in the number of possible r,g,b combinations. In 8-bit you are limited to 64 possible r,g,b values.

[Sykobee (Briggsy)]

So.... on the Sony Ericsson Aino cellphone, the specs says it can display 16.7 million colors. That would be the palette then? When coding though, I'm limited to 65536 colors. That would be the color-table then? So this phone has a 65536 entry CLUT and a 16.7 million full palette?

So what do I call the 32 colors I choose to actually work with, picked from the color-table? If "palette" is a term of the past, what is then used nowadays?

That simply means that the actual screen display (physical hardware) can show 16.7m colours, but the operating system software is forced into 16-bit true-colour mode (probably for performance reasons) despite the hardware supporting it.


I don't think many systems ever supported more than 256 colours in a CLUT (unless they had several 256-entry CLUTs - e.g., arcade games).


The colours that you pick to use, via whatever mean, are just the colours that you've picked to use. You can call them whatever, maybe your "game palette".

[mr_lou]

Although the SE Aino phone can show 16.7 million colors, J2ME can only show 65536 colors. So first thought is that the 65536 colors are the CLUT - but no. Because you can't define these 65536 colors. They are always static.
So the 65536 colors must simply just be the palette. It can produce 65536 colors, and it can show all of them at the same time. So I guess that's just RGB? There's no CLUT here, is there?

I'd like to find some common way of describing in one sentence:
1) The few colors chosen to use,
2) the palette the colors are compatible with,
3) and less important; the full palette

Someone saying "I only use 16 colors", isn't telling much.
But if you say "I use 16 colors from a 65536 palette but with a 4096 color compatibility" tells more.
Or even better: "I use 16 colors from a 65536 color / 16bit (5:6:5) palette, but with a 4096 color / 12bit (4:4:4) compatibility" - that's really giving all the data that could be useful, isn't it?

[mr_lou]

Gimp thinks of this as an "indexed" image. Each pixel is an index. The index looks up in the palette. The palette gives the r,g,b value.

So if an artist creates a picture; a 16 indexed colored PNG or GIF file, would it then be correct to say that he's using a 16 entry CLUT from a 16.7 million palette?

[TotO]

When you use 2 bytes (16bit or 15bit + 1bit transparency) or 4 bytes (24bit colors + 8bit alpha) to code a pixel on the screen, you don't use a CLUT but the direct true color value.

15bit = 5R5G5B1A (1 transparency level)
16bit = 5R6G5B (suck)
24bit = 8R8G8B (no more used)
32bit = 8R8G8B8A (256 transparency levels)

So if an artist creates a picture; a 16 indexed colored PNG or GIF file, would it then be correct to say that he's using a 16 entry CLUT from a 16.7 million palette?

YES!

[ralferoo]

But according to this it's more like 5 bits to red, 6 bits to green and 5 bits to blue.

This is the most usual 16-bit colour format because the eye is more sensitive to greens than red or blue (actually, it's yellowy green the eye is most sensitive too).

TotO is right though. Often the extra 6th bit on G is sacrificed for a single bit alpha, so it's 5 bits each for RGB.

The PCFX is probably the only one that's unique in not using RGB... for that, the 16-bit colour mode is 8-bit Y, 4 bit U, 4 bit V. 

[MacDeath]

If I remember correctly, some MSX had 256 colours palette was it MSX2 ?
MSX TurboR was somewhat "half true colour" too.
Enterprise64/128 also had some strange colour nomber.

[mr_lou]

Are there any standard rules about semi-transparency then?

I mean, if for example a machine use 5 bits for each channel, is it then certain that 5 bits is also assigned to the semi-transparency, giving it 32 levels of semi-transparency?

[ralferoo]

Are there any standard rules about semi-transparency then?

I mean, if for example a machine use 5 bits for each channel, is it then certain that 5 bits is also assigned to the semi-transparency, giving it 32 levels of semi-transparency?

I'd say, if there's 5 bits each for RGB, it's almost certain that there's only 1 bit for alpha, because that adds up to 16 bits. It's "unlikely" a designer will make a palette register cross a word size boundary for alpha, although having said that PC Engine uses 9 bit palettes even though it uses byte IO so it can have 3 bits each of RGB.

If you had 4 bits per channel, you *might* have 4 bits of alpha, but that's by no means guaranteed. Usually, alpha was either on or off until about the late 90s when the first 2D accelerators started to become common.

[arnoldemu]

There is a difference between what the hardware can support in terms of indexed and truecolour (where r,g,b are encoded into a pixel) and what an image format supports such as png.

generally hardware supports various formats including compressed ones.

All formats can be used and it depends on the amount of colours and level of transparency you can get away with.

1 bit alpha is like punch through, either fully transparent or fully opaque. Then there is 8-bit transparency for various levels of transparency.

Let's also not forget, for modern consoles you still have memory problems, you still have to compress textures and choose different pixel formats. You still have cpu bottlenecks and gpu bottlenecks and have to use tricks to get around them. You can also fill up a DVD very quickly too and have to compress the data on the dvd.

There is never enough gpu ram or cpu ram, or cpu/gpu power.
Here i talk about ps3, xbox360 etc.

I know, I work with them

[mr_lou]

Is transparency considered part of the color?

If there is a 16 bit palette, is the transparency then always considered to be part of these bits? Or does it have its own register of some sort?

It would make sense if it's part of the color, but I can't connect the dots.

The Sony Ericsson Aino is listed as having 16.7 million colors. But J2ME only has 65536 colors + 256 alphalevels.
But since 65536*256 = 16.7 million, then it kinda makes sense.

But the Sony Ericsson Vivaz is also listed as having 16.7 million colors - and J2ME also does have these 16.7 million colors but still also 256 alphalevels.

How's it possible to have 16.7 million colors + 256 alphalevels? The Vivaz uses 32bit then? While the Aino uses 24bit?

[TotO]

I though to have answered to your questions...

5R5G5B1A is the 16bit format mostly used for 16/32bit videogames, computers and may be old mobile devices with poor LCD display.
Thats mean 32 RED, 32 GREEN, 32 BLUE pixels with 1 step of transparency : 0% or 100% ... (color pixel or transparent pixel if you prefer)

8R8G8B8A is the 32bit format mostly used today.
That mean 256 RED, 256 GREEN, 256 BLUE pixels with 256 steps of transparency from 0.0% to 100.0% ... (7F = 50% for exemple)


Now, you have to know if a common format is supported by the devices...

[mr_lou]

5R5G5B1A is the 16bit format mostly used for 16/32bit videogames, computers and may be old mobile devices with poor LCD display.
Thats mean 32 RED, 32 GREEN, 32 BLUE pixels with 1 step of transparency : 0% or 100% ... (color pixel or transparent pixel if you prefer)

8R8G8B8A is the 32bit format mostly used today.
That mean 256 RED, 256 GREEN, 256 BLUE pixels with 256 steps of transparency from 0.0% to 100.0% ... (7F = 50% for exemple)

5R5G5B1A <-- is that called a 15bit or a 16bit palette?
8R8G8B8A <-- is that called a 24bit or a 32bit palette?

In other words, is the alpha channel covered by the term palette?

[Sykobee (Briggsy)]

The Sony Ericsson Aino is listed as having 16.7 million colors. But J2ME only has 65536 colors + 256 alphalevels.
But since 65536*256 = 16.7 million, then it kinda makes sense.

But the Sony Ericsson Vivaz is also listed as having 16.7 million colors - and J2ME also does have these 16.7 million colors but still also 256 alphalevels.

How's it possible to have 16.7 million colors + 256 alphalevels? The Vivaz uses 32bit then? While the Aino uses 24bit?

I would guess here that J2ME has abstracted away the colour situation a long way from the hardware, except for the target framebuffer - 16 bit on the Aino and 24-bit on the Vivaz.


The transparency supported by the J2ME image APIs (blitting, etc) is probably handled totally in software, or maybe the hardware blitter - but has nothing to do with the final target framebuffer bit depth.

[mr_lou]

Well regardless of how it's handled, there's clearly some of the same limitations with colors.
Some devices can show 65536 colors, while others can show 16.7 million.
And the available color-table is calculated the same way (at least that's what I'm assuming).
I mean, if it could only show 4096 colors, I would assume it would be #000000, #000011, #000022, #000033 etc.
Anything else wouldn't make much sense.

[MaV]

I mean, if it could only show 4096 colors, I would assume it would be #000000, #000011, #000022, #000033 etc.
Anything else wouldn't make much sense.

You could do that but that would not deliver the best results, as this is the generic approach. If your picture is dominated by red for example, you would need to take that into consideration.

Let's begin with: To display all colours of 24-bit you'd have to have a display size of 4096x4096 (or equal dimensions), and then you still can only show every colour once. A current laptop display - even if the LCD could display 24-bit - would be 1366x768, so even if you assign a different colour to every pixel on the laptop screen, you can show only 281088 colours at once, that's barely above 18-bits, so 19-bit would suffice. That's 32x less colours that you can show at the same time.
But to top that off, practically you will see even less colours, simply because pictures are usually dominated by certain colours (i.e. one RGB value in a lot of pixels).

The method to transform from a greater palette to a smaller is called quantization, and there are a lot of algorithms to do that and take care of the picture's composition:
http://en.wikipedia.org/wiki/Color_quantization
And while we're at it, here's the theoretical background (although both links are lacking, you'd need a book to teach you the ideas):
http://en.wikipedia.org/wiki/Quantization_%28signal_processing%29

So, if you want to transform a 24-bit picture into 16-bits, you need to know what colours are present in the 24-bit picture, what the 16-bit format looks like, then choose the best algorithm for that. Nothing more nothing less.

[mr_lou]

It's not about displaying all the colors at the same time. It's about which colors are available.

You could do that but that would not deliver the best results, as this is the generic approach. If your picture is dominated by red for example, you would need to take that into consideration.

What I need to take into consideration in such a case, is: Which red colors are available in a 12bit palette? The answer is: #110000, #220000, #330000, #440000, #550000, #660000, #770000 etc.
So if my graphics artist has used other shades of red (like e.g. #5a0000 or #700000), then they will change when displayed on my 4096-color-limited device. The device will display them as #550000 and #770000 instead.

So, if you want to transform a 24-bit picture into 16-bits, you need to know what colours are present in the 24-bit picture, what the 16-bit format looks like, then choose the best algorithm for that. Nothing more nothing less.

I prefer just using the Posterize function of GiMP. 

[TotO]

The color space is always the same, but the shade numbers not... So, the quantization is not the solution here, because with a 15bit palette, you lose colours proportionally. (8 times less R, G and B)
You can't get more blue to use for a big sky for example.
It's why posterize was done.