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

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

Reference dpx images

Reference dpx images

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]

Banging bits

Banging bits

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