Fusion 9 read/write DNxHR files incorrectly - color clipping

Hi guys,

Does anyone notice that Fusion 9 read DNxHR files incorrectly? The histogram shows that my values range from 0 to 1 and therefore correct, but my black level is more crushed and my whites are clipped. If I load the same file into Fusion 7.7, my black and whites have more range in them. This is making it hard to use Fusion 9 for DNxHR file if I can't trust my colors are correct. Thanks.

Yes, it has been noticed by some people. But the more people report it, the more likely it is to be fixed, so please send an e-mail to support preferably with an example file. It's a nasty one to be confronted with, that's for sure.

I've just checked fu7 against fu9 and the difference is substantial - denser blacks and brighter clipped whites.

This is a serious problem for me - a lot of editorial departments accept VFX shots as DNxHR quicktimes in order to avoid some of the bizarre gamma and contrast shifts that plague other formats. I've gone to some lengths in fu7 to make sure the DNxHR qts match up both to what editorial see and to what Nuke outputs and this change in contrast when using fu9 could make it unusable in production - just as I was planning on trying to use it on a show that is about to go into post.

I'll try and assemble an example comp and qt file and test it in fu7 and fu9 for Blackmagic to look at and hopefully fix. In the meantime, thanks for the warning!

There is even a difference between Fusion 9 and 9.02 in the handling of DNxHR. It's a nasty bug.

Well, I guess we'll avoid DNxHR for now.

Hey there,

I wonder wether it's a Fu9 only and/or DNxHR only weirdness... It looks like you guys are all on PC but in case of you're not, did anyone notice the same issue on Fu8 and on ProRes ?

Fusion 8 and 7 uses QuickTime for i/o of. Mov files.
While 9 and above added a new proprietary I/O for QuickTime formats. That's also the reason why the list of formats you can export is now smaller then in fu8

Yeah, well this even changed between the initial Fu9 release and the 9.02 update which - as far as DNxHR compatibility was concerned was more of a downgrade.

Thx for these pieces of news...

I've made up a little test bed that compares fu7.7.1 and fu9.0.2. Basically it is a slate frame then 5 frames of Marcie - there is a comp file for fu7.7.1 that makes a DNxHD qt and a comp file for fu9.0.2 that does the same. Below is a screen grab of the result, admittedly on an 8 bit monitor as my 10 bit stuff is in transit at the moment. Top left is the 7.7.1 file displayed in Resolve 14.3.0.014, then clockwise fu7.7.1, quicktime 7.7.9 then fu9.0.2 all in win10.

The good news is the current 9.0.2 seems to display the file with contrast that matches the current Resolve, and 7.7.1 seems to match quicktime (nearly) which makes sense given the comments on changing to a proprietary decoder above. So maybe 7.7.1 is the buggy one, and 9.0.2 is the fix?

One thing I noticed to watch out for - if you read (or if your pipeline uses) a comp file that makes DNxHD quicktimes and was created using 7.7.1 reading it into 9.0.2 has an unseen side effect whereby the compression that was set as 8 bit DNxHD in 7.7.1 gets changed to apple prores 4.2.2 and you have to manually change it to DNxHD SQ 1080p 8bit to get what you would have outputted in 7.7.1. There are a lot more DNxHD options in 9.0.2 (a good thing) but best check that it's still outputting what you think it is.

If anyone wants the testbed files to check for themselves I could post a zip file - it's about 12 megs.

resultsA

resultsA.jpg (161.08 KiB) Viewed 1834 times

Hey JP,

Thanks for doing that. This is definitely an issue in Fu9, however. We use DNxHD/HR in our workflow a fair bit, and DNxHR 444 written out of Resolve with full data levels will be mis-interpreted when read into Fu9. Fu7 will not do this, and if you load it back into Resolve, or anything else, they won't do that either.

It almost looks like Fu9 assumes that any DNxHR quicktime is written as video levels, and interprets it as such, without allowing you to change it.

I'd love this to get resolved as soon as possible - it requires always going to image sequences for Fu9, which can be frustrating on quick turn around jobs.

Your note about the codecs is a good one - this is something I have noticed before. If you have different codecs installed on different machines, then Fusion may pick the wrong one if a job is sent from one machine to another. My guess was that it lists them in an array and stores a codec choice by the number installed, and if that order or number is different on another machine, it ends up choosing the wrong codec.

I've even had this issue when I had the same codecs installed, but they appeared in a different order in the dropdown. This was an issue in Fu6, I ended up always installing the same codecs in the same order on each machine to avoid it, but haven't checked in 9, so it may be different.

As a FYI, I've just been told that this issue is now logged as an issue with the Fusion dev team for the next release. Good news!