New experimental BT709ToBT601() color conversion filter

[trbarry]

Maybe I just should have posted this in the HDTV forum but it may also have some non-HD applications, so I'll post here.

Both DVD and HDTV are MPEG-2 files that can be handled by DVD2AVI, MPEG2DEC3, Avisynth, etc.

But HDTV material (or maybe regular material increasingly shot with HD cams) is usually using the BT.709 color space. And DVD's and SDTV usually use the BT.601 colorimetry. Most of us are apt to have our PC's more calibrated for the BT601 settings. These color spaces are very similar and mostly we have been ignoring the difference. But there is one.

For instance, see the interesting comparison samples on the Sigma Designs site (http://www.sigmadesigns.com/support/chromaticity_correction.htm).

Yesterday I wrote an Avisynth 2.5 filter that will convert from BT.709 (HDTV) to BT.601 (SDTV). You can see a side by side results image of running BT709ToBT601() at www.trbarry.com/BT709ToBT601.2.jpg .

This is only for Avisynth 2.5, only YV12, and currently requires a width multiple of 8. It assumes progressive (or deinterlaced) input so use after TomsMoComp or Telecide if needed.

Anyone interested can check out:
www.trbarry.com/Readme_BT709ToBT601.txt or
www.trbarry.com/BT709ToBT601.zip (source and dll)

This is only a first version so I'm not quite sure I've got the conversion numbers right (from "Video Demystified").

Pls let me know.

- Tom

[FreQi]

Very interesting. I'll have to give this a try with my HD recordings. I did notice that the colors were different from my analog tv caps, and I expected it to be so, but I wasn't aware that the process of SD->HDTV conversion inherently introduced (slight) color errors (although the colors are still better than analog).

And any estimates on what kind of speed hit you might take from encoding with this filter? (is it unnoticeable / fast / slow / deadly?)

[sh0dan]

After first glance on the source, it seems very fast! Or what I'd call "fast enough" - you probably wont notice it in your filter chain, if you're re-encoding the video.

@trbarry: You could easy get rid of the mod8 width requirement, by requesting aligned rowsizes - as far as I can see your filter output will not be influenced, even if there is junk in the "out of frame pixels".
A height that is non-mod2 is not possible anyway, so that shouldn't be a problem :)

[trbarry]

@trbarry: You could easy get rid of the mod8 width requirement, by requesting aligned rowsizes - as far as I can see your filter output will not be influenced, even if there is junk in the "out of frame pixels".

Sh0dan -

Excellent idea!

Now, uhhh, refresh my memory how this works again? ;)

I remember we discussed it but I was never sure exactly how that was implemented. Is there a performance penalty for requesting that? I'd need to guarantee luma size (or pitch) of mod 8 and chroma size (pitch) of mod 4.

I have to go back in and add proper rounding anyway so this is a good time to make other changes.

- Tom

[trbarry]

Another note here. I've heard that some NTSC->PAL conversions seem also to have a similar color shift. Nobody knows yet if HD Cam material may be sneaking into regular SDTV and causing this. So it's still just speculation at this point.

But it might be an interesting experiment for anyone experiencing a color shift similar to the pics above.

- Tom

[sh0dan]

@trbarry: You seem to remember it worse than it is :)

Anyway, it is mod16 for luma and mod8 for chroma!
(as you've written in your sourcecode :) )

Change:
rowsize_Y = dst->GetRowSize(PLANAR_Y); // Could also be PLANAR_Y_ALIGNED which would return a mod16 row_size

into

rowsize_Y = dst->GetRowSize(PLANAR_Y_ALIGNED);

And you will always recieve a width that is mod16. That's all you have to do!

[trbarry]

rowsize_Y = dst->GetRowSize(PLANAR_Y_ALIGNED);

Gosh, I suppose I could deal with that okay. ;)

Still, a useful idea.

- Tom