post in 16 bit how to do ?????

[Deanan]

Shake does not support all codecs at > 8bit. (more specifically it needs
to support the 16bit pixel type because it doesn't support the float one). I'm not sure if it supports any of the 10bit types. So even though codecs like ProRes are 10bit, they go into shake at 8bit.

 

[eskatonia]

deanen, I'm confused as that directly contradicts my own testing experience using shake. I can visually see the difference between a 10 bit ramp as a pro res file and an 8 bit ramp when I view them in shake with gamma 0.1. I realise that shake may not work with all 10 bit codecs but it seems to me that it does work correctly with Pro res 10 bit and cineform 10 bit codecs.

I'll double triple check this to make sure I wasn't hallucinating

edit: shake also support openexr files in float format.

 

[galexander]

deanen, I'm confused as that directly contradicts my own testing experience using shake. I can visually see the difference between a 10 bit ramp as a pro res file and an 8 bit ramp when I view them in shake with gamma 0.1. I realise that shake may not work with all 10 bit codecs but it seems to me that it does work correctly with Pro res 10 bit and cineform 10 bit codecs.

I'll double triple check this to make sure I wasn't hallucinating

if you were hallucinating, can i have some of that ? ha ha ha ha

maybe CRC check the binary size of the file, 10-bit should be larger than 8-for the same size frame. visually you might not see much difference, depends on the scenary, log curve, intensity,.. blah, blah, blah. post what your gamma log curves look like. as you push the high and low ends, the black should be BLACK, white very WHITE.

 

[eskatonia]

I'd rather trust my own eyes.

this is the method I use to test that a workflow is "10 bit clean"

generate a 10 bit ramp file inside final cut pro (I made some plugins to do that). Write them out as in a 10 bit codec. Bring it into shake, apply a gamma 0.1 and then toggle between 8 and 16 bit using an "other->bytes" node.

you can clearly see banding artifacts if any stage of your workflow truncates to 8 bit using this method. On the sample R3D files of the dragsters that jim posted I can see banding on the graduation on the barrel in the background if I export in an 8 bit codec and view it with gamma 0.1

 

[galexander]

I'd rather trust my own eyes.

this is the method I use to test that a workflow is "10 bit clean"

generate a 10 bit ramp file inside final cut pro (I made some plugins to do that). Write them out as in a 10 bit codec. Bring it into shake, apply a gamma 0.1 and then toggle between 8 and 16 bit using an "other->bytes" node.

you can clearly see banding artifacts if any stage of your workflow truncates to 8 bit using this method. On the sample R3D files of the dragsters that jim posted I can see banding on the graduation on the barrel in the background if I export in an 8 bit codec and view it with gamma 0.1

well you can use the "force Luke" if you want to, i trust in little Endians and big Endians myself.

how are you padding the 10-bit data to get to 16-bit? why don't you just convert it to 32-bit floats?

"banding" can mean lots of things..??

if you throw out the LSB, doesn't toggle, isn't random, stuck, your noise floor rises significantly.

 

[eskatonia]

I'm not padding anything. All I'm saying is that I've tested Red Cine -> 10 bit codecs and it has 10 bit color information. Check it yourself using the method I describe.

From there I've tested applying my own plugins in FCP and motion which render in 32 bit YUV back to the codec which the users has selected as their sequence settings. So by using a 10 bit codec and plugins which render in high precison color in FCP you do do an online which preserves your color information in 10 bit through to the final master.

FCP is restricted in that it can only render in > 8 bit if you select a YUV sequence setting. Read my workflow papers for the full details. I welcome people visually testing what I suggest, if there's hole's in it, I want to find them and fix them.

www.coremelt.com/support/workflow

 

[galexander]

I'm not padding anything. All I'm saying is that I've tested Red Cine -> 10 bit codecs and it has 10 bit color information. Check it yourself using the method I describe.

From there I've tested applying my own plugins in FCP and motion which render in 32 bit YUV back to the codec which the users has selected as their sequence settings. So by using a 10 bit codec and plugins which render in high precison color in FCP you do do an online which preserves your color information in 10 bit through to the final master.

FCP is restricted in that it can only render in > 8 bit if you select a YUV sequence setting. Read my workflow papers for the full details. I welcome people visually testing what I suggest, if there's hole's in it, I want to find them and fix them.

www.coremelt.com/support/workflow

look in your previous post you stated that in "shake" you toggle between 8 bit and 16bit. you have to know what you're doing converting data. why anyone would really use 10-bits ? you can't allign 10-bits on the memory boundary, you're wasting lots of space and fragmenting the memory.

 

[eskatonia]

we're clearly trying to reach different goals. The reason to work in 10 bits is that it's well supported in FCP using the pro res codec. There is no 16 bit quicktime codec which FCP can render its timeline and effects processing to.

Full 16 bit is great but its over kill for a lot of purposes where a 10 bit color pipeline would be just fine.

 

[Rainer Fritz]

great discussion..... thx a lot.....

when yoou choose fcp for offline edit it is fine... if you don't want to spend a big number of thousands euros there must be a pssibility to online in a quality standard that matches at minimum the 12 bit linear color space of the red footage... so the pipeline on apple based workflow has to have at least this goal... the first problem was, that color only support 10 bit linear color space, but i am loosing much information because both codecs that support color are 10 bit linear 4:2:2
so one possibility was to use the glue tools plugin to online and grade in dpx format with 10 bit log color space... or using the codecs posted in this thread and render the final file in a format you can playout....
so in my opinion for HD broadcast and DVD finishing 10 bit linear space is ok... but for filmout or D-Cinema it is not....
when i look to fcp what it does with the footage when you add a 3 way color correction for example, there is banding coming up you think you are cutting some dvd ripped footage....
so working with prores422 it is fine for offline... but nothing else....
10 bit 4:2:2 "uncompressed" works also fine and its able to grade in color, but you are loosing color space...
does anybody have a good manual for working with dpx format? i have never done it... and for me it seems together with the glue tools plug in a cheap and solid way to get the best result....

thx a lot
rainer

 

[eskatonia]

rainier, I see there are two classes of people that want to use RED.

a) people that want absolute best quality and nothing short of a 4K 16 bit (or 32 bit float) workflow will do for them. There is a lot of people looking at that, I'm watching it very interestingly and I look forward to seeing what kind of 32 bit HDR workflows people develop. Yeah then you want a DI system at the moment.

b) people that want a step up from HDCAM or other HD formats to something more like film without a huge jump in complexity. These people want a workflow thats as close to shooting video and editing as possible.

for b) I believe that 10 bit and 12 bit online workflows in FCP are appealing.

Don't dismiss the quality of a max bit rate 10 bit ProRes 422 HD master, it is very very good for many purposes. Cineform 2K/12 bit gives you even better quality and will keep the full dynamic range of your 12 bit RED footage. It possible to online in those formats in FCP right now using the steps I suggest.

 

[Simon Blackledge]

Shake screws blackmagic 10bit files currently until you force 8bit on the file in.
s

 

[galexander]

Shake screws blackmagic 10bit files currently until you force 8bit on the file in.
s

ah, now we're getting to the good stuff. what do you mean by 'screws' the 10bit files? what's going on?

 

[Simon Blackledge]

unsure.. apparently an apple problem:-/

if you plot a 10bit its fine.. just funny jumping random coloured pixels on the far right of frame.. so for 8bit makes them go..

something to do with endiens and how it reads them maybe ? :-/


Currently if were doing work off tape.. HD SD we capture 10bit uncompressed. These get passed to an AE pipeline that exports dpx seq.

Were moving to gluetools no though.

s

 

[galexander]

flameop is getting close.

not flameop but others who post here, i think maybe there is a 3rd class of people those who don't understand the implications of LSB vs noise floor vs alignment on a memory boundary.

upconverting is not just padding with zeros to make up the LSB.

 

[galexander]

we're clearly trying to reach different goals. The reason to work in 10 bits is that it's well supported in FCP using the pro res codec. There is no 16 bit quicktime codec which FCP can render its timeline and effects processing to.

Full 16 bit is great but its over kill for a lot of purposes where a 10 bit color pipeline would be just fine.

not to get into a flame war but to be honest, you obviously don't have a clue about QT, QT has 16-bit and higher built in to the libs. they are just VERY, VERY badly implemented.

google is your friend, try this
http://www.virtualdenmark.dk/qtvr/16bit/qtvr16bit.html

and obviously you have no clue about what the LSB vs 8bit, 10bit or 16bit vs noise floor vs aligning on a memory boundary. it has nothing to do with FCP. i'm not trying to be mean, just trying to enlighten.

 

[galexander]

unsure.. apparently an apple problem:-/

if you plot a 10bit its fine.. just funny jumping random coloured pixels on the far right of frame.. so for 8bit makes them go..

something to do with endiens and how it reads them maybe ? :-/

yes, yes, YES,YESSSS!!!!!!!!!! Woohoooo!!!!!

it's damn LSB!!!!

 

[Simon Blackledge]

yep.. same as colour reading some dpx files and clipping vs others not..

I spoke to a pretty high up pro apps dude at IBC 07 and he said he was aware of some apps reading big endians diff from others.. such as dpx in AE and color.

This is over my head but I hope it helps .. if you can help me understand that would be cool.. happy to run any tests at work you need.

s

 

[galexander]

yep.. same as colour reading some dpx files and clipping vs others not..

I spoke to a pretty high up pro apps dude at IBC 07 and he said he was aware of some apps reading big endians diff from others.. such as dpx in AE and color.

This is over my head but I hope it helps .. if you can help me understand that would be cool.. happy to run any tests at work you need.

s

i don't know what setup you have for analyzing but you need to be able look at a histogram of the components and measure the noise floor relative to a good peak, so you need a good signal to noise ratio, S/N.

or run an algorithm over the frame to find the noise floor, the smallest number, without hitting a 'dead' pixel, i'll post what a one looks like for a dark calibration. the chevrons are caused by noise spikes. the light and darker sides of the image are caused because the noise floor of each have offsets, biases in the LSB. in the 3d images, i've overlayed a contour plot on top of the 3d view of the actual pixel array. the one of the right you can see the 'grass' or noise is a lot more than on the left.

LSBs (Least Significant Bits) are important because they define the noise floor. for truly choatic, brownian noise, the LSBs need to be random, so the gaussian distribution of the noise has a mean of ~0.

if the the LSB is 'stuck' meaning has the same value or changes very slowly, the noise floor will rise as this is a constant value. you have added a constant offset, DC component if you will. the noise has increased but the peak signal remains the same, so the S/N has now dropped by the rms average of the 'stuck' bits.

downconverting 16-bit to 8-bit is fairly easy, just truncate if all else fails, chances are fairly good the the LSB will remain random but when you go from 8-bit to 16-bit, you need to be careful how the LSBs are being created, utilized, or chopped to ensure that they are random. otherwise you could get banding, 'bad' pixels, spikes... depends on algorithm in the software really. as you point out from your experience, some do better jobs than others.

hope this wasn't too much egghead stuff....

 

[Simon Blackledge]

no no I get it.. suspect shake is banging its head on a few so to speak.

Just cant get my head round why its just on the right of frame..

Though I will add this. Brights or darks are ok.. no sparkles.. as soon as you get into mids.. then it sparkles.. re reads the data wrong..

do you have access to shake ?

oh.. quick addition.. exporting a 10bit QT via shake gives a really screwed image..

Also Imagineer apps taking in 10bit bm qt's looks the same.. screwed image.. like a really bad encode.. bits randomly read. etc ...

reason we are moving away from BM capture to Scratch.


s

s

 

[galexander]

no no I get it.. suspect shake is banging its head on a few so to speak.

Just cant get my head round why its just on the right of frame..

can you post a 3d image of the pixels like i did? that's the easiest quickest way to 'see' the pixel values.

Though I will add this. Brights or darks are ok.. no sparkles.. as soon as you get into mids.. then it sparkles.. re reads the data wrong..

tough to say without knowing the software really, i'd just be guessing really but to me sounds like the routine is fairly simple, maybe only 2-pt nearest neighbor or linear to be fast?.?.?.? again this could be completely wrong.

do you have access to shake ?

sorry no, i've been lurking around trying to see if anyone has gotten a 10-bit pipeline completely working, the only one so far is Cineform...

i put up a thread with a poll in the redcine if you want to add to the poll.

oh.. quick addition.. exporting a 10bit QT via shake gives a really screwed image..

Also Imagineer apps taking in 10bit bm qt's looks the same.. screwed image.. like a really bad encode.. bits randomly read. etc ...
reason we are moving away from BM capture to Scratch.

QT libs... uugggh, so far they are a no-goer for me, real showstopper.

it has been suggested that
"RedCine should be using the pixel format 'b64a' ", see if this helps..

i have no experience with BM capture, sorry.