HDV downsample to SD DV?

[captinstefan]

Hello,

I'm about to buy the Canon XH-A1’s. I want to shoot and edit in HDV as opposed to SD DV.
I’m concerned as to the quality of downsampling from HDV50i to SD DV50i.
I heard stories that quality is not good depending on how it’s done.

I’ve tried with some sample Canon A1 .m2t clips I downloaded, direct from the timeline in Premiere Pro 2. It did look bad. Maybe I’m doing something wrong?

Any help would be appreciated.

Stefan.

[steve]

There has been correspondence on some web forums that the Mainconcept MPEG codec included in PPro2 does not always handle downsizing very well. Some say that the output is darker than the original, (have noticed this myself). Maybe it doesn't handle the CCIR 709 to 601 colourspace transformation very well.
Have a look at the Adobe forums.

Steve

[Alan Roberts]

That would be consistent with it ignoring the difference between the coding systems. Get those equations wrong and it looks awful. I started doing sums on that in 1988 and reported to the EBU and ITU that the adoption of 709 coding would be a minefield for the future.

[captinstefan]

Thanks for the swift reply.

A minefield it is!

So what are most of you using here when down converting?

If there's some methond that works well, I'd rather hear about it than spend more time experimenting.

[Alan Roberts]

Personally, I edit in Edius Pro4 and use Procoder. Works pretty well, although I;'ve not done the sort of analytical tests on it that I normally do on cameras.

[SimonMW]

Vegas 7 does the conversion very well.

[captinstefan]

Will ProCoder 2 handle HDV then? Do you use it as stand alone or from withing your NLE?
Will ProCoder 2 and Premiere Pro 2 handle the output of HDV, and downsample it to standard DV well?

[GlennChan]

I started doing sums on that in 1988 and reported to the EBU and ITU that the adoption of 709 coding would be a minefield for the future.

Why were the 709 luma coefficients adopted anyways? From my tests, the quality improvement is negligible. For 100% saturated/pure colors, 709 is better in greens while 601 is better for reds. For <<100% saturated/pure colors, both sets of luma coefficients look fine (709 is better, but not noticeably so).

2--Some images so that you can see the difference between the two sets of luma coefficients:

Original image / test pattern
http://glennchan.info/Proofs/forums/dvdoctor/text-test4.png

4:1:1 subsampled image, Rec. 601
http://glennchan.info/Proofs/forums/dvdoctor/tt4-601-601.png

4:1:1 subsampled image, Rec. 709
http://glennchan.info/Proofs/forums/dvdoctor/tt4-709-709.png

*The images were run through my prototype/custom/testing-use chroma subsampler. It's coded to do 4:1:1, which no HD formats use (although 3:1:1 and interlaced 4:2:0 are similar in performance). The subsampling used is simple area averaging filters [0.25 0.5 0.75 1.00 0.75 0.50 0.25]; Rec. 601 and Rec. 709 actually specify more sophisticated filtering, which will exhibit less aliasing and ringing (area averaging doesn't exhibit ringing); but many products don't use such sophisticated filtering.

3- According to Charles Poynton (I believe in his book), the Rec. 709 coefficients were adopted because they were better theoretically, without actually testing its performance in a demonstration system.

[Alan Roberts]

ITU709 uses, for the luma equation, coefficients from the centre line of the display matrix. When you do a full colour analysis of an imaging system, you derive a 3x3 matrix that relates the RGB values to XYZ (the CIE 1931 tristimuli). The centre line of that matrix , when expressed as a single equation, delivers:

Y = r R + g G + b B

where r g and b are scaling multipliers and Y is luminance (not the Y' luma signal used in TV). PAL, NTSC and SECAM all used the coeffients derived for the original NTSC primaries in the luma equation:

Y' = 0.299 R' + 0.587 G' + 0.144 B'

and in ITU601 for obvious reasons.

When ITU709 was being written, to account for new, HDTV and other, systems, there was a move to use a form of coding called "Constant Luminance", in which the luma signal we call Y' was made in the correct colorimetric way, and not in the traditional way. The correct way (for ITU709 primaries) would be to use the centre line of the matrix to form proper luminance:

Y = 0.2126 R + 0.7152 G + 0.0722 B

and then to pass that signal through a gamma-correction to derive the transmission signal (Y'). The problem is that the decoder would have to undo the gamma-correction to decode it, then thought hard but trivial now. The benefit would be that all the grey scale information travelled via the Y' channel, and only colour via the chroma channels. By contrast, using the trraditional coding method results in some grey scale information travelling via the chroma channels, in amounts that are proportional to saturation. When the chroma is low-pass filtered, the hf content is lost, and we get a softness in the picture in highyl coloured areas, a loss of detail and texture. I was pushing the use of CL coding, and it was adpoted as "for testing", which, i n ITU-speak, means "OK, have it you way, but we'll drop it anyway".

As a sop to those of us who thought it a good idea (and that means the EBU), ITU used the "correct" coefficients in the luma matrix:

Y' = 0.2126 R' + 0.7152 G' + 0.0722 B'

so luminance still travels via chroma, but the overall result is neither better nor worse, just different.

[GlennChan]

Well as you pointed out earlier Alan, it's worse when some manufacturers decode luma+chroma incorrectly, using 601 numbers (601 coefficients and associated scale factors) instead of the 709 numbers.

That's an interesting anecdote about CL coding, I guess that sort of explains it (?). Although if you were to adopt CL coding, the whole chain would have to be CL. And without CL coding, then there's not much point in changing the luma coefficients (?).

[Alan Roberts]

All correct :)

Although it makes some sense to have a CL channel but feed signals to it that have been standard-coded (and, obviously, transcoded into CL equation form for that purpose). Programme and channel titling would then be significantly sharper and would look better (it's in highly saturated colour transitions that CL has most to offer). Also, all colour keying would be better.

[Peter Lindsley]

Will ProCoder 2 handle HDV then? Do you use it as stand alone or from withing your NLE?
Will ProCoder 2 and Premiere Pro 2 handle the output of HDV, and downsample it to standard DV well?

Hi, did you get a reply to this question? I'm trying to do exactly as you mention but ProCoder does not list HDV as a source.