RED 3D HDR camera?

[Henri H]

I would a movie to be shot with a high dynamic range capable (RED?) camera. I also want the movie to be three dimensional. Are there any cameras with high dynamic range (HDR) and 3D support?

They say that the real world luminance range has fourteen orders of magnitude. Is it possible to make a camera that covers nearly the entire luminance range?

 

[Mick van Rossum NSC]

I would a movie to be shot with a high dynamic range capable (RED?) camera. I also want the movie to be three dimensional. Are there any cameras with high dynamic range (HDR) and 3D support?

They say that the real world luminance range has fourteen orders of magnitude. Is it possible to make a camera that covers nearly the entire luminance range?

35mm has more dynamic range than any other digital format. Spheron is building a camera right now with 20 stops of dynamic range, but I expect it to be expensive.
So far there are no camera's with the combination of 3d and HDR.

 

[Kenneth Elkington]

There is no 3d hdr camera.

It is possible to make a camera that would cover all real world dynamic range, but at this point it's not anywhere close to practical.

 

[Henri H]

35mm has more dynamic range than any other digital format. Spheron is building a camera right now with 20 stops of dynamic range, but I expect it to be expensive.
So far there are no camera's with the combination of 3d and HDR.

Thanks for the answer!

How many stops of dynamic range does Red One have? How about Red Epic?

 

[Henri H]

There is no 3d hdr camera.

It is possible to make a camera that would cover all real world dynamic range, but at this point it's not anywhere close to practical.

Thanks for your answer!

Maybe it's the best just to combine two Red cameras to shoot 3D?

 

[paulherrin]

yes. I've posted elsewhere about the process with the RED cameras to generate HDR by using the latitude of the RAW data... i.e. "bake" out 3 or more exposure levels in post and then use your tone mapping technique (probably some kind of batch process on each frame). 3d just adds some extra steps, and two cameras.

if you really wanted to get fancy (or out of control)... you could use four cameras...

two beamsplitter rigs using no interaxial seperation. one camera on each with an ND filter, the other without. then put both of those rigs together as a side by side rig.

and we're not sure yet about the dynamic range of the new sensors... the RED One is debatable - most agree on at least 8 usable stops I think. Some say it could be more like 10 or 11 depending on conditions. The new sensors are supposed to be even more powerful.

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

 

[Kenneth Elkington]

At this point if you're shooting motion, there's really no way to get real-world HDR footage, so you should focus your efforts on 3d if that's what you want to do. Shooting stereoscopic is really probably your best bet, and you can link up two red one's via usb to get stereoscopic sync. It hasn't been announced so far how stereoscopic will be accomplished in scarlet and epic, but I don't imagine it would be any more difficult than with the Red ONE.

Regarding your dynamic range question: Red one has (I believe) 10 1/2 or 11 stops of measurable dynamic range, and typically 8 or 9 in real world footage, according to most tests people have run. It's been announced that Epic has about 12 1/3 stops in testing, and judging by the drastically reduced noise floor the disparity between tested and real world dynamic range should be a bit smaller than the Red ONE, though that's just speculation on my part.

 

[Henri H]

Thank you for your answers!

How much is 66 dB in stops?

How many bits are needed to record 20 stops?

Sorry, if my questions don't make sense. I'm still learning this stuff.

 

[Kenneth Elkington]

Thank you for your answers!

How much is 66 dB in stops?

How many bits are needed to record 20 stops?

Sorry, if my questions don't make sense. I'm still learning this stuff.

I don't know about decibels when it comes to light, but you would need at least 21 linear bits to record 20 stops of dynamic range, though I think you'd need to sacrifice an animal to get somewhere close to that.

 

[paulherrin]

Thank you for your answers!

How much is 66 dB in stops?

How many bits are needed to record 20 stops?

Sorry, if my questions don't make sense. I'm still learning this stuff.

well technically (theoretically)... 20 (or 21 I guess). in reality probably 24 or 32 would be good.

 

[Henri H]

I don't know about decibels when it comes to light, but you would need at least 21 linear bits to record 20 stops of dynamic range, though I think you'd need to sacrifice an animal to get somewhere close to that.

This claims to have 20 stops.

 

[paulherrin]

This claims to have 20 stops.

i think we've seen this before... for one, the 20 stops are being compressed down to at least 15 or so for the 16-bit file output. not to mention we haven't actually seen anything. i'm not hating, i'm just saying theoretical 20 stops and the practically usable range can be quite different.

 

[Justin K Phillips]

20 stops can easily fit in 16 bits, particularly if stored with a non-linear tone curve. Some very basic, conceptual math (correct me if I'm way off base):

2^16 / 20 = 3276.8 levels / stop

Considering that most people are satisfied with a measly 256 levels for the entire range, I'd say that's pretty darn good.

 

[Pietro Impagliazzo]

Beam splitter, another beam splitter at each end, 4 cameras, huge light loss, the most cumbersome rig ever.

There you go.

 

[Brian Harbauer]

Thank you for your answers!

How much is 66 dB in stops?

How many bits are needed to record 20 stops?

Sorry, if my questions don't make sense. I'm still learning this stuff.

66dB would be 11 stops on paper. However depending on your noise floor it could be less - meaning it depends on what you consider usable range, what you consider an acceptable amount of noise. It's usually 1 stop per 6dB.

 

[Dan Hudgins]

Black Sun issue.

Black Sun issue.

I posted many drawings and such about using several RED ONE in sync for such projects. If you do the Pellicle beem splitter BEHIND the lens you can make the system much less bulky and be able to use wide angle lenses for the 3D shooting, if the drawings I posted were still in the system you could look at them, but when REDUSER crashed a while back I think the images that do with the posts got lost?

There is a limit to the dynamic range you can get because of the Black Sun issue, I think I saw it once in a shot with headlights in Che #1, but for the most part RED does not seem to Solorize for subjects within 3 stops over white clip, can someone with a RED ONE try pointint it at a frosted light bulb and adjust the exposure with the shutter at 360 degrees so we can see how many stops over white clip one can go before the sensor etc will Solorize?

Within the range before Solorize you can do HDR exposure, maybe get 3 to 4 more stops of highlight range, perhaps at bit more with DRX turned on.

I am working on my own de-Bayer program for use with true RAW digital cinema cameras, you can see sample true RAW conversion in my other posts for the Acam dII and Kinor-2K. If you use a pinkish filter with true RAW cameras you can adjust the clip points in the (my) de-Bayer program to have equal clip for all three colors and get the full sensor range without using the Pseudo extension of DRX processing like the RED programs use.

It would be simple for RED to offer the right kind of pinkish filter for use with their cameras to increase the dynamic range for all K value lighting. A set of such "full dynamic range" filters would include extra bluish coloring for low K value sources and extra redish coloring for high K value sources, maybe 12 to 24 such filters in a set with the 5600K and 3200K being the most used ones, and special ones balanced for various florescent and vapor light sources matched to the sensor's native color bias (Bayer filters have a heavy green bias). Yes that would give some light loss, but in cases where you would use an ND filter, the "full dynamic range" filters would give better results as far as the blue noise etc.

The light loss from the beam splitter for HDR is very low, because you can use a 5%/95% Pellicle or Cube beam splitter, so the light loss would be the same as other 3D beam splitter rigs, there is not particular Penalty for doing HDR also, and with the cameras in Sync there are no particular ghost issues.

If someone is interested in the design of relay optics for the HDR part of the camera rig the can PM me etc.

My software can adjust the frame sets with curves and do the HDR merge with the fuse command.

 

[paulherrin]

Beam splitter, another beam splitter at each end, 4 cameras, huge light loss, the most cumbersome rig ever.

There you go.

hahaha

I posted many drawings and such about using several RED ONE in sync for such projects. If you do the Pellicle beem splitter BEHIND the lens you can make the system much less bulky and be able to use wide angle lenses for the 3D shooting, if the drawings I posted were still in the system you could look at them, but when REDUSER crashed a while back I think the images that do with the posts got lost?

Can you repost those here? Sounds interesting.

 

[Dan Hudgins]

Wide angle

Wide angle

Can you repost those here? Sounds interesting.

One problem you get into with using two cameras for HDR then two of those with a splitter rig for 3D is that if you try to use wide angle lenses you run out of space on the mirrors.

To avoid that you can put a optical relay block with PL mounts onto two cameras, the HDR splitter in inside that block, and you use a single wide angle or other angle taking lens on each pair of cameras. To avoid losses in the relay optics you use a 10/90 or 5/95 cube splitter and have the light parallel going through it, so that means three lenses and a field lens other than the taking lens.

The relay optics do not need to follow focus for the most part they are locked in place, although the field lens and the flange to focal for the taking lenses might need a bit of adjustment when you change the taking lenses because the thinkness of the field lens can cause some shift with very long or very short focus taking lenses.

The two RED ONE bodies on each HDR block would attach with their PL mounts and be locked in place with supports to the tripod holes. You could not get the images to single pixel register so the final register is done in software later, that is you need to shoot a grid chart before each set of takes to use later in post to check the register of the HDR camera pairs.

If you are serious about building such a rig you can PM me and I can try to talk more about some of the details.

If someone with a RED ONE could post the over exposed frosted light bulb photos we can tell how high the exposure can go on the shadow camera before the over exposed parts turn black, and if they do in the current builds...

To make the over exposure shots you start with the light buld at 80% waveform at f/22, then shoot then open up and shoot another and so on down to f/1.2 to see what happens. The light bulb should be outdoors away from anything at night so the background does not flare.

 

[Reinhold R.]

well technically (theoretically)... 20 (or 21 I guess). in reality probably 24 or 32 would be good.

Just had to chime in on this one. What you are confusing is that, 20 stops is a measure of latitude, while 16 (or 20, 24, 32) bits is a measure of resolution/accuracy. It all depends on how you use these bits. Either you get values between 0 and 65,535 (in an integer format) or -5 and +27 million (or almost anything else, really) if you use a floating point format. The lack of accuracy could result in banding issues through heavy (i.e. extreme) color grading.
I work in the VFX business and render out my stuff in 16 bit floating point (which is essentially like taking a highly accurate HDR of your scene) and never had any issues.
Not sure how this translates into the A/D conversion though. I guess that storing the information in a floating point format would be more time consuming. Integer makes sense because the sensor has a physical limit anyway (but you lose accuracy). I'm sure Graeme knows the answer to this

Just my 2p

-Reinhold

 

[Dan Hudgins]

Gamma adjusted 16bits

Gamma adjusted 16bits

Not sure how this translates into the A/D conversion though. I guess that storing the information in a floating point format would be more time consuming. Integer makes sense because the sensor has a physical limit anyway (but you lose accuracy). I'm sure Graeme knows the answer to this

Gamma or Log adjusted 16bits would not show banding on the output 8 ot 10 bits unless you do more than extream grading, since you would need to have the contrast so high you would not see much tonal detail anyway (to loose 6 bits).

The dynamic range is related to the pre-amp gain and the sensor saturation, if you bias the black level up and or use bias lights there is no real lower limit if you average the pixel data, the only "hard" limit is at the top end for white clip.

When you use two sensors you can over-expose one up to the "black sun" limit to get more shadow detail, and under-expose one to get more highlight detail, the process both to reduce noise and add S-curves, then when you join the two images you set the contrast low enough to "fit" the 20-24bits into 16bits in other words you use a lower slope angle or a log curve or a gamma curve to give less contrast to the upper bits since the eye sees the upper bits with less contrast anyway you do not need the full bit range if you change from linear to log or gamma curve, then end result looks about the same if you save in 12 or more bits for black to white...

The sensor slope angle is like the "gamma" of movie film stocks, when you pull process you reduce the slope to get more dynamic range from the film stock, and when you push process you increase the gamma and slope angle of the transfer curve to get less dynamic range.

Going 24bits into 12 is like pull processing you fit a wider contrast range into what the film density range can hold, so you fit a wider contrast range into what the bit range can hold.