DNxHQ 4444 12 bit broken in fuStudio 17.4.3

As reported by @inohide in this thread -

https://www.steakunderwater.com/wesuckl ... php?t=5289

exporting DNxHQ 4444 12bit quicktimes through saver node in fuStudio 17.4.3 is broken. The created quicktime has the RGBA channels mixed up in the wrong order. If you turn off "save alpha" in the saver node options the problems disappears.

DNxHQ is used in a lot of VFX approval pipelines so it is important that BM resolve this ASAP.

Tested and confirmed on win 10.

A workaround until it is fixed is -

WORKAROUND - insert a channel boolean prior to the DNxHQ 4444 saver node with with your image connected to the BG and these mappings -

Operation - Copy

ToRed - Red BG
ToGreen - Blue BG
ToBlue - Alpha BG
ToAlpha - Green BG

This pre-jumbles the channels so that the defective Saver node ends up with them in the right places and the outputted quicktime looks correct with correct alpha channel. Haven't done extensive tests but seems to work ok. Might be some help for someone in need while we wait for a proper BM fix.

It's a "DNxHR 444 12bit" issue, to be exact. The name of the Avid codec is confusing.

You're wrong I'm afraid. The accepted convention is that 444 is RGB and 4444 is RGBA, i.e. with alpha channel. If you turn off the alpha channel the bug goes away so exporting DNxHQ 444 12 bit doesn't have the bug, but DNxHQ 4444 12bit does.

What is "DNxHQ 4444 12bit"? There is no name in avid codec list. It does not exist in Fusion.
And I know "DNxHR 444 12bit" supports alpha channel. This means 4444.

• "DNxHR 444 12bit with save alpha option" : There is a bug where the channels are swapped.
• "DNxHR 444 12bit without save alpha option" is fine.

This is all.

I just wanted to get the information right. Or am I just ignorant?

Fair enough. I guess adding the extra 4 to indicate an alpha channel is a local convention that I assumed was wide spread, apologies.

That's not the point. We're missing the point.

I don't think DNxHQ codec exists. It is DNxHR. It's HR, not HQ. DNxHR HQ is 8bit 422 codec.
DNxHR 444 12bit (this name is in Fusion's codec list) has a bug.

I just don't want to confuse support.

True that, there are DNxHD and DNxHR codec families, no DNxHQ. But if support gets confused by this simple thing they aren't going to be of any help anyway. And this isn't support forum either, so don't hold your breath about this getting into any bug evaluation.

I know..

Tested on FuStudio 17.4.4 build 5 - bug still present.

I am astonished that BMD is ignoring a bug that is this serious while still marketing Fusion as being able to write correct DNxHR 444 files, and that they haven't even bothered to fix it even though a clear and repeatable description and work around has been contributed by the user community. Very poor.

Just ran into this. Still an issue with 17.4.5

kinda depressing that proress 4444 doesn’t work and DNxHR 4444 doesn’t work. Mabye version 18 will figure it out.

I'm not a fan of DNxXX codecs so haven't use them much and didn't notice anything strange in the past.
This time I have a problem in Fusion Studio 17.4.6 for Windows (checked on Mac as well)

Source is in DNxHR 444 12 bit saved by Resolve (I assume). Metadata in Viewport state that it's in RGB ColorFormat. In addition this file can be played by VLC player normally.

After this just rendered in Fusion with MXF as a container and DNxHR 444 12 bit as a codec and reopened in Fusion the only thing is changed in metadata is ColorFormat = YCbCr. Needless to say that two files (source and result) have a lot of difference while comparing with Difference Keyer for example. And result couldn't be played by VLC as well.

Meanwhile if I use Resolve to deliver then everything is OK. ColorFormat of result is RGB and diference between files is around zero. Well, this is a solution but I prefer to use Fusion Standalone for this task.
Is this possible to write correct ColorFormat to MXF with DNxHR 444 12 bit in Fusion?