Have you guys done testing to DPX? I just did a series of tests with my Rokinon 85mm Cine at various ISOs and E/V levels as well as some comparisons of profiles and exported everything through 5DtoRGB out to DPX which was then played back through a high end Christie cinema projector. The export settings were Rec709 Broadcast. Initial observations - nothing I didn't already know. This is with Moon T7. Image detail was very good. Shadow areas were noisy (if cleaned up with Neat Video using a chart on set to create a noise profile, I'm sure this would end up looking very clean), dynamic range is limited as we all know but outside of some extreme DR range I was able to control exposure with ND, and overall the images held up really well projected on 14 ft screen. I was not able to test motion properly as I only have a basic tripod with me at the moment and the head is not fluid enough to do a proper test. I've been watching Alexa footage projected on this same projection system for the past weeks. This is a movie being shot by a Hollywood DP, so naturally the footage looks really great and as expected beats out the GH2 in almost every way. However, I will say that the GH2 holds it's own. The areas where it can't compete are dynamic range, motion, color rendition, and resolution. But the fact that the GH2 looks as good as it does for $800, especially seeing these uncompressed DPX files projected is very cool. I await the BMPCC to compare against the GH2 which is a much fairer comparison. I suspect that camera will replace my GH2 as my compact rig. But I'm not willing to make that claim just yet. Still need to do the tests.

@Rarevision

However, some cameras still write data over 235

I suspect the data over 235 levels comes from sharpening which is applied to the file after it has been remapped to 16-235 (the sensor shoots 0-255 but video gets remapped to 16-235 somewhere down the image processing pipeline). I suspect all picture styles are applied in 8bit mode after the file has been remapped to 16-235 ...

Anyway... thanks for posting!

I should probably clear up any ambiguity about what 5DtoRGB is doing, so here goes.

ProRes files always use broadcast levels. This is something I have no control over, and are written (and read) that way by the ProRes codec. This is also the correct way to do it, because it keeps compatibility with everything else in the post pipeline.

MTS, MOV or any other file compressed with H.264 are primarily 8 bit. That means they have 0-255 possible values for luminance. This is the case even if the camera shoots "broadcast" levels. If it does, there is still data in the file from 0-15 and 236-255, but it is usually nothing that contains any picture information. That is the way it is supposed to be, anyway. The reality is oftentimes very different.

I'll use the example of a camera that shoots to MTS files. MTS files are typically understood to contain video levels in the 16-235 (broadcast) range. However, some cameras still write data over 235. That's right. Sometimes the camera will write highlight data -- that's real information -- above 235. This data will be clipped in any normal NLE or software that doesn't give the option to transcode full range because it assumes, more or less correctly, that no data exists over 235. This is a fault of the camera, not the NLE. I've seen it happen plenty of times, even with cameras that shoot to MP4 files. That's why I added the option to 5DtoRGB to force the use of the entire 0-255 range. So, even though it's supposed to be that cameras shoot 16-235, they don't always stick to the plan, and clipped highlights are the result. You would never even know this was happening without trying to transcode the clips as full range, because any other piece of software that doesn't allow this (and most don't) would never give you the option.

If you don't notice a "flatter" image after transcoding using the full range setting, this is probably because the source is already full range. In this case, using the broadcast range setting will give a much more contrasty image because 5DtoRGB is only considering the data within 16-235 (it is clipping shadow and highlight detail). This is also why footage that is genuinely broadcast range looks correct when using the broadcast range setting, but looks low-contrast when transcoded as full range (even though there may be some extra highlight detail, so keep that in mind).

I hope that helps!

@shian

5DtoRGB is really only for turning mts files into something we can edit.

Mmmmm, not entirely. Not for me. Not when you're talking CS6. That may be the case for some systems running older software. Working with MTS/MP4 files directly in an editing package is as much or more about software as it is hardware. The same system that chugs trying to do it in CS4 likely works just fine running CS6...but there's the rub: CS6 does a bad job of transcoding the MTS.

Beyond the "digital rain" artifacts produced by the Main Concept libraries, it simply doesn't do as good a job with filtering MTS files for grading.

Granted, this may be also more the fault of the Main Concept libraries and not necessarily Adobe's but I've noticed it in my own footage. I haven't investigated whether they've solved this issue with CC or not.

I keep footage as MTS while editing, because I get great realtime performance. Then when the edit is locked I transcode the appropriate clips and conform for grading.

Use Quicktime Pro? I'm sure there's some sort of batch work around for it somewhere.

if you are shooting quicktime movies in the cam, why the hell are you bothering to transcode them? Just start editing.

5DtoRGB is really only for turning mts files into something we can edit.

Something very disconcerting is happening with GH3 footage. I've been transcoding the footage with Broadcast Range thinking that there would be no change, but the resulting footage is a lot more contrasty than the original. This is really bad. Clearly 5dtoRGB is crushing blacks and making the image more contrasty...

Thanks @shian and sorry to be a pain in the ass! I'm putting this subject in a safe and sinking it to the bottom of the ocean.

@Shian Sorry to get you involved in this again but maybe you can chime in here? If not, I completely understand since this has already been beat to death before.

Since I need to match the files I shot on both GH3 and GH2, I opted for transcoding with Broadcast Range. They both look similar to my eye right away. When I transcoded with Full Range, Gh2 files looked "flat" and GH3 files didn't change at all. That would create more work for me in the post since I have to do extra work to math them.

@vicharris

So is this statement not true?

No, it's not true... except of the note the cam records broadcast levels.

you can see that full range is actually just lifting your shadows and compressing your highlights. (...) So you are actually baking a shadow lift and highlight compression into your footage

The other way around! The camera records "broadcast safe" 16-235 levels ... so if you want so, it records "lifted" shadows and "compressed" highlights (in fact nothing is lifted or compressed... but it looks flat on a computer screen). So when you set 5DtoRGB to "broadcast" you are baking an expanded luminance range into your footage. "Fullrange" passes the full range of luminance levels contained in the source file into the transcoded footage.

As far as the GH3 goes the QT files contain meta data showing the colors/levels utilized ... the GH2's MTS files do not contain these tags (see attachment).

@vicharris

well, I did a quick research and found some posts of "shian" on the topic. Since he uses FCP everything is fine with regard to his particular workflow. Nevertheless in 5DtoRGB the setting "broadcast" remaps studioswing to fullswing (16-235 to 0255)... which is a pretty trouble-free workflow for the QT-based FCP applications. However, technically speaking there is a remapping going on ... and this remapping is in 10bit. 5DtoRGBs setting "fullrange" doesn't remap at all. It passes the "full range range of luminance levels contained in the source file" to the outputted file. That's all I am talking about ... And, sorry, this is not "absurd", it's simply what's going on technically ...

Thanks @towi

I have been transcoding my GH2 files as BT.709 "broadcast range" most of the time. So I was basically not gaining but also not losing any information, except for leaving to 5DtoRGB to remap 16-235 to 0-255 in 10bit space.. Is that right?