any codec taking rgb and storing in YUV 4:4:4

[cipher]

If the very original source is in RGB (such as computer generated graphics), then the cost of conversion to yuy2/yv12 colorspace seems to be visible, as the video becomes fainter/greyer/less vivid/less colorful.

Correct me if i'm wrong, but corrently only studio/high profiles of mpeg2 and avc, and theora specs support yuv 4:4:4, so i'm wondering if any codec of these specs actually has implemented storage in yuv 4:4:4?

thx so much!


-- edit ---
x264's lossless mode seems to support yuv 4:4:4, but doesnt seem to take rgb as input, but then pre-converting rgb to yv12 loses the point, in terms of conserving the colours...

[foxyshadis]

YUV 4:4:4 (YV24) has nothing to do with vividness; that is caused by improper colorspace conversions. YV24 is useful for eliminating color bleeding on fine detail. 16-bit YUV is useful for eliminating the severe chroma banding that conversion to YUV causes at times, particularly in noiseless gradients in lights and darks. Neither of these is widely supported at all, though avisynth 2.6 and 3.0 will eventually have some support.

But the compression of whites and blacks into greys is due to "tv" mode yuv being converted via a "pc" mode algorithm. If your decoder is doing it incorrectly, you need relevel it (before or after) by adding a levels input=>16,1.0,235 ouput=>0,255 to the chain somewhere.

[cipher]

But the compression of whites and blacks into greys is due to "tv" mode yuv being converted via a "pc" mode algorithm. If your decoder is doing it incorrectly, you need relevel it (before or after) by adding a levels input=>16,1.0,235 ouput=>0,255 to the chain somewhere.

yes you're completely right, because different encoders assume different color ranges of the input, if not done right, colorspace conversions sometimes can cause seemingly similar color problems. But here the comparisons were made in virtudub before the actually encoding, only after the colorspace conversions, so it's not an issue of yc compress/stretch, i also tried both converttoyv12() and converttoyv12(matrix="pc.601") which are similar to the "pc/tv scales" manipulations, yet the produced pictures were still too different from the original. ^_^

i guess my wording there ("fainter/greyer/less vivid/less colorful") is a bit too confusing :D i should've avoided using them, sorry about that :p

here is what i really meant by that:

oirg = rgb source
http://hmm.cc/files/1800-VsDzo2/orig.png

yuy2 = orig.ConvertToYUY2()
http://hmm.cc/files/1801-x6u69F/yuy2.png

yuy2m = orig.ConvertToYUY2(matrix="pc.601")
http://hmm.cc/files/1802-XwnkyO/yuy2m.png

yv12 = orig.ConvertToYV12()
http://hmm.cc/files/1803-QDWFtI/yv12.png

yv12m = orig.ConvertToYV12(matrix="pc.601")
http://hmm.cc/files/1804-oOUD7G/yv12m.png

Subsampling during coversion and upsampling/averaging-out when converting it back to rgb (to display in monitor) makes the conversion visually irreversible. As expected, rgb-->yuy2-->rgb gives closer result to the original than rgb-->yv12-->rgb probably due to less subsampling.

but since most common codecs would convert inputs to yv12 if they're not already in yv12, we'll eventually end up with results similar to the last 2 pictures above, which is what drives me to ask for a codec featuring YUV 4:4:4 storage ^_^.

btw, if there is some codec supporting what i want, how much compression should i expect?

say, an 8gb losslessly recorded gameplay can be compressed to 100mb in x264 with superior quality (except for the color which is really nobody's fault). But if a yuv 4:4:4 codec has to take say, 7gb, to do a similar job with the right colors, then i'll just accept the fate and go with yv12 :D

[foxyshadis]

Ah, that's exactly where you'd notice it. Does it have to be mpeg? Because if not, zmbv or msu screen lossless would probably compress it more than mpeg without any artifacts or color conversions.

If it does (standalone playback or whatever), you could pointresize to 2x. Otherwise, I believe Sorenson Squeeze can encode to it, several commercial mpeg-2 encoders, and possibly elecard & ateme mpeg-4 products, but I'm not aware of any free software that does yet. ffmpeg supports full-chroma for lossless, but I don't see any way of using it with mpeg encoders.

[fccHandler]

PICVideo MJPEG can store YUV 4:4:4 motion JPEG, if you set its subsampling to 1/1/1.

[mpgxsvcd]

PICVideo MJPEG can store YUV 4:4:4 motion JPEG, if you set its subsampling to 1/1/1.

Is it possible that the mjpeg video in my Canon S3-IS Digital Still camera is 640x480 4:4:4? It stores it in a 640x480 30 FPS progressive mjpeg in a .avi container. When I use Windows Media encoder 9 and set the Pixel format to YV12 I see the chroma affect on bright red objects. Is there another pixel format I should try? My choices are IYUV, I420, YV12, YUY2, UYVY, YVYU, YVU9, RGB 24, RGB 32, RGB 555, RGB 565, and RGB 8. Which one of those are 4:4:4? Is there a way to determine what pixel format a video was recorded in?

[fccHandler]

RGB24 or RGB32 will keep the full chroma. However, I think if you're encoding to WMV or MPEG4 it's going to get downsampled to 4:2:0 regardless. Honestly I'm not quite sure what the "pixel format" selector in WME9 does, or why they put it there.

I don't know a program to tell you the format of your MJPEG, but if you upload a short clip I can probably tell you.

[cipher]

Because if not, zmbv or msu screen lossless would probably compress it more than mpeg without any artifacts or color conversions.

msu is amazing!...i cant believe it has compressed a 7.xgb, already huffyuv-compressed video into 45mb (losslessly!), which makes the comparison on its webpage (http://www.compression.ru/video/ls-codec/screen_capture_codec_en.html) between msu and huffyuv really conservative. And you're right, it can probably beat h.264 in this case, as the bitrate is as low as 213kbps (256x224@60fps), well at least the colors are all right :D

thank you all guys, and especially thank you foxyshadis :)

[mpgxsvcd]

RGB24 or RGB32 will keep the full chroma. However, I think if you're encoding to WMV or MPEG4 it's going to get downsampled to 4:2:0 regardless. Honestly I'm not quite sure what the "pixel format" selector in WME9 does, or why they put it there.

I don't know a program to tell you the format of your MJPEG, but if you upload a short clip I can probably tell you.

Here is a sample movie that I am trying to convert to Windows Media Advanced Profile. It is a 640x480 30 FPS MJPEG video in a .avi container. Can you tell me what pixel format this movie is in(4:4:4, 4:2:0, etc……)? What color space does it use(YV12, RGB, etc...)?

http://img2.dpreview.com/reviews/S3IS/MVI_0639.AVI

[fccHandler]

It's JPEG-compressed YCbCr 4:2:2. Decompressing this source to YUY2 pixel format will not lose any color information. Hope that helps. :)

[mpgxsvcd]

It's JPEG-compressed YCbCr 4:2:2. Decompressing this source to YUY2 pixel format will not lose any color information. Hope that helps. :)


Awesome thanks. What if I used YV12? Would YV12 have any color loss?

[fccHandler]

Yes, if you use YV12 then the two color planes (Cb and Cr) will be downsampled to half their height. You'll lose some vertical color resolution, but you may lose that anyway when you convert to WMV. I don't know if Advanced Profile supports 4:2:2 sampling, or how to do it. We need zambelli here...

[zambelli]

Yes, if you use YV12 then the two color planes (Cb and Cr) will be downsampled to half their height. You'll lose some vertical color resolution, but you may lose that anyway when you convert to WMV. I don't know if Advanced Profile supports 4:2:2 sampling, or how to do it. We need zambelli here...
No, only 4:2:0 is supported in Advanced Profile. Sorry.

[mpgxsvcd]

No, only 4:2:0 is supported in Advanced Profile. Sorry.

Zambelli,

Ok I figured that wmv9 would not support 4:2:2. However, when I encode the same file with Windows Media Encoder 9 studio it appears to keep the 4:2:2 color. There is an obvious difference between what I get in WME9 and what I get in WME9 Studio. Is it possible that WME9 Studio can keep the 4:2:2? You said that wmv9 advanced can not do 4:2:2. Can any other “wmv” codec do 4:2:2? I think you need the quicktime codec to decode the mjpeg .avi files that I posted.

[j7n]

Almost two years have passed since the original question. Has the situation changed?

Is there any video codec supporting full resolution YCbCr?

[The_Dukester]

How about Sheervideo?:

http://www.bitjazz.com/en/products/sheervideo/

[j7n]

SheerVideo appears to be lossless. For that there are free solutions.

I find the chroma subsampling a "legacy" technology, much like interlacing. Not unlike the later, it also eats CPU during upsampling: in ffdshow, almost as much as the video decoding itself (ASP, MPEG-2). And from experience with JPEG, it does not offer substantial space savings. Ironically the people bragging about their megapixels/HD hardware, most often don't realise that the actual amount of px is only half of that only for this one example.

[Dark Shikari]

SheerVideo appears to be lossless. For that there are free solutions.

I find the chroma subsampling a "legacy" technology, much like interlacing.Once you realize how many bits end up being wasted on chroma in modern codecs in 4:4:4 mode (and, correspondingly, how little visual difference there is), you'll understand why it isn't legacy ;)
I find the chroma subsampling a "legacy" technology, much like interlacing. Not unlike the later, it also eats CPU during upsampling: in ffdshow, almost as much as the video decoding itself (ASP, MPEG-2).No it doesn't, because all modern video cards support YV12 output.
And from experience with JPEG, it does not offer substantial space savings.This isn't necessarily the case for video, however.
Ironically the people bragging about their megapixels/HD hardware, most often don't realise that the actual amount of px is only half of that only for this one example.Part of the point of YUV in modern video formats is to concentrate as much information as possible into the luminance channel; therefore, it isn't inaccurate to use luma as the main indicator of "megapixels."

[akupenguin]

Given a certain number of samples, I'd take 1920x1080 4:2:0 over 1358x764 4:4:4, thankyouverymuch.

[j7n]

The fact that these arguments are expressed by most experienced developers does bear certain weight. I suppose my viewing conditions (25cm from the display) are the reason why chroma artifacts bother me. But then again nobody objects audio quality evaluation using headphones.

This isn't necessarily the case for video, however.
In laymans terms, why is it so?

The hardware support for reduced resolution YUV is poor at least in some ATI Radeons: Only one simultaneous stream is supported. And blurred reds are not that much better than blocky reds. Proper, smooth upsampling only makes you believe that no details have been lost, it doesn't put these details back.

[Caroliano]

Once you realize how many bits end up being wasted on chroma in modern codecs in 4:4:4 mode (and, correspondingly, how little visual difference there is), you'll understand why it isn't legacy
And what about 4:2:2? It should already be sufficient to eliminate the severe banding. Is this more wastefull than using gradfunk and then encoding with --fgo in x264 and an low quantizer?

[Dark Shikari]

And what about 4:2:2? It should already be sufficient to eliminate the severe banding. Is this more wastefull than using gradfunk and then encoding with --fgo in x264 and an low quantizer?Why would chroma subsampling cause banding, and/or why would a lack of chroma subsampling eliminate banding?

[akupenguin]

Proper, smooth upsampling only makes you believe that no details have been lost, it doesn't put these details back.
The foundation of psy optimization is: If you can't tell, it doesn't matter.

[Caroliano]

I'm based at what foxyshadis said, and that I already have heard in other places
16-bit YUV is useful for eliminating the severe chroma banding that conversion to YUV causes at times, particularly in noiseless gradients in lights and darks.
Did I misundertood?

[Dark Shikari]

I'm based at what foxyshadis said, and that I already have heard in other places

Did I misundertood?He's talking about higher-bit Y channel, e.g. 12-bit Y and normal 4-bit UV instead of 8-bit Y. This has nothing to do with chroma subsampling.

[akupenguin]

He's talking about higher-bit Y channel, e.g. 12-bit Y and normal 4-bit UV instead of 8-bit Y. This has nothing to do with chroma subsampling.
Now that's misleading. 4-bit UV would be really bandy. It's 8-bit, 4x subsampled. As opposed to, say, 16-bit 8x subsampled, which is the same total bits per pixel but with less band and more blur.
I also don't know any applications that use different depth for Y and UV, though H.264 allows it.

[Dark Shikari]

Now that's misleading. 4-bit UV would be really bandy. It's 8-bit, 4x subsampled. As opposed to, say, 16-bit 8x subsampled, which is the same total bits per pixel but with less band and more blur.That's true, but how else are we supposed to express numbers that add up to 12-bit (YV12), 16-bit, etc? :p I probably should have been a bit more clear.

[akupenguin]

You're not supposed to. Don't say "YV#" for any # other than 12. Because 12 is the only one that isn't ambiguous (ok, I'm discounting the possibility of 10-bit Y, 8-bit UV, 4:1:0 :))

[Inventive Software]

This could of course all be negated and you could use RGB32. Wasted bits, mind....

[j7n]

Of course RGB would be quite wasteful, at least for lossy. But the title of this topic says YUV.

Seeing how much transcoding is still taking place, and how some people see YV12 problem gone (http://forum.doom9.org/showthread.php?p=340302#post340302) just by applying interpolation, I guess transparency is not yet in demand from video encoders.

No it doesn't, because all modern video cards support YV12 output.
YV12 sucks @ss also on Intel 965G. This video driver resamples the Y channel! I made nice sharp grayscale credits and they came out as if lowpassed for TV.

Personally I hate 4:2:0 and don't know how people can put up with it. In this day and age of super high res and computing power it is sad that we are limited to 4:2:0 for the foreable future (both BluRay and HD-DVD are 4:2:0 only right?). 4:4:4 should be standard. Oh well...

Yeah, chroma subsampling sucks, no doubt about it. But is not THAT bad (especially 4:2:2), and it was necessary for digital video to even be practical in the old days. Eventually we will kick chroma subsampling to the curb I'm sure, but for now, it remains an effective compression method. Let's murder interlacing first!!!

I will speak of this topic no more until another two years have passed.