Hi there,

I have just upgraded to MC7 from 6.5 using a free upgrade.  Having run a few tests I am experiencing a noticeable shift in gamma levels, something which did not happen with either v6.5 or 5.5 (and I am running the same system).

I am working a project which happens once a year - encoding and editing films together for a film festival.  The workflow has been tried and tested over the last three years and I have never run in to any problems before.

My first test following the most recent upgrade was importing a mixture of .mov and .mp4s all encoded with h.264.  All films are either 1080p or 720p with varying data rates.

First import was using DNxHD 90X and this produced a noticeable gamma shift.  (The system also hung with an error message telling me some of the files were an unrecognised format - not sure if this is related).

I then imported the same files using prores 422.  The import worked fine, with no hang, but the same shift in gamma was aparrent.

I have also performed an export text using prores and DNxHD 90X (ordinarily I would be exporting same as source DNxHD 90X for this particular workflow) and an even more noticable gamma shift is apparent.

I have attached a graphic for reference.  The screen shot on the left is the original file (notice the deep blacks).  The middle grab is the DNxHD 90X import in Composer.  The grab on the right is the DNxHD export.

Does anyone have any idea what may be happening here?  I have never had such a noticeable shift on import before and I'm thinking about rolling back to MC6.5.

As well as QT X I also Have QT Pro v7.6.6 installed on the system.  Could this have something to do with it?  I know MC7 is QT X qualofied but I use QT Pro for other reasons and really need to keep it installed if at all possible.

Thanks in advance.

Thie issue is quicktime.  There is a gamma shift, and they seem to "fix" it from time to time so that previous solutions stop working.

AMA link -- don't import -- the footage.  Then transcode to the DNxHD flavor of your choice.  This is faster, more color accurate, and avoids the quicktime engine.

When you export, do a QTRef and use squeeze, TMPGenc, AME, etc to make your final files.

I've not yet tried V7 (experience has tought me to give .0.0 releases a wide, or rather, a very wide, berth :).....) but I've a few comments that may (or may not....) help you.

Firstly QT Pro 7.6.6 will not (and cannot) interfere with Avid.  It is just an app that doesn't install any common frameworks or components, so is completely independant and uses the pre-existing 32-bit Quicktime libraries. So this is not a problem.

The difference between the source QT and the source monitor in Avid is normal as Avid always shows blacks as a dark grey (of value 16) when footage is correctly imported.  This is just the monitoring within Avid and it has always been that way - external monitoring will show correct colorimetry.  Check in the waveform monitor (edit a clip into a sequence, go into colour correction mode, put Y waveform in the right hand monitor).  Your full blacks should sit at 16 (not 0).

However that your export has the same levels is not right.  Did you export with 709 levels?  So that the levels match your initial footage, you want to be exporting with RGB levels.  Note that with same-as-source DNxHD exports, the choice between RGB and 709 doesn't change the levels in the video data (where black is always stored at 16 and white at 235 - if everything is correctly set up) - just the rendering in quicktime and other apps that use Quicktime to serve the frames. The H264 and Prores codec always render out at full-swing (so called RGB levels) - the DNxHD codec will do the same if set to RGB levels.

I think there are two problems here: the levels issue (which you should be able to sort out), and a gamma difference which may be trickier.... as there are the color values stored in the file and those rendered out when you look at the footage in QT.  Two files with exactly the same "essence" - i.e. the same encoded data - can render out differently if the colour metadata (colr/nclc/gama atoms in the QT file) is different or absent - whereas software that directly accesses the encoded data (which Avid+AMA does on known codecs) will display the footage with identical colorimetry.  That the footage appears different in the QT player may not necessarily be a problem in reality, if the software interprets the decoded YCrCb data rather than relying on QT to convert to RGB.

I suggest always bringing footage in via AMA then transcoding, rather than via File/Import.  Make sure you don't have Perian installed, as this interferes with the import process introducing levels and gamma problems (if it is installed, deactivate it in the System preferences, and restart avid and probably the transcode services too - I'd reboot to be on the safe side).  AMA seems to be more transparent - File/import always uses quicktime to read the video samples (except for fast-imports) whereas AMA bypasses the Quicktime codec mechanism for known codecs, and for the rest it seems to work better.

For your exports, prefer same-as-source exports (or QT Ref) with RGB levels (after doing a mixdown if need be) over quicktime exports with a custom codec.  When you export non-same-as-source, Quicktime gets involved which has two disadvantages - there frames are retranscoded via Quicktime and you are limited to 8-bit exports (even if you choose a 10bit codec) - unless this has changed recently which i doubt...

Hope this helps,

Janusz

Firstly thanks to all who have posted thus far.  Here are some responses to your comments and suggestions:

I did have Perian installed and have now removed it.  I restarted the machine and re-imported with DNxHD 90x with the same results.  Could it be that I need to re-install MC having removed Perian?

janusz:

The difference between the source QT and the source monitor in Avid is normal as Avid always shows blacks as a dark grey (of value 16) when footage is correctly imported.  This is just the monitoring within Avid and it has always been that way - external monitoring will show correct colorimetry.  Check in the waveform monitor (edit a clip into a sequence, go into colour correction mode, put Y waveform in the right hand monitor).  Your full blacks should sit at 16 (not 0).

I need to point out that colour space is not my forte.  I have uploaded a new screen grab.  In the middle is the fresh import in the source monitor.  I understand what you say about black levels being set to 16.  In the wavefor on the right the blacks look to becoming in way above that.  If I knock setup to to -13 it looks about right.  Anyway, the left image is a same as source export using 709.  The image below is same as source RGB.  Although the blacks look better they look grainy.  I've always exported material using 709 and not noticed a problem before.  Does it matter that I didn't import the material with RGB levels?  The larger image is the original file.

Now, having said all that while I have been compiling this I did as you suggest an imported via AMA and did a transcode to DNxHD 90x and the blacks look perfect.  When did this become the preferred workflow?  I must have missed a meeting...

Thanks for all you help!

Snowball:

When did this become the preferred workflow?  I must have missed a meeting...

 

It was a couple years back.    Glad you got it working.