YCbCr *into* RGB channels.

[Richard Berg]

Nice post -- one of the better color cube explanations I've seen.

Now then...people who are THAT concerned about color fidelity shouldn't be using DV

[Dimwitted]

trevlac, thank you very much! I don't understand any of the source code, but it appears to do exactly what I want!

[khmann]

Originally posted by trevlac

On the following I don't really mean to pick at you but I think this exemplifies the colorspace conversion bitching that bugs me.

How do you think it comes up with luma ? ~ R*.3 + G*.6 + B*.1

very true. this and the 4:4:4 = 4x 4:2:0 are good points. In my case, Deshaker is a two pass motion-compensation (steadycam) operation that requires RGB data. First pass, I give it raw DV in VirtualDub. This works best as DV edge enhancement is present which helps with tracking. (yuy2inrgb still seems to work for this, but probably not recommended)

Second pass I call through VDmod plugin inside AVS script. Since second pass just scales and offsets input video based on motion vectors from pass 1 (I already feed it softer (FFT'd) video for better compression/anti-aliasing) this method of stuffing YCbCr would seem to work very well. How many other legitimate uses there are, I have no idea.

...

<rant> But I can't wait for some form of 4:4:4 YCbCr 16bit avisynth- even though everything would need to be re-written to take advantage of it. Until then I'm hoping to combine many of the functions I use to master my video (4:1:1 -> 4:2:2, levels, gamma, contrast, hue offset, saturation, overlay... with some mild AGC) into a single filter so that I can do everything 16 bit internally, and then round (or dither) back to 8 bit for output... </rant>

uh... which I can then MPEG2 encode at 256kbit... uh.. :) yes, in most cases the impact of stacking 8 bit filters and color space conversions is negligable.

I'm still new to avisynth development. although I have coded many similar things under Linux using mjpegtools 'y4m' planer Y CbCr interface, I'm a little lost on the packed pixel behavior of the (interpolate) clause.

I'll get there... thanks for your time!

[khmann]

Originally posted by Dimwitted

Hence, I would like to find a method (presumably using Avisynth) that will output an uncompressed (RGB) AVI file, in which R contains the Y, G contains the Cb, and B contains the Cr data from the original DV AVI.

I think the "correct" behavior of this would be:

Y into G
Cr into R
Cb into B

that way things remain somewhat closer to "normal", ha ha...

And I wouldn't turn down a RGBINYUY2, as aparantly avisynth development requires MS Visual C which I'll have to try using at work next week...

[trevlac]

@Richard

Thanks for the comment.


@khmann

<rant> But I can't wait for some form of 4:4:4 YCbCr 16bit avisynth- even though everything would need to be re-written to take advantage of it. Until then I'm hoping to combine many of the functions I use to master my video (4:1:1 -> 4:2:2, levels, gamma, contrast, hue offset, saturation, overlay... with some mild AGC) into a single filter so that I can do everything 16 bit internally, and then round (or dither) back to 8 bit for output... </rant>

16bit would be nifty. If you get that all in one working ... please share. I very much a novice at AVS or even video code. But frankly ... I'm beginning to find it more fun than actually making the video.

Also ... nice comments on deshaker. I havn't really looked at it, but what you say does make sense. Although the scaling of the CbCr might be messy. And GBR to YUV would be better