12800 ISO

[Abe Espinoza]

Out of the camera is for live broadcast video. ''Fix'' in post sometimes is for film and Red cameras.
You choose the camera for your needs. I choose Red cameras. I choose 16 bit redcode raw 15+ DR 19,4 MP 300 FPR and reduser.

Fix in post is what you do when you don't expose/ light correctly no matter what you choose to shoot on. Even shooting film you want to over expose by a 2/3 of a stop when shooting dark imagery. The point of that is to get as much information engrained into the silver halide cystals/ or for a RED onto the sensor so that their is information in your dark areas, instead of trying to pull information out of the darks that really don't have much to give.

 

[Abe Espinoza]

Dragon even with LowLight OLPF is not exactly a no-light "night vision" camera.

Completely agree. We are saying the same thing.

 

[Alexandros Tsoupras]

Fix in post is what you do when you don't expose/ light correctly no matter what you choose to shoot on. Even shooting film you want to over expose by a 2/3 of a stop when shooting dark imagery. The point of that is to get as much information engrained into the silver halide cystals/ or for a RED onto the sensor so that their is information in your dark areas, instead of trying to pull information out of the darks that really don't have much to give.

BTW, I have a Scarlet Dragon coming my way and I had a Scarlet MX. I love my RED. Some people here are really defensive… Jeez, relax

Hello Abe. In the DXOmark test http://www.dxomark.com/Reviews/RED-...ore-barrier/Low-Light-ISO-10th-place-ISO-2745
the Dragon with the LLO scored 10th place for low light iso. Just imagine if the Dragon had internal noise reduction full frame size and if it had less MegaPixels 12 like the a7s.
Regards Alex.

 

[David Kuhn]

One request for clarification- David states above that the sensor is 10 bits. Isn't it actually 16 bits?

I see online people stating 16bit... but I'm not sure if that's sensor or storage format (I don't see it called out in RED specs for the Dragon). It's definitely STORED as 16 bit... but that's normal with any sensor that's more than 8 bit, data is generally stored in the next largest multiple of 8 (digital world likes bytes). The histogram stretching I'm seeing doesn't look like what I'd expect from a 16 bit sensor unless my guess that the 'raw' values of the sensor are in the neighborhood of 200-400 ISO is off. The histogram looks more like a 10/12 bit sensor to me. Histograms typically bin data into 256 steps (8 bits)... the histogram below shows the green channel in the OP's shot... the discrete steps in the histogram occur when a math routine has been used to stretch the raw data (the ISO routine in this case) and the initial data is not dense enough to completely fill the 256 bins... some get left empty. This data appears to indicate there are probably 64, possibly 128 steps of data that have been nonlinearly stretched to use the whole 256 bins. A 10 bit sensor would have 64/128 steps in the bottom 6.25%/12.5% of the sensors range - which appears to roughly match the image at an ISO setting of 400. A 16 bit sensor would have 64/128 steps in the bottom 1.6% & 3.1% of the sensor range respectively... the histogram for such a sensor at it's 'raw' values would look pretty much like a spike at the left side of the histogram. I don't have any inside info on the Dragon... I've just seen a LOT of 10 bit (and quite a few 12 bit) cameras over the years, this is what they look like when you stretch a low light image to brighten it up (though I generally have used a linear stretch... bit shift... rather than the nonlinear routine that Red is obviously using). Maybe the 'Native ISO' of the Dragon is much lower than I was thinking it was... that would be an alternative explanation for what is seen below.

 

[David Battistella]

also...how do you name calibrations for different exposures?

export to SSD and they can be renamed.

if you copy them to the desktop they can also be renamed.

Blackshading is is camera sensor specific and can not be loaded onto another camera/sensor.


battistella

 

[Terry VerHaar]

I see online people stating 16bit... but I'm not sure if that's sensor or storage format (I don't see it called out in RED specs for the Dragon). It's definitely STORED as 16 bit... but that's normal with any sensor that's more than 8 bit, data is generally stored in the next largest multiple of 8 (digital world likes bytes). The histogram stretching I'm seeing doesn't look like what I'd expect from a 16 bit sensor unless my guess that the 'raw' values of the sensor are in the neighborhood of 200-400 ISO is off. The histogram looks more like a 10/12 bit sensor to me. Histograms typically bin data into 256 steps (8 bits)... the histogram below shows the green channel in the OP's shot... the discrete steps in the histogram occur when a math routine has been used to stretch the raw data (the ISO routine in this case) and the initial data is not dense enough to completely fill the 256 bins... some get left empty. This data appears to indicate there are probably 64, possibly 128 steps of data that have been nonlinearly stretched to use the whole 256 bins. A 10 bit sensor would have 64/128 steps in the bottom 6.25%/12.5% of the sensors range - which appears to roughly match the image at an ISO setting of 400. A 16 bit sensor would have 64/128 steps in the bottom 1.6% & 3.1% of the sensor range respectively... the histogram for such a sensor at it's 'raw' values would look pretty much like a spike at the left side of the histogram. I don't have any inside info on the Dragon... I've just seen a LOT of 10 bit (and quite a few 12 bit) cameras over the years, this is what they look like when you stretch a low light image to brighten it up (though I generally have used a linear stretch... bit shift... rather than the nonlinear routine that Red is obviously using). Maybe the 'Native ISO' of the Dragon is much lower than I was thinking it was... that would be an alternative explanation for what is seen below.

Hmmmm... I guess I have always seen the specs listing "12 and 16-bit RAW" and thought that referred to the bit depth of the sensor. Your 10-bit number seems to come from inference rather than any stated material from RED. I am just wondering if anyone can point to any definitive information?

 

[D Fuller]

Maybe the 'Native ISO' of the Dragon is much lower than I was thinking it was... that would be an alternative explanation for what is seen below.

That is exactly what DXOMark said when they looked at Dragon. They say it is a 16-bit sensor, and said they measured native ISO at 104. Now that does not match up with my own observations in using it, but it's interesting to note, given your histogram analysis above.

 

[Gavin Greenwalt]

David I would be interested to look at the R3D for that file. Keep in mind though that even if they store it in 16 bit it'll almost certainly be 16 bit *linear* so if you apply an exponential gamma curve (like sRGB) to the data and export from RCX you'll be stretching out mids and highlights most of all which results in less than 16 bits of detail in *gamma corrected* colorspace. Considering you're looking at a gamma corrected image in Photoshop you've almost undoubtedly taken a 16 bit linear image, stretched it all out, and then from the looks of it, stretched it out even more in photoshop. So it's a mutilated 16 bit image. There is a reason that Kodak long ago recommend 10bit Log for film scans. It's because in log space you get about the the same precision as you do in 16 bit linear space but at a fraction of the bits. So when you say "this looks like 10 bit" what you're probably thinking (accurately) is that there is as much useful precision as 10 bit log dpx. If you export a 16 bit linear EXR from RCX take a look at the histogram in linear space and I bet you'll no longer see quite as large of gaps.