Welcome to our community

Be a part of something great, join today!

  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Washed out colors on DNx-wrapped QTs

Bradinn

Member
Joined
Dec 9, 2008
Messages
9
Reaction score
0
Points
0
Hello everybody...

I'm preparing to cut a project on Avid Media Composer 4.0.5 on a Mac, it will be my first time using Red footage with Avid (I have a good amount of experience with Red and FCP). I've been testing out footage I have left over from an old Red project and running into an issue where upon import, my footage has a very unpleasant desaturated look. I've done a lot of searching through various forums and come across a few instances where people say it has to do with luminance issues between 601/709 and RGB on the source/timeline monitors.

Here's a couple of them:
http://community.avid.com/forums/p/67309/376951.aspx#376951
http://community.avid.com/forums/p/32334/179122.aspx#179

While this does fit my description to a degree, I think the problem I'm having goes beyond that. Just to be sure, on the same project with the same settings, I imported footage that I transcoded using Clipfinder at 1/4 res debayer 1080 DNxHD 36 codec. Then I imported a QT reference file (the M proxy) direct from the camera files. The reference file was what I would have expected the image to look like while the DNx was completely washed out. I'll post a comparison picture:

Here is the M proxy:
redfootageproxyimport.png


Here is the DNx wrapped QT
redfootagednximport.png


I also tried transcoding using RedRushes with the same result. I've played around with the color space and the gamma, I tried using a 10 bit DNxHD 175, I've imported RGB and 601/709, and done everything by the book as I understand it for Clipfinder and RedRushes workflows. Everything gives me these washed out files. Before this, I had never run into that problems with Avid.

Something I just noticed as I was posting these screenshots is that if I open up the M proxy and the DNx transcode in Quicktime, the transcode is obviously brighter, but not washed out. But then, when I compare them to the screenshot of the M Proxy imported by Avid, the image is almost identical to what my transcode looks like in Quicktime. I'm not sure exactly what that means, but maybe someone does?

Top left is M proxy in Quicktime Player, Bottom left is transcode in QT Player, middle right is the screenshot of the M proxy as imported by Avid.
redfootagecomparison.jpg


Does anybody recognize this problem? I don't know if it's an issue with the way I'm transcoding or the way Avid is importing, but I'd like to figure this one out!

If it makes any difference, I believe the camera build for that footage is #17, it's 4k footage that I scaled down to 1920x1080 on the transcode. 23.98 fps. I'm on an iMac with a ATI Radeon HD 2600 Pro graphics card. I am current on all Red software and drivers.

Thanks in advance to anybody who has any insight on this, I don't really know what else to try...
 
When in the RED tools, are you set up for a 709 Gamma for output?

Michael
 
When you imported the files in Avid did you get an Import or a Fast Import. This is a major signpost about your Avid settings for Red. If your settings are correct size, 601/709 and the capture setting is the same Dnx as the file you should get a Fast Import. If any of these are wrong you will only get an Import.

Micheal's question is good, he always gives excellent advise. But to me this looks like a classic case of wrong settings. Dnx files should be 601/709 (although I have seen the option to make them RGB - bad idea). Assuming that they are 601/709 and you told the Avid that they were RGB, then on import Avid is going to raise the Blacks, lower the Whites and the result will look washed out.

Joe Ogburn
 
Hey guys, thanks for the quick responses. This forum is always amazingly helpful.

I did set the gamma to 709 on the output and I'm importing 601/709, so I have been getting the fast import. Everything appears to be working correctly except that color problem. I also tried importing to RGB and got the same result (although of course it was not a fast import).

I'll give you my settings and maybe you can tell me if anything sounds incorrect:
Output format: Quicktime
Debayer: 1/4 res
Codec: AVID 1080p DNxHD 36 8-bit (should this be just AVID DNxHD?)
Scale: 1920x1080
Resampling filter: Catmull / Rom (sharp)
Look Source: RSX file
Color Space: REC 709
Gamma Space: REC 709

I haven't been making any other adjustments. Then I kick out an ALE and batch import on a 1080p 23.98fps AVID timeline using 601/709 setting, no resizing, and no alpha channel. I get the fast import the way I would expect to, but those colors are washed out.

It seems as though my image gets brighter after the transcode with Red Tools the first time, and then it gets even brighter (and low contrast) when I take it into AVID. I never noticed it with FCP, but should my transcodes be brighter in the first place? And on top of that, I've never noticed my images losing contrast when I've taken Quicktimes from XDCAM or P2 into my AVID before. Do you guys see anything with those settings?
 
I'm having a similar issue giving QT wrapped DNxHD files to our editor from Premiere Pro as well. I think the issue may be with the Quicktime Encoder assuming you are always feeding a .709 signal into it. I am on Windows.


My guess is that the "Washed out footage" looks like Adobe is encoding the footage as RGB, and then DNxHD is interpreting it as .709 materials. (Even though we have captured uncompressed .709 from our Black-Magic Card.
 
I'll play around with some settings to see where it may be changing...

Michael
 
hmmm.... I find that I get three slight differences between the R3D file in Red Alert, the QT exported using the RSX (with 709 gamma output), and the QT imported into Avid. I suspect something in the QT changing since it doesn't quite match what I see in Red Alert (I used an RGB color picker for value matching). But it is not as severe as what you are seeing - but there is a difference. I will the same with MXF direct out in REDCINE-X to see how that behaves.

Michael
 
This is a known issue with QuickTime. It is very difficult to get decent WYSIWYG renders out of RC-X even with the Rocket card, without a lot of trial and error. Boost teh contrast to something like .70 for starters to get things close. It will look awful in RCX but the QT will look more correct.

It's the Apple Gamma issue. it picks what ever gamma it wants depanding on the CODEC it is writing too.

David
 
Checking it out in rcx, I notice that once I go to 709 gamma space, I basically recreate the faded image I see in Avid, so perhaps I'll just have to compensate like David said. By doing so, am I going to end up effecting my R3Ds and conform process, or is this strictly effecting the transcode? It seems like this would just be a superficial solution, but I suppose it's better than editing those terrible looking transcodes.

Am I safe in assuming then that this is not a user error and is simply an issue with the Avid system for Mac?
 
When you used RCX, did you create MXF/DNxHD directly or still go through QuickTime? DNxHD is an HD format in the REC 709 color space where in 8 bit is it 16RGB to 235RGB. Getting the sources to map to that correctly is the tricky part.

Michael
 
The JPEG attached is from a RCX direct transcode to MXF/DNxHD and then to QT/DNxHD imported as 709. RCX on the left, QT on the right.

Michael
 

Attachments

  • compare.jpg
    compare.jpg
    87.8 KB · Views: 0
It would seem that when rendering to QT with that CODEC that QT sees it as a REC 709 codec. You will not be destroying anything in your R3D when you go to a conform.

All you have to do is bring all the clips back into RC-X and apply the META preset to all the clips and they will be back to how they came off the camera on the day.

Because there is no new QT codec from RED I am going to guess that when you send REDCOLR and REDGAMMA to QT then and QT does not know what these color spaces are then it is defaulting to known values.

As Michaels post demonstrates it seems that REC 709 GAMMA is what the AVID CODEC defaults to.

David
 
Hey guys, I did some grades in RCX last night after selecting 709 for color and gamma, and I just bumped up the contrast to .70 like David suggested, along with with a few other changes with color temperature and other levels to get it looking ideal. I only used a couple clips at first and exported direct to MXF. When I brought it into Avid, it appeared to be very close if not identical to my grading in RCX. Since I have the first batch of rushes and have already graded them, I will be trying it out tonight.

I think this actually ended up as a favorable solution as I was previously unaware RCX could export directly to MXF, and you can get such great images out of it. The only problem is that I get that pmm_insufficient_media error when I bring the clips into Avid so I have to unlink the audio channels. This isn't necessarily a problem because I'm doing dual system for this project, but it would have been nice to have my scratch track while I sync and the workaround for that error is really not worth the trouble just to have the reference audio. I could see this being a problem if you weren't doing dual system and had several hundred/thousand files with the error, but then I would assume most people wouldn't be doing anything other than dual system for Red.

Can I feel relatively safe about conforming these RCX MXFs later on down the line? I will be taking my offline to a facility that will be doing the grading and online, and I haven't been able to read a whole lot about people's experiences with RCX's MXF exports once they get to that point. It appears all the metadata is correct, I'm just using a whole new set of tools for Red between RCX and Avid since I had previously used Clipfinder/Redrushes and FCP.

Thanks again for all the help guys. I would have been stuck for who knows how much longer without all the insight and experimenting you all have done on this. Hugely beneficial as always and I hope anybody else having these issues will see this thread.
 
I worked with Deanan to ensure all metadata integrity from RCX to MXF/DNxHD. If using only the MXF you will have absolute TC as START and 16 character as TAPE. If you want all the additional metadata you can merge the ALE into the clips created by MXF.

Michael
 
you're just the man around here michael...you must have extremely good karma
 
I hope so... :) never know when I might need it!
 
Back
Top