YCoCg - any chance to use it and support it?

[pandy]

YCoCg seems to be much more optimal to RGB<>YCxCx conversion and processing. Is there any chance tu support YCoCg in future Avisynth versions?

[foxyshadis]

Unfortunately it's not actually supported anywhere, so what would you use it for? Unless you're doing rgb->yuv->rgb in Avisynth, every video codec needs YCbCr. Plus between sampling and display (ie, through all processing, encoding, and decoding stages) YCbCr can usually be maintained, so there's only one conversion cycle.

When you do need RGB, such as with Premier and other NLEs, it would be nice to have something with a closer mapping back to RGB (presumably this is purely a "PC" levels colorspace as well).

[pandy]

Some of avisynth plugins work only in YV12 or/and YUY2, some other plugins (VDub for example) use RGB - using YCoCg can solve such problems. RGB<>YCbCr always loose some amount of information.
YCoCg seems to be like nice solving of problems beetwen two worlds of color coding ie RGB and YCxCy.

[hanfrunz]

what is YCoCg??? Never heard of it... can you give some links?

[unskinnyboy]

This (http://research.microsoft.com/~malvar/papers/JVT-I014r3.pdf) paper covers YCoCg & Reversible YCoCg (YCoCg-R).

[MfA]

Without any fourcc let alone codec support it doesn't make much sense, although maybe things will change when microsoft brings out it's own image compression format (Im relatively sure it uses this color-space).

[guada2]

:thanks: unskinnyboy

@foxyshadis
it seems interesting, but when that is very useful ( i speak only in optimal phase).

Bye.

[pandy]

YCoCg don't need any fourcc - normally we use YCbCr 601 or 709 color, YCoCg is simpler, use only integer, is fully reverssible <> RGB (601 or 709 not), when we mix plugins inside script (from various reasons) we can use both (RGB and YCoCg) color spaces without sacrifice data/information. At the end of script 601 or 709 must be used or - or we can YCoCg treat as special/undefined color space (which is valid as extension to the official MPEG and AVC norms).
Its obvious that YCoCg will not be playable by the modern hardware (its not true when on the output of decoder we use fully programable color matrix - this can be done for example on the Analog Devices digital encoders), but can be playable on all software decoders on modern PC.
I think that we have only two problems:
at first M$ patents problems, second implementations.
AFAIK there is plugin for conversion between 601<>709 - maybe this is first solution - plugin for RGB<>YCoCg with additional sampling schemes conversion valid for YV12 and YUY2.

[MfA]

First of all 24 bit RGB -> 24 bit YCoCg is not reversible, because of the dynamic range increase. Even ignoring that, if you only used it internally in Avisynth the only way this would be handy is if you were mixing filters using RGB and yuv 4:4:4 ... and there are not a whole lot of the latter.

[foxyshadis]

Actually it'd be useful for 4:2:2 and 4:2:0 as well, since its dynamic range (even limited to 8-bit) maps much more closely to 8-bit rgb. It would cut down on some of the severe banding problems that 8-bit YCbCr causes, since its dynamic range is too high at some points and too low at others - exacerbated by the use of "TV" levels. The chroma bleeding of subsampling is an unrelated issue.

For fully reversible to RGB you need 9-bit YCoCg or 10-bit YCbCr.

YCoCg may be what the new Windows Picture Format is coded in. I knew it didn't always use YCbCr before, but wasn't sure what it did use. Since it was submitted to JVT, it should at least be part of a patent pool.

[IanB]

In the 2.6 Branch we have a generic 3x3 matrix transform which we use to do the YV24 <-> RGB transforms. It currently has Rec.601 and Rec.709 matrices (TV and PC levels versions). It could certainly grow other matrices.

One of the issues that the YCoCg people seems to have neglected in their transform is that the Y component is not related to Luminance as seen by the human eye. They are using Y=0.25*R+0.5*G+0.25*B. Many of the tricks used to achieve acceptable lossfull video compression rely on good decoupling between luma and chroma signals. This correlation with human vision is assumed by many of the YUV video filters, so YCoCg probably would not be a good candidate colour space to process in.

The original NTSC YIQ encoding scheme allowed for twice the bandwidth for the I chroma (orange-cyan axis) component, but universally TV manufacturers chose to use a simpler, cheaper decoder that ignored this improvement. This technology has been relegated to history. YIQ could be a good choice to process in.

[MfA]

The way color is translated into perceived brightness is rather complex, and certainly not linear. I doubt the difference between YCoCg and YUV is all that important in that respect. The fact that it decorrelates better is probably more important.

[foxyshadis]

Yes, I noticed while implementing the filter (hijacking YV12 as the output space >.>) that it was designed entirely for additions and shifts, ie, extremely fast transforms, rather than being related to perceptual quality. I'm not convinced that even at the time it was introduced there was any need for it.

It loses more important areas where the eye has a stronger response, gives too much weight to blue, and as Ian says, the chroma planes retain far too much brightness information.

It seems it's past time to introduce non-linear transforms (polynomial or exponential) to more perfectly reproduce the eye's non-linear responses to colors, as well as local brightness and saturation. Certainly the computing power has long been available.

I suppose I could finish if anyone really wants to experiment, but lossy compression results looked rather worse already.

[CruNcher]

@foxyshadis and MfA
maybe it has something todo with this
http://research.microsoft.com/Asia/dload_files/group/mcom/2005/cr1402.pdf ?