YUV and all it's greatness
I have been troubleshooting this for over two days and feel now it's safe to come to Cow.
Long story short, I need to export some dpx sequences from Smoke. I've used connectFX to create a few watermarks, etc. Our viewing delivery settings are DNxHD 115, quicktime wrapper. That's a 1080 8-bit format. Now, when I exported, I noticed that the DNxHD in quicktime 7 is considerably flatter than it appears in Smoke. Nuke confirms this. Smoke won't see it even when you bring the QT back in.
So I tried to quick solution. I exported "with YUV headroom." Perfect. Everything looked right. However, Nuke, where these will be QCed, sees an odd noise of some sort. I've attached an image so you can see. It's as if some of the levels are out of range, I'm not sure.
The two days of troubleshooting have included two roads: One is to find a way to clamp, or something, the YUV quicktime so that when brought into Nuke, we don't have this issue. The second is to find if there is a way to apply some kind of Smoke LUT onto the clip itself and export without YUV. This attempt is trying to give the QT the YUV look without the YUV problems seen in Nuke. I've tried TONS of the LUTS with no success.
Reposted form a similar question on the AREA.
Smoke and Quicktime Player (and other quicktime apps) handle gamma "differently".
QT makes assumptions on the gamma of YUV QT files being 2.2, and RGB QT files are 1.8. Therefore, for a YUV QT such as Prores 422 HQ, it will automatically lower gamma to 1.8 for display purposes.
Smoke does not apply these automatic changes. This means that if you wanted to export a YUV QT from smoke to be used in FCP, you would need to compensate for these automatic changes when you export. (there are 1.8 to 2.2. and 2.2 to 1.8 gamma presets)
It's been an annoyance for some time.
There are LUTS you can add to the export to convert the gamma
Senior Editor - Autodesk Smoke
WTHR-TV Indianapolis,IN, USA
And this is why quicktime is such a pain. :)
Yes and I was worried that it would be an annoyance here. It's remaining persistent however. I'll continue to try and fine tune it, but basically, I had already tried this step and just did it again. I'm trying to apply a "remove gamma" LUT so that I can export without the YUV setting (since that creates a second problem in Nuke) but that matches that more saturated image I see in my viewer. However, all the presets are too dark, starting of course with the closest "remove_1.70_gamma" via the color transform options. I assume this is where I'm supposed to source the LUT?
Being the case, I will try and see if I can make a custom. But the suggested two don't seem to do the trick for me.
To be clear again, the "adding YUV" option matched my monitor but had that noise issue. Fixing that went nowhere, so I'm trying to add a lut or something to emulate the yuv settings.
Hey sorry to be a pain but a series of tests today narrowed this issue down to one thing: YUV. Simply put, when I export something with YUV and bring it into Nuke, it errors (that color noise). However, when I bring back that yuv QT into Smoke, and export it again, this time without YUV headroom selected, Nuke now regonizes this. To recap: I am exporting a QT from dpxs, selecting "add YUV," thing bringing that export back in, re-exporting it but without YUV selected (making it identical in reality).
This works whether I add a reqired LUT to the yuv QT or to the second QT exported.
This made me think: Ok, 8-bit QT (DNxHD 115), the dpxs are 10-bit, something 10 is getting trapped. We'll, I've reformatted my dpxs so that they are 8, and the error occurs. The LUT is being rendered at 8. Hmm.
Any ideas? I'm no color space expert but I've tried to see if there was a way to export my dpxs in this yuv colorspace so as to avoid the generational loss, plus the above is a poor workflow. That's where I'd need help. I'd also be happy to add a LUT to the dpxs that converted it to this colorspace.
I know it's odd for the author to reply multiple times to their own post, but I did want to post a solution since a strong database=faster solutions.
There are various issues that can arise with rgb v yuv. I assumed this was one of them. Rather, this was a codec issue specifically from Avid. Avid posted a DNxHD/VC-3 Compliance Issue recently, announcing the discovering of bit-field corruption. This is that "color noise" I referred to.
Avid has since fixed this codec. My codecs were sent directly from a friend, however I would believe they are available on the site (though that said, I believe those are the ones we had originally). If you don't have them, feel free to reply and I'll be able to email you PC or Mac codecs to fix this DNxHD specific problem.