Procoder Express/CCE Basic/Tmpgenc color output difference

[Wile_E]

Been experimenting with these other encoders. I've been using TmpGenc 3.0. I'm capturing using ADVC-300 to DV. CCE and Procoder Express both seem to change the color. Some threads on this forum suggest adding the "Shrink 601 colorspace" filter for Procoder. Well...Procoder Express doesn't have such an option. (I'm using trial of Edius 3, that includes Procoder Express). CCE Basic also shifts the colors around a bit, from the original DV source.

What is actually causing the shift in color? I took still images of the encoded MPEG2 files, and looked at their histograms. Procoder's histogram looks nothing like the original DV. It is boosting red and also equalizing all other colors/luminance. CCE's histogram is close to the DV one, but red is still boosted a bit.

Is there ANY encoder besides TmpGenc that doesn't mess around with the colors behind your back????? Am I doing something wrong? If so, please enlighten me!

[Wile_E]

Here are some examples. The original DV file was run through Convolution3D to smooth out the output first. Notice how CCE and Procoder Express color output is different from the original DV output. Tmpgenc is actually the most accurate, keeping the original DV colors. Is the color change, due to DV having YUY2, and DVD having YV12 colorspace?

CCE - The yellows and blues are slightly different.
Procoder Express - Too dark. But there is no option to add 601 colorspace. So you are left with this dark, more contrasty output. Whites are also out of range.
original DV output


Tmpgenc


CCE Basic


Procoder Express

[Wile_E]

Hmm. It looks like my Canopus ADVC uses RGB24 colorspace! I checked the files with Virtualdub, and it says RGB24! No wonder!

I thought DV was YUV colorspace? Why is Canopus ADVC using RGB24?

[Kool_Aid]

Wouldn't that depend on which DV codec you selected, or are you using the Canopus native DV?

[Wile_E]

Yes, thanks for pointing that out. I didn't even know codecs had different color output. I was using VirtualDub, but only had it on uncompressed output! DOH!

I now see an option, to output Canopus using standard 0-100 IRE. This is better.

[edDV]

Something is strange about this capture. DV and DVD MPeg2 call for black at level 16 and white at 235. Your original DV and all encodes show a Y (luminance) range of 0-255. I assume this is a timeline jpg cap?

Here is a reference SMPTE bar (Sony Vegas DV) showing level 16 at 0 IRE and level 235 at 100 IRE.



Here is a 7.5IRE ADVC-100 color bar recorded to VHS and then played back through the ADVC-100 with SW2 in 7.5IRE position. The color bar VHS playback is scaled properly to 16-235 (0-100 IRE for DV and MPeg2 scaling).



Now here is your orig1 showing 0-255 scaling for Y. Black is at blanking level, peak white extends above 235 (not unusual for peak white).

Was this rescaling done by Convolution3D or was the 7.5 IRE switch on the ADVC-300 in the wrong position? Also, does Convolution3D explain your RGB colorspace? I'm not familiar with that filter.

Added: Note that if this waveform is used to author a DVD as is, the DVD player will assume level 16 (0 IRE) is black. All the information below 0 IRE will appear below the analog NTSC black reference of 7.5 IRE and will be below black on your TV unless you adjust brightness. If you adjust brightness to make this look good, all other NTSC sources will look over bright unless you adjust brightness down. This would apply to composite, S-Video, component analog outputs plus any digital outputs



tmp1.jpg
TMPGEnc's Y looks very similar to the original.


cce1.jpg CCE's peak white is down about 3 IRE here but the spotlight is still near 81IRE. This may be intentional by CCE to contol "superwhite" (above 235) down.


p1.jpg
Procoder is showing seriously crushed blacks. Also whites are compressed upward. Note the spotlight that was at ~81IRE is pushed up to ~89IRE. The left wall highlight (midtone) remains at ~60 IRE.


Why not try it again without Convolution3D? Or try a before and after Convolution3D.

OK I'm done.

[edDV]

FWIW
I ran your orig1.jpg through the Vegas-Mainconcept encoder and got this.

[Wile_E]

I don't think I have VirtualDub set up correctly. Here is timeline cap from within Vegas Movie Studio 4. This looks better. But when I open the original DV file in VirtualDub, it is darker. VD sees the original DV file as RGB24 colorspace. Is this correct for Canopus ADVC hardware?

I tried setting VD to output to YUY2, but it didn't change a thing!

Vegas Movie Studio

[edDV]

Here is your Vegas Movie Studio 4 capture on the waveform monitor. Y is scaled properly between 16 and 235 (0-100 IRE).

It may be either the Convolution 3D filter or Virtualdub itself that caused the 0-255 scaling. I think the RGB24 is measuring Virtualdubs color space not the Canopus ADVC. The ADVC is feeding component YUV at DV levels if set properly.

RGB24 uses 0-255 scaling. To author a DVD, this must be converted back to YUV with 16-235 Y scaling. This should be done by the MPeg2 encoder ideally, but your encoder results don't show proper Y scaling to DVD spec.

I believe encoders must have settings to properly convert RGB24 inputs to DVD spec levels. Maybe some TMPGEnc, CCE or Procoder Express experts can offer advice.

[Wile_E]

Thanks for your help! With your help, I think I understand what's going on now.

1. VirtualDub is operating internally in RGB24 colorspace. It automatically converts DV YUY2 to RGB24 without telling the user. (I did not know that.)
2. Depending on your encoder, you have to select the colorspace output in VirtualDub correctly.
3. Then the encoder has to have an option to change the colorspace back to proper 16-235 Y scaling.

CCE- Select YUY2 output in VirtualDub. Then in the CCE program, select 16-235 luminance. I tested it, and it's output appears almost exactly to the original DV colors. It works.
TMPGEnc - Select YUY2 or RGB24 in VirtualDub. TMPGEnc seems to be smart enough to convert YUY2 or RGB24 to the right levels for DVD output.
Procoder Express - Has no setting to convert to proper 16-235 Y scaling. Only the more expensive Procoder 2.0 has that option. I contacted Canopus the other day, and they got back with me and said Procoder Express doesn't offer 601 or 709 colorspace corrections. Procoder Express is worthless to me, if it's not going to convert my DV AVI files to proper colorspace.

So with VirtualDub, at least one colorspace conversion is happening, (RGB24), the minute you open the file. This can't be avoided.

[edDV]

Thanks for testing those encoders. I've been wondering about the same issues.

I tend to stick to Mainconcept based encoders because I get consistant results across applications. Your work makes it easier for me to venture out into CCE and TMPGEnc for comparison.

PS: From my experience 80% of "color" issues relate to Y (luminance) levels be it the 16-235 issue or gamma. First you fix Y, then color correction is easy.

[Wile_E]

I found a link that explains Virtualdub's RGB24 support. It says, if you use the "fast-recompress" mode, instead of "full-processing", it will not convert to RGB24.

http://www.animemusicvideos.org/guides/avtechold/colorspace.html

[Wile_E]

edDV,

Your color bar output shows luminance of 0-100 for your color bar chart. But in the original DV capture, the range is usually about 5-110 with "auto gain" turned on. I have been using "Auto Gain" of the ADVC-300 in it's default position.

I am not sure why this is happening to auto gain. Canopus got the default setting wrong? I've tried several tapes, and all gain up to 110. Is 110 luminance considered safe, or clipping? Should I back it down a bit, until it stays within 100 IRE? When luminance is 5-110, the histogram spreads wider to 0-255. Otherwise if luminance is 0-100, the histogram is 0-230.

[edDV]

edDV,

Your color bar output shows luminance of 0-100 for your color bar chart. But in the original DV capture, the range is usually about 5-110 with "auto gain" turned on. I have been using "Auto Gain" of the ADVC-300 in it's default position.

I am not sure why this is happening to auto gain. Canopus got the default setting wrong? I've tried several tapes, and all gain up to 110. Is 110 luminance considered safe, or clipping? Should I back it down a bit, until it stays within 100 IRE? When luminance is 5-110, the histogram spreads wider to 0-255. Otherwise if luminance is 0-100, the histogram is 0-230.

I'll try to draw you a diagram of how I did it.

Are you talking about the color bar that the ADVC-300 creates or is the bar from your computer? How are you measuring the IRE? Is this measured from a captured source?

[Wile_E]

Here is an example, when turning on Auto Gain Control. Without AGC, the luminance is well under 100 IRE. Should I lower the AGC, so everything is below 100 IRE?

[edDV]

On the waveform monitor, black looks good. That dip below zero is an overshoot. White as you say is a bit hot at 105. This would encode 5% hot. Clipping would occur at 108 IRE.

What does it show with ADVC AGC off?

That vcr has issues. Is that EP playback?
I'd be interested in seeing the color bar with AGC off.

[Wile_E]

Here it is with Canopus ADVC AGC turned OFF. VCR doesn't have problems. It is Canopus ADVC-300 that has problems with it's AGC. When AGC is turned on, IRE goes above 100. Of course, there is a manual slider, that I can use to turn it down. Canopus maybe has defaults too high.

VCR is JVC 9911u, playback is SP mode with Auto picture control.

[edDV]

This white level is OK. AGC averages fields to make a best guess for gain. Best not to use it unless the source is wandering in levels.

Manual control is best for a TV recording. It's unlikely a TV broadcast will change levels during the program.

I wish my ADVC-100 had just a manual gain. Comcast levels vary +/- 5 IRE between channels.

[Wile_E]

UPDATE for those captures in my second post...
Those captures were made within VirtualDub. Apparently since VD works internally in RGB24, any still frame cap will look dark. VD is not compensating.

It is best to take a still-frame capture within an editor like Sony Vegas. I tried this again for all encoders....All encoders show correct levels! Including Procoder! You do NOT need that 601 conversion option for Procoder Express. It must do it automatically. So nothing is wrong with any of the encoders.

Procoder and TMPGEnc match exact colors to DV source. CCE still shows slight color difference. So basically, It was user error(my error), in using VD to make still caps. Always use video editor like Vegas to take caps.

[spectroelectro]

Fascinating topic. This set of posts has a lot of really good information in it.

[vhelp]

Now this, I disagree with

If you take a main capture source (from any source) and you proceed
to encode it through all the encoders at your finger-tips, and then
run them all through an anaylizer, they all should equal
the same results. But..

They won't. The reason are various..

One could probably be that the encoder(s) use a differnt setup of
algorithems in its formulas for:

* RGB to YUV conversion, or
* YUV to RGB and back to YUV conversion.

Another.. could be that the encoder(s) all use one form of pre-filtering
in its encoding process. An good example of this 'flitch' would be
in the case of Procoder. I've worked with this encoder, and I have found
that by default, it pre-filters the color space to darker (don't have
the word for it yet) and this is why I was stating that you have to
include the 601 filter (I can't remember the number off the top of my
head) and this gave a closest match, but not exact. Then, I went on
stating that the only encoder that I was sure of, that matched the
color space perfectly, was TMPGenc. I still agree to this.

The best TIP I can give is like this ...

If you are planning on capturing something, and you capture to YUVxx,
and you plan on running some filtering (ie, using AVIsynth) ..that you
should be sure that any filters you use does not require you to change
the color space (and, then back) ( ie, convertToYUY2() convertToYUV12()
and then back to convertToRGB() ) etc. because you are now changing
your sources color space. Then, when you bring it into your encoder,
(lets use TMPGenc for this scenario) and TMPGenc gets to it, it will
convert to RGB (if source is in YUY2 or YUY12, for instance) and there
is where you will have color space problems, hence your color balance
will not match, such as in the Procoder scenario.

If your final Capture Source color space is RGB ...

The tip is to NOT change any color space, and keep it in RGB, if you
are going to feed it inside TMPGenc for the final encoding.
But, remember NOT to change color space if you are working with AVIsynth
script filters. Many of them will only work in either YUY2 or YV12
color space, and will require you to use the convertToYUY2() or
convertToYV12() color conversion filters in order to use a given filter
for a job.. though some will work w/out any convertToxxx() filters.

I haven't made up my mind as to CCE 's usage.

I believe that with CCE, you are best to keep your source (if you captured
it in YUVxxx color space. From memory, CCE "will read" YUY2 color
space. But, I have found that you can feed CCE RGB color space too.

What is not noted for sure, is weather or not, CCE works in YUV color space
only. In other words, assuming that your source is YUVxxx to begin
with.. the question is asked, "does it convert to RGB, during its encoding
process, or does it process the YUVxxx source file in YUV space
throughout during its encoding process ??"
.
Or..
.
Does CCE work with a given YUVxxx source on a pre-bases only, then
does an RGB conversion, and finally encodes to YUV MPEG.

Note, the YUVxxx can be YUY2, or YV12, etc.

At the moment, I have not seen any "official" pappers/documents on this
matter w/ respect to CCE. Pretty much everything is speculation at best.
Theory is ok.. as I do that often too But, it does not account for
truth if it can't be proven or noted on "official" documents.

But, personally speaking from my own set of experiences (and wisdom)
I prefer to work in RGB space (that is, feed a given source as RGB) to
my encoder of choice, which just so happens to be TMPGenc to this date.

If I have noted/commented/stated anything in error, feel free to correct
or enlighten me on them. Thanks.

-vhelp 3501

[edDV]

@ vhelp

I guess the best way to summarize your point is to understand your tools and process. Ideally one should minimize color space conversions and understand how to make quality measurements for each color space.

I like to use the waveform monitor and vectorscope. The waveform monitor can quickly reveal the shifts in black and white levels (0-255 for RGB and 16-235 YUV) resulting from color space change. Ideally your picture monitor calibration would shift when changing color space but it doesn't. It's so easy to make eyeball "correction" adjustments that are inappropriate.

[vhelp]

>> I guess the best way to summarize your point is to understand your
>> tools and process.

Yes.

The less times you have to fiddle with color space, the better you are
left with your "original" source being closely reproduced after the
finishing touch of MPEG.

When you capture a given source to DV, it is already in YUV 411 color space.
When you open this format inside an editor, say vdub, (depending on the
codec that vdub calls for the decoding part) vdub's window will show a
YUV -> RGB color space conversion on-the-fly, during your panning from
left to right inside the video's timeline, hence your RGB darker looking
colors. At my current state of knowledge w/ vdub, it does not display any
video as YUV output. All codecs (using vdub or similar editor) will do
a YUV -> RGB conversion for displaying. The way I see it with vdub, it is:

source --> vdub -> vfw[codec] -> [conversion]RGB -> video window=RGB OUTPUT

When you play this same (captured) DV file inside something like,
Media Player, it will use DirectShow and play the DV file in YUV color
space, inside an Overlay window.. which is why you see the color space
looking brighter and even a little washed out.. but is normal for this
viewing mode, inside Overlay. (You can always tell if you are in Overlay
mode, during a certain video file playing, if you try to copy the screen
or window to the clipboard.. if it does not display the video's bitmap,
(just a black box) then it is using Overlay)
You can turn off Overlay for Media Player under properties and something
else setting, and it will display in RGB color space.

-vhelp 3503

[edDV]

>> I guess the best way to summarize your point is to understand your
>> tools and process.

Yes.

The less times you have to fiddle with color space, the better you are
left with your "original" source being closely reproduced after the
finishing touch of MPEG.

When you capture a given source to DV, it is already in YUV 411 color space.
When you open this format inside an editor, say vdub, (depending on the
codec that vdub calls for the decoding part) vdub's window will show a
YUV -> RGB color space conversion on-the-fly, during your panning from
left to right inside the video's timeline, hence your RGB darker looking
colors. At my current state of knowledge w/ vdub, it does not display any
video as YUV output. All codecs (using vdub or similar editor) will do
a YUV -> RGB conversion for displaying. The way I see it with vdub, it is:

source --> vdub -> vfw[codec] -> [conversion]RGB -> video window=RGB OUTPUT

I hope someone writes a YUV over IEEE-1394 monitoring plug-in similar to the features found in FCP, Premiere and Vegas. That way the same monitor can view source and timeline output for direct comparison using the same calibration. A waveform monitor would complete the package.

When you play this same (captured) DV file inside something like,
Media Player, it will use DirectShow and play the DV file in YUV color
space, inside an Overlay window.. which is why you see the color space
looking brighter and even a little washed out.. but is normal for this
viewing mode, inside Overlay. (You can always tell if you are in Overlay
mode, during a certain video file playing, if you try to copy the screen
or window to the clipboard.. if it does not display the video's bitmap,
(just a black box) then it is using Overlay)
You can turn off Overlay for Media Player under properties and something
else setting, and it will display in RGB color space.

-vhelp 3503

"which is why you see the color space
looking brighter and even a little washed out"

Overlay is not calibrated but generally shows brighter than RGB for YUV sources. "Washed out" can be either due to the source video or the overlay adjustments in display properties.

I've adjusted overlay settings off SMPTE and THX color bars but have never gotten as close a match through the NVidia or ATI cards as with IEEE-1394 DV monitoring through the camcorder or ADVC-100.