TDeint and TIVTC - Page 39

anton_foy · 24th October 2006, 18:48

I am not sure this would be an improvement that would be added to Tdeint or if this should be done seperately afterwards.

These two pictures below are a comparison of the artifacts left behind from Tdeint+eedi2 and MvBob.
Artifacts

Notice the compressionlike artifacts left by Tdeint (face and shirt) opposed to MVbob's output. Some combing is left aswell but it can be reduced with undot() pretty well.

I was thinking that maybe a smoothingfilter that works together with Tdeint right after the deinterlacing process occur. This could be activated by some memory function perhaps storing what pixels has been deinterlaced and smooth these areas like degrainmedian does. Being a total retard regarding programming this may possibly be stupid suggestion but hope it will be of some interest in the area.

Tdeint is so good and get almost the same quality on my footage as MVBob but about 3 times faster.

Terranigma · 24th October 2006, 23:39

Hi. Is there anyway to use eedi2 with tdeint via external deinterlacing @ scene changes? I've tried to do a manual override, but it won't deinterlace, so in order to avoid that, i'd use tfm(flags=5,hint=true). Maybe there's something that i'm doing wrong?

Revgen · 25th October 2006, 05:25

You can use the clip2 parameter.

Look here

ChiDragon · 25th October 2006, 07:15

tritical, sorry to bother you again, but I've got a new problem. I've specified a video section with an override file, and it properly overrides everything in the section except one cycle. My ovr line is "28779,29087 v". Frame 28806 is being dropped and none of the frames in its cycle are blended, although it does state VIDEO in the display stats. This cycle is also treated the same way without the ovr file, which is weird because it properly finds and blends 5 cycles before and 10+ after, and I have conCycle set to default (my vidThresh is 3). Not only that, but it doesn't even drop the frame with the lowest displayed metric (28809 has 10.45 vs. the 18.46 of 28806).

I'm using an input file on the actual encode, although I tested without the input file and found the same results. As a workaround I edited the second value for frame 28806 in the TDecimate stats file and it now properly blends all the frames in the cycle (I just copied the next frame's metric).

Original stats:

Code:

28805 67940 6099494
28806 62565 6437117
28807 95045 8689400
28808 73794 6207936
28809 35429 3322493

Edited stats:

Code:

28805 67940 6099494
28806 62565 8689400
28807 95045 8689400
28808 73794 6207936
28809 35429 3322493

Editing the first value increased the metric displayed by TDecimate but the frame was still dropped.

tritical · 25th October 2006, 21:13

@ChiDragon
Try increasing the scenechange threshold in tdecimate. When using hybrid=1, and a scenechange is detected in a video cycle, it prefers to drop a frame one side of the scenechange over blending the cycle. For scenechange detection only one frame in the prev, curr, and next cycles can be over the threshold, so by changing the stats file as you did you probably made 2 frames be over the limit making it not detect a scenechange and thus blending the cycle.

@anton_foy
It would be possible to do what you propose, but it would also be quite a bit of work. Such artifacts are a result of poor motion detection, so I think improving motion detection is a better place to invest time than trying to filter the mistakes. I've had a new motion-masking filter finished for a while, but just haven't sat down and written the help file.

Didée · 25th October 2006, 22:44

@ anton_foy ( & tritical, too)

Anton, from your post it is not too easy to gather what are the "good effects", and what are the bad ones. But after reading several times and looking at the zoooomed picture often, I think that you, tritical, got it the wrong way round. (Not sure, though.)

Quote:

Notice the compressionlike artifacts left by Tdeint (face and shirt) opposed to MVbob's output. Some combing is left aswell but it can be reduced with undot() pretty well.

Ah, language ... let's try to work it up.

Mentioned are two different types of "artefacts": the "compressionlike" ones, and the combing artefacts. Truth is, both filters show good (read: bad) amount of residual combing, MVBob even more than TDeint. In this point, both filters are basically equal.
But the "compressionlike" artefacts of TDeint shall appear *opposed* to MVBob, so these can't be related to residual combing. Okay, there is this area on the shirt, right below the collar, where the residual combing of TDeint is most obvious ... but that's a small area only, and moreover nothing like this is to be seen in the face, where the "compressionlike" artefacts shall appear, too.

So, my guess is that the wording "compressionlike" is targetting at the, well, "chunky" look in those areas where TDeint did deinterlace: at the very edges of the face (cheeks), at the light-shadow transition of the nose bridge, and, especially in the left part of the picture, at the dark parts of the shirt's folds.
In these areas, TDeint did deinterlace, and interpolation left back this chunky look. MVBob, in comparison, did not deinterlace most of these areas, but decided (falsely, imo) to weave them. So, MVBob did create more residual combing, but in this scene, this did the visual trick of "dithering" the chunkyness that (probably) is inherent to the source from the start.

Now, what's good, what's bad, and what is to do?

But in any case: any filtering like "smoothing" or "noise reduction" of those areas that actually have been deinterlaced, this should not be the task of the deinterlacer (again, imo.) A deinterlacer should either weave or interpolate pixels, eventually do postprocessing to reduce residual combing. But active image processing is just not the job of a deinterlacer.

(BTW: while in *this* case MVBob's "residual-combing-denoising" visually worked out, there are instances where it will fail big time. You might check these short samples here.)

But while I'm babbling anyways

, this brings up another point that has bugged me for quite some time: most of tritical's filters have these nice options to spit out visualizations of "what is done where". A really nice feature! ... but: often it's a pity, that from those relatively slow filters you can only have either the actual processing, or the visualization mask. Imagine, you want to have the actual processing, *and* the visualization mask in order to do further processing based on the mask. This means that you have to run the (relatively slow) filter *two times*, to get both the processing and the mask.
Wild suggestion: would it be possible to add an option, which would force to give out both the processing and the mask (say, stacked vertically)? Then one could simply do some cropping after calling the filter, and would have both outputs with only one call of the filter.

TDeint and TTempsmooth are the filters where I would love to have this feature, quite frequently ...

Chainmax · 25th October 2006, 23:54

Hey Didée, there's still no match for SmartDecimate on Restore24, right?

Didée · 26th October 2006, 00:01

Frankly, I can't tell. Last time I checked, I found TDecimate/mode7 not always reliable in long encodings - but that was a looong time, perhaps a year, ago ... things might have changed.

Since R24 offers the option to use either one or the other, feel free to test it out, and report back.

ChiDragon · 26th October 2006, 01:47

@tritical:
Ah, scenethresh=16 also did the trick. Makes sense now how it would be appropriate to drop the scene change frame rather than blend where possible (although in this case it wasn't a scene change

). Thanks for clearing it up.

akapuma · 26th October 2006, 11:36

Quote:

Originally Posted by tritical

Only 18 months since v1.0 beta 1

... here is TDeint v1.0 Final. Changes:

Code:

+ added blend deinterlacing option (type = 4)
- changed denoise default to false
- pixels detected as moving, but with absolute difference < 4 to both vertical 
     neighbors are no longer automatically weaved (should fix problems with slow fades)

Hello,

why the denoise default is changed from true to false?

Best regards

akapuma

tritical · 26th October 2006, 21:04

@akapuma
I changed it to false because it is kinda worthless and just slows things down imo. All it currently does is remove individual pixels that were detected as moving but who had no immediate neighbors (8 surrounding pixels) that were. I originally wanted to expand it to do more, but I never found an algorithm that worked well.

@ChiDragon
I'm glad that something finally worked how it's suppose to

.

@Didée
Yeah, I misinterpreted the artifacts he was talking about in the image. Though either way I'm not keen on incorporating postprocessing like that into tdeint. However, with AP > 0 TDeint internally creates a mask marking weaved pixels with AP value > thresh (also subject to APType conditions) vs. other pixels. Outputting that mask as part of the map parameter could make such processing possible externally.

Creating both the map and the regular frame and stacking them vertically or horizontally is a great idea. I'll add it in the next version of tdeint.

@Chainmax + Didée
As far as mode 7 goes, I have only one clip to test on and for me it produces no duplicates. Also, smartdecimate always crashes after processing only a few frames so I haven't done much in the way of comparisons. Though a few days ago I built avisynth_c v0.15 using an updated avisynth lib/header and then built smartdecimate v0.23 using the updated avisynth_c and it all works fine now. So I'd be happy to look at samples where mode 7 gives crappy results compared to smartdecimate.

ChiDragon · 29th October 2006, 10:25

tritical:
What do you think about extending that "drop one side of scene change during video w/SC" thing so that if the hints declare that only of the two frames (or maybe one in the whole cycle) is combed, drop that one. I just noticed a scene where that would help (a bad edit between two actual film patterns).

On the other hand, I suppose the current method would be preferable if vidthresh is set too low and TDec sees a dupe at the scene change as being video. Then it would be better to keep the combed frame...

Just a thought. :P

Livesms · 29th October 2006, 19:09

Can anybody tell me why when I use two pass deinterlace with

Code:

#1 pass
d2vname = "Untitle.d2v"
MPEG2(d2vname, true)

tfm(d2v=d2vname, output="matches.txt")
tdecimate(mode=4, output="metrics.txt")

and

Code:

#2 pass
d2vname = "Untitle.d2v"
MPEG2(d2vname, true)

tfm(d2v=d2vname, input="matches.txt")
tdecimate(mode=5, hybrid=2, vfrDec=0, input="metrics.txt", tfmIn="matches.txt", mkvOut="mkv-timecodesfile.txt") # not anime or cartoon

I'm getting 23.822fps instead of 25.000fps

And when I use

Code:

d2vname = "Untitle.d2v"
MPEG2(d2vname, true)

tfm(d2v=d2vname)
tdecimate(cycle=25)

it produses 24.000fps instead of 25.000fps.

Source is 25.000fps. How can get 25.000fps - deinterlace without changing fps?

PS. I'm looking for quality deinterlace of VHS video captured with DVD-Recoder MPEG-2 8000kbit/s. Here is another canidate

Code:

MPEG2("Untitle.d2v", true)

 interp = separatefields().selecteven().EEDI2(field=1)
 deinted = tdeint(edeint=interp,order=1,field=1)
 tfm(clip2 = deinted,order=1)

But two pass or another IVTC for PAL gives more accurate results.

ChiDragon · 29th October 2006, 19:44

If you don't want to change the framerate, just use TFM without TDecimate. TDecimate is intended for telecine, not normal PAL speedup with mismatched fields.

Livesms · 29th October 2006, 19:48

Quote:

Originally Posted by ChiDragon

If you don't want to change the framerate, just use TFM without TDecimate. TDecimate is intended for telecine, not normal PAL speedup with mismatched fields.

Should I skeep tdecimate both in first and second pass?

Will it cause in result quality?

foxyshadis · 29th October 2006, 23:10

You have to figure out whether it's field-shifted, fully interlaced, or telecined. (Once in a while PAL is telecined from film.) And if it's hybrid telecined pal, TIVTC doesn't support that one yet, but I can't imagine that being common.

Here's some information on each: http://www.doom9.org/ivtc-tut.htm
And the method neuron2 drills into everyone for finding out what you have, is just use separatefields and step through it, until you find the pattern, if any.

Livesms · 30th October 2006, 07:18

Quote:

Originally Posted by foxyshadis

You have to figure out whether it's field-shifted, fully interlaced, or telecined. (Once in a while PAL is telecined from film.) And if it's hybrid telecined pal, TIVTC doesn't support that one yet, but I can't imagine that being common.

Here's some information on each: http://www.doom9.org/ivtc-tut.htm
And the method neuron2 drills into everyone for finding out what you have, is just use separatefields and step through it, until you find the pattern, if any.

I've got PAL (720*576) material with such frames. Source fps is 25.000

IVTC ADVICE in http://www.doom9.org/ivtc-tut.htm page mostly deal with NTSC. But I work with PAL DVD video.

foxyshadis · 30th October 2006, 08:14

Did that come from a cooking show? (Yum!) If so, the chances are very good that it's fully interlaced, needing deinterlacing, and ivtc is the wrong operation. It's impossible to say without a sequence of frames though.

Livesms · 30th October 2006, 08:30

Quote:

Originally Posted by foxyshadis

Did that come from a cooking show? (Yum!) If so, the chances are very good that it's fully interlaced, needing deinterlacing, and ivtc is the wrong operation. It's impossible to say without a sequence of frames though.

Ok. Here is 10 frames from video http://dump.ru/files/3/379894795/PAL.rar (comporessd by Huffyuv)

If IVTC is wrong way, so why it gives me better results

manono · 30th October 2006, 09:49

Hi-

As foxyshadis speculated, it is pure interlace. Put on a bobber (or separate the fields) and step through it, and you'll see that every frame/field is different. No repeats. The reason (maybe) why you think TIVTC does such a good job is that it doesn't find any field matches and just deinterlaces. You can do as well, and do it faster, by just using TDeint. And if this is for DVD, then I wouldn't recommend deinterlacing at all.

24th October 2006, 18:48	#761 \| Link
anton_foy Registered User Join Date: Dec 2005 Location: Sweden Posts: 703	Artifacts. I am not sure this would be an improvement that would be added to Tdeint or if this should be done seperately afterwards. These two pictures below are a comparison of the artifacts left behind from Tdeint+eedi2 and MvBob. Artifacts Notice the compressionlike artifacts left by Tdeint (face and shirt) opposed to MVbob's output. Some combing is left aswell but it can be reduced with undot() pretty well. I was thinking that maybe a smoothingfilter that works together with Tdeint right after the deinterlacing process occur. This could be activated by some memory function perhaps storing what pixels has been deinterlaced and smooth these areas like degrainmedian does. Being a total retard regarding programming this may possibly be stupid suggestion but hope it will be of some interest in the area. Tdeint is so good and get almost the same quality on my footage as MVBob but about 3 times faster.

25th October 2006, 05:25	#763 \| Link
Revgen Registered User Join Date: Sep 2004 Location: Near LA, California, USA Posts: 1,545	You can use the clip2 parameter. Look here __________________ Pirate: Now how would you like to die? Would you like to have your head chopped off or be burned at the stake? Curly: Burned at the stake! Moe: Why? Curly: A hot steak is always better than a cold chop.

25th October 2006, 07:15	#764 \| Link
ChiDragon Registered User Join Date: Sep 2005 Location: Vancouver Posts: 600	tritical, sorry to bother you again, but I've got a new problem. I've specified a video section with an override file, and it properly overrides everything in the section except one cycle. My ovr line is "28779,29087 v". Frame 28806 is being dropped and none of the frames in its cycle are blended, although it does state VIDEO in the display stats. This cycle is also treated the same way without the ovr file, which is weird because it properly finds and blends 5 cycles before and 10+ after, and I have conCycle set to default (my vidThresh is 3). Not only that, but it doesn't even drop the frame with the lowest displayed metric (28809 has 10.45 vs. the 18.46 of 28806). I'm using an input file on the actual encode, although I tested without the input file and found the same results. As a workaround I edited the second value for frame 28806 in the TDecimate stats file and it now properly blends all the frames in the cycle (I just copied the next frame's metric). Original stats: Code: 28805 67940 6099494 28806 62565 6437117 28807 95045 8689400 28808 73794 6207936 28809 35429 3322493 Edited stats: Code: 28805 67940 6099494 28806 62565 8689400 28807 95045 8689400 28808 73794 6207936 28809 35429 3322493 Editing the first value increased the metric displayed by TDecimate but the frame was still dropped.

25th October 2006, 23:54	#767 \| Link
Chainmax Huh? Join Date: Sep 2003 Location: Uruguay Posts: 3,103	Hey Didée, there's still no match for SmartDecimate on Restore24, right? __________________ Read Decomb's readmes and tutorials, the IVTC tutorial and the capture guide in order to learn about combing and how to deal with it.

26th October 2006, 00:01	#768 \| Link
Didée Registered User Join Date: Apr 2002 Location: Germany Posts: 5,391	Frankly, I can't tell. Last time I checked, I found TDecimate/mode7 not always reliable in long encodings - but that was a looong time, perhaps a year, ago ... things might have changed. Since R24 offers the option to use either one or the other, feel free to test it out, and report back. __________________ - We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!)

24th October 2006, 23:39	#762 \| Link
Terranigma Space Reserved Join Date: May 2006 Posts: 953	Hi. Is there anyway to use eedi2 with tdeint via external deinterlacing @ scene changes? I've tried to do a manual override, but it won't deinterlace, so in order to avoid that, i'd use tfm(flags=5,hint=true). Maybe there's something that i'm doing wrong?

25th October 2006, 21:13	#765 \| Link
tritical Registered User Join Date: Dec 2003 Location: MO, US Posts: 999	@ChiDragon Try increasing the scenechange threshold in tdecimate. When using hybrid=1, and a scenechange is detected in a video cycle, it prefers to drop a frame one side of the scenechange over blending the cycle. For scenechange detection only one frame in the prev, curr, and next cycles can be over the threshold, so by changing the stats file as you did you probably made 2 frames be over the limit making it not detect a scenechange and thus blending the cycle. @anton_foy It would be possible to do what you propose, but it would also be quite a bit of work. Such artifacts are a result of poor motion detection, so I think improving motion detection is a better place to invest time than trying to filter the mistakes. I've had a new motion-masking filter finished for a while, but just haven't sat down and written the help file.

26th October 2006, 01:47	#769 \| Link
ChiDragon Registered User Join Date: Sep 2005 Location: Vancouver Posts: 600	@tritical: Ah, scenethresh=16 also did the trick. Makes sense now how it would be appropriate to drop the scene change frame rather than blend where possible (although in this case it wasn't a scene change ). Thanks for clearing it up.

26th October 2006, 21:04	#771 \| Link
tritical Registered User Join Date: Dec 2003 Location: MO, US Posts: 999	@akapuma I changed it to false because it is kinda worthless and just slows things down imo. All it currently does is remove individual pixels that were detected as moving but who had no immediate neighbors (8 surrounding pixels) that were. I originally wanted to expand it to do more, but I never found an algorithm that worked well. @ChiDragon I'm glad that something finally worked how it's suppose to . @Didée Yeah, I misinterpreted the artifacts he was talking about in the image. Though either way I'm not keen on incorporating postprocessing like that into tdeint. However, with AP > 0 TDeint internally creates a mask marking weaved pixels with AP value > thresh (also subject to APType conditions) vs. other pixels. Outputting that mask as part of the map parameter could make such processing possible externally. Creating both the map and the regular frame and stacking them vertically or horizontally is a great idea. I'll add it in the next version of tdeint. @Chainmax + Didée As far as mode 7 goes, I have only one clip to test on and for me it produces no duplicates. Also, smartdecimate always crashes after processing only a few frames so I haven't done much in the way of comparisons. Though a few days ago I built avisynth_c v0.15 using an updated avisynth lib/header and then built smartdecimate v0.23 using the updated avisynth_c and it all works fine now. So I'd be happy to look at samples where mode 7 gives crappy results compared to smartdecimate.

29th October 2006, 10:25	#772 \| Link
ChiDragon Registered User Join Date: Sep 2005 Location: Vancouver Posts: 600	tritical: What do you think about extending that "drop one side of scene change during video w/SC" thing so that if the hints declare that only of the two frames (or maybe one in the whole cycle) is combed, drop that one. I just noticed a scene where that would help (a bad edit between two actual film patterns). On the other hand, I suppose the current method would be preferable if vidthresh is set too low and TDec sees a dupe at the scene change as being video. Then it would be better to keep the combed frame... Just a thought. :P

29th October 2006, 19:44	#774 \| Link
ChiDragon Registered User Join Date: Sep 2005 Location: Vancouver Posts: 600	If you don't want to change the framerate, just use TFM without TDecimate. TDecimate is intended for telecine, not normal PAL speedup with mismatched fields.

29th October 2006, 23:10	#776 \| Link
foxyshadis Angel of Night Join Date: Nov 2004 Location: Tangled in the silks Posts: 9,559	You have to figure out whether it's field-shifted, fully interlaced, or telecined. (Once in a while PAL is telecined from film.) And if it's hybrid telecined pal, TIVTC doesn't support that one yet, but I can't imagine that being common. Here's some information on each: http://www.doom9.org/ivtc-tut.htm And the method neuron2 drills into everyone for finding out what you have, is just use separatefields and step through it, until you find the pattern, if any.

30th October 2006, 08:14	#778 \| Link
foxyshadis Angel of Night Join Date: Nov 2004 Location: Tangled in the silks Posts: 9,559	Did that come from a cooking show? (Yum!) If so, the chances are very good that it's fully interlaced, needing deinterlacing, and ivtc is the wrong operation. It's impossible to say without a sequence of frames though.

30th October 2006, 09:49	#780 \| Link
manono Moderator Join Date: Oct 2001 Location: Hawaii Posts: 7,406	Hi- As foxyshadis speculated, it is pure interlace. Put on a bobber (or separate the fields) and step through it, and you'll see that every frame/field is different. No repeats. The reason (maybe) why you think TIVTC does such a good job is that it doesn't find any field matches and just deinterlaces. You can do as well, and do it faster, by just using TDeint. And if this is for DVD, then I wouldn't recommend deinterlacing at all.