| 16bit Colorspace Efficiency | page 1 2 3
|
|---|
|
|---|
Wojtek P
Poland
| |
Posts 1597
29 Dec 2010 20:21
| Loïc Dupuy wrote:
|
The YCbCr21 example is impressive, nearly the 24bits quality.
|
There are special cases for that format - things with thin colorful stripes will have colors changed.
For 2D games, it is a bit awkward format to manipulate, a bit like the old 8 bits with color clashes :-)
|
As i've said you have RGB888 available. For this IS faster to manipulate by Natami coprocessors if implemented, while being nearly same quality!
to test
http://www.tensor.gdynia.pl/~wojtek/colorspace-comparision/flower.png
http://www.tensor.gdynia.pl/~wojtek/colorspace-comparision/flower-YCbCr.png
this format is NOT that difficult to manipulate.
YCbCr colorspace still have same rules that RGB - it's linear colorspace
You want to colors of 2 points - just add it as in RGB
you want to dim pixels 2 times - just divide by 2 like in RGB.
just you have Cb and Cr values one for 2 points.
BTW. YCbCr colorspace was invented with color TV, long before there were ANY displays for computers available :)
nothing new, as most things in computers.
| |
Thomas Richter
Germany
| | (MX-Board Owner)
Posts 1425
29 Dec 2010 20:50
| Wojtek P wrote:
|
here it is
http://www.tensor.gdynia.pl/~wojtek/colorspace-comparision/YCbCr21.png
i really can't see a difference!
|
Certainly. It's an "old hat" as we say in Germany. There's a reason why video uses YUV422 (this is the name used in the field for this format), and why color TV (NTSC) uses this format. Actually, PAL is even YUV420, i.e. one luma sample (U and V) for *four* chroma samples. But that's probably harder to do in hardware, thus I guess YUV 422 is fine.BTW, old JPEG is almost exclusively YUV 420 (for the same reason) even though 444 is supported, ditto JPEG XR. JPEG 2000 doesn't require subsampling - wavelets can do that much more economically. Thus, "no surprise" for me, and exactly why I'm advocating this type of a format (despite its usefulness for any video playback, which is also almost exclusively in 422 or 420). So long,
Thomas
| |
Wojtek P
Poland
| |
Posts 1597
29 Dec 2010 21:08
| Thomas Richter wrote:
|
Certainly. It's an "old hat" as we say in Germany. There's a
|
Most inventions in for example high-performance processors are from 60's !!! IBM Stretch (available 1960) was able to do few instructions at once, IBM 360/95 (i think 1966) could do full out of order execution with register renaming.
They faced the same problem - magnetic core memory was slower than transistor based processor.
Now DRAM is much slower that CPU.
reason why video uses YUV422 (this is the name used in the field for this format), and why color TV (NTSC) uses this format. Actually, PAL is even YUV420, i.e. one luma sample (U and V) for *four* chroma samples. But that's probably harder to do in hardware, thus I guess YUV 422 is fine.
BTW, old JPEG is almost exclusively YUV 420 (for the same reason) even though 444 is supported, ditto JPEG XR. JPEG 2000 doesn't require subsampling - wavelets can do that much more economically.
Thus, "no surprise" for me, and exactly why I'm advocating this type of a format (despite its usefulness for any video playback, which is also almost exclusively in 422 or 420).
|
That's good you plan to support that format for display and - more important - for Natami coprocessors.
Actually i found that 2x2 subsampling still does make very little or no visible difference.
In my video codec (that is now 80% implemented i would say) i could choose between no subsampling, 2:1 subsampling in vertical direction or 4:1 subsampling (halved in both vertical and horizontal direction).
From what i see there is nearly no visible difference so i actually test things at 4:1 subsampling.
i did tests on movie that was 1280x768 and downscaled 2x2 to 640x384 so to be sure that former compression didn't already removed too much.
| |
Samuel D Crow
USA
| | (Natami Team)
Posts 1295
04 Jan 2011 22:02
| While sketching in features for a tentative list for the NatAmi, it occurred to me that 422 YUV could be implemented using palette mapping only. That would allow us to use the same bitplane and byteplane hardware for anything other than HAM mode. Do we really need this screenmode as separate? A YUV 16-bit mode would be another story, as would a 16-bit grey-alpha blitter mode (supported by PNG). These might have limited usability but if HAM8 mode was redone for these as 16-bit byteplanar modes, would that be a waste of hardware and registers? Finally, since I brought up about alpha channel modes, would alternative alpha channel modes required by OpenGL make sense as well? This is starting to get complicated!
| |
Wojtek P
Poland
| |
Posts 1597
04 Jan 2011 22:13
| Samuel D Crow wrote:
|
While sketching in features for a tentative list for the NatAmi, it occurred to me that 422 YUV could be implemented using palette mapping only.
|
How?
Can natami have 3 playfields with summing of values from each, and each with different resolution? If so of course you can make 2 palettes one with Cb to RGB mapping, other with Cr to RGB mapping, and another plane as grayscale.
And that pallettes must support negative values. Ang hardware must support clipping (if final value will be 255).
| |
Megol .
| |
Posts 674
05 Jan 2011 10:56
| Wojtek P wrote:
|
Thomas Richter wrote:
|
Certainly. It's an "old hat" as we say in Germany. There's a
|
Most inventions in for example high-performance processors are from 60's !!! IBM Stretch (available 1960) was able to do few instructions at once, IBM 360/95 (i think 1966) could do full out of order execution with register renaming.
They faced the same problem - magnetic core memory was slower than transistor based processor.
...
|
No it isn't!!!! (
| |
Gunnar von Boehn
Germany
| | (Moderator)
Posts 5775
05 Jan 2011 12:10
| Samuel D Crow wrote:
|
While sketching in features for a tentative list for the NatAmi, it occurred to me that 422 YUV could be implemented using palette mapping only. That would allow us to use the same bitplane and byteplane hardware for anything other than HAM mode.
|
Can you eleborate on this?
Please give an example with some real pixel data.
| |
Megol .
| |
Posts 674
05 Jan 2011 12:50
| Megol . wrote:
|
Wojtek P wrote:
|
Thomas Richter wrote:
|
Certainly. It's an "old hat" as we say in Germany. There's a
|
Most inventions in for example high-performance processors are from 60's !!! IBM Stretch (available 1960) was able to do few instructions at once, IBM 360/95 (i think 1966) could do full out of order execution with register renaming.
They faced the same problem - magnetic core memory was slower than transistor based processor.
...
|
No it isn't!!!! (
|
Why did my post get cut off? I didn't use any strange characters...
Short rewrite:
. No full OoO was possible in the 60ies. Tomasulos algorithm, while innovative wasn't general enough.
. Techniques making OoO possible for the general case came much later than the 60ies.
. Techniques for making OoO effective came much later.
| |
Samuel D Crow
USA
| | (Natami Team)
Posts 1295
05 Jan 2011 17:50
| @Gunnar von Boehn Sorry. I had flawed ideas of how YUV worked as was pointed out.
| |
Wojtek P
Poland
| |
Posts 1597
05 Jan 2011 18:48
| Megol . wrote:
|
Tomasulos algorithm, while innovative wasn't general enough.
|
It is exactly algorith about OoO execution.
It was improved later to allow more than one operation per clock (original allow exactly one).
Anyway - it allowed one operation per clock even if execution units needed 2-3 clocks per operation.
| |
Pawel K.
Poland
| |
Posts 53
06 Nov 2011 15:17
| 4:2:2 subsampling is useless for desktop. It's good for movies and photos but desktop just looks ugly with it. Haven't you people ever hooked PC to HDTV display? Color element like red font on green background blurred to point just unreadable. And it's with all icons and all computer pixel graphics... Also how would this speed anything up?
Also how would look screenshot of image? and screenshot of screenshot? I'm really shocked you people even consider this mess as an option... Natami is 32bit and have 32bit Blitter so why not use only mode that don't need any transformations = fastest. I'm talking ofcourse about 32bit as 24bit is retarded. Typical resolutions today are 1920x1080/1200 and those takes mere ~8MB with 32bit. Why anyone would want banding or blurred colours to save 4MB? <_<
| |
Thomas Richter
Germany
| | (MX-Board Owner)
Posts 1425
06 Nov 2011 17:06
| Pawel K. wrote:
|
4:2:2 subsampling is useless for desktop.
|
But not for video playback, which might be one interesting application.Pawel K. wrote:
|
Also how would this speed anything up?
|
By not requiring a YUV to RGB color transform when playing back video or rendering JPEGs, and by dividing the bandwidth in a half for moving such data to the memory.Pawel K. wrote:
|
Also how would look screenshot of image? and screenshot of screenshot? I'm really shocked you people even consider this mess as an option...
|
How on earth could you ever take screen shots of HAM pictures, after all? Oh, right, by viewing them on HAM screens obviously. No difference.Pawel K. wrote:
|
Natami is 32bit and have 32bit Blitter so why not use only mode that don't need any transformations = fastest.
|
But that is exactly the point. The blitter is 16 bit as it is the Amiga blitter. It has now a 32 bit memory interface, but its registers and all such are still the old 16 bit registers the blitter always had.And no, video does not come in RGB, and it is exactly the point that a VUY video buffer would *not* require a transformation. There is currently no true color mode, only a 8bpp planar mode, and running through an inverse color lookup for the bitplane mode surely makes things a lot slower.
| |
Marcel Verdaasdonk
Netherlands
| |
Posts 3976
07 Nov 2011 16:33
| Pawel K. wrote:
|
Also how would this speed anything up?
Also how would look screenshot of image? and screenshot of screenshot? I'm really shocked you people even consider this mess as an option...
Natami is 32bit and have 32bit Blitter so why not use only mode that don't need any transformations = fastest. I'm talking ofcourse about 32bit as 24bit is retarded. Typical resolutions today are 1920x1080/1200 and those takes mere ~8MB with 32bit. Why anyone would want banding or blurred colours to save 4MB? <_<
|
Besides the things thomas mentioned there is one more thing, Bandwidth.
This shouldn't be a bottle neck but having more bandwidth for other stuff is handy.
| |
Pawel K.
Poland
| |
Posts 53
07 Nov 2011 17:16
| I think all modern computer needs is 32bpp + hardware YUV decoder with blit and/or overlay functionality to speed things up. 16bit and 24bit modes are waste of logic cells imho...
| |
Marcel Verdaasdonk
Netherlands
| |
Posts 3976
08 Nov 2011 13:21
| Pawel K. wrote:
|
I think all modern computer needs is 32bpp + hardware YUV decoder with blit and/or overlay functionality to speed things up.
16bit and 24bit modes are waste of logic cells imho...
|
lol, ThoR already said that the registers of the blitter are 16bit, as we all know sending more in it causes it to overflow into the next register. ;)
So we have the 16bit registers already i don't see the benefit of wasting more to get 32bpp in a ackward method.
| |
Pawel K.
Poland
| |
Posts 53
13 Nov 2011 10:41
| well if 3x8bit method is more efficient for current blitter implementation then I guess 32bit mode would be useless as it wont give more quality anyway. Still YUV overlay would make more sense than YUV screen mode :)
| |
Marcel Verdaasdonk
Netherlands
| |
Posts 3976
13 Nov 2011 23:21
| actually it doesn't Pawel, like you yourself said memory is plenty so we don't need to do overlay, besides that YUV overlay is more processing intensive then storing YUV screens in memory. ;)
| |
Thomas Richter
Germany
| | (MX-Board Owner)
Posts 1425
14 Nov 2011 08:01
| Marcel Verdaasdonk wrote:
|
actually it doesn't Pawel, like you yourself said memory is plenty so we don't need to do overlay, besides that YUV overlay is more processing intensive then storing YUV screens in memory. ;)
|
At least overlays would require additional hardware, i.e. increase the complexity at Thomas' side. A YUV overlay would probably require an additional DMA channel that just picks samples from an extra bitplane and merges this with the output. All of course possible, but I believe - let's get the thing ready first and then think about extensions...
| |
|
Do you have ideas and feature wishes? Post them here and discuss your ideas.