black point for export

[latcho]

Hello,
I'm new to Edius 5.
I made my first edits and all went well except for the exporting to file;
If I render via the quicktime exporter -> codec H264 then my black and white points are of big tme; the picture becomes brighter overall, black is consitently a soft darker grey and colors are too bright as if +3DB brightness.
What can I do.
PS: my source files where 1440x1080 29.97 (1.3333) MTS from a canon cam convertyed to Canopus HQ standard.
Within the program's preview monitors all is looking good.

Thanks guru's!

[SRsupport]

There is a problem with quicktime under windows. Othe Nle's have this problem too.
I know Avid advised of a setting in quicktime which you should disable. Unfortunately I lost my documents on that.

[cuervo]

sorry SRSUPPORT, but, I don't think that's the problem. I've gone thru the recommended workaround for QT on the PC and it doesn't fix the problem. The problem appears more related to a bug in the way QT's H.264 encodes footage. I think Apple has the 601-709 conversions wrong. The error manifests differently depending on whether you encoded an RGB or REC 709 source.Either ways of encoding result in blown out luma values and/or distorted colors.

As a demo of what I'm saying, import an NTSC colorbar pattern into your favorite NLE, then export that pattern as H.264. You will have the choice of importing and exporting RGB or 601/709. That's 4 variations to test 1-RGB IN, RGB out 2-RGB in, 601 out 3-601in-RGBout 4-601in-601out. I think you'll find that all four workflows result in some combination of blown luma values(black at RGB32) or distorted colors.

[latcho]

still in trouble

H264 / mov is not the only codec that translates luma wrong.
other QT codecs and even mpeg sometimes too; funny thing: sometimes mpeg plays as black on VLC and grey in Quicktime ... but more often both GREY.
I've tried all possible application settings and export settings within my project but I don't seem to manage to export a black-BLACK in a uniform playable format (except MPEG2 but only black in in VLC)...
Is it possible that the OHCI 1440x1080/29.97settings declare some kind of different (YUV?) luma standard which is than badly translated to RGB in more common user formats ?

[Zorro]

Have a look here:

http://ediusforum.grassvalley.com/fo...ead.php?t=8241

[cuervo]

Latcho..

You're quite right, other codecs display some problems, as well. I use 3 different NLE's...after all, an NLE is just a tool. All three, i.e. Edius5, Vegas8, Avid Media Composer 3, have the same problem with incorrect luma, distorted color, or both with certain codecs. WMV, for example is always RGB 0-255, it won't do anything else.

IMHO, it's a codec problem, not the NLE. Due in no small part to the uneducated, miseducated codec software writers and the confusion over 601, 709, RGB, YUV, NTSC. I don't think these guys are image users, just software writers.

The ONLY fix I've ever found is to apply a darkening filter with TMPGenC or Procoder3. Even then, when the luma is forced to be right, the colors are wrong. Canopus HQ, for example, works fine as long as I stay within the Edius family. If I export to another NLE, everything goes haywire.

In the FWIW category, I am a habitual user of Cineform Intermediate. Cineform seems to be one of the few companies who get the transformations right. Bitjazz's SHEER codec is another company that seems to have it right.

[latcho]

Edius functionallity

Thanks for your answers.
what I find odd is that when I first export to CanopusHQ-Standard and then
export to H264 in Procoder everything goes well.
It would be great to have an option as an extra advanced encoding setting in EDIUS that acts as a translation bridge between the renderer and the encodeing codec: "force rgb 0-255 /full color range"
that would solve all I guess...
And by the way, if I encode my source HDcam material to Canopus HQ-S before editing, I would at least love an option to discard the switch directly to full range colors... (or a project setting that offers me a full color range conversion on export) because that handicaps has eventually caused the problem I guess.
And then is Edius/Canopus to blame for not letting me bypass the codec writers 601/701/rgb confusions. Because QT en Mpeg2 are not silly codecs I guess.
Let me know what you think.

[cuervo]

Latcho..

I should make it clear that I have no hard evidence of my criticisms. My opinions are based, strictly, on empirical experience and some deductive reasoning. Why, for example, is so little written about this issue? I would think it would be a BIG source for discussion, yet it is not. All I can assume is that most editors don't notice how much of their work is washed out by blacks being raised to RGB30 or even 40. I won't discount some fatal flaw in my workflow and thinking, but, I think it's unlikely.

At any rate, many of the faulty codecs were written some years ago when DV was the only digital format. Time and technology has moved on, the codecs have not, whether it's negligence or lack of development money by the software writiers.

Still, your suggestions are things I've often pondered myself. It is not unreasonable to expect any NLE preview window to show the final output, including the effects of the "render to" codec. Once that is selected in the "export" command, the NLE software has enough info to show the result. This would save me countless lost hours, alone. I've FINALLY begun to compile a matrix of codecs, noting what output I get for which input parameter, 601/709(16-235) or RGB(0-255).

[latcho]

exporter colorspace conversion prefs

anyways,
I think Edius could proove a pro's suite on this subject/matter :)
If I have a problem with many codecs on this luma blow.then there is only one place where I'm ought to be able to fix it: "the exporter" settings... and not in some codec's proprietary pref box.
thanks for listening and joining all of you :)

[cuervo]

Not in my experience. For example, some codecs remap the luma range regardless of what you feed them. In other words, you may select codec input values of 16-235(as most NLE's do), but when you export it, the codec automatically remaps the luma to 32-215. I have not found a way to prevent this because there is no switch in the codec to stop the remapping. Starting with codec input values of 0-255 results in codec output values of 16-235, but, now the chroma values are distorted. Red, as an example, should be 180:16:16 on a SMPTE colorbar, ends up being 200:32:32. Clearly incorrect.