Log in

View Full Version : Deinterlacing Angel PAL


Gser
24th April 2010, 19:19
Well I *guess* its a film-->NTSC--->PAL transfer, which means blending etc. What should I do with it?

http://www.megaupload.com/?d=JGMZDXA2
Password: AC32_Rsdb

Floatingshed
24th April 2010, 19:23
Well I *guess* its a film-->NTSC--->PAL transfer, which means blending etc. What should I do with it?

http://www.megaupload.com/?d=JGMZDXA2
Password: AC32_Rsdb

Employ common courtesy when asking for help and use the word please?

Inspector.Gadget
24th April 2010, 19:29
1) There is no need to or gain from compressing already-compressed video.
2) Thank you for adding a password to the archive, making it even more of a pain in the neck to deal with. When you want help, make it easy for people to help you.

Gser
24th April 2010, 19:45
Employ common courtesy when asking for help and use the word please?

With cherries on top? plz (Interesting fact of the day: The is no equivilent of the word "please", in the Finnish language)

1) There is no need to or gain from compressing already-compressed video.

2) Thank you for adding a password to the archive, making it even more of a pain in the neck to deal with. When you want help, make it easy for people to help you.

1)Except when you wish to compress it even more.

2)Sorry, I tend to be overcautious when uploading copyrighted material. Just copy paste the password. plz

Inspector.Gadget
24th April 2010, 19:56
1)Except when you wish to compress it even more.

Use Search. This is a misconception.

Gser
24th April 2010, 20:38
Use Search. This is a misconception.

Or use the video in a project that is in a different frame rate than this source. I intend to do both.

Inspector.Gadget
24th April 2010, 20:54
In what way does placing the file in an archive have anything to do with framerate?

Guest
24th April 2010, 21:13
Employ common courtesy when asking for help and use the word please? Please refrain from off-topic posts per forum rule 3. You can send messages like this through PM. Thank you.

Gser
24th April 2010, 21:38
In what way does placing the file in an archive have anything to do with framerate?

Nothing, I intend upon compressing it with another codec after the project is done. The reason why I "zipped" the file for the upload was to hide the nature of the file and encrypt it. But, alas we have gone off topic.

Inspector.Gadget
24th April 2010, 21:55
Given the rules we follow on this forum, any attempt at "hiding the nature of the file" is suspect. I will not be returning to this thread.

Gser
24th April 2010, 22:28
Given the rules we follow on this forum, any attempt at "hiding the nature of the file" is suspect. I will not be returning to this thread.

Rule 17) No discussion about the rules or their interpretation. And my intent was not to hide the nature of the file from the users of this forum but from the rest of the internet, including the file-sharing site. There are no rules against it.

manono
25th April 2010, 00:48
I just spent 10 minutes trying to get at it without any luck. My suggestions are, that if you want help with this you:
1) Not encrypt it
2) Not password protect it
3) Send to someplace other than MegaUpload (Try Sendspace or MediaFire)
4) Make it smaller. No one needs over 50MB to figure out what's going on. Ten well chosen seconds of steady movement is more than enough.

Guest
25th April 2010, 16:39
Ditto what manono said!

I tried to unzip your archive and got "unsupported compression format".

Gser
25th April 2010, 16:51
I just spent 10 minutes trying to get at it without any luck. My suggestions are, that if you want help with this you:
1) Not encrypt it
2) Not password protect it
3) Send to someplace other than MegaUpload (Try Sendspace or MediaFire)
4) Make it smaller. No one needs over 50MB to figure out what's going on. Ten well chosen seconds of steady movement is more than enough.

Very well. I guess whatever you guys try to open it with doesn't support 256bit AES encryption or the LZMA2 compression.
http://www.hiderefer.com/tPMiPF6z.htm

loekverhees
25th April 2010, 17:14
You could try:

MPEG2Source("Angel.d2v")
SeparateFields().SelectEven()
Lanczos4Resize(720,576)
Then you have 25p video.

Gser
25th April 2010, 17:45
You could try:

MPEG2Source("Angel.d2v")
SeparateFields().SelectEven()
Lanczos4Resize(720,576)
Then you have 25p video.

No, thanks.

loekverhees
25th April 2010, 17:47
"No" ? What do you mean?

Didée
25th April 2010, 17:49
loekverhees: that's a poor advise. Normconversions have the blendings in both top and bottom fields (for PAL usually, phase-changing twice per second)

Gser: Use Srestore.

loekverhees
25th April 2010, 17:55
But if you look at the fields using SeparateFields(), they are (almost) identical (after SeparateFields(), frame 0 and 1 are identical and 2 and 3 are identical etc.), so there is no additional information in the second field. Therefore you can trow away half of the fields, at least that is what I thought. Or am I missing something? And you mention blending, but I can not find any blending anywhere. Where do you see the blending?

Didée
25th April 2010, 18:06
Oh ... now that I looked at the sample, you're right. Going by the OP, I blindly assumed it would be field blended. But in fact it's just a simple PAL phase shift (or 2:2 pulldown, or however you want to name it).

If the pattern is consistant, a simple "separatefields().trim(1,0).weave()" will do it.

If the pattern isn't consistant (aka "dynamic phase shift"), then "TFM()" will adaptively reconstruct the progressive frames.

Didée
25th April 2010, 18:24
... and looking closer, after the fieldmatching the result is full of dreadful aliasing. A common problem with such sources. The ugliness could be be reduced e.g. by Vinverse() (pretty fast), or with an AA script like e.g. NNEDI2AA (http://forum.doom9.org/showthread.php?p=1386903#post1386903) (much slower, but better quality)

Gser
25th April 2010, 19:04
... and looking closer, after the fieldmatching the result is full of dreadful aliasing. A common problem with such sources. The ugliness could be be reduced e.g. by Vinverse() (pretty fast), or with an AA script like e.g. NNEDI2AA (http://forum.doom9.org/showthread.php?p=1386903#post1386903) (much slower, but better quality)

AHA! Actually tfm was what I tried first but I wondered why it looked like crap. I had to change the matching to be more aggressive too. Thank yous.

I'm guessing NNEDI2AA needs repair, removegrain, nnedi2 and masktools?

loekverhees
25th April 2010, 19:32
... and looking closer, after the fieldmatching the result is full of dreadful aliasing. A common problem with such sources. The ugliness could be be reduced e.g. by Vinverse() (pretty fast), or with an AA script like e.g. NNEDI2AA (http://forum.doom9.org/showthread.php?p=1386903#post1386903) (much slower, but better quality)
If the aliasing you are mentioning are the horizontal lines artefacts (that you get after separatefields().trim(1,0).weave()), why not choose my example script? Using mine, there is no aliasing at all. So no need to use Vinverse() or NNEDI2AA(), right? Please let me know if I am overlooking something, always wanting to learn :).

Didée
25th April 2010, 20:03
While it seems there isn't very much delta information in fields of different phase, there still will be some information. Your suggestion just throws it away. My suggestion will make use of that information.

In short: less detail vs. more detail, more blurry vs. more sharp. That's about it.


Edit: Actually, the problem is that the fields are badly aligned - there's an offset of roughly 0.25 pixel. Trying the following script:
separatefields()
ev = selecteven()
od = selectodd()
ev2 = ev.spline36resize(width,height,0,0.25,width,height+.0001)
interleave(ev2,od).trim(1,0).weave()
will correct the wrong offset, and get rid of most of the aliasing.

Though, the "perceived image quality" of NNEDI2AA still is better.

The starting sequence (with the watch) is a good place to compare the different strategies. 400% zoom is recommended for evaluation.

loekverhees
25th April 2010, 20:20
Ok, thanks. I compared your script and mine and looked at the clock in the first part of the clip. I could not see any difference in vertical resolution (one was not sharper than the other). Which is weird isn't it? Because I am trowing away half of the horizontal lines essentially, so the vertical resolution would be halved. But why is it that I am not seeing any difference in vertical resolution (see example: here (http://img231.imageshack.us/i/comparisonw.png/))?

Or is it that Lanczos4Resize is so good?

Didée
25th April 2010, 20:27
Ermh ... I don't know about your eyesight. But I for one do see an obvious difference between NNEDI2AAS() and your SelectEven().Resize().

loekverhees
25th April 2010, 20:54
I did not see any difference in resolution/sharpness in the sample I posted on ImagesHack. How should I implement the NNEDI2AAS filter? I tried but without succes.

Gser
25th April 2010, 21:00
Edit: Actually, the problem is that the fields are badly aligned - there's an offset of roughly 0.25 pixel.
Damn, where do you come up with this stuff. :D

loekverhees
25th April 2010, 21:19
Gser, I tried the code in your previous post (which is now gone apparently) but I got something heavily distorted and something of a blend image (see the attachment below). What am I doing wrong?

Gser
25th April 2010, 21:27
Gser, I tried the code in your previous post (which is now gone apparently) but I got something heavily distorted and something of a blend image (see the attachment below). What am I doing wrong?

Yes I noticed that too. Guess I did something wrong. Now we wait...

Didée
25th April 2010, 21:33
Damn, where do you come up with this stuff. :D
Easy conclusion. The mere fact that the content is phase shifted indicates that the footage was edited with separated fields. Then, when a standard resizer is applied to field-separated footage, the result will be misaligned fields, necessarily. (Rule of thumb: the average professional video editor has little clue of what s/he's doing.)

Taken strictly, the offset most probably isn't exactly 0.25 pixel. It's just an arbitrary value I tried, and seems to fit reasonably well. (The precisely-exact value depends on the original resolutions before & after the resize.)

Gser
25th April 2010, 21:35
(The precisely-exact value depends on the original resolutions before & after the resize.)One could hazard a guess at the original being 720x480.

loekverhees
25th April 2010, 21:40
I don't think the original was NTSC since it seems, as Didée says, it's a 2:2 pulldown (so 25p to 25i). So I think the original was already PAL.

Gser
25th April 2010, 21:45
I don't think the original was NTSC since it seems, as Didée says, it's a 2:2 pulldown (so 25p to 25i). So I think the original was already PAL.

It was prolly speeded up from film first.

loekverhees
25th April 2010, 21:57
Ok, that's possible indeed.

TinTime
26th April 2010, 14:02
A lot of US tv shows from the 90s / early 2000s seem to end up like this. It's probably been through a DEFT conversion (or similar) where NTSC 60i is fed in one end and PAL 50i is output. The converter will IVTC to recover the original film, resize, and speed up.

This can result in some problems to deal with.

Firstly the output tends to flit backwards and forwards between current and previous field matches so TFM or Telecide is essential to recover the progressive frames.

Secondly, if there are genuine video sequences in the source (or worse, sequences that the converter incorrectly decides are video) then the output will contain blended fields.

Finally it seems there can be a problem with the resizing. I wasn't aware of this before - thanks Didée :)

Newer releases seem to be much better. I'm watching Cheers on PAL DVD at the moment and the quality is excellent - no deinterlacing or field matching required. So an older show than Angel but a newer DVD release.