Adaptive chroma upsampling

[scharfis_brain]

@mantis2k:
I suggest this script for a Pulldown Conversion from PAL to NTSC:
loadplugin("D:\x\dgdecode.dll")
loadplugin("D:\x\decomb.dll")

mpeg2source("man.d2v")

# crop away black borders
crop(0,72,0,-96)

# match fields
telecide(order=1,guide=2,post=0)

#shift chroma and remove chroma flicker
mergechroma(crop(0,4,0,0).addborders(0,0,0,4).blur(0,1))

# convert image size to NTSC
converttoyuy2()
last.lanczosresize(last.width,round(last.height/1.2))
addborders(0,ceil((480-last.height)/2),0,floor((480-last.height)/2))

I think this is enough filtering.

[Guest]

@scharfi,

Isn't it better to do the color space up conversion in MPEG2Source (using upConv=true), where you can be sure you are doing the correct upsampling on the original encoded MPEG2 pictures? It's perhaps a small point, but worth noting.

[Carpo]

If it's 3:2 pulled-down material, you can just do IVTC first and then do the traditional 4% speedup. What kind of material are you talking about?


bit of all sorts really animation mainstream films and the such - just wondered how it would be done so i could mess about and see if i could get the hang of it as there has been a few ntsc films my uncle has brought with him on visits fromt he states (he lives there now) that my standalone has an issue with - was wondering if converting it to pal might solve the issue

[scharfis_brain]

since I am SURE, that I have a progressive image after telecide, I can upconvert it progressively after teleciding with a simple converttoyuy2().

also, I don't think, that relying on the frametype alone for upconversion is so good (but it is a starting point...).
I've seen several DVB-S streams where the image content was interlaced, but the image was coded progressively (motion probably was und a certain threshold).

In past I've done some motion adaptive YV12<->YUY2 conversions for hybrid video:
http://forum.doom9.org/showpost.php?p=618364&postcount=1

of course, for this video those routines will probably fail due te big imperfection.

[Guest]

The flags reliably state how the video was *encoded*. And that is how the upsampling should be done at the time an MPEG picture is decoded. Whether the *content* is actually progressive is irrelevant.

I think your idea that since you've decombed you can now treat it as if it was *encoded* progressively is a misconception. Think about that carefully, please.

[scharfis_brain]

An interlaced encoded progressive PAL-movie is better upsampled progressively.

interlaced downsampling of progressive frame contents can be
upsampled progressively without drawbacks.

Have I written drawback?
upsampling interlaced mpeg2 with progressive video in a progressive way enhances chroma quality!

one can do so, because the inventor of YUV 4:2:0 has wisely choosen the position of the sampling points.
They are the same for interlaced and progressive. Only their origin is different.

[Guest]

We'll have to agree to differ. I am giving the correct MPEG2 theory. You are giving unsupported claims.

It is not correct that the sampling points for interlaced and progressive encoding are the same.

I remind you that quality DVD players that avoid the chroma upsampling bug all follow the progressive flag and upsample per MPEG2 picture.

I will try to prepare a demonstration that illustrates the perils of not upsampling at picture decode time.

[Guest]

bit of all sorts really animation mainstream films and the such - just wondered how it would be done so i could mess about and see if i could get the hang of it as there has been a few ntsc films my uncle has brought with him on visits fromt he states (he lives there now) that my standalone has an issue with - was wondering if converting it to pal might solve the issue The method to use is going to depend on whether the material is 3:2 pulled down, video, or field-blended. You can show us a clip of one that you'd like to convert and we can advise you. But not in a thread about PAL --> NTSC. Please start a new thread.

[scharfis_brain]

how can I convince you?

EDIT: I have several interlaced encoded movies, that look MUCH better using progressive upsampling than interlaced upsampling.

also, I claim that motion adaptive upsampling of real interlaced content looks better than plain interlaced upsampling.

According the this page, the chroma sampling points are located in the SAME spatial position for interlaced and progressive YUV 4:2:0:
http://www.mir.com/DMG/chroma.html

[Guest]

how can I convince you? Let's take it offline and then we'll come back to the thread with our conclusion. First, I'll prepare and send you a PM with my position. Please standby. It'll come this weekend, but not immediately as I've to go pick up some drugs for my dad and then I'm off to the pool. :)

I read your argument as that the method may not be fully correct per MPEG2, but it has useful side effects that may improve matters in some cases. I can accept that in principle, but I'd like to see a specific example if you can provide one. And I'll try to give a counter example. It may be yet another case where the nature of the content is the determining factor. But let's do it offline. Thanks for engaging in this with me. I always learn a lot from our interactions.

[Guest]

According to this page, the chroma sampling points are located in the SAME spatial position for interlaced and progressive YUV 4:2:0: But they come from different fields in the original full resolution image that was sampled. So they need to be recreated in the same way. That's the whole point. But can we please take it offline as I suggested, because I think we may be having some terminology differences as well that will just confuse things for people. We can come back with a clear analysis. Is that OK?

[scharfis_brain]

We can come back with a clear analysis. Is that OK?

This is fully okay.
I also have to leave now.

EDIT: could you split this thread in a way, that our chroma-discussion is located in a new thread?

[mantis2k]

You're showing your lack of knowledge again. The best players analyse the video to determine the appropriate mode of decombing to use. So they do "know about" the nature of the source video.
In that case, the deinterlacing software should also be able to analyse the source when converting to progressive. I shouldn't need to know anything specific about my DVD video.

Like me, he hasn't the time to repeat existing explanations for every newbie that arrives wanting to be spoonfed.
I'm not asking for a big explanation. He could atleast say which software each script/function uses, to put them into context. He's just being lazy, and I doubt English is his native language either.

Within the domain of this site and it's history, his comments are very well placed in context.
Not everyone who visits this site is a part of the board's history. Your comments are bordering on elitism.

loadplugin("dgdecode.dll")
loadplugin("leakkerneldeint.dll")
MPEG2Source("kungfu.d2v",upConv=true)
leakkerneldeint(order=1,threshold=0)
You're getting ahead of yourself again, like Mr. Brain. Correct me if I'm wrong, but I assume you're biased towards AviSynth, which in turn uses TMPGEnc? Well, TMPGEnc is not the best MPEG encoder on the market, and downgraded my video last time I tried it, making it appear too bright. Anyway, I'm willing to give your scripts a try, so can you please tell me how to use them? If it's too much trouble, just give me a link to a guide/tutorial...

@mantis: why are you capturing to lossy MPEG2?
I'm capturing to DVD, which in turn uses MPEG2 video streams.

the video is blocky and totally smoothed.
That's because it's from a rare VHS tape, which is not original or the best of quality to start with.

loadplugin("D:\x\dgdecode.dll")
loadplugin("D:\x\decomb.dll")

mpeg2source("man.d2v")

# crop away black borders
crop(0,72,0,-96)

# match fields
telecide(order=1,guide=2,post=0)

#shift chroma and remove chroma flicker
mergechroma(crop(0,4,0,0).addborders(0,0,0,4).blur(0,1))

# convert image size to NTSC
converttoyuy2()
last.lanczosresize(last.width,round(last.height/1.2))
addborders(0,ceil((480-last.height)/2),0,floor((480-last.height)/2))
Wow, I didn't realise you guys had the time of day to insert comments into your code! :p

Thanks for all your help so far! However, I don't wish to muck around with the boarders!? Surely, the picture would look the wrong aspect ratio when authored back to DVD?

[Guest]

He's just being lazy...

You're getting ahead of yourself again, like Mr. Brain.

Wow, I didn't realise you guys had the time of day to insert comments into your code! You've just crossed the line, mantis2k. We're trying to help you and you respond with insults. Please see forum rule 4. Thank you.
:readrule:

[Guest]

could you split this thread in a way, that our chroma-discussion is located in a new thread? I can't do it because I'm not a moderator on this forum. We can resume in the Avisynth development forum if you like.

[mantis2k]

You've just crossed the line, mantis2k. We're trying to help you and you respond with insults. Please see forum rule 4. Thank you.
:readrule:
No need to feel insulted! Noticed the smily I used after my comment, indicating that I was joking being sarcastic... If I've violated a rule then you've also violated the same rule several times, by some of your comments towards me.

[mantis2k]

scharfis_brain (copied and pasted),

Do you personally feel insulted that I referred to you as Mr. Brain because I couldn't remember the first part of your nickname?

[communist]

I'm not asking for a big explanation. He could atleast say which software each script/function uses, to put them into context. He's just being lazy, and I doubt English is his native language either.
AviSynth + mentioned external plugins which can be found here:
www.avisynth.org
Also his explanations make totally sense to me and my native language isnt English either :p

You're getting ahead of yourself again, like Mr. Brain. Correct me if I'm wrong, but I assume you're biased towards AviSynth, which in turn uses TMPGEnc? Well, TMPGEnc is not the best MPEG encoder on the market, and downgraded my video last time I tried it, making it appear too bright. Anyway, I'm willing to give your scripts a try, so can you please tell me how to use them? If it's too much trouble, just give me a link to a guide/tutorial...
Yes you're wrong - AviSynth has nothing to do with TMPGEnc. TMPGEnc is an MPEG Encoder, AviSynth is a frameserver using a scripting language that can be easily learned. For an overview / manual how to use AviSynth have a look at the abovementioned link.

I'm capturing to DVD, which in turn uses MPEG2 video streams.

That's because it's from a rare VHS tape, which is not original or the best of quality to start with.
Capturing lossless or *almost* lossless would have saved you from the blocks introduced by the real time encoder used in your DVD recorder and would allow for some cleanup and improved picture that you could have encoded to MPEG (for DVD).


Thanks for all your help so far! However, I don't wish to muck around with the boarders!? Surely, the picture would look the wrong aspect ratio when authored back to DVD?
Hence they added the AddBorders (http://www.avisynth.org/AddBorders) command to AviSynth ;)

[mg262]

Can I add to @communist's answer:

If you're working from VHS, please read the analogue capture guide; it tells you, among other things, that AVISynth is unrelated to any encoder, that capturing in MPEG is (to put it mildly) not the preferred method and, perhaps of more use to you at the moment, exactly how you should preserve the aspect ratio. I believe it also has an introduction to using AVISynth in it.

Out of curiosity, may I ask what you are capturing? (Preservation of old tapes -- mainly children's programmes! -- being my main interest.)

Grrr.. the speech recogniser posted this before I was finished again. I wanted to say one other thing, which is that in a limited medium like this, it can be very hard to read the tone of people's posts. So it is best to try and make sure that there is absolutely no way that your comments can be interpreted as being aggressive, sarcastic or critical unless that is really what you intend (and if that is really what you intend then you would be better off starting flame wars on USENET). Something to bear in mind is that, despite the fact that they have answered these questions literally hundreds of times, @scharfis_brain and @neuron2 still seem to take the time to keep answering them... so it is if nothing else more polite to say 'I'm sorry, I really didn't understand that, could you give me an idea of what terms to search for so I can' rather than that something 'makes no sense to the average person'.

[scharfis_brain]

@neuron2: Did you've got some time to check my claims?

[Guest]

@scharfis_brain

Sorry, not yet. Can you supply a clip that demonstrates your point of view, i.e., one that is encoded interlaced but looks better when upsampled progressively after deinterlacing?

[scharfis_brain]

have a look on your FTP.

There I've placed a m2v & a avs file demonstrating the difference between

dumb interlaced upsampling
dumb progressive upsampling
and
motion adaptive upsampling

[Guest]

have a look on your FTP. What is fc.avs and where do I get it?

Please state what the results are according to you for the three methods.

[Paulcat]

Mantis2K: Considering the pool of knowledge represented by a small group of people, it's easy to feel pretty dumb here. Of course, since they have had to answer the same questions over and over, they tend to get sarcastic themselves.

Considering your original question, what I would do is separate your audio and video (from the dvd) into separate streams (DVD Decrypter will do it quite efficiently). You can load your *.M2V file into tmpgenc and reprocess it, all you really have to do is re-size it, and leave the framerate at 25fps (assuming a PAL source). To check if the video is interlaced, look under SETTINGS, ADVANCED and double click on DEINTERLACE. You can turn off the filter and look at the image to see if there are interlace lines (will be obvious!), then you can choose odd field or even field and activate the filter.
(Make sure you encode as non-interlaced!!)
When you are done, you will have a 25fps progressive 720x480 *.m2v file. Run that through DGPulldown to change the 25fps to 29.976 and use your favourite dvd authoring tool to re-multiplex your original audio and your new video file, and, voila!

[scharfis_brain]

@neuron2: whoops. I forgot to delete those lines.


just knock out all this fc() stuff.
it is just a framecache.

then, when the script is running, you should clearly see, that

- progressive upsampling brings far more detailed static chroma but destroys interlacing
(similar, as if I would resize interlaced video without progressive treatment!)

- interlaced upsampling reduces detail of static areas (toally jaggy, do a zoom to get a 1st-time impression!) but leaves chroma-interlacing intact
(similar, like stupid interlaced resizing of progressive video)

- motionadaptive upsampling combines the advantages of both sampling type.
additional (thanks to TDeint) it does a ELA-interpolation of moving (interlaced) areas.
So it is like doing a motion adaptive interaled resizing like I earlierer recommended:

motionadaptivebob()
resize()
assume?ff().separatefields().selectevery(4,0,3).weave()

if you take a closer look at my function yv12toyuy2_laced() you will see, that it uses exactly the same method!
You may also try to replace tdeint with leakkerneldeint.

[Guest]

I've forgotten how unreliable the progressive_frame flag can be! Gosh, I've even posted many times about that. I must be getting senile.

So, your clip is downsampled progressively, but the progressive_frame flag is left at 0. Unfortunately, this is a common error, because the progressive_frame flag does not affect the decoding process in any way and is just there to guide the display process, so it can be wrong without affecting the decoding of the picture.

If the progressive_frame flag is unreliable, then we move into the realm of image heuristics, of which your solution is an example. If the flag is reliable, then upConv=true is satisfactory.

Interestingly, there is a patent describing an approach similar to yours:

http://www.freshpatents.com/Chroma-upsampling-method-and-apparatus-therefor-dt20050210ptan20050030422.php?type=description

I'm thinking of making a native conversion plugin that does this.

Interestingly, with your clip, if you compare upConv=true to ConvertToYUY2(interlaced=true), you would expect them to be the same, because the progressive_frame flag denotes interlaced. But the upConv=true way looks better, even though some artifacts are still visible. I'm curious about why. I'll look into it.

EDIT: I'm not sure of this anymore. As you say, interlaced upsampling preserves the interlacing, so that suggests that it really is downsampled as interlaced. I have to ponder some more. The content appears to be field-blended progressive from an NTSC->PAL conversion. I wonder how that affects things, because that's not traditional interlacing. Maybe the encoder had downsampled some frames progressively and some interlaced but without bothering to set the progressive_frame flag.

EDIT2: Negative on the speculation that the encoder had downsampled some frames progressively and some interlaced, because in a frame showing interlacing, if you upsample progressively you get rid of the CUE but mess up the interlacing, while if you upsample interlaced you keep the interlacing OK but have the CUE. Hmm. Very strange. I'm going to think how this mess could have arisen as a consequence of the field-blending format conversion. I do agree that the heuristic approach appears to be the right way to go -- for this video at least.

[Guest]

@scharfi,

I've convinced myself that the presence of areas that upsample better interlaced and areas that upsample better progressive in the same frame is an artifact of the field blending process *for the clip that you provided*.

I'd be very interested to hear if you have any examples where you see this phenomenon in a clip that is not field-blended; that is, dual areas within the same frame. Of course I also acknowledge that the progressive_frame flag can be outright wrong, but that would affect the whole frame.

I think another possible case would arise from applying the upsampling to a frame that has been progressively downsampled but then pulled down so that portions of it are interlaced. It was to avoid this case that I preferred upConv=true (because it upsamples the encoded pictures and not the pulled-down frames). Another reason is to avoid having to use image heuristics to determine per frame which upsampling to use, but that assumes that the flags are reliable.

You've certainly convinced me that there is (possibly a lot of) video that cries out for adaptive chroma upsampling. I'm wondering if we've been unnecessarily making lots of poor upconversions due to this phenomenon, and whether we should make a fast native adaptive upsampler for the Avisynth core.

I would appreciate hearing your views about this. Thanks for yet again stimulating some new arrangements in my neurons, especially neuron number two.

[Guest]

I created this thread from a thread in another forum on scharfi's suggestion because it is interesting and relevant here.

[Guest]

I whipped up a quickie native version of the adaptive upsampling.

http://neuron2.net/autoyuy2/autoyuy2.html

[Wilbert]

Sorry for jumping into this discussion. I hope you don't mind :)

An interlaced encoded progressive PAL-movie is better upsampled progressively.
I agree with scharfis on this statement. In fact, i agree with a much stronger statement. Given an interlaced frame, combed parts of that frame should be upsampled interlaced, and static parts progressively.

After reading this thread, i think scharfis would agree with this, but i don't know about you? Of course i can make some artificial clip showing this, i hope .... :)

I've convinced myself that the presence of areas that upsample better interlaced and areas that upsample better progressive in the same frame is an artifact of the field blending process *for the clip that you provided*.
So, i think this is always true, and not only for 'field blending conversions and 3:2 pulldown of progressively sampled video'.

How large is that clip of scharfis? I would like to have it too :)

[Guest]

An interlaced encoded progressive PAL-movie is better upsampled progressively. No way that is true! Now I'll have to make one to prove it.

How large is that clip of scharfis? I would like to have it too :) 4 and a bit megabytes. It's still up there.

[Wilbert]

Ok, here's some proof. The package can be downloaded here:

http://www.geocities.com/wilbertdijkhof/graft.zip

image.m2v is a mpeg-2 file, which is progressive encoded as interlaced (using TMPGEnc). All the necessary stuff to create it is given in the zip file above.

I upsampled the clip to YUY2 using progressive and interlaced mode. The result (enlarged and saved as jpg):

http://www.geocities.com/wilbertdijkhof/prog_enc-as-int-resized.jpg

What do you think about it?

Btw, perhaps it would have been better to resize the right part of the pic in "interlaced mode". I will try that tomorrow.

[Guest]

Ok, here's some proof. I'll have a look. Thanks. I'm glad that someone other than scharfi and I find this interesting. :)

But don't do resizing. That obscures things. I'll use my own means to zoom in without causing additional image changes.

[Guest]

Oh my Darwin. I just ran some tests of my own using a color gradient ramp and downsampling to YV12 as well as MPEG2 encoding. I upsampled using the built-in Avisynth functions and AutoYUY2() with threshold=100000 and -100000 to force progressive and interlaced upsampling, respectively. All the tests so far supported your assertion. But it's contrary to theory! I think. :)

I'll try to find the root cause of this and report back. Either the theory is wrong or some component in the chain is not working as I think. But right now it's looking like AutoYUY2() is even more important than I thought.

I hear the Twilight Zone theme playing in my head.

Just think of all the suboptimal conversions we've been making!!!

[Backwoods]

I'll have a look. Thanks. I'm glad that someone other than scharfi and I find this interesting. :).

Hey I'm reading and following it, I just have absolutely nothing to add.

[fccHandler]

Same here. You lost me somewhere on the previous page, but then I haven't seen the clips. And I saw almost no difference in the pictures Wilbert posted (or was that the point?)

I am interested in how this thread turns out. ;)

[IanB]

Just to put a spanner in the works, the "improved" look is when viewing both fields at the same time on a PC screen, when in reality interlaced content should be viewed sequentially 1/50th of a second apart. This is all an extension of deinterlacing and smart bobing theory and I think there is merit in fixing the chroma resampling of interlaced content.

IanB

[yaz]

I'm glad that someone other than scharfi and I find this interesting. :)" when men are speakin' children are just lis'nin' " ;) (or "don't stop, baybeee...")

the bests
y

[Seed]

Just to put a spanner in the works, the "improved" look is when viewing both fields at the same time on a PC screen, when in reality interlaced content should be viewed sequentially 1/50th of a second apart. This is all an extension of deinterlacing and smart bobing theory and I think there is merit in fixing the chroma resampling of interlaced content.

IanB

I did some testing some time back and I recall that (interlaced= true) is still the correct way. One reason is as stated by IanB. Always check interlaced footage on TV. Or use assumexff().separatefields().

Also, if one view or grab the still frame in Virtualdub, remember Vdub (or probably other players) sometimes shows chroma upsampling error on displaying yv12 as RGB, when certain codecs are used to decode yv12 or when wrong field order is assumed. Make sure to use assumexff().separatefields().

[scharfis_brain]

my TV-Picture looks a LOT better, when the DVD-SAP upsamles pregressively (progressive MPEG), than with interlaced upsampling.

static areas are - even if the scanlines are written sequentially to the screen - quasistatic, that's why I would like to improve upsampling.

Also with the given YV12-(Sub)Pixel position it is fully legitme to do this, because they are on the same spatial position.
Only the temporal one differs, but this is no Matter in static areas!

EDIT:
I am currently a phase shifted Knight-Rider Sample Clip to Donalds FTP.
It is dynamically phase shifted, and thus: encoded interlaced.
Also it is from ultra crappy-low bitrate German DVB.

The progressive Upsampling looks better than interlaced upsampling, after doing a telecide() before.

Maybe one needs to raise the saturation a 'little' bit (tweak(sat=4), hehe) to get the idea...

Of course, progressive upsampling will look worse than interlaced upsamling, if there are combs left in, especially, when telecide doesn't find a good match, or the heavy mpeg compression introduced these combs...
But this will be fixed with adaptive upsampling, I hope.


loadplugin("D:\x\dgdecode.dll")
loadplugin("D:\x\decomb.dll")


mpeg2source("knight.d2v",cpu=4)

# undo phase shift with YY12 chroma
telecide(order=1,guide=2,post=0)

# alternate upsampling between progressive and interlaced
interleave(converttoyuy2(interlaced=false),converttoyuy2(interlaced=true))

# raise sat for better examination
tweak(sat=4)

[Seed]

my TV-Picture looks a LOT better, when the DVD-SAP upsamles pregressively (progressive MPEG), than with interlaced upsampling.

We are probably dealing with 2 conceptually different things here.

Perceptually/Visually, depending on the video footage and personal preference, sometimes an deinterlaced (luma and chroma) interlaced video may also look better on TV than the original interlaced footage, e.g smoother. (Also when converted to mpeg, a deinterlaced footage is significantly more compressible than interlaced one). Adaptive chroma upsampling is akin to smart deinterlacing on chroma plane.

IIRC from my limited testing sometimes back on interlaced footage, in which I was more concerned with the accuracy of conversion (perserving the original details of video footage), I did 4-5 generations of to and fro conversion of yv12 <--> yuy2. Again IIRC the fourth/fifth generation of conversion looks almost the same as the first generation of conversion (i.e almost no generation loss) when (interlaced=true) is used compared with (interlaced=false).

PS: Mine are PAL interlaced video

[scharfis_brain]

@Seed: five times chroma forth & back like this:


converttoyuy2(interlaced=true)
converttoyv12(interlaced=true)
converttoyuy2(interlaced=true)
converttoyv12(interlaced=true)
converttoyuy2(interlaced=true)
converttoyv12(interlaced=true)
converttoyuy2(interlaced=true)
converttoyv12(interlaced=true)
converttoyuy2(interlaced=true)
converttoyv12(interlaced=true)
converttoyuy2(interlaced=true)
converttoyv12(interlaced=true)
converttoyuy2(interlaced=true)


will blur the chroma like hell!

only if you do
converttoyuy2(interlaced=false)
converttoyv12(interlaced=false)
converttoyuy2(interlaced=false)
converttoyv12(interlaced=false)
converttoyuy2(interlaced=false)
converttoyv12(interlaced=false)
converttoyuy2(interlaced=false)
converttoyv12(interlaced=false)
converttoyuy2(interlaced=false)
converttoyv12(interlaced=false)
converttoyuy2(interlaced=false)
converttoyv12(interlaced=false)
converttoyuy2(interlaced=false)

it is nearly lossless!

doing the same with an motion adaptive yv12 <-> yuy2 conversion will be somwhere in the middle.

@Donald: AutoYUY2 does not work, if I have telecide in the script, too.
It immediatelly closes VDub on open.

which kind of interpolation do you use? linear?

It would be nice, if you could build in some kind of EDI and a fieldmatcher.
(Hmm. maybe I am whishing too much from you so I should stick with my TDeint based chroma conversions, because they currently are fitting all my needs except that they are a bit too slow :( )

[Guest]

@Donald: AutoYUY2 does not work, if I have telecide in the script, too. It immediatelly closes VDub on open. Can you give me the script, please?

which kind of interpolation do you use? linear? Yes.

It would be nice, if you could build in some kind of EDI and a fieldmatcher.
(Hmm. maybe I am whishing too much from you so I should stick with my TDeint based chroma conversions, because they currently are fitting all my needs except that they are a bit too slow :( ) Right now, I'm just trying to understand what's going on. Where I will go with it, I don't know yet.

[scharfis_brain]

mpeg2source("knight.d2v",cpu=4)

# undo phase shift with YY12 chroma
telecide(order=1,guide=2,post=0)

# I know, that this is not correct to use them in this order, but I am just curious, why it crashes...
autoyuy2()

# raise sat for better examination
tweak(sat=4)

[Seed]

Well, I dug out my old clips and did some limited testing again, and confirm my earlier statement. I get result that are completely opposite to scharfis_brain:

My original footate: PAL interlaced top field first (tried both yuy2 and yv12)


assumetff()
converttoyuy2(interlaced=true) # for yv12 clip
converttoyv12(interlaced=true)
converttoyuy2(interlaced=true)
converttoyv12(interlaced=true)
converttoyuy2(interlaced=true)
converttoyv12(interlaced=true)
converttoyuy2(interlaced=true)
converttoyv12(interlaced=true)
converttoyuy2(interlaced=true)
converttoyv12(interlaced=true)
converttoyuy2(interlaced=true)
converttoyv12(interlaced=true)
converttoyuy2(interlaced=true)
# with/without separatefields() in order to better
# view chroma smearing on Vdub

--> no chroma blurring/smearing, no significant loss of details, but slight luma brightness changes after several generations


assumetff()
converttoyuy2(interlaced=false) # for yv12 clip
converttoyv12(interlaced=false)
converttoyuy2(interlaced=false)
converttoyv12(interlaced=false)
converttoyuy2(interlaced=false)
converttoyv12(interlaced=false)
converttoyuy2(interlaced=false)
converttoyv12(interlaced=false)
converttoyuy2(interlaced=false)
converttoyv12(interlaced=false)
converttoyuy2(interlaced=false)
converttoyv12(interlaced=false)
converttoyuy2(interlaced=false)
# with/without separatefields() in order to better
# view chroma smearing on Vdub

---> A lot of chroma smearing/blurring in high motion scenes/parts even on first generation conversion!

I don't know if this is due to difference in source materials. I myself am quite confused of all these discrepancies. I sincerely hope to learn the correct way of chroma upsampling, with preserving the details during conversion my main concern.

[scharfis_brain]

for sure, you cannot assume that you will get good quality with progressive upsampling with moving interlaced content.

I was using a still frame with pixel-crisp chroma.

the interlaced yuy2-yv12-yuy2 conversion blurred the chroma vertically, while the progressive conversion did no blur.

[Guest]

@Donald: AutoYUY2 does not work, if I have telecide in the script, too. It immediatelly closes VDub on open. Oops, it's so long since I've coded an Avisynth filter! I was getting the src pointer as a write pointer instead of a read pointer, and when Telecide held a reference to it, the missing MakeWritable() call caused a dereference of a null pointer. It's fixed in beta 2:

http://neuron2.net/autoyuy2/autoyuy2_100b2.zip

[Wilbert]

neuron2, could you post your tests/findings?

[Guest]

Sure, when I have some findings. I have just returned to this after fixing some bugs in DGMPGDec. I have some doubts about the down/up sampling descriptions at www.avisynth.org, so I going to run some tests to see if that is what the filters are really doing. If it is, I'm not surprised we have problems. More later...

[Guest]

Here are some initial results of some black-box testing. I started with a test YUY2 file with known U values that I generated programmatically. Then I downsampled and upsampled using ConvertToYV12 followed by ConvertToYUY2. I wrote a utility filter to dump the resulting U values. I am reserving judgment for now on a) whether these convert functions are coded correctly, and b) whether these convert function algorithms are optimal in terms of reproducing the input pattern. I will address that later.

There are 5 log files that give the results. Their file names consist of 3 letters followed by ".log". The first letter is p or i for progressive or interlaced content. The second letter is p or i for progressive or interlaced downsampling. The third letter is p or i for progressive or interlaced upsampling. This report includes only progressive content. Tomorrow I will test interlaced content. The file p--.log shows the input pattern. It is a step followed by a ramp on the U channel. The step allows seeing CUE (chroma upsampling error) or ICP (interlaced chroma problem), while the ramp allows one to assess chroma resolution and chroma shift.

The log files are linked below. The header of each log file includes a comment describing the results and errors encountered. The surprising things to me in this so far are that a) "pii" loses 50% vertical chroma resolution (!), and b) "pip" shifts the chroma by one line while delivering full resolution. I have a hunch that something may be broken in the interlaced chroma upsampling, but I will reserve judgment for now.

Interesting is the "pip" case, which is the focus of the claims made in this thread. It does in fact yield full chroma resolution and a correct ramp, but the chroma is shifted by one line and edges are significantly blurred, facts not yet noted.

http://neuron2.net/misc/sampling/p--.log
http://neuron2.net/misc/sampling/ppp.log
http://neuron2.net/misc/sampling/ppi.log
http://neuron2.net/misc/sampling/pip.log
http://neuron2.net/misc/sampling/pii.log

(Note that the test file was mod 4 in height but at line 240, I clamped U at 240 and deleted the remaining lines in the test logs.)