Fixing NTSC DV 4:1:1 Chroma Problems [Archive]

trbarry

26th July 2003, 15:45

I'm not aware of one but I did post a few months ago about how Avisynth resize could be speeded up somewhat in the case where both the H & V dimensions were both being resized. This would be done by slightly integrating the H & V resize steps to avoid some conversion steps and temporary results.

But I don't exactly remember the details or where the post is.

- Tom

JohnMK

27th July 2003, 09:47

Benchmarking on a hyperthreading P4 shows lanczosresize is pretty much identical in CPU usage as bicubicresize.

sh0dan

27th July 2003, 11:09

I have spend a _lot_ of time on the resize filters, as they are very widely used, and I cannot see any way of gaining more speed without sacrificing quality. The dynamicly compiled YV12 (horizontal) resizer should be as fast as it gets.

As trbarry suggests a combined horizontal/vertical resizer might speed up things - however there are several things that make me doubt it would be faster.

1) Very bad cache performance - it would require massive lookup tables, and make data access very scattered. We would no longer be able to unpack data and keep it in cache, as we do with the horizontal resizer.

2) Complexity - it will make the algorithm quite complex with a lot of loop overhead.

@Fred: Where did you get the idea that there should be something faster?

FredThompson

27th July 2003, 13:13

@sh0dan

Not that it SHOULD be any faster, I was wondering if it COULD be any faster.

I'm wondering if there's a way to speed this up:

LanczosResize(1440,480).MergeChroma(ConvertToRGB().BilinearResize(180,480).BilinearResize(1440,480).ConvertBackToYUY2()).ConvertToRGB().LanczosResize(720,480).ConvertBackToYUY2().

trbarry

27th July 2003, 14:43

As trbarry suggests a combined horizontal/vertical resizer might speed up things - however there are several things that make me doubt it would be faster. ...

Sh0dan -

I found the old thread. What I was actually proposing was what we talked about here (http://forum.doom9.org/showthread.php?s=&threadid=34866&highlight=resize+and+horizontal+and+vertical).

At the time I thought you were partially agreeing with me but that was way back last fall and I know you've done a bunch of optimizing since then. And I haven't looked at the code since.

- Tom

JohnMK

27th July 2003, 21:49

Let's say you've got a 720 x 480 DVD and you crop to 704x464, and resize to 704x304, will this be faster since you're only resizing in one direction? If there's a difference, is it marked or marginal?

FredThompson

27th July 2003, 22:41

The fragment I posted is a modified version of Xesdeeni's correction for NTSC DV chroma bleed. In this particular case, the resizing is done in both directions because the double interpolation all but removes the problem of one chroma value for 4 adjacent pixels. I'm wondering if there is a faster way to do this. My hunch is the biggest return would be optimizing the resizing process. If it's already optimized about as much as it can be, ok.

wrt cropping and resizing DVD source, sure, the fewer processing steps, the faster processing can be completed. Your scenario is quite a bit different from what I'm working on. Good point, though.

trbarry

28th July 2003, 04:17

BTW, I think my SimpleResize is probably still the fastest by a bit. But it doesn't smooth much.

But if you just want to fuzz up the chroma a bit would it help if I made a version of UnFilter that can operate just on chroma? UnFilter already has separate filter parms for horizontal & vertical and for 4:1:1 I guess you only want a fast horizontal smoother.

- Tom

FredThompson

28th July 2003, 05:34

You know, that just might be fantastic. The problem we're seeing is a grid-like pattern that's annoying as all heck. You can see an example near the top of this page: http://www.geocities.com/fredthompson6 (the area which compares Canopus DV and FlyVideo) and Xesdeeni's script and screenshots are in this thread: http://forum.doom9.org/showthread.php?s=&threadid=57013 and this website: http://www.geocities.com/xesdeeni2001

Xesdeeni's original script worked on luma and had a softening effect. IanD did a tremendous amount of experimentation and we've finally settled on Lanczos chroma-only.

The grid pattern seems to have a vertical aspect as well.

If you are willing to give it a shot, sure, let's see if there's another way. This problem is going to be common to anyone using DV as an NTSC capture codec so any advancement helping to correct this would help quite a few people.

I haven't tested unfilter on this problem. After two weeks of tweaking and testing and comparing notes, my head is still swimming.

trbarry

28th July 2003, 11:51

I don't have time to study it properly this morning but it occurs to me that interlaced 4:1:1 to interlaced 4:2:0 would be a horrible color converson, easy to screw up. It would lose color info even in the best case. Maybe going first to YUY2 and deinterlacing there might be better?

Anybody know how this data is entering Avisynth and what codecs are converting what? I may also be working with some DVcam data soon so I'll check this later today. I'm not sure a modified UnFilter is the best solution by itself.

- Tom

sh0dan

28th July 2003, 15:21

I'm sorry - time is quite sparse right now - so a quick answer:

@Fred: This is to be expected - sharper resizer = more aliasing. No way around that. It is hard to give a universally best resize algorithm. I usually go for either lanczos (clean, not sharpened material) or neutral bicubic. Never sharp bicubic, as it tends to have a bigger tendency at aliasing.

I hope to get time to look more closely at Xesdeeni's tests. In my head a pointresize downscale and a lanczos/bicubic upscale for chroma would make the most sense - not sure if the pointresizer is precise enough though.

If speed is a problem you might try:

v = Avisource()
chU = utoy(v)
chV = vtoy(v)
# resize these two
YToUV(chU, chV, v)

Instead of mergechroma (which will make the resizer work on the full image size). This should make it between twice and 4 times as fast. D*mn - I'm good at optimizing the resizer! :)

Btw, moved thread to where it belongs.

trbarry

28th July 2003, 15:49

Fred -

I don't have any DV/4:1:1 files to play with. Could you post about 10 frames with that red ray somewhere?

- Tom

trbarry

28th July 2003, 16:04

sh0dan -

Hope you are still around for the moment.

IIRC, for Avisynth 2.5 we (you) went to a lot of trouble making sure we preferentially get YV12 input into Avisynth instead of YUY2. For MPEG-2 or MPEG-4 data that is a very good idea.

But for 4:1:1 data that would be a very bad idea. Is Avisynth getting 4:1:1 data as YV12 4:2:0? And does it have to?

- Tom

FredThompson

28th July 2003, 16:16

@sh0dan, thanks, we'll give it a whirl.

@trbarry, IanD has shipped a CD to me with test clips. I doubt it will be here by tomorrow and I leave on Wednesday for a week. I'll ask him if there's a quicker way to get me a few test frames. The challenge is he's in Australia and has a monthly bandwidth cap.

Any improvement in speed/quality would be fantastic. If it can be done for both progressive and interlaced great. Interlaced could always be split into 2 streams for processing then woven back together.

FWIW, there are 3 really good test clips from the Star Wars laserdisc:

1) The opening scene where the Imperial ship shoots a red light beam weapon at the fleeing Rebel ship.
2) Red light reflecting off R2D2's "head" when Princess Leia puts a memory card in him.
3) A blue light ring "stunning" Princes Leia.

Don't remember if he's also sending me one of C3PO and a bunch of colored panel lights.

sh0dan

28th July 2003, 16:19

trbarry: Of course! (How silly of me to miss that one) 4:1:1 should preferable be YUY2, and remain so - at least until chroma is finished.

The functions i describe above does NOT support YUY2, but they should. When I get my new computer up, I will hopefully soon be able to make the additions, so users are able to also extract/merge U/V from YUY2 material.

trbarry

28th July 2003, 17:00

trbarry: Of course! (How silly of me to miss that one) 4:1:1 should preferable be YUY2, and remain so - at least until chroma is finished.

Not sure I understand here. If Avisource can actually get the 4:1:1 data before any other conversions then it should be easy to make a decent YUY2 version of it. It would only need to be re-arranged and horizontally averaged to make up the missing chroma pixels. 4:2:2 is happily a proper superset of 4:1:1.

I was worried that it was also being converted to YV12, thus again losing half the chroma resolution (down to 1/8), this time in the vertical direction. I would avoid that like the plague, at least until we had a chance to deinterlace it and gain back some vertical chroma resolution.

Of course it's probably going to be eventually converted to 4:2:0 MPEG-4 anyway but we don't want to lose any more before we have to.

I won't do anything now if it can just be fixed in the input routines but it would be very easy to write a very quick optional filter that assumed the chroma had been interpolated on input by nearest neigbor, and fixed it. That is, assume it had not been cropped and that every other horizontal chroma pixel was more or less a duplicate. Ignore those odd (starting from 0) chroma pixels and re-create them from an average of their 2 left and right neighbors, which we assume were the originals. I think this should work. ???

- Tom

sh0dan

28th July 2003, 18:32

I don't think any DV codecs deliver as YV12 - I only know of YUY2 capable codecs. The missing chroma in YUY2 is probably a 50/50 of the two neightboring pixels - if not a copy (which obviously gives lower visual quality).

trbarry

28th July 2003, 19:44

if not a copy (which obviously gives lower visual quality).

sh0dan -

I got the impression from some of the links above from some of the links above that some of the 4:1:1 codecs were doing just that, just making copies instead of 50/50 averages. That's what my suggested filter would fix.

And I think you are saying that Avisynth always first sees the data as YUY2, right?

- Tom

FredThompson

29th July 2003, 03:36

I've just uploaded 2 10 frame samples.

http://www.geocities.com/fredthompson6 The site has an hourly bandwidth limit. If you can't get there, wait an hour or so. The site will come back up.

These are interlaced NTSC DV captures by the Canopus ADVC-100 from the Star Wars laserdisc.

@TRBarry, do you think your idea will work for interlaced as well?

FredThompson

29th July 2003, 05:03

IanD just sent me two more samples. One is Princess Leia's hand inserting a memeory card into R2D2. There's a red light reflecting on his "head." The other is C3PO next to a bunch of panel lights.

I can't promise to have these up before I leave Wednesday morning but I'll try to get it done.

trbarry

29th July 2003, 15:25

Well, I've got the first 2 samples but the only way I've been able to look at them so far is with the DirectShowSource using (probably) the M$ codec. It looks like I have to go codec hunting.

Any suggestions which codec to focus on first?

- Tom

trbarry

29th July 2003, 15:36

@TRBarry, do you think your idea will work for interlaced as well?

It would not help whatever mistakes a codec might have made vertically. Theoretically they should not have made any if they went from 4:1:1 to 4:2:2 cause there is nothing really to do vertically. But some of those other threads suggest problems have been seen so I really don't know yet.

If Avisynth asked for it could those codec just pass data in a 4:1:1 format and let Avisynth convert it to 4:2:2 on input? It seems like such a fast simple conversion that I'm sure I don't really understand the problems yet. ;)

- Tom

cweb

29th July 2003, 16:45

Is this just an NTSC DV problem or does it occur with PAL DV too?

I can't say I've seen it with PAL DV and Lanczos, at least so far..

FredThompson

29th July 2003, 17:13

@trbarry,

The only free DV codecs I know of are the DirectShow and Canopus read-only one. Canopus won't do full-range luma. There is an old one from Panasonic available but I don't know the legal status. MainConcept has a demo, maybe Avid does as well.

@cweb,

PAL DV has a similar problem: http://www.hometheaterhifi.com/volume_8_2/dvd-benchmark-special-report-chroma-bug-4-2001.html

jorel

29th July 2003, 18:04

FredThompson

link to freeware video codecs,...sometimes is "out of service"
but is very complete!

http://mirror01.iptelecom.net.ua/~video/

http://www.kmstudio.com.ua/video/codecs.htm

:)

Xesdeeni

29th July 2003, 19:27

Fred, the ugly script I posted was really just a "proof-of-concept." It should be relatively simple to create a filter that will do the same thing without all the filter trickery. An actual interpolation would probably be a bit better.

But one problem is that you can't interpolate across 4 chroma samples in YUY2 (4:2:2) color space, because there are only 2 chroma samples, not 4. In the VirtualDub codec I wrote, I used RGB (I had to, VD only supports RGB), and converted it internally to 4:4:4 (actually 4:4:4:4), did the interpolation, and then went back to RGB. Something similar would have to be done in an AVISynth filter, since 4:4:4 isn't supported.

However, you should realize that if the destination is YV12 (4:2:0 for MPEG), then you will undo part of your smoothing when you encode the resulting image. Instead of 1 chroma for every 4 lumas horizontally (4:1:1), you'll have 1 chroma for 4 lumas in a square (4:2:0). But they'll all share the same chroma. Just like the DV codecs, if the decoder you use replicates and doesn't interpolate, you'll get 4 pixels with the same chroma, although in a square instead of a line.

Xesdeeni

trbarry

29th July 2003, 19:53

I don't think there is much point in interpolating to get 4:4:4 unless you are actually going to store it that way. It maybe would look better in vdub RGB preview but that's really all that's gained.

But creating the best 4:2:2 and subsequently 4:2:0 is still needed.

And for those helping, I found the Canopus & MainConcept codecs. That should be enough for testing for now.

- Tom

FredThompson

29th July 2003, 20:06

@xesdeeni, yes, I understand.

FredThompson

31st July 2003, 04:20

@trbarry,

Am I correct that you plan to pull 4:1:1 then interpolate the chroma? IOW, bypass the codec's attempt to do so?

I ask because the codecs all seem to take a different approach and preventing them from "breaking" the chroma in the first place seems like a good idea.

Xesdeeni

31st July 2003, 13:14

Fred,

Take a look at the sample pictures mentioned above (http://www.geocities.com/xesdeeni2001/: "4:1:1 Comparison"). The codecs mentioned above, MainConcept and Canopus, both seem to do the same thing. Namely, they replicate the chroma across all 4 pixels. Neither interpolates. Almost anything would be better than that :)

Xesdeeni

FredThompson

31st July 2003, 15:28

I ask because I've heard the Sony DV codec doesn't show this problem but does mess up luma.

trbarry

31st July 2003, 16:13

Am I correct that you plan to pull 4:1:1 then interpolate the chroma? IOW, bypass the codec's attempt to do so?

Fred -

This is maybe a last resort, but would certainly work if the codecs will even deliver as 4:1:1. But I don't know yet if that much will be needed anyway. I'm busy selling my house and moving so I don't have as much time for this right now.

However if the main problem is just horizontal pixels being replicated then I'll at least provide a quickie filter that does a re-convert to YUY2 properly since that is very simple to do using either a linear or cubic horizontal interpolation. And no data would have been actually lost in duplicating chroma pixels to YUY2 as long as we knew what happened. (and didn't crop or resize first)

However if the problem is at the time of the original 4:1:1 compression I don't know at all what to do about it. There is an inevitable chorma loss in first decimating 4:1 horizontally for 4:1:1 and then again in a square pattern for 4:2:0 MPEG-2/4.

That would be like trying to put a straight MPEG in a square hole. ;)
<bad pun>

Dunno yet.

- Tom

trbarry

31st July 2003, 19:09

Well, it was easier to just write a quickie filter and see what it does. It seems to help, at least for the horizontal dup problem.

I've only tested with the MainConcept decoder so far, with Fred's data. But it does seem that even chroma pixels are just being duplicated in that codec. The new filter will help that by discarding the odd chroma pixels and recreating them as the average of the 2 adjacent even pixels.

It doesn't matter whether the material is interlaced. There are no parms, only Avisynth 2.5 YUY2 supported. Probably use it right after Avisource as:

ReInterpolate411()

Try the new barely tested test version from:

www.trbarry.com/ReInterpolate411.zip (source but no readme included)

As always, let me know if I obviously screwed up somewhere.

- Tom

FredThompson

31st July 2003, 19:20

Cool. I'm literally walking out the door and won't be back for a week. I'll ask IanD to test this. Thanks.

trbarry

1st August 2003, 01:01

I already found a silly bug that would make things look uglier than needed. If anyone is testing this please download v 0.1.1 from the same loc:

www.trbarry.com/ReInterpolate411.zip

- Tom

IanD

1st August 2003, 07:03

Originally posted by trbarry
Well, it was easier to just write a quickie filter and see what it does. It seems to help, at least for the horizontal dup problem.

I've only tested with the MainConcept decoder so far, with Fred's data. But it does seem that even chroma pixels are just being duplicated in that codec. The new filter will help that by discarding the odd chroma pixels and recreating them as the average of the 2 adjacent even pixels.

Tom,

The Canopus and Mainconcept DV decoders appear very similar in that they both produce the chroma bug for 4:1:1.

Have now tried ReInterpolate411() on a Canopus software DV decode of the material I sent to Fred Thompson and it does seem to fix the chroma bug.

However, when comparing the Canopus decode and the reinterpolated version of the Star Wars laser blast space scene as bmp enlarged to 1600% (to make the pixels visible) and flipping between the two, the laser blast seems to move left by 2 pixels even though the white rocket engines remain more or less in the same positions.

I have noticed a similar effect when comparing the Panasonic and Canopus decoders: one will have a slippage of a few pixels compared to the other.

Could this be a result of the different decoders (and your interpolation) applying interpolation in opposite directions (if that makes any sense)?

Anyway, ReInterpolate411() at least removes the obvious chroma bug problem and brings the decode back to a quality similar to the Sony decoder (which doesn't have the chroma bug but which shifts the brightness upwards).

Each decoder seems to do something different to the original DV image.

So far I haven't found a way to view the original DV source without the influence of decoder peculiarities. Even using Directshowsource in Avisynth (to make use of the inbuilt DV decoder in windows as comparison) seems to return only a 320x240 image and I can't find an option to supply the full 720x480.

Ian

trbarry

1st August 2003, 13:40

However, when comparing the Canopus decode and the reinterpolated version of the Star Wars laser blast space scene as bmp enlarged to 1600% (to make the pixels visible) and flipping between the two, the laser blast seems to move left by 2 pixels even though the white rocket engines remain more or less in the same positions.

IanD -

I think the Canopus and Main Concept decoders duplicate the left (even) chroma pixels. In YUY2 this effectively moves the chroma image 1 (YUY2) chroma pixel (2 luma pixels) to the right. So hopefully ReInterpolate411 is just putting it back.

- Tom

trbarry

1st August 2003, 13:50

So far I haven't found a way to view the original DV source without the influence of decoder peculiarities. Even using Directshowsource in Avisynth (to make use of the inbuilt DV decoder in windows as comparison) seems to return only a 320x240 image and I can't find an option to supply the full 720x480.

I actually don't use DV yet and am not an expert on it. But I'm almost certain I've heard this problem discussed before. Just don't remember where. IIRC, there is something in the DXSDK that let's you get around this somehow but I think the discussion was on AVS HTPC Forum and probably over a year ago.

- Tom

FredThompson

10th August 2003, 04:17

Hey, Tom, you're famous!

This filter showed up on one of the links sites I monitor:

http://stupid.mine.nu/~d2lzinfo/main.html

Look at the entry for 8/1-3

trbarry

10th August 2003, 16:20

Hey, Tom, you're famous!

I don't think finding a single link somewhere really counts towards my 15 minutes of fame. ;)

But it's nice to know someone thought it was useful enough to post it. And I admit that I do get a kick out of Google'ing "trbarry" and finding a lot of foreign languange pages that seem to be talking about my filters, even if I have no idea what they are saying.

- Tom

r6d2

10th August 2003, 17:05

Originally posted by trbarry
And I admit that I do get a kick out of Google'ing "trbarry" and finding a lot of foreign languange pages that seem to be talking about my filters, even if I have no idea what they are saying.
Well, in this case at least, Babelfish from Altavista says that the presumed japanese "smilies" which appear on this text:

ReInterpolate411 v.0.1.1BAvisynthƒvƒ‰ƒOƒCƒ“B

translate into: "Plug in" :)

Regards,

Edit: vBulletin does not seem to like japanese smilies. It converted them into something else more like Einstein's equations. :D