ConvertToYCgCo - New Colorspace

[xv]

I´ve created a plug-in for conversion to the YCgCo colorspace.

This colorspace is not derived from PAL/NTSC, but designed for better compressibilty. I´ve made a test with lossless x264 encoding, I tested just a few short samples, but for them YCgCo gives 10% less bitrate than normal bt709/bt601. Quality is of course the same (except some rounding if your source is actually bt709/bt601, for RGB source rounding errors are smaller, because RGB fits better in YCgCo).

Unfortunately most application cannot display this colorspace at the moment (madVR as of version 0.82.5 displays YCgCo correctly, older versions since 0.68 supported it, but is was partly broken and resulted in slightly wrong colors). Most programs will just use bt709/bt601 matrix to decode (like VirtualDub, VLC, any DirectShow-based player without madVR renderer) and colors will be awfully wrong.

If you encode to H.264 using x264 ensure you are telling the encoder to set the correct flags in the H.264 bitstream:
--colormatrix YCgCo --range pc --input-range pc

Latest version: 0.4 (link to post with download) (http://forum.doom9.org/showthread.php?p=1565259#post1565259)
Version in this post is outdated, please do not use!

[jmac698]

Can you give the translation matrix?
Some more info on the theory would be interesting.

[xv]

The conversion formula:

Y = 0.25 * R + 0.5 * G + 0.25 * B
Cg = -0.25 * R + 0.5 * G - 0.25 * B + 0.5
Co = 0.5 * R - 0.5 * B + 0.5

The 0.5 offset is for [0,1] range, for [0,255] range (8 Bit) it´s 128.
This conversion formula is specified in the H.264 spec (in E.2.1 VUI Parameter Semantics, page 379 in 3/2010 standard).

[jmac698]

Ok, that's Chroma Green and Chroma Orange, and they need 9bits to maintain conversion accuracy. They have low mutual correlation. This can be decoded on playback, if we make a script to convert it (with masktools) and load the script in ffdshow. Do you have the formula to go back to rgb?

[Gavino]

Do you have the formula to go back to rgb?
Don't you know how to do matrix inversion (or solve simultaneous equations)? :)

For Cg and Co in [-0.5, 0.5]
R = Y - Cg + Co
G = Y + Cg
B = Y - Cg - Co

For example, see http://de.wikipedia.org/wiki/YCgCo-Farbmodell.

[jmac698]

Yes I know, I was lazy :)
Another sample pic
https://secure.wikimedia.org/wikipedia/commons/wiki/File:YCgCo-1600x4800.jpg

[xv]

It would not be that difficult to write a plug-in that converts YCgCo back to RGB, but that wouldn´t be more than a testing solution for playback. Hopefully in the next madVR version we have support and automatic detection from H.264 bitstream.

There is another formula for YCgCo-R that needs 9 Bit for chroma and 8 Bit luma and is fully reversable (for 8 Bit source). Unfortunately x264 does not support different luma/chroma bitdepths (yet?). Also there is no colorspace with 8 Bit luma and 9 Bit chroma, conversion would have to be integrated in encoder/decoder and input/output would be RGB.

The interesting question is how does it perform visually with chroma subsampling.

[jmac698]

We can experiment with all this in script:

#RGB<=>YCgCo demo by jmac, requires masktools v2a38+, tested in avisynth 2.58
#Ver 0.1 - does something, but incorrectly - almost finished
#ImageReader("E:\project001a\YCgCo\YCgCo-1600x4800.jpg")#Sample picture stacked as RGB,Y,Cg,Co (Cg and Co are colourized for illustration)
colorbars
rgb=verticalunstack4(0)
y=verticalunstack4(1)
cg=verticalunstack4(2)
co=verticalunstack4(3)
#Testing...
RGBintoYV12(colorbars)
YV12intoRGB
RGB2YCgCo
#for realtime playback in ffdshow, erase all lines above
YCgCo2RGB

function verticalunstack4(clip v, int slice) {
#Return n'th vertical slice of n slices, e.g. 4 videos stackedvertically (opposite of stackvertical)
#note slice=0 is the top block
slices=4
v
blockheight=height/slices
select (slice, \
crop(0,0,0,-3*blockheight), \
crop(0,blockheight,0,-2*blockheight), \
crop(0,2*blockheight,0,blockheight), \
crop(0,3*blockheight,0,0))
}

function RGB2YCgCo(clip v) {
#convert an assumed RGB clip into Co,Y,Cg
#~ Y = 0.25 * R + 0.5 * G + 0.25 * B
#~ Cg = -0.25 * R + 0.5 * G - 0.25 * B + 0.5
#~ Co = 0.5 * R - 0.5 * B + 0.5
v
#put planes into yuv for masktools (awkward)
RGBintoYV12
#Note: remember b=u, r=v, g=y
mt_lut(yexpr="v 4 / y 2 / + u 4 / +",uexpr="v 2 / u 2 / + 128 +",vexpr="v -4 / y 2 / + u -4 / 128 +")
YV12intoRGB
}

function YCgCo2RGB(clip v) {
#convert an assumed Co,Y,Cg clip into RGB
#~ R = Y - Cg + Co
#~ G = Y + Cg
#~ B = Y - Cg - Co
v
#put planes into yuv for masktools (awkward)
RGBintoYV12
#Note: remember b=u, r=v, g=y
mt_lut(yexpr="y u +",uexpr="y u - v -",vexpr="y u - v +")
YV12intoRGB
}

function RGBintoYV12(clip v) {
#place r,g,b data directly into v,y,u planes
#this result has no visual meaning (however, closest approximation) but is only for performing arithmetic on the data
v
pointresize(width*2,height*2)#doublesize to allow full 4:4:4 color resolution with u,v
r=ShowRed.converttoyv12
g=ShowGreen.converttoyv12
g=g.pointresize(width*2,height*2)#this is destined for Y which must be larger
b=ShowBlue.converttoyv12
YtoUV(b,r,g)#b->u, r->v, g->y
}

function YV12intoRGB(clip v) {
#place v,y,u data into r,g,b planes
#this result has no visual meaning (however, closest approximation) but is only for performing arithmetic on the data
v
r=vtoy.converttorgb
g=greyscale.converttorgb
g=g.pointresize(width/2,height/2)#Y was doublesized
b=utoy.converttorgb
MergeRGB(r,g,b)#u->b, v->r, y->g
pointresize(width/2,height/2)#doublesize to allow full 4:4:4 color resolution with u,v
}

I'll update later to fix the bugs...

[Gavino]

mt_lut(yexpr="v 4 / y 2 / + u 4 / +",uexpr="v 2 / u 2 / + 128 +",vexpr="v -4 / y 2 / + u -4 / 128 +")
That won't work. The only variable you can use in mt_lut is "x", which refers to Y in yexpr, U in uexpr and V in vexpr.
To combine values from all three channels, you have to use mt_lutxyz, with each channel in a separate clip.
I'm not sure negative constants (-4) are recognised either.

select (slice, \
crop(0,0,0,-3*blockheight), \
crop(0,blockheight,0,-2*blockheight), \
crop(0,2*blockheight,0,blockheight), \
crop(0,3*blockheight,0,0))
This can be written more simply as
crop(0,slice*blockheight,0,blockheight)

[xv]

It´s now more than one and my attachment is still not approved, so I uploaded it here:
http://www.mediafire.com/?d7ididp7o635xcl
Another plug-in is in work "ManualColorMatrix", where you can do any kind of matrix multiplication and offset correction of color triplets (but ConvertToYCgCo should be used for RGB->YCgCo because it will most likely be faster (uses SSE2)).

[pandy]

Avisynth 2.58 please - 2.6 is still far from end, TIA!

[xv]

The plugin needs the YV24 colorspace (YUV without subsampling), which is unfortunately not supported by AviSynth before version 2.6, therefore no AviSynth 2.5 support :(.

[jmac698]

Why does it need yv24 when it's an rgb operation? Rgb will work fine. My script works in 2.58 as well.

[xv]

It does not make much sense to store the YCgCo data as RGB. You cannot use that RGB data, how do you tell other software that RGB is in fact YCgCo?
But like I said I will write another plugin for any matrix conversion that will support RGB/YV24 input/output.

[jmac698]

That's a good question, but you have to realize that RGB is only a convention which has little meaning. The actual position of the bytes and what they contain is mostly what's important. I can stuff any data I want into any stream. The only question is how to make it useful with other programs. In our case the most useful thing I see is to feed it to x264 encoder. There's programs which pipe raw video data so we need to know what arrangement of bytes x264 would need. I can rearrange the pixels to get the data right, the color format makes no difference at all.

In my 10bit video importer, I opened the raw data of a quicktime file and rearranged the pixels to display a sensible picture. I then put the extra bits in another clip and wrote tools to manipulate levels, so it's actually useful.

Btw, please consider using the informal deepcolor format other authors use, where MSB is top half of picture and LSB on bottom half. By doing this we can then adjust levels and dither back down to 8 bit with other plugins.

We need an internal format that you can manipulate with plugins and scripts, and an export from this format outside of avisynth to other formats.

Also YCgCo stuffed into G,B,R can still be compressed. It has to be displayed with my script for realtime playback. I also put it into yv12 by doublesizing the video, but I can also subsample the CgCo. Lack of yv24 is not a problem for processing.

Try the script - you can play with subsampling or whatever you want to see the effects.

[pandy]

Is there any reason to not implement YV12 sub-sampling? for YV24 RGB organization of data can be used...

[xv]

x264 for example accepts YV24 and can encode it correctly (with --colormatrix YCgCo --fullrange on). It cannot encode YCgCo in RGB correctly:
-It converts it to a YUV format assuming it´s RGB -> video will be a mess
-It encodes it as RGB without subsampling, but result will be suboptimal since it treats RGB different than YUV/YCgCo
What´s the problem with AviSynth 2.6? Any serious issue?

I see that there are many hacks to implement workarounds for missing features and I think that´s great for testing and AviSynth internal stuff, but like you said outside of AviSynth that doesn´t work well. My goal was to get YCgCo out of AviSynth to feed the data to x264.

[xv]

Is there any reason to not implement YV12 sub-sampling? for YV24 RGB organization of data can be used... The reason is quite simple, in AviSynth 2.6 that´s useless, just use ConvertToYCgCo().ConvertToYV12()
I´ll see if I can yust copy the subsampling algorithm from AviSynth into my filter to allow direct subsampling and AviSynth 2.5 support.

[pandy]

It was my point - to re-implement YV12 AviSynth internal filter by Your external YCoCg filter - this should create more flexible environment and more than only YV24 color space supported. Anyway thanks for all - even if i can't use Your filter now.

[xv]

I´ve added support for YUY2 and YV12 subsampling. I´ve done this by calling lanczos to resize U/V plane.
I´m not sure that´s correct, but I used src_left=-0.5 for YV12 to have correct chroma position, does anyone know if that´s correct?

http://www.mediafire.com/?vzgm1po5a3630sw

[pandy]

Thank You Very Much! - IMO MPEG-2 is kind of standard (even if MPEG-1 position is IMHO better) - H.264 use MPEG-2 chroma sample location

[xv]

That´s why I used MPEG-2 chroma position (in fact H.264 supports many chroma positions, there is a bitstream flag, but probably all decoder/renderer ignore that)

I´m not sure I did it correct with src_left=-0.5

[Gavino]

I´ve added support for YUY2 and YV12 subsampling. I´ve done this by calling lanczos to resize U/V plane.
I´m not sure that´s correct, but I used src_left=-0.5 for YV12 to have correct chroma position, does anyone know if that´s correct?
src_left=-0.5 for downsizing and src_left=+0.25 for upsizing

[xv]

src_left=-0.5 for downsizing and src_left=+0.25 for upsizingThanks, so I did it correct :)
Is lanczos recommend for Chroma downsizing? I´ve seen jmac698 used BilinearResize for downsizing in his script.

[Gavino]

Internally Avisynth uses (the equivalent of) BilinearResize for the default conversion path, and when using the chromaresample option of v2.60, the default is bicubic.

[Zerofool]

Hello,

I recently found out about this colorspace and the possible compression gains so I decided to give it a try with x264.

My source is fullrange RGB. Unfortunately, the resulting file doesn't look exactly right, the black level is off (should be 0/0/0 but it's 0/19/18) and the video is blue-ish. Pure white is OK though (255/255/255). I use the latest MadVR as both decoder and renderer (through MPC-HC), and also tried LAVF+MadVR with the same success. My encoding settings include:
--colormatrix YCgCo --range pc --input-range pc --output-csp i444
and I tried with both the 10-bit and 8-bit x264 builds.

I noticed that you said this:
x264 for example accepts YV24 and can encode it correctly (with --colormatrix YCgCo --fullrange on).
Is that for limited-range sources? If so, how does your filter treat full-range sources?

Is there anything that I can do to correct the situation? Should any special --colorprim and --transfer parameters be set when encoding? Because MadVR says "primaries BT.709 (says bitstream)".

Anyway, if I use any other renderer the black is OK (and all the grayscale as a whole), but naturally, the colors are messed up :).

Your BigBuckBunny samples look OK through MadVR (dec+rend) though...

[Zerofool]

Nope, not exactly sure, just suspecting it does. There's nothing about YCgCo in madVR's changelog, so nothing official. I could only find this statement of the author:

Also keep in mind that h264 allows more matrices to be used, e.g. YCgCo, GBR, SMPTE 240M. I have h264 samples which were encoded with YCgCo and GBR matrices. And madVR v0.69 now treats them correctly (automatically).

Truth to be told, with madVR the video looks close to what I expect it to look like, so it's some minor glitch, but I don't know if it's in the renderer, this filter, or in my encoding approach.
The samples I mentioned (probably the ones madshi talks about) look normal, as far as I can tell.

[xv]

It seems that the problem is somewhere in madVR. I made a few samples and noticed similar problems. But madVR is not open-source so I cannot analyze the problem, madshi has to do that.

To verify that your encoding is correct open the file in avisynth and add the following command (you need the ManualColorMatrix plug-in (http://forum.doom9.org/showthread.php?t=161777)):
ManualColorMatrix(2, 1.0, -1.0, 1.0, 1.0, 1.0, 0.0, 1.0, -1.0, -1.0, 0.0, -128.0, 256.0)This will convert YCgCo manually to RGB (you need AviSynth 2.6 for YV24 support). If colors are wrong something is wrong with your encode, otherwise the problem is madVR.

[xv]

Madshi has fixed YCgCo matrix in madVR 0.82.5 (http://forum.doom9.org/showthread.php?p=1564599#post1564599)!
Now correctly encoded videos should look perfect.

[LexSfX]

Hi, XV. I am posting this on behalf of natt (http://tasvideos.org/forum/profile.php?mode=viewprofile&u=5551), a proficient video encoder from tasvideos.org (http://tasvideos.org). He wrote the following in response to your colorspace conversion code.

---

(Note: I'm working off the 2011 h.264 spec)

The h.264 spec is very explicit about how RGB->YCgCo should be rounded. Looking over your source code (the C++ version), it doesn't appear to follow those conventions. In particular, rounding should be done towards the nearest integer (not towards zero).

As a part of a little educational study, I wrote an RGB->YCgCo converter a while back, and I believe it fully implements the conversion with rounding exactly as the specification requires. (Of course, if there's any disagreement, I'd love to see test vectors).

It's in C, and also implements the case of different bitdepths between RGB and YCgCo (which is not needed here) by changing BITDEPTHR and BITDEPTHY.

typedef struct
{
int y;
int cg; // "Cb"
int co; // "Cr"
} ycc_t;

typedef struct
{
int r;
int g;
int b;
} rgb_t;

// R,G,B have bitdepth BITDEPTHR
// Y,Cg,Co have bitdepth BITDEPTHY

#define BITDEPTHR 8
#define BITDEPTHY 8

#define SRCRNG ((1 << BITDEPTHR) - 1) // rgb values are from [0, SRCRNG]

#define SFC (1 << (BITDEPTHY - 1)) // used in some calculations, the "center point" of Cg, Co
#define RNG ((1 << BITDEPTHY) - 1) // ycc values are from [0, RNG]



void rgb_to_ycgco_int (ycc_t *dst, const rgb_t *src)
{ // E-19 through E-21
int r = src->r * RNG;
int g = src->g * RNG;
int b = src->b * RNG;

int y = 2 * g + r + b;
int cb = 2 * g - r - b;
int cr = 2 * r - 2 * b;

// round away from 0
y += 2 * SRCRNG;
if (cb < 0)
cb -= 2 * SRCRNG;
else
cb += 2 * SRCRNG;
if (cr < 0)
cr -= 2 * SRCRNG;
else
cr += 2 * SRCRNG;

y /= 4 * SRCRNG;
cb /= 4 * SRCRNG;
cr /= 4 * SRCRNG;
cb += SFC;
cr += SFC;

// clip
if (cb > RNG)
cb--;
if (cr > RNG)
cr--;

dst->y = y;
dst->cg = cb;
dst->co = cr;

}

-natt

[xv]

You are right. How rounding is done in C++ version is defined by compiler, which is not good. SSE2 version was wrong (rounding towards zero). Fixing is really simple, I just added 0.5 and then use floor() to ensure it´s rounded towards zero (this is also what H.264 spec says). In SSE2 I just changed cvttps2dq to cvtps2dq.
Could you verify it´s correct?
Only using integers for conversion is interesting and is most likely also a lot faster. When I find some time I´ll rewrite my assembly integer-only and see how it compares in speed. Results should be the same.

[xv]

I converted all code to int-only. Output of C and SSE version is bit-identical (as it should be) and should conform to H.264 spec. Using ints instead of float also gives a speed increase (especially for the C version).
I used binary operations instead of arithmetic to increase performance, that´s the way I´ve done it:
g<<=1; // the same as g*=2;
y = g+r+b;
cg = g-r-b+512;
co = r-b+256;
if (y&0x2) { y>>=2; y++; } // same as if(y%4>1) { y/=4; y++; }
else y>>=2;
if (cg&0x2) { cg>>=2; cg++; if(cg>255) cg--; }
else cg>>=2;
if (co&0x1) { co>>=1; co++; if(co>255) co--; }
else co>>=1;
Please check if everything is 100% correct now.

[natt]

Sorry for the slow response time. I had to wait for the board-imposed 5 day timeout, and didn't want to make Lex carry around messages for me.

The idea looks basically right, except for one hitch: the rounding for Cg, Co. The h264 spec says that you're supposed to round before you add 128:


Y = Round( 0.5 * G + 0.25 * ( R + B ) )
Cg = Round( 0.5 * G − 0.25 * ( R + B ) ) + 128
Co = Round( 0.5 * (R − B ) ) + 128


So your rounding of Y is correct, and Cg and Co when they're in [128,255] ([0, 127] before +128). But the rounding tricks don't work right with negatives unless you make a second case. For instance:

Round ( (-75) / 2)

As in the h264 spec:
Round (-37.5)
Sign(-37.5)*Floor(Abs(-37.5) + 0.5)
(-1)*Floor(38)
-38

Truncate and then add 1 because the original was odd:
(-75) / 2 + 1
(-37) + 1
-36

[xv]

Also your example is wrong you are right:

The problem is I´ve not seen the 0.5 problem. My code rounds up, but spec says in this case round away from zero, and that of course makes a difference for negative numbers. For .25 and .75 rounding is correct:
Round((-75)/2) + 128 = Sign(-37.5)*Floor(Abs(-37.5)+0.5) + 128 = (-1)*Floor(38) + 128 = -38 + 128 = 90
(-75 + 256) / 2 = 181/2 = 90 + 1 = 91 => NOT OK

Round((-149)/4) + 128 = Sign(-37.25)*Floor(Abs(-37.25)+0.5) + 128 = (-1)*Floor(37.75) + 128 = -37 + 128 = 91
(-149 + 512) / 4 = 363/4 = 90 + 1 = 91 => OK

Round((-151)/4) + 128 = Sign(-37.75)*Floor(Abs(-37.75)+0.5) + 128 = (-1)*Floor(38.25) + 128 = -38 + 128 = 90
(-151 + 512) / 4 = 361/4 = 90 + 0 = 90 => OK

I´ll see how I can fix that efficiently.

[aufkrawall]

I´ll see how I can fix that efficiently.
When you have fixed it, converting RGB to I444 YCgCo should be totally lossless, right? :)
That would be really very cool, makes RGB redundant.

Edit: Is there any way to losslessly convert back to RGB?

[natt]

When you have fixed it, converting RGB to I444 YCgCo should be totally lossless, right? :)
That would be really very cool, makes RGB redundant.

Edit: Is there any way to losslessly convert back to RGB?

You need at least one more bit, ie, RGB 8bit->YCgCo 9bit->RGB 8bit is perfect. There's no way to exactly express every value from RGB 8bit in YCgCo 8bit because YCgCo covers a lot more colors.

[aufkrawall]

You need at least one more bit, ie, RGB 8bit->YCgCo 9bit->RGB 8bit is perfect. There's no way to exactly express every value from RGB 8bit in YCgCo 8bit because YCgCo covers a lot more colors.
Can this be achieved with the 10 bit version of x264?

[Zerofool]

Madshi has fixed YCgCo matrix in madVR 0.82.5 (http://forum.doom9.org/showthread.php?p=1564599#post1564599)!
Now correctly encoded videos should look perfect.
I had deleted my previous test samples, so I redid the tests with your latest plug-in (v04), and yes, they all work perfectly with the latest madVR version. Thanks for the heads up!
Unfortunately, I didn't see the expected compression efficiency improvement, only few tens of kilobytes with the little testing I did, but there are possibly cases where the difference will be bigger.

To verify that your encoding is correct open the file in avisynth and add the following command (you need the ManualColorMatrix plug-in (http://forum.doom9.org/showthread.php?t=161777)):
ManualColorMatrix(2, 1.0, -1.0, 1.0, 1.0, 1.0, 0.0, 1.0, -1.0, -1.0, 0.0, -128.0, 256.0)This will convert YCgCo manually to RGB (you need AviSynth 2.6 for YV24 support). If colors are wrong something is wrong with your encode, otherwise the problem is madVR.
Unfortunately, I don't know how to do that, because all H.264 decoders that support 4:4:4 decoding (to my knowledge), only support AYUV output colorspace, which is the closest to YV24, but Avisynth obviously doesn't like it at all. Any suggestions in that regard are welcome.

Can this be achieved with the 10 bit version of x264?
That's what I wondered and asked Dark Shikari, but received no answer, most likely meaning it won't work, or it's too much trouble to implement:
Let's say we have a 8bpp RGB clip, so for its conversion we'll need at least 8bit luma and at least 9bit chroma. So what if we do the conversion and then we upscale the result to 10bit? That way both luma and chroma will have the same depth. Wouldn't the color values remain the same and therefore reproduce the initial 8bpp RGB in the end? Wouldn't it work that way?

[natt]

Can this be achieved with the 10 bit version of x264?

When you tell x264 "--colormatrix YCgCo", all it does set the VUI flag. It otherwise completely ignores it.

That means that if you send x264 supposed "YUV" data that is in fact YCgCo, it will pass it through unmolested, compress it appropriately, and set the VUI flag for YCgCo.

How you do that depends on your workflow. This plugin will allow it with 8 bit, and will work if x264 reads the script directly or you use something like avs2pipemod.

For 10 bit, I don't personally know much about how high bitdepth inside avisynth works. What I did for a few test clips is have my script output the original BGR, and then use a simple command line application of my own creation to do BGR 8 8 8->YCgCo 10 10 10. Seemed to work fine (but was affected by the madvr "teal bug" at the time).

[aufkrawall]

When you tell x264 "--colormatrix YCgCo", all it does set the VUI flag. It otherwise completely ignores it.

That means that if you send x264 supposed "YUV" data that is in fact YCgCo, it will pass it through unmolested, compress it appropriately, and set the VUI flag for YCgCo.

How you do that depends on your workflow. This plugin will allow it with 8 bit, and will work if x264 reads the script directly or you use something like avs2pipemod.

That sounds good. :)


For 10 bit, I don't personally know much about how high bitdepth inside avisynth works. What I did for a few test clips is have my script output the original BGR, and then use a simple command line application of my own creation to do BGR 8 8 8->YCgCo 10 10 10. Seemed to work fine (but was affected by the madvr "teal bug" at the time).
Please, how would you convert a YCgCo 8 bit video back to RGB without writing an own helper tool for this? :D
When I tell Avisynth or x264 to simply convert to RGB, the result is a mess of colors.

Edit: The plug in would need to convert back to RGB, I suppose. :(

[jmartinr]

I posted a feature request for YCgCo in flash player:
https://bugbase.adobe.com/index.cfm?event=bug&id=3150425

[henryho_hk]

Kinda confused..... When we say "Y = 0.25 * R + 0.5 * G + 0.25 * B", are we talking about linearized values or gamma-compressed ones?

[jmartinr]

Feature request for YCgCo in flash player can now be found at:
http://ideas.adobe.com/ct/ct_a_view_idea.bix?c=6D2B3E83-E9E6-4F44-BFB4-F99CBC0646AE&idea_id=3EC9FA2C-1565-41B9-937E-934F863FE04D

[aufkrawall]

xv, are you still working on it?
I just hope so. :)

[jmartinr]

I guess the thing left to do is using more than 8 bits.

[aufkrawall]

http://forum.doom9.org/showpost.php?p=1566080&postcount=34
Sounds to me like an open issue.
It'd be also very helpful if there was a way to convert back from YCgCo to RGB again.