not sure Jason you said something about it being a bad process to use..didn't you?

RGB to YUV isn't a big penalty (about processing power)Don't know if image quality will suffer too much...
The only problem I see is that you would need a YV12 colorspace capable codec to compress the Bayer more or less directly.
If not you would need to interpolate at least the R and B parts.
Are you going to convert the Bayer on camera?

no we capture the RAW pixel data and then de-bayer the image and save with quicktime SheerVideo 10bit....unless that is that we have to go from RGB -> YUV first in a new process?? will the quicktime take care of that or not?

If this is a Quicktime process then I am home free and can jstu input the data into the quicktime SDK and let it do the RGB--> YUV conversion...I am not sure if this is how it works..anyone?

ohh, right.Clear now.
If that is the case just ask your programmer to implement the YUV conversion (I don't trust on built-in conversions, sorry)and send it to the codec..

good news:

Obin,

Within a few days we will release SheerVideo v1.9.8. This public
preview of version 2 will contain all the engine enhancements of v2,
including the incorporation of our StickyColor technology for
interconversion between RGB[A] and Y'CbCr[A] pixel formats. Version 2
turns the six specific SheerVideo codecs into a set of hubs capable of
inputting and outputting any pixel format with the least possible
information loss. In other words, every one of the Sheer codecs:

Sheer RGB[A] 8b
Sheer RGB[A] 10b
Sheer Y'CbCr[A] 8bv 4:4:4[:4]
Sheer Y'CbCr[A] 10bv 4:4:4[:4]
Sheer Y'CbCr[A] 8bv 4:2:2[:4]
Sheer Y'CbCr[A] 10bv 4:2:2[:4]

will directly input and output all of the following pixel formats:

ARGB (RGB[A] 8b)
'b64a' (RGB[A] 10+b)
'v408', 'r408' (Y'CbCr[A] 8bv 4:4:4[:4])
'v410' (Y'CbCr[A] 8bv 4:4:4[:4])
'2vuy', 'yuvs' (Y'CbCr[A] 8bv 4:2:2[:4])
'v210', 'v216', 'Y216' (Y'CbCr[A] 10bv 4:2:2[:4])

I hope this information helps answer your questions.

- Andreas

SheerVideo

Well....
Nice ,isn't it? :)

<<<-- Originally posted by Obin Olson : would anyone care for a frame or 2 in the RAW format we have going? I would like to know the Rob project could transcode this RAW file yet... -->>>

The conversion application will not support this without work from
you guys Obin. As soon as the basics are done it will be an open
source project and you can add your own handler to read your
format. We can't just "magically" add stuff for you.

RGB to YUV conversion is extensively documented and reasonable straight forward to code. It would be worth picking up this book for the algorithms (and better understanding of the process) Video Demystified. One warning RGB to YUV calculations are always performed on gamma corrected RGB -- don't forget this stage.

Hey Obin,

Yah, I forgot about that "sticky color" stuff that Andreas had talked about before. Supposedly it's seemless/lossless RGB->YUV conversion, because typically you are loosing something in the translation from RGB->YUV; the color spaces are not identical (AFAIK), unless using true floating-point operations, and even then I think there are ways to screw it up. I think the big problem is that you typically color-correct in RGB, so even if you have something in YUV, you're going to have to convert it back to RGB for good color-correction and then back to YUV for editing.

ok so then the workflow would be TIFF for CC in high bit and then save to sheer in yuv for editing? how does that sound?

The whole point is to keep it in a greater then 8bit depth at all times..wha would the point of YUV be anyway?

That sounds good.

Altough you might want to consider the option of just doing offline/online-I think that you might be creating more problems that it's worth by trying to edit with the online files when that's not really necessary (unless it's short-form project). I know for anything over 10 minutes, you're gonna want to try and do offline/online for the sake of sanity.

so what an option that allows a save to SD resolution and DV codec??

Sticky color is lossless and artifact free 10 bit RGB > 12(16) bit YUV > 10 bit RGB and 10 bit YUV > 12(16) bit RGB > 10 bit YUV.
http://www.bitjazz.com/bitjazz/press/2004.04.22.shtml

FCP has a very nice mediamanager that will batch process your Project into another format.
It can automatically convert all your uncompressed 10 bit HD files into SD DV (or any other format of choise) and convert your edited sequences as well. All in one single step.
Later you can simply relink to your HD files to make an online version.

Either that or you can use Sequence Publisher from IRIDAS for the conversion of the 16-bit TIFF files to a DV codec. The nice thing about that program is it allows custom burn-windows, etc., things that come in very handy for offline/online workflows.

If you're on the Mac, I can't reccomend Shake enough. Shake combind with some Perl, Python, or Tcl/Tk scripting is an unbeatable combination for file conversion, etc., although it's an expensive file converter at that!

BTW, Obin,

Just want to say again, if you take your 12-bit RGB linear image, and map that to a 10-bit Log colorspace, then encode to Sheer, you should be perfectly fine. In fact, you can then use Stickycolor to go back and forth between YUV and RGB, and like Anders pointed out, no loss. If you just use 10-bit linear though, you're loosing two bits, and in the case of the Altasens, those two bits are valuable, since you have greater than 11bits that are not contaminated by noise according to the Altasens spec sheet.