I was wondering, if you hear that a certain device can only show 256 colors, what are you thinking?
1) The device can show any 256 colors you define? For example, 256 shades of blue.
2) The device has a colortable with predefined colors you can choose from, usually created by dividing each RGB channel with a factor. E.g. having 6 blues, 6 greens and 6 reds gives you the 216-colors defined as the WebSafe colors.
If you picked number 2 then you also think:
2a) These 216 colors are always used on devices that can only show 256 colors, because that's just how it works when limited colors.
2b) These 216 colors are probably used on devices that can only show 256 colors.
It has a palette of 256 predetermined colours, of which the user can use a predetermined account at any time. Or all, if a mode allows it.
But what's the point of the question?
I think that a lot of people thinks they can use any color they want. Ironically that means that even though they use only 16 colors, they would have gotten a more accurate result using 32.
Quote from: mr_lou on 09:27, 14 October 12I was wondering, if you hear that a certain device can only show 256 colors, what are you thinking?
The screen mode allow to display 8bit pixels (1x256 or 16x16 colours) from a 9, 12, 15, 18 or 24 bit palette.
If the device get a LCD display, each R G B component get the same levels. So, it's not possible to be limited to 256 colours.
The 216 colours palette (6x6x6) simulate a true color mode using a fixed palette (and probably dithering) on a 8bit screen mode.
Most existing LCD screens can display 262144 colours (worst can display 4096...).
If your screen mode can display 24bit, you lose shades on display.
But if your screen mode is lower, you can't reach them so all look perfect.
The Amiga had max 6-bit colors, meaning it could display 64 colors on the screen at the same time.
But could these 64 colors be any color you wanted? Could it be #000001, #000002, #000003, etc?
Or was the Amiga limited in a similar way as the CPC is? (The CPC can display 16 colors on the screen at the same time, but we can't choose any 16 colors we want).
If I code a gradient for J2ME, then it's very clear that some phones display this gradient very good, while other phones do not.
And I'm not talking about insanely old phones here.
So it's obvious that these phones are limited regarding how many colors they can show. I'm curious to find out how they are limited. How do I find out which colors I can use?
This is where I first assumed that I'd probably be safe if I just used the websafe color-table. But now I just learned that there's actually something called 8-bit color, which uses 3 bits for the red channel, 3 bits for the green channel, but only 2 bits for the blue channel.
http://en.wikipedia.org/wiki/8-bit_color (http://en.wikipedia.org/wiki/8-bit_color)
Maybe that's what's being used in limited devices?
I'm afraid that can vary greatly with each device.
The limitations arise from how the color is coded to how much colors the screen can really show.
For example, there are Android devices that still have 24-bit color, but 16-bit color screens....
Quote from: mr_lou on 11:30, 14 October 12
The Amiga had max 6-bit colors, meaning it could display 64 colors on the screen at the same time.
But could these 64 colors be any color you wanted? Could it be #000001, #000002, #000003, etc?
Or was the Amiga limited in a similar way as the CPC is? (The CPC can display 16 colors on the screen at the same time, but we can't choose any 16 colors we want).
The earlier Amigas had a 4096 colour pallette from which you could choose a smaller number of colours depending on the video mode, the CPC has a 27 colour pallette, while the Amstrad plus models have a 4096 colour pallette.
Is there no standard term to use when
1) talking about the amount of colors you can choose from
2) talking about the chosen colors that can displayed on the screen at the same time
E.g. the 27 colors of the CPC = "the CPC color table" while the 16 colors I pick from the 27 colors is called "my palette".
Or what?
Quote from: mr_lou on 11:30, 14 October 12
The Amiga had max 6-bit colors, meaning it could display 64 colors on the screen at the same time.
But could these 64 colors be any color you wanted? Could it be #000001, #000002, #000003, etc?
Or was the Amiga limited in a similar way as the CPC is? (The CPC can display 16 colors on the screen at the same time, but we can't choose any 16 colors we want).
On CPC Mode 0, you can chose 16 colours from 27 available, because 4bit can index 16 colors.
On Amiga OCS, you can chose 32 colours
(5bit index, not 6) from 4096 available.
But, if the program (CPC rasters) or the hardware (Amiga Copper) allow to change the index content while the screen is displayed, then you can fake the user eyes by showing more colours that expected.
Ok, here's my problem.
I have coded a gradient with J2ME. It displays nicely on a Sony Ericsson Vivaz because J2ME is given 16777216 colors on that device. But Sony Ericsson Aino is only given 65536 colors.
So now I'd like to know how to calculate the colortable used by the Aino.
Looking at the term "8-bit color (http://en.wikipedia.org/wiki/8-bit_color)", this table is calculated by using 3 bits to red, 3 bits to green and 2 bits to blue.
So I thought maybe "16-bit color" was calculated using 6 bits to red, 6 bits to green and 4 bits to blue. But according to this (http://en.wikipedia.org/wiki/High_color) it's more like 5 bits to red, 6 bits to green and 5 bits to blue.
What I'm after, is some kind of colortable, similar to the websafe colors, that are "safe" to use on 16-bit displays such as a Sony Ericsson Aino. And also for devices that can only show 4096 colors. How do I know which 4096 colors that is? (Is it 4 bits for each channel? Or is it 5*5*2? Does it vary that much, or is there some kind of standard?).
How "safe" am I if I with with using 4 bits for each channel all the time?
Quote from: mr_lou on 12:59, 14 October 12And also for devices that can only show 4096 colors. How do I know which 4096 colors that is? (Is it 4 bits for each channel? Or is it 5*5*2? Does it vary that much, or is there some kind of standard?). How "safe" am I if I with with using 4 bits for each channel all the time?
It's what I said before... If your LCD is limited, you lose shades. In all cases, the values are 2^n compatible.
To be safe, you have better to use a 12bit color-space (4R4G4B) for your programs, to look the same on all your devices.
That mean 16 shades for each component:
00, 11, 22, 33, 44, 55, 66, 77, 88, 99, AA, BB, CC, DD, EE, FF
If you need to convert GFx (photoshop, paint shop pro, ...), use the Posterize function with the value 16.
Quote from: TotO on 13:15, 14 October 12
To be safe, you have better to use a 12bit color-space (4R4G4B) for your programs, to look the same on all your devices.
That mean 16 shades for each components:
00, 11, 22, 33, 44, 55, 66, 77, 88, 99, AA, BB, CC, DD, EE, FF
That's about as far as I've gotten too. Glad to hear someone confirm it.
Posterize, nice. Didn't know I could do that. So far I just tried changing Mode to Indexed colors, and selecting the Web-safe palette. That didn't produce a great result. Posterize works much better. (Using GiMP).
Quote from: mr_lou on 13:47, 14 October 12Posterize, nice. Didn't know I could do that. So far I just tried changing Mode to Indexed colors, and selecting the Web-safe palette. That didn't produce a great result. Posterize works much better. (Using GiMP).
Yes, it's the number of shades for recomputing the RGB colour space. ;)
Some values for computers and videogames systems (colours) :
3 = CPC (27)
4 = PC EGA / Master System (64)
8 = ST / Megadrive / PCE (512)
16 = Amiga / CPC+ / STe / Game Gear (4096)
32 = Neo Geo / SNES / GBA (32768)
64 = Falcon / DS (262144)
256 = Amiga AGA / Modern computers and consoles (16777216)
Quote from: mr_lou on 12:43, 14 October 12
E.g. the 27 colors of the CPC = "the CPC color table" while the 16 colors I pick from the 27 colors is called "my palette".
Or what?
In CPC terms, the 16 colours you have are called INKs. Each INK can be set to one of the 27 colours of the CPC palette. The term INK is derived from the BASIC command INK and the parameter is called so as well. Likewise PEN and PAPER have this parameter "ink" to denote the same.
That would be the term at least, if people used it.
Quote from: MaV on 19:44, 14 October 12That would be the term at least, if people used it.
People don't use that term. And I'm not just thinking CPC here.
People often use the word "palette", and whenever I hear that word I can't help but to think "Oh? But from which color-table?"
A palette is a bunch of colors manually selected by the graphics artist.
But picking any random 16 colors from the 16.7 million choices is not optimal if you don't want the colors to automatically change when displayed on a retro platform (or cellphone).
So I use "color-table" as a term to describe the colors available, and "palette" to describe the colors chosen.
Quote from: mr_lou on 19:55, 14 October 12
People don't use that term. And I'm not just thinking CPC here.
Well, that's what I said. INK is not used, although it would fit for the CPC. It would not be understood by others.
Palette and colour-table are perfectly fine.
On those limited systems (8bit) having a whole true colour range where you can only display 16 colours is somewhat stupid.
The "Amiga500/Atari STE/Amstrad PLUS" plaette is clearly the maximum you can decently need.
Hell even a "true EGA" palette (4x4x4 = 64 colours) is quite enough actually if theorically limited to 16 inks.
And the Atari ST/SegaMegaDrive palette (512colours) is also quite enough.
Of course those old 2D bitmap displays designed for CRT monitors had a lot of tricks to cheat the number of displayed colours on the screen.
You could flicker, which is sadly not as good as it should and often cause severe epileptic crisis...
Or more simply, Raster and split rasters, even attributes is a nice way to add colours with a notorious RAM gain for Datas.
Many systems had some "software video modes", consisting of various tricks according to what the hardware could allow through experience and tweaks.
As already told, it is important to differenciate colours and inks.
While normal CPC is limited to 16 inks max, it is easily possible to display the whole 27 colours the system can produce, even additional ones through flickerings.
Of course it implies somewhat severe limitations, be it "attributes like" (scanline) or CPU time based (to interrupt, putting rasters or various effects must be processed and programmed, hence it use both RAM and CPU cycles, both being quite limited..
Quote from: MacDeath on 22:21, 14 October 12On those limited systems (8bit) having a whole true colour range where you can only display 16 colours is somewhat stupid.
The "Amiga500/Atari STE/Amstrad PLUS" plaette is clearly the maximum you can decently need.
I agree. I even think the posterize-6 / WebSafe color-table is enough in many cases.
I sometimes take a look at Pixel Art at pixeljoint.com - Forum Avatars, Buddy Icons, Sprites (http://www.pixeljoint.com)
I thought pixel artists would stick to certain limited color-tables as part of the pixel-retroness, but it doesn't seem so. I asked at their forum, and it seems that while they do enjoy seeing how few colors they can use (e.g. only 16), they still pick these few colors from the huge 16.7 million color-table.
That means that their art will look differently when displayed on certain limited devices.
It surprised me a bit that pixel artists doesn't seem to pay any attention to this. I expected it would be part of the pixel-graphics scope somehow.
Also, I'd love to see a site like IndieGameMusic.com except for graphics at IndieGameGraphics.com some day. Some graphics-artist should do it.
But it would require artists to agree on certain color-tables and palettes and putting their art into certain boxes to make it easier for game-developers to search.
E.g. "Posterize-6 compatible" means all colors used stays within the websafe space.
Or "C64 color-table" tells you all colors used are from the C64 color-table.
Then game-developers should be able to search by how many colors are used in the palette + from which color-table.
E.g. "4 colors used" from "CPC color-table" = MODE 1 compatible, and
"22 colors used" from "WebSafe color-table" = definitely shows correctly on older phones
(Then comes of course a bunch of other search criterias such as tilesize and a bunch of other stuff only a graphics-artist would know).
I made IndieGameMusic.com because I could. Being a webdeveloper + musician, it was kinda in the cards. I just can't seem to find any webdeveloper + graphics-artist anywhere who feels like doing a similar IndieGameGraphics.com
Quote from: mr_lou on 07:09, 15 October 12It surprised me a bit that pixel artists doesn't seem to pay any attention to this. I expected it would be part of the pixel-graphics scope somehow.
Sure, but only "old" pixel artists know that and take care about.
(more easy to work too)The 24-bit palette is only usefull if you need gradiants for sky, light effects, etc.
Else, the 12-bit palette is more than enough to get all sort of colours and match with 99% of the LCD device display.
The 9-bit and less palettes lack too much shades to be realistic.
(like "skin", "champagne", ...)
Many moderner pixel artists don't know about the time when computers where in 2D and limitedto bitmap world.
To them, pixel art is a style, not somehing mandatory due to machine logic limitation.
Also due to the modern machines being entirely 3D and having very diverse range of display resolution, you now have to stick to somewhat zoomable "vector pictures" even for portable devices like telephones and Androids tablets all have resolution according to screen they have.
So you can't even do real pixel art unless you autozoom, which add many colours and automatic antialiasings.
Sure, they know the style, not the limitations...
That was a shame, because they can use the good colours and pixels ratio, to look better too. ;)
Quote from: mr_lou on 09:27, 14 October 12
I was wondering, if you hear that a certain device can only show 256 colors, what are you thinking?
Commonly, that the device has a 256 entry palette (CLUT) to define which colour to show from a larger palette (12/15/16/18/24-bit) for a given pixel value.
Less commonly, a direct RGB value, I know that R3G3B2 was used by a couple of systems in the past. This bypasses the need for a large CLUT, which could use a lot of die space. Not so many greys available though.
Even less commonly, a set of colours modified from a base palette. The Acorn Archimedes had a 16 entry CLUT, but modified that palette to generate another 15 palettes to get 256 colours.
Quote from: mr_lou on 11:30, 14 October 12
The Amiga had max 6-bit colors, meaning it could display 64 colors on the screen at the same time.
But could these 64 colors be any color you wanted? Could it be #000001, #000002, #000003, etc?
Or was the Amiga limited in a similar way as the CPC is? (The CPC can display 16 colors on the screen at the same time, but we can't choose any 16 colors we want).
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).
As you can imagine, this was very often used for very quick and easy shadows in games - but not many games actually used the EHB mode.
Later Amigas (AGA) had a full 256-entry CLUT and a 24-bit palette.
Quote from: Briggsy on 15:58, 15 October 12Commonly, that the device has a 256 entry palette (CLUT) to define which colour to show from a larger palette (12/15/16/18/24-bit) for a given pixel value.
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 (http://en.wikipedia.org/wiki/Colour_look-up_table)
QuoteA CLUT is characterized by the number of entries in the palette: determines the maximum number of colours which can appear on screen simultaneously (a subset of the wider full palette, which is to be understood as the total number of colours that a given system is able to generate or manage, e.g. the full RGB colour palette).
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.
Quote from: Briggsy on 16:01, 15 October 12The 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.
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.
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?
Quote from: mr_lou on 16:52, 15 October 12
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 (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).
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.
Quote from: mr_lou on 17:18, 15 October 12
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".
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?
Quote from: arnoldemu on 17:52, 15 October 12
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?
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)
Quote from: mr_lou on 19:07, 15 October 12
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!
Quote from: mr_lou on 12:59, 14 October 12
But according to this (http://en.wikipedia.org/wiki/High_color) 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. :o
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.
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?
Quote from: mr_lou on 06:26, 17 October 12
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.
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 ;)
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?
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... ;)
Quote from: TotO on 13:07, 17 October 12
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?
Quote from: mr_lou on 11:37, 17 October 12
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.
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.
Quote from: mr_lou on 14:07, 17 October 12
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 (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 (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.
It's not about displaying all the colors at the same time. It's about which colors are available.
Quote from: MaV on 16:27, 17 October 12
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.
Quote from: MaV on 16:27, 17 October 12
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. :)
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.