RGB - colour distribution

[aths]

I made some tests with photographs. The pattern are projections on certain side faces. The images show from left to right the following axis in the order of (X-axis, Y-axis)

(Red, Green)
(Blue, Green)
(Red, Blue)

either from bottom left (0, 0) to top right (1, 1). The bright grids are deviding the charts in parts of 0.25 for linear RGB. Since I analyzed photographs, I also included the 0.5-line for sRGB with a darker line.

The last three images can be clicked to see the original photo (JPEG compressed, I analyzed an bitmap.) (I can't remember which are the first three pics I analyzed.)

(The seperated "side galaxy" is the blue ground of the traffic sign. Click the diagram to see the picture.)






So, despite some outliers, the majority of all pixels are near the gray axis.

I find this interesting especially when using YCbCr. Here are some CbCr-planes for certain values of Y:

As one easily can see, the YCbCr-cube lies only partly in the RGB-cube. (From 16777216 possible colours with YCbCr 888 are only 3918122 representable with RGB [0..1]. This is less than 24%!) So what I suggest is:

- Find a good matrix for an Yab-representation (with other matrix values than YCbCr) for every single picture (texture) and store it with the picture (or texture). This is similar to the NCC palette storing.

- Also, depending on the actual distribution of the values, use a finer quantization for ab-Values with less saturdation. If a and b is in the range from -0.5 .. 0.5, the finer resultion is needed around zero.

 

[MfA]

Best they could do with phosphors, and now we are stuck with it

 

[aths]

Best they could do with phosphors, and now we are stuck with it

The main information of my posting should be the notice of the colour distribution of a photograph in the RGB cube. I don't was aware of the dense accumulation near the gray diagonal.

 

[Simon F]

Best they could do with phosphors, and now we are stuck with it

The main information of my posting should be the notice of the colour distribution of a photograph in the RGB cube. I don't was aware of the dense accumulation near the gray diagonal.

Aths,
That is typical of the images you have chosen. You'd could easily get a different distribution if you chose "graphics".

 

[aths]

Best they could do with phosphors, and now we are stuck with it

The main information of my posting should be the notice of the colour distribution of a photograph in the RGB cube. I don't was aware of the dense accumulation near the gray diagonal.

Aths,
That is typical of the images you have chosen. You'd could easily get a different distribution if you chose "graphics".

Yes, but it's a diploma thesis where I cannot solve all issues. Actually I cannot even make a proposal better than DXT1.

BTW these images are in fact a by-product of a test of your theory, that the weights of 0, 3/8, 5/8 and 1 should be better than 0, 1/3, 2/3 and 1. So I tested the distribution of 4x4 pixel squares.

My result is (just by looking, don't made big numerical analyzes) 0, 1/3, 2/3 and 1 should be fine. May be its an option to store both reference colours with RGB 555, so we have 2 bits free. Including a comparision of the the "integer number" of both colours, we can reference to 1 out of 8 weight tables. This way its possible to define mid-centered, out-centered, left- or right-weighted weight values. But since DXT1 is already that good I really doubt this would be make a noticable difference in quality.

I also have ideas of storing 3 colours and interpolate them in a special way. But again – DXT1 is just too good already.

 

[Simon F]

BTW these images are in fact a by-product of a test of your theory, that the weights of 0, 3/8, 5/8 and 1 should be better than 0, 1/3, 2/3 and 1. So I tested the distribution of 4x4 pixel squares.

Sorry, but you are misinterpreting my comments. The "normal" distribution (which, apart from the reduced hardware costs, led to the choice of 3/8 & 5/8 weights used in PVRTC) was found when combining the two low-frequency bilinear signals. DXTC uses constant values per block and so a uniform distribution is (in all probability) more useful.

 

[aths]

BTW these images are in fact a by-product of a test of your theory, that the weights of 0, 3/8, 5/8 and 1 should be better than 0, 1/3, 2/3 and 1. So I tested the distribution of 4x4 pixel squares.

Sorry, but you are misinterpreting my comments. The "normal" distribution (which, apart from the reduced hardware costs, led to the choice of 3/8 & 5/8 weights used in PVRTC) was found when combining the two low-frequency bilinear signals. DXTC uses constant values per block and so a uniform distribution is (in all probability) more useful.

Thank you for the clarification. (You are already the most often quoted person in my degree dissertation.)

 

[Simon F]

Oh Struth! You'll never pass if you do that!

 

[aths]

Oh Struth! You'll never pass if you do that!

I already hear the professor say: "Your work is both good and original.

Unfortunately, ..."


Jokes aside, I have to document my sources.