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

[Rainer Fritz]

Hi All !

So after testing around I am a little bit confused...
Can please somebody explane me how to do the post on apple in 16 bit...
It seems to me that there are some problems....
When I render with Redcine 16 bit Tiffs FCP has great problems with that... same at color... dpx file export from redcine works only at 10 bit at the moment I think so.... export options from color seems to be only prores or 10 bit uncompressed 4:2:2....
so i want to export tiffs or dpx in 16 bit from redcine and want to online the proxies of that in fcp and then grading it in color... but that seems not possible...

thx

rainer

[I Bloom]

so i want to export tiffs or dpx in 16 bit from redcine and want to online the proxies of that in fcp and then grading it in color... but that seems not possible...


You are speaking of 2K images correct?

IBloom

[Rainer Fritz]

yes 2k....

[Sanjin Jukic]

Rainer,

You should buy Glue-tools DPX plug in for FCP (http://www.gluetools.com/products_dpx.html)>>

"Currently supports QuickTime’s 16-bits per channel API."

Also call them directly and get confirmation about it before you buy.

Link>> (http://www.gluetools.com/contact.html)

[Rainer Fritz]

thx for the information sanjin... i have had the demo version installed...
so but i am confused, because dpx is 10bit log.... think i know not enough about the theory on the codec... it would be roughly enough because the cam has a 12 bit depth... but why has final cut and color so big problems on the tiff sequences and proxies when i can choose it at my timeline settings... color can't handle that tiffs anyway....
i wan't to use the highest quality level...

[Thomas Mathai]

16bit tiffs won't help you in FCP, since FCP is quicktime only and tiffs will be imported as single stills, not as clips like After Effects or Motion would do.

You would want to convert to a 16bit quicktime codec. There are a few out there, but I haven't tried them for editing.

I know Digital Anarchy has the Microcosm Codec, http://www.digitalanarchy.com/micro/micro_main.html

They also have a 16bit None codec for free, though I doubt that would be practical.

If you have scanned film to DPX files, then most likely they are in log color space, but you can have DPX files in any color space you want.

[Rainer Fritz]

Thx Thomas for the info....

I tried it with apple's animation codec.... in fcp it works... but in color not.
So here again asked for implementing more codecs from apple side to color. the best is 10 bit uncompressed, but that is for filmmakers not enough. color should be able to handle the animation codec....

thx
rainer

[Dominic Jones]

Do some research on Log vs Lin formats, as they are very different (Wikipedia, maybe?). It's not really my area of expertise, but 10-bit Log is generally regarded as able to handle as much dynamic range as 16-bit Lin, although there is some argument about exactly how many stops of DR can be effectively encoded into 10-bit Log.

The Red is 12-bit Lin, which by all accounts is well below the threshold for 10-bit Log encoding.

Most high-end work (such as DI's for features etc) is currently done using 10-bit Log DPX stacks, so it certainly is "good enough" to handle high end CC and VFX work - you should be fine with that, give it a try...

[Lucas Wilson]

Do some research on Log vs Lin formats, as they are very different (Wikipedia, maybe?). It's not really my area of expertise, but 10-bit Log is generally regarded as able to handle as much dynamic range as 16-bit Lin, although there is some argument about exactly how many stops of DR can be effectively encoded into 10-bit Log.

The Red is 12-bit Lin, which by all accounts is well below the threshold for 10-bit Log encoding.

Most high-end work (such as DI's for features etc) is currently done using 10-bit Log DPX stacks, so it certainly is "good enough" to handle high end CC and VFX work - you should be fine with that, give it a try...

This is all basically true, but you leave off one critical element...

If you are working in 10-bit log, then you *must* have LUT capability for viewing to convert log data into gamma-encoded linear for proper viewing.

To my knowledge, FCP doesn't have any kind of realtime LUT capability. Any 10-bit log material would have to be linearized on input in order to work correctly, which sort of defeats the point of working in log space.

I'd be happy to be proven wrong about this functionality in FCP/FCS2, but I'm pretty sure it isn't there.

Lucas
------
ASSIMILATE, Inc.
LA, CA, USA

[Simon Blackledge]

You could put a HD-Link Pro into the mix and use a LUT via that to drive another monitor. Thats all I can think of currently with FCP.

Apple Color can use them, as well as using say CineSpace
http://cinespace.risingsunresearch.com/forum/viewtopic.php?p=251&sid=6c9a37762f6bfc3bf0df505d2852954e


Si

[Nick Shaw]

FCP can't handle 10 bit log properly (other than by using eg Blackmagic 10 bit RGB codec for cut only editing with, as Si says, an HDLink on the output for viewing LUTs) but Color can work with 10 bit log DPXs, and does have LUT functionality. You need to be very careful, and do some stuff manually, but you can do a DPX conform (2k) in Color.

[Rainer Fritz]

thx a lot for feedback and info....

I should take a little bit more knowledge on dpx and the gluetool plugin, because it is also working on color...

Do you know some knowledge links on the web ?

if apple is not coming down from theire way.....

thx
rainer

[Stokestack]

I would take a look at BitJazz's Sheer codec. It gives you lots of options regarding color space, alpha, color sampling. It also losslessly (TRULY losslessly) compresses, so you save some space. There's also a free decompressor for it, in case you need to pass the footage around.

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

[Simon Blackledge]

Not sure how upto date this is

http://www.bitjazz.com/en/support/sheervideo/known_problems.php

s

[eskatonia]

why do you need to do the post in 16 bit? Whats your final delivery format? is it for feature film work? if not then why are you attempting 16 bit?
Just curious as a full 16 bit workflow will be very painful for no gain unless you are doing a DI and going back to film... In which case i suggest using a DI system and not FCP.

is the 10 bit online workflow I've suggested any use to you?

see here:
http://www.coremelt.com/support/workflow/

[galexander]

why do you need to do the post in 16 bit? Whats your final delivery format? is it for feature film work? if not then why are you attempting 16 bit?
Just curious as a full 16 bit workflow will be very painful for no gain unless you are doing a DI and going back to film... In which case i suggest using a DI system and not FCP.

is the 10 bit online workflow I've suggested any use to you?

see here:
http://www.coremelt.com/support/workflow/

i would actually like to see a 16-bit work flow as well.

i've used other cameras which output 16-bits for scientific applications, i.e., you don't 'edit' the files for a movie but you are analyzing the hyperspectral cube of data, looking at waterfalls, PCA etc.

[eskatonia]

i would actually like to see a 16-bit work flow as well.

i've used other cameras which output 16-bits for scientific applications, i.e., you don't 'edit' the files for a movie but you are analyzing the hyperspectral cube of data, looking at waterfalls, PCA etc.

well sure, but you can't get more out than whats there. The R3D files only contain 12 bit linear color information so working with for example 12 bit CineForm codec lets you preserve all the color information that's there.

[galexander]

well sure, but you can't get more out than whats there. The R3D files only contain 12 bit linear color information so working with for example 12 bit CineForm codec lets you preserve all the color information that's there.

if you look in the threads with the QT bombing, the Redcine files are actually 8-bit.

[eskatonia]

using Red Cine to convert R3D files to 10 bit Quicktime codecs gives you 10 bit color information (or 12 bit if you go to Cineform with max settings). I have tested this myself visually by examining the footage in Shake with different gamma settings and I can see the difference between a 10 bit and an 8 bit export from Red Cine. I will read your threads for more info.

EDIT: ah ok. People are having problems on PC's and with other codecs.

I can confirm the following works:

MacBook Pro 10.4.11 or 10.5.1 (tested both). Red Cine 74 build. Export in ProRes 422 HQ or Cineform Codec.
Your quicktime files will contain 10 bit color information. I did see some problems with other codecs but I believe the above two codecs give you very good workflow solutions.

[galexander]

using Red Cine to convert R3D files to 10 bit Quicktime codecs gives you 10 bit color information (or 12 bit if you go to Cineform with max settings). I have tested this myself visually by examining the footage in Shake with different gamma settings and I can see the difference between a 10 bit and an 8 bit export from Red Cine. I will read your threads for more info.

EDIT: ah ok. People are having problems on PC's and with other codecs.

I can confirm the following works:

MacBook Pro 10.4.11 or 10.5.1 (tested both). Red Cine 74 build. Export in ProRes 422 HQ or Cineform Codec.
Your quicktime files will contain 10 bit color information. I did see some problems with other codecs but I believe the above two codecs give you very good workflow solutions.

thanks! i'm curious could you please post one of your log files using each codec on a 4k frame?

[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.

[Simon Blackledge]

thing is.. on non blackmagic install macpros, load a capture from BM but just using Apple uncompressed 10bit ( latest BM is based on apple 10bit) it loads fine.

How do I 3d plot on osx and I'll run it.?



you can get the blackmagic codec for PC from website dude.

10bit wise.. prores works fine.. in shake also..

Mind.. only Shake and imagineer have errors.. AE reads them fine..

my head hurts :-/

[galexander]

thing is.. on non blackmagic install macpros, load a capture from BM but just using Apple uncompressed 10bit ( latest BM is based on apple 10bit) it loads fine.

How do I 3d plot on osx and I'll run it.?


have read that BM is one of the few systems that actually works..

i use Matlab and IDL in PC Land for Mac..?.? let me look for a few days but basically you want to suck in a frame of data but instead of displaying it 2d, you want to force it to 3D, with the 3rd dimension being the value of the pixel.



you can get the blackmagic codec for PC from website dude.

10bit wise.. prores works fine.. in shake also..

Mind.. only Shake and imagineer have errors.. AE reads them fine..

my head hurts :-/

it sounds like anything that touches a QT wrapper will have problems except for AE, it has it's own engine. can you export 10-bit HD using a different codec with shake and not get the errors?

the guy was right, AE reads the files correctly. it is why most in PC land are using that initially as premiere chokes on 10-bit, or dumps down to 8-bit depending on... the moon? no one knows?

[galexander]

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


i would suspect that they read off the array in four separate quadrants and that particular quadrant has some offset? bad cal coefficients? bad/leaky capacitor? could be a lot of things..

if you had a labsphere, i could help you figure it out.

[eskatonia]

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.


galexander I'd like to suggest we could achieve more by appreciating our different backgrounds and learning from each other. You're obviously very knowledgeable about qt from a technical side. that's great.

My background is pragmatic, it's from designing multiple high bit depth color pipelines that worked from the only criteria that matters to me: The clients were happy with the end results. This includes previously designing a feature film pipeline and recently completing a job which was all done in 12 bits per channel color in flame telecined from 35 MM film as DPX 10 bit log files.

I may well have have been wibbling the LSB and misaligning my memory boundaries but clearly no one in the whole job from director to client had a problem with that. ;)

Now to address your points: Yes Quicktime has 16 bit per channel codecs, there are several eg DA NONE16 or Microcosm but FCP does not support them as they are RGB codecs. FCP can only process your footage in high precision color (which means 32 bit per channel YUV in FCP) if you use a YUV codec so as of FCP 6.0.2 if you want to use FCP to online in high color depth then that means you can only use YUV codecs. And that means 10 bit or 12 bit as there are no 16 bit YUV Quicktime codecs.

You may very well be able to go from RedCine -> Microcosm codec in 16 bit but that won't be a very good workflow solution as the only application which properly works with Microcosm is After Effects.

So, if you want 16 bit per channel, my advice to anyone is forget Quicktime and do it using image sequences either DPX, 16 bit tiff or 16 bit half float OpenEXR files.

However if your actual goal was not 16 bit per channel but just "something better than 8 bit", then 10 bit per channel Quicktime codecs or CineForm 12 bit offer you a very good solution as they work right now with all the apps you need.

eg you can go Red Cine -> pro res 422 10 bit. Edit in FCP in high precision, apply effects in high precision, do motion graphics in 16 bit in Motion or AE, drop them on the edit, pass it back from FCP to Color to grade in 10 bit or 16 bit and then have a final master in pro res 422 in which you've preserved your 10 bit color until the end. I know this works because I actually have tested the whole workflow with both R3D files and with test ramp images and checked for truncation and other artifacts and viewed the quality of the end result and compared source input to final output with DIFF nodes in shake and with different gamma settings.

Now fine you can say that's not good enough quality for your standards because I wibbled some lsb somewhere and my noise levels are too high but I'll show my ends results to 10 different clients and none of them will see what you're talking about.

[galexander]

..stuff deleted....

Now fine you can say that's not good enough quality for your standards because I wibbled some lsb somewhere and my noise levels are too high but I'll show my ends results to 10 different clients and none of them will see what you're talking about.

ah see, now this is great stuff! your comments are well taken and appreciated.

i'm going to look into the work flows you've suggested as well.

agree that you right that the best way to get the true 16-bit is dpx or 32-bit tiffs. i'm looking at a variety of solutions at the moment, not just the Red camera, but Dalsa, Viper as well. those cameras will put out true 12-bit and 14-bit files. one of the Dalsa's actually is full 16-bit with 12-bit effective(mono dcam 16) at HD, 30fps, mono.

so i'm looking for a solution for the full-dynmaic range of 16-bit, if i'm going to thrown down $25 to $60k of my own money for a full up system. i don't want a kluge :) something that half-ass works.

as a craft so to speak, i see much more artistic creativity with the bits of resolution. you will get much more 'finese' for lack of a better word.

have a read at this thread, especially the comments of Stacey Spears.

i'm hoping he'll post some of images and you'll see what i mean. lower resolution is like looking through a foggy glass compared with the extra bits done correctly.

http://www.reduser.net/forum/showthread.php?t=7596

[eskatonia]

I fully accept my solution is a kludge and you know what, I don't need to understand every step involved. I just need to look at the end results and judge if they are acceptable or not.

I am very interested to see what higher quality solutions become available, but in the meantime I think some people will find value in my "middle high end" production suggestion.

btw, you could set up a full 16 bit half float solution right now. Smoke 2008 for online, Toxic for comp, Lustre for grade combo but you'll need considerably more than 60K to set it up ;)

[galexander]

I fully accept my solution is a kludge and you know what, I don't need to understand every step involved. I just need to look at the end results and judge if they are acceptable or not.

I am very interested to see what higher quality solutions become available, but in the meantime I think some people will find value in my "middle high end" production suggestion.

btw, you could set up a full 16 bit half float solution right now. Smoke 2008 for online, Toxic for comp, Lustre for grade combo but you'll need considerably more than 60K to set it up ;)

fair enough. :) actually i will probably give your solution a go myself.

i just plan on doing quite a bit of filming out in the field in remote rural locations. no internet, no wifi, solar power, i want something that i know is going to work. you know, it's easy at your desk to fix 'stuff' if it breaks or you need to reinstall or recompile, google, no worries. :)

see this thread turned out to be very enlightening and productive. thanks!!

[Ross Birkbeck]

This thread's great! But one question:

If you go with Gluetools can you get 12bit dpx wrapped for quicktime through the Redcine - FCP - Shake - Color workflow, or is the Gluetools Dpx RGB, thus screwing you in FCP?

[Mark L. Pederson]

This thread's great! But one question:

If you go with Gluetools can you get 12bit dpx wrapped for quicktime through the Redcine - FCP - Shake - Color workflow, or is the Gluetools Dpx RGB, thus screwing you in FCP?

I just sent an email to the guys at GLUE TOOLS asking them to join the forum -

[Robert Monaghan]

Thanks for the invite Mark,

Here are some thoughts after reading the thread:
- 16-bit floats are difficult to work with on any system directly. You generally have to convert them to 32-bit floats to work with modern CPUs. Once you've done your work, you need to convert them back. 16-bit float is a format that really is designed to give you the advantages of 32-bit float, but a smaller data size. Generally, this format is used if you are going to pump 3D data between the CPU and the GPU of a OpenGL card. In my mind, 16-bit Integer is a much more efficient way to go, for HDR imagery. Floats are overkill. Certainly, specialized uses for the image data would dictate whether or not you use floats. If it is for display purposes however, you won't be able to tell them apart, so why bother with the 32bit <-> 16bit conversion step.

- QuickTime will handle any bitdepth the developer wants. If you want something exotic that QuickTime currently doesn't support, you can easily add it. (I've done it.) Standard QuickTime is basically 8-bit 422 YUV and 8-bit RGB. Final Cut Studio adds some 10-bit 422 video Codecs. I and others have added 10bit 444 video and 10-bit RGB codecs. Even if your files are 10-bit RGB, your application will only grab an 8-bit copy if that is all it can understand. Just because QuickTime can offer the data in 10-bit or deeper, doesn't mean your Application is smart enough to open it in 10-bit or deeper.

- Glue Tools Cineon/DPX components, and the Phantom Cine components all work at 16-bit internally. Depending upon the Application that uses my software, you can access either 8-bit, 10-bit or 16-bit RGB data. Or, you can open it as 8-bit, 10-bit YUV. At NAB2008, we will be releasing versions that open open and save 8, 10 and 12 bit DPX files. Possibly other depths too.

Hope this helps,

bob.

[Mark L. Pederson]

Thanks for the invite Mark

Great to see you posting!

[Rainer Fritz]

Thx Bob, thats good Infos and news...

So do you think it will be possible to get from you a small manual for the gluetools and working with dpx and LUTs?
There is not much info regarding the possibilities and settings at the plug in.
That would be great...

rainer

[galexander]

Thanks for posting!
i enjoy these hard-core tech discussions.

just to preface my comments and give them some context. i'm old fortran hacker used to looking at stacked hyspectral images to find objects, bad guys, etc, who are trying to 'hide', so the '16/32/64-bit float' world is actually easier for me to deal with but this whole 'film' aspect is a different and strange animal to me. IMHO maintaining numerical accuracy and precision is extremely important but i'm here to learn new tricks as well.

from your post, to me, it confirms that there is definetely a bug in QT wrapper that is processing the dpx file. as other threads have indicated (ref im.thatoneguy), the film industry has used this format for a long time, yet people now are having problems, freezing on the initial frame, general program bombing/crashing, being forced into 8-bit output solution. these are mainly in PC land, mainly with Redcine(ref Jay, Rfo, Pailli), btw. there is one in Mac (ref Arno) land and the workflow bombs when the GPU buffer is filled.

i would like your expert guru opinion on

PC land workflow, maintaining accurancy throughout work flow?

Can you suggest one with non-Adobe components? non QT?

a general flavor for the opinion of some about QT can be summed up as follows;

Originally Posted by im.thatoneguy
"...I wasn't recommending using quicktime. I hate quicktime.
It's complete garbage. I stay away from it whenever possible.
If I could club quicktime like a baby seal I would. " :)

again thanks for taking the time to post!! much appreciated.

[galexander]

i've found a good set of references images for different configurations, they are not 4k, but i have independently verified the bit depth with matlab and photoshop

ftp://ftp.graphicsmagick.org/pub/dpx/

flowers-1920x1080-LinearLuma-10.dpx
flowers-1920x1080-Rec709Luma-10.dpx
flowers-1920x1080-Rec709YCbCr-4:2:2-10.dpx
flowers-1920x1080-Rec709YCbCr-4:4:4-10.dpx
flowers-1920x1080-RGB-10-packed.dpx
flowers-1920x1080-RGB-10.dpx
flowers-1920x1080-RGB-12-packed.dpx
flowers-1920x1080-RGB-12.dpx
flowers-1920x1080-RGB-16.dpx
flowers-1920x1080-RGB-8.dpx
flowers-720x486-LinearLuma-10.dpx
flowers-720x486-Rec601Luma-10.dpx
flowers-720x486-Rec601YCbCr-4:2:2-10.dpx
flowers.jpg

[Rainer Fritz]

What do you think about JPEG 2000 ?
It is wavelet based same as redcode and used for the DCDM (digital cinema distribution master). If you could CC it in 16 bit that would be fine....
why does apples color only support 10 bit uncompressed and prores422 ? is there any way to do grading in this formats and conform with an other format after to get the grading working on a higher format ???
i don't want to buy a $$.$$$ CC suite.... :)

regards
rainer

[galexander]

After thrashing through the SMPTE docs, i've come up with the following

DPX files can also contain bit-depths that cause pixel samples not to end
on byte boundaries (e.g., 10/12-bit and 14-bit images).

SMPTE 268M-2003 Reference
10-bit components filled to 32-bit boundary
12-bit components filled to 16-bit boundary
14-bit components filled to 16-bit boundary


you also have to do some bit splicing to extract the color information, R,G,B for 10-bit and when you process a 10-bit image, you have to muliply the pixels by 64 or you will get a black image.

i highly suspect the following reasons that the QT wrapper is screwed up, they are related. wrong endian type, the magic number is wrong, aligned the 10-bit component on the wrong boundary or a combination of any. IMHO

just my .02

[Rainer Fritz]

Hey Alexander !

Come on... take the keyboard and write us a nice color correction tool... :)

regards

[galexander]

Hey Alexander !

Come on... take the keyboard and write us a nice color correction tool... :)

regards

hey rainer,

good one :) if i had time, i could hack one up for you.

where did Bob go? did we scare him off? i thought maybe he was going to answer your questions about JPEG2000.... if i get a chance i'll see if i hack up a quick color correction, i'll probably be in C. do Macs still include c/c++ compiler? you want full 16-bit or just 10? :) well i'll cross-platform it for GCC, almost any compiler can understand gcc.

it's been heaps fun but think i'm going to be posting and swinging from the vines so to speak in the cinematography.com it's more my 'open' and 'free' forum. i'm finding it a bit too "stuffy", not in this thread but other threads.

ping me over cinematography.com forum or if you have a hacker streak doom9.org forum :)