Thanks a lot musicvid, that does help indeed.
I changed the privacy settings, you should now ne able to view it - it's a split screen comparison with the original avchd canon footage.
Thanks for the clue to transcode in Vegas directly.
I was wondering if MXF would be somewhat less heavy on the preview, as I still get quite a stuttery preview with the DNXHD files.

"I was wondering if MXF would be somewhat less heavy on the preview, as I still get quite a stuttery preview with the DNXHD files. "

It certainly might go easier on the preview -- worth a try.

thanks, on my next project I'll go for MXF and see.

Just for comparison, here is how DNxHD 8-bit compares to MXF EX35 shown as the difference from a Belle-Nuit reference chart. Of course, the MXF will not be as bad in the reds as it looks here with your 4:2:0 source footage.

Uncompressed (control) difference would be all black with a white point in the vectorscope, so less is better. DNxHD is on top, MXF is bottom.





For those interested in this stuff, these images are from my next round of comparisons of Y'CbCr intermediate codecs, coming out sometime this winter. Stay tuned

if these are comparisons of Y'CbCr intermediate codecs, why is the black point at 0 RGB?
shouldn't it be 16 RGB?

edit
actually, now looking at the screengrab again, i'm more confused.
the Waveform monitor reads 0 and so does the Histogram. ???
what clue am i missing here; this should not be.

Since these are part of a larger series of tests including a number RGB codecs as well, the preliminary choice was to run all tests at full range, to compare inherent bit depth retention of the codecs in the nude, and on a level playing field. It seemed the most valid starting point, and turned out to be so farther down the road (see below**).

WRT the waveform monitor, it too was set to full range.

As a camera-to-editor or platform-to-platform transport, one does not want any range compression at all in the intermediate. It needs to pass every bit of video data downstream as transparently and efficiently as possible. The camera "may" shoot at REC 709 levels, or it may not. If the latter, the final levels call needs to be made at the editor / renderer, not at the intermediate stage. The good ones like DNxHD can flag the output for 709 or RGB downstream encoders while still retaining every bit of bit of data it was given.

In the case of a downstream encoder like Handbrake that does not do levels conversion, the choice to set the intermediate levels to 16-235 becomes an exception, not a rule. Again, we want the intermediate to pass everything we give it transparently, quickly, and compactly.

** The choice to test everything on a level playing field became much more important when I discovered that two or three venerable "lossless" RGB codecs are not mathematically lossless at all in the deep shadows (0-16), and are probably unsuitable for critical CG work despite their considerable lore and advocacy.

A second round of tests comparing only Y'CbCr codecs to each other at 16-235 levels "may" be forthcoming, but I'm not sure what that would show, since the range (bit depth) compression is a constant. Maybe someone would like to start their own round of tests with this added constraint.

As I said Rob, stay tuned, it's a WIP, and these preliminary images were offered only for the purposes of this thread.

cool... thx for the reply, looking forward to the tests. good luck!