Redcine and Highlights/superwhites/HDR

[Trevor Meier]

In Redcine, what will be the available methods for messing with dynamic range? The curve will allow for adjustment of gamma, but I'm wondering about superwhites when going to DPX or quicktime. Will you be able to set a 100% white highlight marker and maintain headroom above that in the export? Or will we need to squeeze all of the captured range inside the legal ranges of whatever you're exporting to?

There's a good reason I'm asking this... but it's a really long explanation so I'll save it unless someone's really bored ;)

[Graeme Nattress]

If you want spare space above white, just drop the curve white point a bit to give you the room you want. Quality will be lower as you're now using less quantisation levels to describe the data though.

Graeme

[Barend Onneweer]

But I'm assuming that REDCINE will allow me to set a whitepoint (1,0) for a clip, and still retain the 'overbrights' when exporting to an HDR capable format such as OpenEXR.

That way you could underexpose a stop or two in-camera to avoid clipping, and export to an OpenEXR sequence - with the white point set more or less correctly.

Barend

[Graeme Nattress]

What I'd expect, and I could be wrong, is that when going to a float format like EXR, we'd not clip at the 0,1 range on export so superbrights would still be there, waiting.

Graeme

[Mike Harrington]

Redcine can'y capture at HDR levels...it's a 10 bit codec...
Even if it captured 16 bit...it would still be a long way from HDR.

We may be thinking of something totally different though..

If you underexpose and set your white point low...everything above that should be clipped by the REDCINE codec(remember only 10 bits to play with)
So even though you export to HDR that clipped information would be lost.

You could slide your whites up and down the dynamic range but the overbrights will be RGB 1024,1024,1024. There's no more room in the codec.

[Barend Onneweer]

Uhm... REDCINE isn't a codec. It's the tool to convert from RAW to anything.

What I understand is that REDCODE RAW is 12-bit. If I underexpose by one or two stops I'd still have decent color resolution left in the image, and a couple of bits to spare on 'overbrights'. In REDCINE I crank up the exposure to get a nicely exposed picture, but this will push some highlights over white.

Basically I'd underexpose two stops in-camera and correct exposure back up in REDCINE.

If you export to a fileformat that clips at white - usually called a value of 1 - you'll lose the data beyond white. But as said I hope REDCINE retains the 'overbrights' when exporting to a filetype that can store values exceeding 1 - such as the OpenEXR fileformat.

Barend

[Graeme Nattress]

REDCODE is 12bit actually....

Barend - makes sense.

Graeme

[Mike Harrington]

I get ya....
I had a misunderstanding of the whole workflow.
Actually quite clever.....leaves you a lot more room in post.

[Curran Giddens]

I'll be experimenting with openEXR files from Redcine. Since I will be rendering 3D objects and backgrounds from Maya to openEXR. I will also be using openEXR for HDR backgrounds from a DSLR still camera.

I'm hoping Apple's Final Touch/Shake replacement will let me view all layers composited together, but at the same time, let me color-correct each seperate layer individually in realtime!

After color-correction, I will composite and save as 16-bit tiff image sequence.

[Mark L. Pederson]

I'll be experimenting with openEXR files from Redcine. Since I will be rendering 3D objects and backgrounds from Maya to openEXR. I will also be using openEXR for HDR backgrounds from a DSLR still camera.

I'm hoping Apple's Final Touch/Shake replacement will let me view all layers composited together, but at the same time, let me color-correct each seperate layer individually in realtime!

After color-correction, I will composite and save as 16-bit tiff image sequence.

I wouldn't hold your breath on ANYTHING realtime in OpenEXR from Apple. Keep a close eye on NUKE from D2 - it's got by far the best OpenEXR support of any app hands down.

[Curran Giddens]

I guess it doesn't have to be realtime. I just checked out a walkthrough for Nuke 4.5 on studiodaily.com. I actually don't mind the scan lines that Nuke uses. I'm glad Nuke is now available for OS X, that software is exactly what I'm looking for!

[Lucas Wilson]

I wouldn't hold your breath on ANYTHING realtime in OpenEXR from Apple. Keep a close eye on NUKE from D2 - it's got by far the best OpenEXR support of any app hands down.

I wouldn't hold your breath on anything realtime in OpenEXR, period. OpenEXR is a compressed format. There is an uncompressed flavor, but if you're going to use uncompressed EXR, then that sort of defeats the purpose. Might as well do 10-bit DPX or 16-bit TIFF at that point.

There is a new EXR schema that ILM has released, but it is not in common use yet. The D2 guys will probably be the first to embrace it.

Lucas
-----
ASSIMILATE, Inc.
Los Angeles (...back in LA, living the dream...)

[Joe Carney]

Thanks Luki, but I thought one of the things OpenEXR offered was z depth, so incorporating 3D and 2D content was easier or at least smoother.
Wish I could afford Nuke. I like that 3D work space.

[Jeff Kilgroe]

There is a new EXR schema that ILM has released, but it is not in common use yet. The D2 guys will probably be the first to embrace it.

I'm guessing you're talking about the B44 compression spec... I thought this introduced a fixed compression ratio to better facilitate real-time playback? But I haven't looked into it... Is there any other advantages here that would help with RED and comps done at 10/12/16 bits?

[Rob Lohman]

Not really, B44 is just a different compression scheme. OpenEXR actually allows a bunch of other channels which according to a Nuke presentation I once saw is indeed used by the product (when they are available, i.e. from a render).