Deinterlace should preserve original pixels?

[Nikos]

Does eedi2Bob or nnediBob has similar problem with shift?
Also may i replace the Bob with FixedBob in MCBob function or in yadifmod?

s = last
interp=s.FixedBob().selecteven()
s.yadifmod(mode=0, edeint=interp)

[IanB]

@florinandrei,

Nit pick 1 :-
# Pick one if DirectShow can't decide
This implies in some alternate universe DirectShowSource knows something about field order. In this world it has no idea. For interlaced content you always have to work it out and script appropriately.

Nit pick 2 :-
Your edit to "Elum = " is not universally correct. For other pixel formats these are the Even and Odd complete data.

@Gavino,

Originally Posted by Gavino

Considering that one of the advantages of the original method over that of bob-resize-Weave was speed, I would like to ask IanB how much of that advantage has been lost in the case of YV12, given the extra work it now has to do. Can the code possibly be tweaked to reduce the penalty?

Well it is doing 2 near identical resize operations instead of 1, plus a MergeChroma (half Blit). So a bit less than 50% speed.

In the 2.5 world there is no quick way to spec the resizer luma and chroma offsets independently. One could always razor the code, but it is hardly worth it. In the 2.6 development Sh0dan has added the beginnings of some chroma positioning options. This may allow Bob() to spec the resizer luma and chroma offsets independently. Also there is the Y8 pixel format available so each plane can be independently processed in a user script. Somewhat like this :-

...
  SeparateFields() 
  Shift=(GetParity() ? -0.25 : 0.25) * (Height()/Float(NewHeight/2)-1.0)
  Y = ConvertToY8() # Zero cost
  Ey = Y.SelectEven().Spline36resize(NewWidth, NewHeight/2, 0,    Shift) # Uniplanar
  Oy = Y.SelectOdd( ).Spline36resize(NewWidth, NewHeight/2, 0,   -Shift) # Uniplanar
  UV = Interleave(UtoY8(), VtoY8())  # Zero cost
  Euv = UV.SelectEvery(4, 0,1).Spline36Resize(NewWidth/2, NewHeight/4, 0,  Shift) # Uniplanar*2
  Ouv = UV.SelectEvery(4, 2,3).Spline36Resize(NewWidth/2, NewHeight/4, 0, -shift) # Uniplanar*2
  E = YToUV(SelectEven(Euv), SelectOdd(Euv), Ey) # Blit
  O = YToUV(SelectEven(Ouv), SelectOdd(Ouv), Oy) # Blit
  Interleave(E, O)
  Weave()

@henryho_hk,

Might be a little easier for us poor Humans to visualise but the dumb computer couldn't care less.

@Nikos,

eedi2Bob or nnediBob, we do not know, Tritical is sitting on the source code because they are part of his thesis. Why don't you test and report what you find.

It probably does not matter, the actual error here is really quite small. I had trouble building a suitable test pattern to reliably see this error. In normal use the chroma subsampling for interlaced 4:2:2 is severe enough that it out weighs our small displacement problem.

[florinandrei]

Originally Posted by IanB

It probably does not matter, the actual error here is really quite small. I had trouble building a suitable test pattern to reliably see this error. In normal use the chroma subsampling for interlaced 4:2:2 is severe enough that it out weighs our small displacement problem.

Maybe the chroma error introduces a tiny bit of blur?

[halsboss]

Originally Posted by IanB

  SeparateFields() 
  Shift=(GetParity() ? -0.25 : 0.25) * (Height()/Float(NewHeight/2)-1.0)
  Y = ConvertToY8() # Zero cost
  Ey = Y.SelectEven().Spline36resize(NewWidth, NewHeight/2, 0,    Shift) # Uniplanar
  Oy = Y.SelectOdd( ).Spline36resize(NewWidth, NewHeight/2, 0,   -Shift) # Uniplanar
  UV = Interleave(UtoY8(), VtoY8())  # Zero cost
  Euv = UV.SelectEvery(4, 0,1).Spline36Resize(NewWidth/2, NewHeight/4, 0,  Shift) # Uniplanar*2
  Ouv = UV.SelectEvery(4, 2,3).Spline36Resize(NewWidth/2, NewHeight/4, 0, -shift) # Uniplanar*2
  E = YToUV(SelectEven(Euv), SelectOdd(Euv), Ey) # Blit
  O = YToUV(SelectEven(Ouv), SelectOdd(Ouv), Oy) # Blit
  Interleave(E, O)
  Weave()

So, was this the final script instead of that in post 38 http://forum.doom9.org/showthread.ph...85#post1174185 ??

[Fizick]

well, interesting discussion!
not directly related, but now i understand, that pelclip in MVTools is not quite correct for chroma.
similar is that original points are (should) preverved

[henryho_hk]

Originally Posted by IanB

@henryho_hk,

Might be a little easier for us poor Humans to visualise but the dumb computer couldn't care less.

I thought the extracted UtoY and VtoY contain 1/4 data of their original image. Hence, It will be a bit faster (esp for 1080i or p footages).

[IanB]

Originally Posted by florinandrei

Maybe the chroma error introduces a tiny bit of blur?

(I should have said 4:2:0) The issue is that the small offset error in the code is small compared to the chroma subsampling.

Originally Posted by halsboss

So, was this the final script instead of that in post 38

No, that is a pseudo example of how you might be able to code it up in 2.6. Post 38 is an academically pure version for 2.5, given the trouble I had building a test pattern to actually see the error, I do not believe it is worthwhile.

@Fizick,

As above, I do not believe there is anything significant to worry about. But we are all a little anal about getting this stuff right, so it is good to document where we are wrong and how to eventually fix it.

@henryho_hk,

Yes, I guess if you are sufficiently motivated you could use UtoY to make a sightly faster version.

[florinandrei]

Originally Posted by IanB

No, that is a pseudo example of how you might be able to code it up in 2.6. Post 38 is an academically pure version for 2.5, given the trouble I had building a test pattern to actually see the error, I do not believe it is worthwhile.

On my system (AMD Phenom 4 core 9850), the "pure" version is only a little bit slower than the "brute" one. It's 10.3 fps "pure" vs 12.7 fps "brute" when transcoding from 1080i AVCHD (MainConcept decoder via DirectShow) to 480i MPEG2 (HCenc encoder with max quality profile).

[IanB]

Originally Posted by florinandrei

... It's 10.3 fps "pure" vs 12.7 fps "brute" ...

So the "pure" takes 18.3ms out of 78.7ms per frame longer to process ... ... ...

[halsboss]

Originally Posted by IanB

No, that is a pseudo example of how you might be able to code it up in 2.6. Post 38 is an academically pure version for 2.5, given the trouble I had building a test pattern to actually see the error, I do not believe it is worthwhile.

Originally Posted by florinandrei

On my system (AMD Phenom 4 core 9850), the "pure" version is only a little bit slower than the "brute" one. It's 10.3 fps "pure" vs 12.7 fps "brute" when transcoding from 1080i AVCHD (MainConcept decoder via DirectShow) to 480i MPEG2 (HCenc encoder with max quality profile).

Er, which was the "brute" one I could use and not notice the difference ? 10.3->12.7 is significant enough for me.

[Gavino]

Originally Posted by halsboss

Er, which was the "brute" one I could use and not notice the difference ? 10.3->12.7 is significant enough for me.

The 'brute' version is the one that was generally accepted before I discovered the error and proposed the 'pure' solution. This is the 'pure' version:

function IResize(clip Clip, int NewWidth, int NewHeight) {
  Clip
  SeparateFields() 
  Shift=(GetParity() ? -0.25 : 0.25) * (Height()/Float(NewHeight/2)-1.0)
  E  = SelectEven().Spline36resize(NewWidth, NewHeight/2, 0,    Shift)
  O  = SelectOdd( ).Spline36resize(NewWidth, NewHeight/2, 0,   -Shift)
  Ec = SelectEven().Spline36Resize(NewWidth, NewHeight/2, 0,  2*Shift)
  Oc = SelectOdd( ).Spline36Resize(NewWidth, NewHeight/2, 0, -2*shift)
  Interleave(E, O)
  IsYV12() ? MergeChroma(Interleave(Ec, Oc)) : Last
  Weave()
}

Removing the lines in blue gives the 'brute' solution.

Spline36Resize can be replaced by another resizer if you wish.

[halsboss]

Well, that's floored me, look at the signs on SHIFT in this link http://forum.doom9.org/showthread.ph...81#post1172981

Function Foo(clip clip, float shift) {
  Clip
  Tc=SelectEven().Spline36resize(NewWidth, NewHeight/2, 0, -Shift, Width(), Height()) 
  Bc=SelectOdd().Spline36resize(NewWidth, NewHeight/2, 0, Shift, Width(), Height()) 
  Interleave(Tc, Bc)
  Weave()
}

which, just a few posts later http://forum.doom9.org/showthread.ph...85#post1174185 turns into

SeparateFields()

Shift = (GetParity() ? -0.25 : 0.25) * (Height()/Float(NewHeight/2)-1.0)

Elum = SelectEven().Spline36Resize(NewWidth, NewHeight/2, 0,    Shift)
Olum = SelectOdd() .Spline36Resize(NewWidth, NewHeight/2, 0,   -Shift)
Echr = SelectEven().Spline36Resize(NewWidth, NewHeight/2, 0,  2*Shift)
Ochr = SelectOdd() .Spline36Resize(NewWidth, NewHeight/2, 0, -2*shift)

Interleave(Elum, Olum)
IsYV12() ? MergeChroma(Interleave(Echr, Ochr)) : Last
Weave()

whihc is it ??

[Gavino]

@halsboss

In the first link, function Foo was part of a test IanB was doing to verify the correct value of the shift, varying shift from -1.0 to +1.0, so on its own it is incomplete.

The second link shows one way of expressing the complete 'pure' solution, and is equivalent to what I posted (#51).

[halsboss]

OK. Thankyou for clarifying that. Cheers !

[Katie Boundary]

This is all fascinating. Regarding bob-deinterlacers and YCbCr colorspaces, I'm afraid I don't understand why such complex solutions are necessary. Couldn't you just write them so they function like this:

L=bob()
C=separatefields().bicubicresize(720,480)
Mergechroma(L,C)

?

[wonkey_monkey]

For the same reason bob exists in the first place. You wouldn't do separatefields().bicubicresize() on luma, so why would you do it on chroma? There is top field chroma and bottom field chrome just as there is top field luma and bottom field luma. Separatefields "loses" information on their proper positioning.

[johnmeyer]

I think that if you want to do a bob() that can then immediately be recombined to give you exactly what you started with, you use this:

bob(0.0,1.0)

Obviously you would never actually bob and then do this:

separatefields().selectevery(4,1,2).weave()

to put everything back together, but there are all sorts of scripts where it is important not to introduce shifts.

[Katie Boundary]

Yes but the question is whether or not preserving the original scanlines is a good idea when dealing with YCbCr colorspaces.

[TheFluff]

Originally Posted by Katie Boundary

This is all fascinating. Regarding bob-deinterlacers and YCbCr colorspaces, I'm afraid I don't understand why such complex solutions are necessary. Couldn't you just write them so they function like this:



?

I'm pretty sure that if you do that to an actually interlaced source, the chroma will appear to jump up and down because you're treating the top and bottom field chroma sample positions as if they were in the same spatial positions, which they aren't.

The question whether it's a good idea to preserve the original pixels has been extensively discussed in this thread already. I'm of the opinion that there's no inherent reason as to why doing so would make the image look any better, and many bob-style deinterlacers either don't preserve original pixels at all or does so only by coincidence.