Doh I’m stupid sometimes
So when I installed Word Press some 6 months I must have left comments require moderation on… but didn’t realise it, didn’t even know there was a moderation section. Thanks [Maven] from Beyond3D for telling me comments weren’t working.
I’ve turned moderation off now, so comment away 
And me and my big mouth, remind my never to discuss anything techinical on the net, in case thousands of fanboys think I’m making hardware comments on PS3, whereas instead I’m just mentioning some cool techy stuff.
Sunday, December 11th, 2005 @ 12:55 pm 
Random Rubbish
RSS 2.0
Trackback
December 11th, 2005 at 1:03 pm
To prove comments are working (I think) i’ll leave myself a comment.
Just read all the comments, people have posted over the last 6 months, thanks for all the posts, much appreciated
I never realised anybody had ever left any comments, so I wasn’t ignored anybody. So sorry for anybody who left a comment and wondered why I ignored them… never say them till today.
December 11th, 2005 at 5:01 pm
Cool
Speaking of cool techy stuff… how does MSAA resolving NOT mess up the NAO_32 pixel format? The hardware expects A8R8G8B8, I would presume.
December 11th, 2005 at 9:12 pm
Umh..nice question, yeah, very nice question..:D
December 12th, 2005 at 11:45 am
Storing luminance (Y) as INT16, or mantissa (8) + exponent (8), and Cr (8) & Cb(8) would not give the correct result, but would look OK, I think. Although they’re probably using a different colourspace (RCT from JPEG2000?)…
December 12th, 2005 at 2:06 pm
I honestly don’t know… Marco did the work and I haven’t actually had much chance to see how it actually works. There are two modes one with 8 bit luminance (NAO24 + 8 bit alpha) and 16 bit luminance (NAO32) but IIRC sure he mentioned its not straight luminace but some function of it…
December 13th, 2005 at 12:36 am
Hi Maven,
the problem with YCrCb or RCT is that they just someway decouple chroma informations from luminance, this is good but it’s not enough cause in th end we need to store in a fixed range all this data and for instance it would be no different that using RGBE, in fact we would try to normalize Y,Cb and Cr storing an extra normalization value such an exponent.
) color space.
We could use Y as normalization exponent and store Y and Cb/(Y + |Cb| + |Cr|) and Cr/(Y + |Cb| + |Cr|), moreover one would ne a pair of extra bits sto store Cb and Cr original signs.
Or we can directly use a space where chroma values are positive all the time, and there’s a nice color space that provides that which is CIE 1931 (yes, it’s old
CIE components are called X,Y and Z. Y is a luminance-like component while X and Z are chrominance-like components, now we could store Y and x = X/(X+Y+Z) and y = Y/(X+Y+Z) (x and y are called chromacity), but we can do so much better than that, since x and y maps a light spectrum region wider than what our eyes can see.
We are lucky cause we don’t even have to scratch our heads here since the CIE commitee has arleady a solution for that and it’s called CIE Luv (to be fair there’s even another one called CIE Lab), you can find the standard transform to go from CIE XYZ to CIE Luv pretty easily (even though you want to do some extra algebra work on them to reduce the amount of calculations and thus improve accuracy).
In this space you have Y (old ‘luminance’), u and v. You can go even a step further than that, save some bits and cut the visibile spectrum even more clamping u and v between 0 and k, where k
December 13th, 2005 at 12:37 am
(EDIT, I want more comments space!
)
You can go even a step further than that, save some bits and cut the visibile spectrum even more clamping u and v between 0 and k, where k
December 13th, 2005 at 12:39 am
(Umh..it’s not a problem of space, I think there is some problem with the ‘less than’ symbol)
You can go even a step further than that, save some bits and cut the visibile spectrum even more clamping u and v between 0 and k, where k is smaller than 1. k = 1/2 is a good value, you don’t lose anything that your eyes can see and you gain an extra bit.
There are different ways to store Y as you mentioned, as an INT16 or as floating point number (mantissa + exponent). I’m storing Y as log2(Y) but this is just a slightly convoluted floating point representation.
Encoding those 3 quantities in 32 bits it’s not rocket science but it’s not also very simple cause I had a lot of problems with Y splitted over 2 channels cause decoding was giving me costantly higher or lower Y values than the expected value, but in the end I found a way to fool the hw and have the smallest error possible ( smaller than 2^-16).
If you want to LERP in this space (blending? bilinear filtering?) you have to employ some other extra tricks while encoding, and in some cases you get very nice (but mathematically incorrect) results.
ciao,
Marco
December 14th, 2005 at 9:50 am
Marco has been chatting about it on Beyond3D, this one answers most of the questions http://www.beyond3d.com/forum/showpost.php?p=650143&postcount=260
April 5th, 2006 at 11:55 pm
hi
can anyone help me with this problems plz
observe for an NTSC system and calaulate the values for chromacity
Red-xr:0.67
Red-yr:0.33
Green-xg:0.21
Green-yg:0.71
Blue-xb:0.14
Blue-yb:0.08
White point-xw: 0.3101
white point-yw:0.3162
November 13th, 2008 at 12:49 am
xks1lld8415lx0dq
March 20th, 2010 at 12:52 am
Потрясающе! Вот не ожидал…)
March 27th, 2010 at 3:11 pm
Я писал что-то подобное, но у Вас тема более глубого раскрыта
March 27th, 2010 at 9:59 pm
Отличная статья. Краткость явно Ваша сестра