Blackmagic Shuttle DNxHD issue

[James Hughes]

The new codec installed fine, but unfortunately didn’t fix the gamma level issue.
I tried using the CalibratedQ software, but it didn’t seem to make a difference either.
Interestingly though, opening the same file in both Quicktime player and in MPEG Streamclip, the levels were a bit better in MPEG Streamclip.
So, BM….. I’m still looking for a solution to this. Really hope you can figure this one out!

cheers.

[Gunter Puszkar]

Hi Guys,

if I look to your pictures I see not a “gamma shift” I see a difference between decoding of DNxHD 422 into RGB and AVCHD in RGB via DNxHD. Thats a codec issue, which we saw in Baselight as well with transcoded footage generated with Avid MetaFuze.
Same happend here with AfterEffects. The workflow guides from “cablibrated MXF” are correct and helping us to avoid this fullrange (0-255)/headrange (16-236) issue.

I believe, AVID has changed the DNxHD decoding method to work in 444 with DNxHD, because than they need fullrange decode. In the AVID SDK i’ve have seen new methods implemented…
This introduces a new standard process issue, on processes were no new decoding method is used. We worked that out with other systems as well.

Thats why I think the issues are in the old Avid codecs prior to 2.3.4

The biggest problem of ignoring that issue is the compression levels gets to hard. We had transcoded DNxHD ARRI Alexa Footage with LogC graded without massive artifacts. Now on the new codec methods, the same grading process looks awfull with a lot of bandings. But thanks to Filmlight, the issued a new decoding method per each clip, so you can decide, how you want to go.

Gunter Puszkar
Head of Postproduction
PostFactory GmbH
Berlin, Germany

[Alex Maranda]

That’s not a gamma shift issue, which by definition affects midtones.

The Luma graph from the AVCHD recording shows full range data (full swing), with values from 0-255, which is good for dynamic range but is illegal video (for broadcast purposes). It has both superblacks and superwhites, which is good for CC.

The DNxHD recorded by the Shuttle shows legal video ranges (studio swing 15-235). Looking at the luma density around the black point it appears the full range signal outputted by FS100 has been COMPRESSED to studio range and not clipped. It is arguably correct behavior, if one was to broadcast the recording directly.

The dynamic range can be stretched back in color correction as the information is not totally lost (it’s a less than ideal situation though as the compression/stretching will induce artifacts).

I think there should be an option on how the data is to be recorded: full swing vs studio swing (Rec709).
Personally I would choose to record full swing (illegal video) at all times and color correct to legal range for broadcast delivery, as it keeps all options open (web, cinema).

The trick in AVID is to import full swing data as Rec709, which leaves it as is. If you specify RGB it will compress/rescale it upon import to Rec709 (studio range).

[Greg Booth]

Hi James,

If you’re using Calibrated{Q} MXF Import with the BlackMagic DNxHD MXF files in Adobe applications then you should change the DNxHD Color Levels in the Calibrated{Q} MXF Import Options application to ‘Full Range’ since Adobe applications use Full Range RGB when converting YUV to/from RGB.

Here’s a link to the Calibrated{Q} MXF Import User Guide here. In the User Guide we go over how the Avid QT Codecs will encode/decode to/from RGB<->DNxHD422 with either SMPTE Range RGB or Full Range RGB, as well as what Color Level works best in different applications (like Adobe apps or FCP).

I hope that helps!

Cheers,
Greg

Calibrated Software

[Bill Ravens]

Good call! I agree with you guys. The option should be given to the user, full range RGB or remapped YUV range. I’m not convinced that there isn’t clipping going on. BTW, the pedestal level is really a function of the exposure. I used an example that was exposed to 0 RGB. If I had exposed to 16 RGB, the Hyperdeck pedestal values would have been around RGB32. Calibrated{Q} explains the issue very well in their user manual.

BTW, I’m using the latest DNxHD codec, v2.3.7, and I’m still seeing the gamma shift.

[James Hughes]

thanks greg.
I’ve only tried it in demo mode as i was trying to avoid a cost.
i’ll have another go as you suggest.
cheers.

[James Hughes]

yep. the option would be great.

[James Hughes]

Liam, any ideas on this?
(I’m told if anyone can sort this out, you can!)
cheers,

[Bill Ravens]

James….

I recorded HD color bars from my FS100 to the Hyperdeck. Opening these files in Resolve shows the levels to be remapped to levels that are compressed across the entire range. We know all this. Using Resolve to expand the levels back out, there appears to be no lost data or clopped superwhites/superblacks.

My plan, as a workaround, is to simply reexpand the acquisition in resolve to RGB levels.

[James Hughes]

Yeah, it looks like the only way.
My problem is that the shuttles are part of my rental stock, and I can’t really expect someone who is hiring my camera / shuttle kit to have to deal with all this.
Anyway, hopefully BM come up with a solution, and hopefully I haven’t wasted a couple of thousand bucks.
Cheers Bill.