It’s Important to understand that Avid in the Beginnings was build to deliver Broadcast Levels. Everything else would be handled outside of it (DI Workflows for Instance). In a World of Online Delivery and People watching on Computer and Handheld Devices Avid had to move, but it’s still kind of complicated in my opinion. But they’re getting better.

Since AMA you got two Options of Import Media: still the “Classic Import” (Conversion to DNxHD) and AMA  (or transcode from AMA to DNxHD)
1.) Here comes the wierd thing:
In the Classic “Import…” Dialogue Options Window you have to choose “709/601 16-235 Videolevel”. Because this tells Avid “My incoming Video is ALLREADY BROADCAST-SAVE – SO PLEASE DON’T TOUCH IT” (in Fact it’s not but you TELL Avid hereby not to shift Levels!)

Important (and even more stranger): on Export you also have to select “Video Levels 709 bla ba 16-235″. At Least I was succesful this way. Dont know the Reason but I guess you kind of tell the Encoder what you are feeding him (and not how to tag the file). If you choose “RGB 0-255″ Avid again will shift levels in Order to make the File Broadcast Save.
Yes, that’s really missleading.

2. AMA. On Export it’s the same. On Import it’s better: you can choose (rightclick on clip(s) how to handle the Levels, here I choose “do not touch Levels”). It’s recommendet to use AMA these days and transcode from there your Offline Intermediate. When finished, relink to the Originals and Export to higher Bitrates

HTH, sorry for my Englisch, and Avid should pay me for this
(no, to be fair: read the Avid Community Forums, there are much more educated and talentented People than me, which is where this Info is coming from. !!! http://community.avid.com/forums/)

To clarify, 8bit Canon DSLR video like many other consumer video cameras capture luma in the 0 – 255 range, generally 16 – 255 but chroma is always within 16 – 240. It’s very difficult to get a camera to saturate color and go outside of 16 – 240. If luma and chroma we’re full 8bit range or more accurately 1 – 254, then that would not be rec709 but xvYCC or as Sony calls it xvcolor. 1.8x more color information and a wider gamut than sRGB but maintaining the same color primaries.

rec709 can be full luma range legally, it’s only ‘illegal’ for broadcast, not editing and grading before squeezing into legal range before encoding to delivery codec.

The whole ‘illega’ description is daft. If a camera captures luma 0 – 255 then that is what it does and is the way it should be handled. If a NLE or transcode tool handles it as 16 – 235 then it will introduce quantization errors, visible as spikes and gaps in a hstogram and artifacts. This is what CS5 is doing along with better interpolation in the conversion to RGB. Like 5DToRGB.

Users of applications like Avisynth have been happily processing full range video in 8bit form for many years. No need to convert it to 10bit. That is a work around for NLE’s bad handling of it, no real need to convert to 10bit it’s still 8bit’s worth of levels in a 10bit file unless some dithering goes on to generate additional data.

Whether setting your camera to AdobeRGB or sRGB for video doesn’t matter. rec709 video is always sRGB color primaries, rec709 transfer curve and encoding flagged as such. That includes using Cinestyle, it’s still rec709.

rec709 has received a bad reputation for steep contrast & crushed shadows because so many NLE’s have handled it badly when they convert it to RGB for color processing and display. Properly exposed, full range luma, rec709 video is no where near as contrasty as believed.

Where you mention RGB and rec709 do you mean that you have transcoded with full 0 – 255 levels rather than 16 – 235, 240? and kept it as YCbCr or have you done a color space conversion to RGB?

It’s confusing, 8bit is 256 levels whether it’s YCbCr or RGB. Again NLE’s at fault with their weird descriptions calling 16 – 235 video levels and 0 – 255 RGB levels.