I have to correct myself.

I have here both Edius 6.5 (retail version) and Vegas. If I render an clip to the Canopus HQ codec, I see a luminance shift - from 16..235 it seems to go now to 0..255 if I import that in Vegas. So, in Edius the luminance is correct, but NOT in Vegas.

I had a look for the registry entries - and do not find them on my system, as it was reported by Fuchs. I have no idea where I find those settings.

But with that behaviour the codec is not usefull for Vegas.

Did you encode and decode inside Vegas? Or did you use the external Canopus encoder?
AVI or Quicktime?

Malowz, knowing how comfortable you are with scripts etc., you might be interested in my Vegas > Frameserver > AviSynth > Megui method for web encoding, especially if you are deinterlacing. You can avoid the intermediate, and play with infinite possibilities (denoising, resizing, sharpening etc..) within AviSynth.

But I realise it might not be as convenient as a fully automated script to go from Canopus HQ to mp4 via CLI Handbrake.

"Did you encode and decode inside Vegas? Or did you use the external Canopus encoder?
AVI or Quicktime?"

I have encoded
a) in Edius
b) using the AVCHD2HQ converter
c) in Vegas

If you import the files in Vegas.
a) and b) are wrong, c) is fine.

If you import the files in Edius
a) and b) are fine, but c) is wrong (and luminance is shrinked down in that case).

Encoding was done with avi.

My conclusion: as long as we do not know settings to adjust that, the latest version of the Canopus HQ codec should not be used anymore for a transfer between Vegas and Edius or Edius and Veags.

for "people" with the color shift problem:

open regedit

go to key:
HKEY_CURRENT_USER\Software\Canopus\Codec\CUVC

right clik on the right side, "New" > "DWORD (32bit) value"

name it "color_space" (no quotes)

after that, double click on it, change value to 1

so the same for HQX:
HKEY_CURRENT_USER\Software\Canopus\Codec\CHQX

close vegas if it is already open. if you have a template on vegas with canopus HQ or HQX, DELETE IT. then, create a new one.

do not try to open old HQ or HQX files (results may vary), start to use it from here.

post back the results ;)

Thank you, I have tried that and can confirm that it works.

In more detail: I have added the "color_space" to the existing HKEY_CURRENT_USER\Software\Canopus\Codec\CUVC
entry.

The other setting for CHQX is not available on my machine (where I have both Vegas and the retail version of Edius 6.5 installed, in addition also the actual AVCHD2HQ converter). So for CHQX I had to add CHQX as an additional key, and have entered here the DWORD 32bit value = 1 only.

I have tested to render a file to the Canopus HQ codec with the AVCHD2HQ converter, and have imported that in Veags - and here the luminance is now fine. I have also tested if the usage of such a file in Edius is fine - ok it is fine too.

When I render in Vegas using that settings, I receive an additional reduction in luminance! I see that after importing the Vegas output both in Vegas, but also in Edius. Before we re-import such a file in Vegas, the color_space must be set to 0 again. So I think here we have to take care - for importing HQ files in Vegas that is fine, but not for the export from Vegas!

did you have a template for HQ or HQX in vegas? did you deleted it?

im exporting from vegas/importing in vegas and no shift whatsoever.

Why do you think that the templates are important? We are talking about the decoding behaviour, arn't we? At least how I intend to use that codec (to bring something from Edius in Veags in the correct way). So files encoded in Edius were fine in Vegas, after changing the color space setting.

But to encode a file in Vegas and use that in Edius is still not fine.

the template save internal codec settings. caused my firsts attempts to get wrong levels.

and i don't know for sure, but i think the setting on the levels info is saved inside "codec data" on the file, cause older files encoded without the "1" setting where decoded with the correct levels, but showed posterize on histogram.

that why the "delete template if you have" and "don't test with old encoded files"

@Nick Hope
im testing handbrake, separated CLI apps(same as megui use), and frameserve. again, frameserve is giving a file with audio longer than the video. (last second is duplicated)

exporting to Canopus HQ slowed the hole process by 20% (export avi > CLI apps vs. Frameserve > CLI apps) so, i will go with Canopus HQ from now on, as i find "safer" and easier to have the actual video file rendered. ;)

CLI apps have a few advantages over handbrake, but im testing both.

VP12 is not happy using Canopus Codecs!

A render to DVDA WS Video stream fails in VP12 but is OK in VP11.

an update was released more than a month ago:

Version 6.52 (Release: 10/18/2012)
Fixed an issue with super white clipping.
Fixed an issue with decoding.

malowz:
You are the KING!

Thanks for the registry tip, it works 100% :-)

glad it helped ;)

previous versions of the codec had an option in the interface. i wonder why they removed. but the registry key still work ;)

im using this codec everyday, in basically everything. exporting from after effects, boris red, converting captured videos in batch, exporting... not a single problem...

Yes, and the template in Vegas is really important,
because before registry hack i save a hqx template,
made the registry hack, and make a new template.
Now the 2 templates don't give the same result!
So even if i set the color_space in registry, i still can
render to "old" hqx format, but of course i don't do it.

Using the new template, rendering from Vegas to HQX,
and importing back, levels are good. Importing to Edius,
i get a little overexposed sky for example, but interesting, that
this can be corrected/revealed with YUV filter, or WITHOUT correcting,
just exporting to mpeg2 format, the video will not have
overexposed sky. So i don't know why Edius preview
monitor don't show the same levels as the rendered file?
How can editors do color corrections, etc. with this limitation?
Vegas show the sky correct in 8bit project setting, but
again overexposed in 32bit (full range) setting.

I work in 8bit, so i see all the details, what my camera record,
but don't know why not see it in edius, just on the rendered file?

(ok, its not an edius forum, but maybe somebody know the answer)

thanks!

vegas saves internal codec settings on the templates, and makes sense, so you can have settings with different "internal" options. or if you make a template with quality "best" on the codec, change the codec configuration later, now your template is changed too. the way vegas works prevent this.

that's why i repeatedly said to delete previous templates.

i think edius handles the codec colorspace itself, (maybe there's an option on it?), cause this may be the reason the configuration in codec is gone. as the codecs where made for edius, makes sense.

EDIT: tested a project in 8bits/32bits, and looks like the image its the same. no highlight clipping...

Did you set to 32bit full range?
You test it with a video that has a lot of highlight range? (sky, etc)

edit: oh, it depends, what's on the timeline. With HQX files i don't see the change, but with MTS files from my HX7V cam or TD10 files, it does change!

yeap, HQ files i got no change (8bits vs. 32bits, gamma 2.2)

but with EX3 video files it changes. i believe cause if you specify "full levels", vegas convert the videos with format that "should" be with studio levels.

but as avi with canopus codecs are "unknown", vegas does not change it.

"but with EX3 video files it changes"

Yes, and overexposures the bright areas, which had details on it. Why? I think it's just not normal, when camera can record some detail in bright area, we will loose it?

well, the main question is: should video cameras record "past RGB 235"?

technically, no, but most of them do. clipping that extra, depending on the scene can be harmless (sometimes in just a bit of highlights in dresses, light sources, etc) and sometimes is a very bright sky, etc.

if you are editing a video that "should" be in studio levels (16-236) and you specify a project with full-levels, makes sense to convert, but it will ignore if your video had a "extra" image in the highlights.

this can be fixed by darkening the highlights only, or using a curve to "smooth" the very bright areas, instead of clipping it or darkening the entire image, to preserve highlights.

im testing some images here, and most of the time, the highlights have no useful information, BUT, in some cases, where i shot "too hot", some overexposed images can benefit from the extra "past 235", but after fixing, i have nothing "after 235".

so, to my eyes, its not a problem, as long you know hot to correctly deal with it.

also, i use Carbon Coder to encode to DVD, and it clips anything outside 16-235. but again, it's not a problem, as the video its already adjusted to be in 16-235 range (i use the Broadcast Colors filter on the output to make sure it's in the correct range. it also smooth the "edge" levels to reduce the clipping harshness).

anyone care to dumb this all down to a couple sentances for a non-tech guy?
1. is whatever this is, faster?
2. how does one use it?

@musicvid

i did tests comparing canopus/dnxhd/cineform in this thread, just look some messages up.

and in my usage, i never had problems with it. and i use in in vegas, virtualdub, carbon coder.

but again, im not everybody, so please, test yourself too so we can have more "data".

the same way some people like and use cineform without problems, i got nothing BUT problems, so one persons only its not enough to get a full result ;)

@wwjd

1. is whatever this is, faster?
faster to what? DNxHD? yes.
2. how does one use it?
create a template in the "video for windows" export module in vegas.

I need to retract my previous statements completely, as I discovered I did not test Canopus initially. My lingering disappointment was actually with the Matrox codecs, which a few here have found problematic. Even the Matrox Uncompressed codec is not uncompressed, as can be seen below.

I'll step out of the way of this discussion until I have some direct knowledge to share, and sorry for what must have looked like a troll-post!
You've also got me curious about Canopus now. Those "Difference" tests you shared are interesting.