>>Lowering the ISO gives us crisper and cleaner blacks, as indicated by the ISO 200 trace. - snip- >>Once again, the "bit bucket" is getting smaller, as maximum white only reaches about 82% on the >>waveform (85% or so in extended mode).
Why wouldn't simply opening up two stops at ISO 200 from your ISO 800 middle gray starting point reset the grayscale back to normal filling the "bit bucket" to the brim? Opening up two stops would indicate by the waveform you haven't lost anything by remapping the underexposed portion in the toe and moving the white chips back to their proper value. So at 200 ISO you would have just as much DR with less electronic noise but need to open up two stops which is expected in this situation. Is there something I'm missing here?
This would be no different than loading your camera with ISO 200 film stock and shooting it at ISO 800 then printing it based on the ISO 800 stock. The 200 stock would look underexposed and have less dynamic range than the ISO 800 stock albeit less grainy.
Los Angeles, CA
New Orleans, LA
>>"Why wouldn't simply opening up two stops at ISO 200 from your ISO 800 middle gray starting >>point reset the grayscale back to normal filling the "bit bucket" to the brim?"
Keep the 18% in same spot under different ISO and compare shoulder and toe?In Arri Raw?
Chan Chi Ying DP HK
>> Why wouldn't simply opening up two stops at ISO 200 from your ISO 800 middle gray starting point >>reset the grayscale back to normal filling the "bit bucket" to the brim?
Because you've actually changed the gain in the camera. If you've set the ISO at 200 then you've reallocated two one-stop steps from above middle gray to below middle gray, and the point where white clips has physically changed. At ISO 200 you have five stops from middle gray before white clips. At ISO 800 you have seven stops.
You ask about going the other way�rating at 200 but exposing for 800. I guess you could do that without any real penalty because, while you've changed the gain in the camera, you're also remapping your exposure values manually and pushing them two stops down the scale. There are two reasons not to do that: (1) If you're shooting in LogC, your maximum white is around 85% instead of 104% at ISO 800 (probably a relatively minor hit), and (2) it's going to look awful in post without a LUT.
Besides, you're going to get exactly the same results as if you rated the camera at ISO 800 anyway. The only reason 200 looks so crisp is because you've pushed the noise floor away from the mid-tones. If you set the camera at 200 and rate at 800 then you have to pull everything up to make it look right, which means the relationship between the noise floor and middle gray becomes the same as if you'd set the camera at 800 in the first place.
If you really want to take advantage of the full "bit bucket" in LogC it appears that you have to set the camera at ISO 1600 (which gives full access to the 0-109% range) and then rate it at something else, using a LUT for viewing. I think that's a bit extreme, though. I'm not sure a few less bits is going to matter that much.
Art Adams | Director of Photography
San Francisco Bay Area
Art Adams wrote:
>> �it appears that you have to set the camera at ISO 1600 (which gives full access to the -109% >>range)
I think we need to be a bit careful with terminology here. My understanding is that the ALEXA does not in fact use the 0-109% range, but only goes up to 100%. You have the option to choose "Extended Range" on the REC OUT SDI, but all that does is set the SDI code values that 0% and 100% map to as 5 and 1019 rather than the "legal" 64 and 960. This may appear on a waveform monitor which is expecting a "legal" signal to go up to 109%, but it is not really the case. You can see from the LogC ProRes files that the signal only goes up to 100% not 109% - see this screen-grab.
To quote from the ALEXA manual :
Note: Check which mode your recorder supports. If you set the camera to extended, but your recorder only supports legal, you will end up with clipped images!
I have seen a lot of problems caused by people not understanding the difference between "legal" and "full/extended range" signals. If in doubt, stick to "legal". You may have slightly fewer code values to play with, but you do not risk your image data getting clipped at some
point in your workflow.
It's easily done.
The screen-grab link didn't make it into my last post, so here it is :
But the waveform itself clips at white in this image, so how would you know if there was any extended range available?
For the record, Alexa's monitor out always tops out at 100%, apparently to make sure it is compatible with any monitor it is connected to. Record out, on the other hand, can display 0-109%. Presumably that is to take advantage of ArriRaw and a number of off-board digital recorders.
I was skeptical about the claim that you couldn't record ProRes values above 100%, though, so I checked... and I have some Alexa footage that was shot at ISO 800 in extended mode and the highlights don't exceed 100%. And actually they don't exceed about 95% because they were shot in LogC.
>> But the waveform itself clips at white in this image, so how would you know if there was any >>extended range available?
Sorry, should have said "clips at 100%" instead.
Art Adams | Director of Photography
San Francisco Bay Area
Art Adams wrote:
>> I was skeptical about the claim that you couldn't record ProRes values above 100%, though, so I >>checked... and I have some Alexa footage that was shot at ISO 800 in extended mode and the >>highlights don't exceed 100%. And actually they don't exceed about 95% because they were shot in >>LogC.
Disclaimer, this is speculation on my part..
I don't know this for sure, but I believe that you are limited to the ProRes codec's range. Your image payload will probably limited to what ever your ProRes variant's range is. Based upon what I know of ProRes and QuickTime, the image range is probably scaled to YCbCr legal range. (Again, I could be wrong, but I don't believe so. Everything I have seen, when decoding the images, says legal range to me.)
LogC code values would simply map the the destination ProRes video range selected. Probably 0-219 for the r408 pixel type and 64-940 for v210 pixel type. Again, this is typical ProRes. I would assume that ARRI is planting the LogC into the payload directly using a carefully built LUT. (This *very roughly* is similar in concept to how a DPX file is encoded using RGB LogC values.)
Secondly, QuickTime does not have any means of flagging a QT movie as being "Full Range". It doesn't exist. Some 3rd parties have a system of embedding their own flags, but there isn't anything 'standard' out there. Even between Final Cut Pro and Compressor, there isn't a signaling system that a movie is actually a full range or video range. Everything is assumed to be video range.
I haven't done any analysis of a LogC ProRes file. I have yet to see one in person. When I get my hands on a file, I should have a better understanding.
>>"Based upon what I know of ProRes and QuickTime, the image range is probably scaled to YCbCr >>legal range."
Hi Bob, seems to imply this is true of ProRes 4444 as well as HQ, is this what you're saying --- not questioning you, just want to be sure....
Sam Wells wrote:
>> "Based upon what I know of ProRes and QuickTime, the image range is probably scaled to YCbCr >>legal range."
It is my understanding that the current build of the Alexa software only allows for a legal 10bit YCbCr capture.
Production and post workflows
Seeing stereo in LA,
Living on airplanes,
Landing in Chicago,
Regardless of what may be packed into the movie, only FCP will have a chance to let the user see anything other than legal range with 8-bit codecs. FCP does a trick, but the rest of Final Cut Studio can't do this.
Ranges other than legal range are not explicitly supported in the current QuickTime API.. The API doesn't have any mechanism for switching from Legal Range YCbCr to anything else. There is no way to encode the data or decompress the data as legal or extended. It doesn't matter what the codec is.
Robert Monaghan wrote:
>> There is no way to encode the data or decompress the data as legal or extended. It doesn't matter >>what the codec is.
Actually, one correction:
If the a given codec supports an extended video range internally, you could feed it "Non legal" extended range imagery from your own custom application. But standard applications or quicktime player would decompress the data and wouldn't know what to do with the extended data, probably clipping it as a result. (As it rightfully should.)
>>But standard applications or quicktime player would decompress the data and wouldn't know what >>to do with the extended data, probably clipping it as a result. (As it rightfully should.)
I agree that putting anything other than legal range data into a ProRes QuickTime file would be a very risky thing to do. It would be very easy to clip the extended ranges without realising. The only Mac applications I am aware of which read the full range of the data in ProRes QuickTimes are FCP, Avid MC5, Baselight (MacBook Pro version or Baselight Kompressor), and Nuke (but then only with a work-around which I have found to convert the extended range into un-clamped float data.) QuickTime Player, Smoke on Mac, After Effects, Shake, and probably most other apps will not pass data outside the legal range,
and will clip it.