 |
Welcome to the Natami / Amiga ForumThis forum is for AMIGA fans interested in the new NATAMI platform.
Please read the forum usage manual.
|
 Do you have ideas and feature wishes? Post them here and discuss your ideas. |
| 16bit Colorspace Efficiency | page 1 2 3
|
|---|
|
|---|
Thomas Richter
Germany
| | (MX-Board Owner)
Posts 1425
27 Dec 2010 15:43
| Marcel Verdaasdonk wrote:
|
i've been thinking,(brace yourself)what if we went for HSV?
H8,S3,V5 (anyone got a better proposal?)
I suppose looking at lab this would require a extra register to set white.(you have a curve for platinum heated through a variation of temperatures)
|
HSV is not standardized, there are no applications that require HSV. It would basically be a very isolated format you would create. Besides, it is rather complex for hardware to convert from/to HSV, which is needed for the VGA/DVI adapter. YUV is probably your best bet, it is actually useful and easy to convert. More perceptually relevant colorspaces are CIELab, CIEJab and friends, but none of these are very suitable for hardware, and none of them have an application domain that would require hardware support. Greetings, Thomas
| |
Megol .
| |
Posts 672
27 Dec 2010 16:11
| Samuel D Crow wrote:
|
Marcel, I know you are no artist. Artists have tried for a decade or so to take advantage of the extra bit of green in R5G6B5 resolutions. There is absolutely no benefit to having an extra bit of green over having a mask bit like the Irrlicht graphics engine uses (R5G5B5A1).
|
:0
One extra bit for green makes a big difference in picture quality. Just take some natural 24bit pictures and compare the quality when reducing to 15/16 bit color, it should be very easy to tell which is which.
| |
Claudio Wieland
Germany
| | (Natami Team)
Posts 703
27 Dec 2010 17:17
| Well, you can't get clean yellow or pure white/grey with RGB565. That's more than enough reason not to use it, at least for me. I also prefer RGB5551 or RGB1555.
| |
Gunnar von Boehn
Germany
| | (Moderator)
Posts 5775
27 Dec 2010 18:01
| Claudio Wieland wrote:
|
Well, you can't get clean yellow or pure white/grey with RGB565.
|
Not true! Reading the posts here is really funny.
| |
Marcel Verdaasdonk
Netherlands
| |
Posts 3975
27 Dec 2010 18:17
| The solution is to each his own, so are there any more formats that need some more thought?
| |
Claudio Wieland
Germany
| | (Natami Team)
Posts 703
27 Dec 2010 21:11
| Gunnar von Boehn wrote:
|
Claudio Wieland wrote:
|
Well, you can't get clean yellow or pure white/grey with RGB565.
|
Not true!
Reading the posts here is really funny.
|
OK, I take it back :D .
| |
Wojtek P
Poland
| |
Posts 1597
27 Dec 2010 21:24
| Gunnar von Boehn wrote:
|
Claudio Wieland wrote:
|
Well, you can't get clean yellow or pure white/grey with RGB565.
|
Not true!
Reading the posts here is really funny.
|
Indeed. just not using greens LSB means we have RGB555
| |
Samuel D Crow
USA
| | (Natami Team)
Posts 1295
27 Dec 2010 23:03
| Wojtek P wrote:
| | Indeed. just not using greens LSB means we have RGB555 |
Actually to nullify the LSB you have to feed the MSB value into the LSB.
| |
Loïc Dupuy
France
| |
Posts 253
27 Dec 2010 23:56
| Gunnar von Boehn wrote:
|
Claudio Wieland wrote:
|
Well, you can't get clean yellow or pure white/grey with RGB565.
|
Not true!
|
If you take extra care to avoid them, but you fall down to the 555 space, so let's add an A bit. When you look at the 16bit pc fps era with small texture, you've got the phenomena describe by Claudio Wieland for the dithering. That's because of the integer div on R,G,B, the fractional error report for the next pixel has not the same size on R,G,B
Example: First pixel is 16/32,16/64,16/32, your dithering function tell you that you have to add 1/64,1/64,1/64 for the next pixel, so the red and blue component stay the same, and your green increase, and you've got an artifact. I found them particulary annoying for my eyes and breaking aesthetism.
It's my point of view, and it differs beetween each individuals.
| |
Gunnar von Boehn
Germany
| | (Moderator)
Posts 5775
29 Dec 2010 12:42
| Loïc Dupuy wrote:
|
Gunnar von Boehn wrote:
|
Claudio Wieland wrote:
|
Well, you can't get clean yellow or pure white/grey with RGB565.
|
Not true!
|
If you take extra care to avoid them, but you fall down to the 555 space, so let's add an A bit.
|
You have to very clearly differentiate between GFX format for input or output. Both true White and true Yellow are no problem on a 16bit 5/6/5 screen. 16bit screen has the advantage of doubling the colors over a 15bit screen. As someone said before, this does makes a difference for pictures. I think we should clearly differentiate between SCREEN FORMATS and GFX FORMATS. For screen formats ALPHA makes no sense. For GFX FORMATS used in textures or BOBS an alpha format does make sense.
| |
Loïc Dupuy
France
| |
Posts 253
29 Dec 2010 16:39
| Gunnar von Boehn wrote:
|
16bit screen has the advantage of doubling the colors over a 15bit screen. As someone said before, this does makes a difference for pictures.
|
Yes but you have to take extra care in your algorithms to avoid color artifact, when you do a linear gradient beetween white and black on 64 pixels, you will have half pixel with a green tint (R&B change every 2 pixels, green change every pixel).You dithering function works as intended, but the colorspace is not symetric.
I you adapt your dithering function to produce only grey gradiant, but then you are limiting yourself to a 555 colorspace.
Gunnar von Boehn wrote:
|
I think we should clearly differentiate between SCREEN FORMATS and GFX FORMATS.
For screen formats ALPHA makes no sense.
|
On the Falcon, there was the 565 mode and the A555 for genlocking, so screen formats ALPHA can have a meaning.Especially, if we use the blitter brute force for composing 2 screens (cookie cut). Gunnar von Boehn wrote:
|
For GFX FORMATS used in textures or BOBS an alpha format does make sense.
|
So you are meaning, that we will be able to cookie cut 1555 graphics on a 565 screen ?
| |
Wojtek P
Poland
| |
Posts 1597
29 Dec 2010 16:57
|
How about nonlinear color scale ?
with colors from 0-31 there is much more perceived difference between 0 and 1, and between 30 and 31..
| |
Gunnar von Boehn
Germany
| | (Moderator)
Posts 5775
29 Dec 2010 17:14
| Loïc Dupuy wrote:
|
Gunnar von Boehn wrote:
|
I think we should clearly differentiate between SCREEN FORMATS and GFX FORMATS.
For screen formats ALPHA makes no sense.
|
On the Falcon, there was the 565 mode and the A555 for genlocking, so screen formats ALPHA can have a meaning.
Especially, if we use the blitter brute force for composing 2 screens (cookie cut).
|
AMIGA RTG system do NOT support ALPHA modes.
Any reserved alpha bits are just wastes space on AMIGA RTG systems. Loïc Dupuy wrote:
|
Gunnar von Boehn wrote:
|
For GFX FORMATS used in textures or BOBS an alpha format does make sense.
|
So you are meaning, that we will be able to cookie cut 1555 graphics on a 565 screen ?
|
This would waste 32768 colors
The better solutions is using a single key-color,
this leaves you the full range of 65535 colors. A HW 16bit mode is the best solution.
A HW 16bit mode gives you all 65536 colors.
If an applications does NOT want to use the full range but wants 15bit - then just leave the Lowest Bit away then you have your 15bit effect on the 16bit screen.
| |
Wojtek P
Poland
| |
Posts 1597
29 Dec 2010 18:14
| Gunnar von Boehn wrote:
|
A HW 16bit mode is the best solution.
A HW 16bit mode gives you all 65536 colors.
If an applications does NOT want to use the full range but wants 15bit - then just leave the Lowest Bit away then you have your 15bit effect on the 16bit screen.
|
Simple and best. thanks for explanation!Anyway what about EHB-style coding 5 bits for each color - up to half of max brighness
1 bit - doubling of brightness. wait 20 minutes i will make a short demo
| |
Wojtek P
Poland
| |
Posts 1597
29 Dec 2010 18:40
| demo done
original image, unpacked from jpg , scaled down to 1024x768, packed lossless to png
http://www.tensor.gdynia.pl/~wojtek/colorspace-comparision/RGB888.png
the same image coded as RGB565 (actually still RGB888 but with stripped data to reflect RGB565, red and blue have masked out 3 LSB's, green 2 LSB's)
http://www.tensor.gdynia.pl/~wojtek/colorspace-comparision/RGB565.png
the same image coded as RGB555+EHB bit.
actually RGB888 with masked out 3 LSB's on every color if any of colors are above 0x7F, or 2 LSB's otherwise.
http://www.tensor.gdynia.pl/~wojtek/colorspace-comparision/RGB555+EHB.png
then RGB555 image (all colors have 3 LSB's masked out)
http://www.tensor.gdynia.pl/~wojtek/colorspace-comparision/RGB555.png
| |
Loïc Dupuy
France
| |
Posts 253
29 Dec 2010 19:03
| Interesting benchmark, the best one is obviously the RGB888 :-D On this example the best 16bit one is the RGB565 obviously.
The gradient are smoother in the sky, and the dark area under the trees is more precise. The RGB555+EHB is not so bad for the dark area, but it is not really better than the RGB555 for the sky. With at least 256MiB of RAM, do we have to limit ourselves to 16 bits graphics outside emulation and ports ? 24bits is the way to go, even in 1280x1024, 256MIB is equivalent to ~65 1280x1024x24bits screens, it means a lot of room for keeping 2D images, and with the hard disk, we can download them during play like SWIV Frankly gradient are so smoother in 24bits.
| |
Wojtek P
Poland
| |
Posts 1597
29 Dec 2010 19:10
| Loïc Dupuy wrote:
|
Interesting benchmark, the best one is obviously the RGB888 :-D
On this example the best 16bit one is the RGB565 obviously.
The gradient are smoother in the sky, and the dark area under the trees is more precise. The RGB555+EHB is not so bad for the dark area, but it is not really better than the RGB555 for the sky.
|
RGB555+EHB is exactly the same as RGB555 on bright areas - because colors are brighter than half.
This depends on image - that's why i put it to view.
the image isn't perfect for comparision - if you have some image (photo or raytraced) that was NOT compressed by JPG prior please send me.
RGB555+EHB is for sure better than RGB555, but if it's better than RGB565 is up to discussion. it depends on image and it's not much better for sure.
With at least 256MiB of RAM, do we have to limit ourselves to 16 bits graphics outside emulation and ports ?
|
Limiting and having a choice are 2 different thing.
16 bits IS FASTER TO PROCESS. much faster.
Natami is able to display truecolor RGB888.
16 bits means everything is word aligned. it especially is important for blitter and 3D core. physical DRAM access is 8 or 16 bytes, so it fits 4 or 8 points and 16-bit color, but some point in 24-bit coding will wrap around.
for 3D core taking textures it makes BIG difference in performance.
and don't forget i intentionally made no dithering to test images.
do you like test YCbCr coded images too?
| |
Gunnar von Boehn
Germany
| | (Moderator)
Posts 5775
29 Dec 2010 19:38
| Many thanks for the demo.
I like your attitude to test something in real instead guessing!Wojtek P wrote:
|
do you like test YCbCr coded images too?
|
Yes this would be nice to compare!
| |
Wojtek P
Poland
| |
Posts 1597
29 Dec 2010 19:46
| Gunnar von Boehn wrote:
|
Many thanks for the demo.
I like your attitude to test something in real instead guessing!
Wojtek P wrote:
|
do you like test YCbCr coded images too?
|
Yes this would be nice to compare!
|
here it is
http://www.tensor.gdynia.pl/~wojtek/colorspace-comparision/YCbCr21.pngi really can't see a difference! the coding is 2 points per 32-bit. as memory is always accessed with more than that - its fine. the coding is in bytes Y1,Cb,Y2,Cr Y1,Y2 - luminance for this 2 points
Cb,Cr - chrominances - each is average for that 2 points. i think i can demonstrate 8BPP coding that won't be visibly worse than RGB565 if you wish, but it will need to be 32-bit for 2x2 pixel block. bad for display output,but maybe good for textures?
| |
Loïc Dupuy
France
| |
Posts 253
29 Dec 2010 20:12
| The YCbCr21 example is impressive, nearly the 24bits quality. For 2D games, it is a bit awkward format to manipulate, a bit like the old 8 bits with color clashes :-) I do not have loseless pictures, but a quick search on internet give me this 3 links
EXTERNAL LINK EXTERNAL LINK EXTERNAL LINK
Not the ideal pictures for a test, but i did not found better, sorry.
| |
|
|
|
|
