New IVTC for Avisynth

[Blight]

Yeah, I'm still on a p3/733. I keep delaying the purchase. I feel the athlons at their current mhz and die size are just too hot. I think i'll wait for the 0.13m shrink which is due in the next 2-3 months.

Might grab some GF4 while I'm at it.

Also, what do you think of SSE. Anywhere to implement it to improve speed? I know most of the code is probably integer so SSE won't be as useful, but maybe in some places... Also, SSE2 should be useful as well, although you probably lack the P4 to do it.

BTW, Just for kicks I encoded some episode of Xena with v1.91 last week. Even though it was mostly blended fields (I hate those 30->25 fps blend conversion) the resulting image was very nice...

Oh, and regarding the comparison I ran last night. Here's a weird thing. Both videos were encoded using DivX 4.12 1-pass quality based (100 quality). The Greedy file came out at 3mb while the Decomb file came out at 2mb. I think this is due to greedy's deinterlacing not blending on missed fields. Not entirely sure though.

I'll try running longer comparisons this weekend.

P.S.
I still think adding decimate into the telecide filter would speed things up even further ...

[western shinma]

I've only done one such comparison but with Nandub at 3x constant quantizer. Decomb clocked in at 25 megs, and Greedy was only 20. This was with default postprocessing in Decomb and force film with vertical filter enabled for Greedy. With Decomb's postprocessing disabled and Greedy's vertical filter deactivated, both files turned out almost exactly the same size, but there was a considerable amount of interlacing left over.

[Blight]

Ok, took another try at benchmarking...

Same parameters as last test. Used a 1 minute clip of high-motion from Andromeda.

I did multiple encodes to rule out caching improving speeds.
Encoded (video only) DivX 4.12 one-pass quality at 100%

GreedyHMA = 3:09 - 77.0mb
Decomb 3.0 (blend:on) = 2:54 - 50.0mb
Decomb 3.0 (blend:off) = 2:54 - 51.5mb

Speed difference = 8-9% in favor of Decomb 3.0

I'm not quite sure how to explain the differences in size, My guess would once again be that the field blending in Decomb compresses better than the Interpolation in GreedyHMA. It's very hard to know which gives the better quality.

Also, blending on/off didn't seem to have any effects on speed, at least not on this one minute clip.

[Guest]

Thank you, Blight, for the results. That is good news!

One little point. Decomb will do either blend or interpolate. You obviously know that but for others I point it out in case they think they need to use GreedyHMA to use interpolation.

On the file size difference: yes, the blending may compress slightly better, but it is unlikely to be responsible for the results you see, because you'd expect a big difference between the blend on and blend off cases for Decomb. I wonder if GreedyHMA is letting any combed frames go through to the output, as its combing detection is not as effective as Decomb's and it takes a lot of bits to encode combed areas.

I'm working on the Decimate-Blend experiments now.

[Guest]

@Blight

Just had another thought. Since the times for Decomb blend on and blend off are so similar, it probably means that Decomb did not detect very many frames as combed and so did not deinterlace many frames. If GreedyHMA is deinterlacing a lot more frames, then this could salvage your theory about blending versus interpolation being responsible for the size difference. I do know that GreedyHMA tends to deinterlace more frames than it should, because the combing detection is not as effective as that of Decomb.

You could test your theory by just running FieldDeinterlace(full=true) with blend on and blend off. If there is a big file size difference then your theory would stand up.

[trbarry]

I wonder if GreedyHMA is letting any combed frames go through to the output, as its combing detection is not as effective as Decomb's and it takes a lot of bits to encode combed areas.

That was also the first think I thought of when reading this. If so there are probably some obviously combed frames to be found in the output. But it may also be a question of filtering. Softer material always compresses better, so adding any filter including just turning on Greedy's vertical filter options would correct this.

From my DScaler background I personally like large resolutions and very crisp detail and much of my programming reflects it. But obviously that does not make material that compresses very well, at least without some additional filtering. That should be moot if I ever release the version with variable sharpen/soften.

Of course now after Blight's results I'm going to have to go back and tune the darn thing to go faster so that might take longer, even when I do get back to GreedyHMA. ;)

On another topic, I believe that GreedyHMA and Wiz IVTC decimation is broken towards the end of the clip (when the filter requests frame numbers greater than the decimated number, which it must do to determine which frames to decimate).

I thought I had a check in the decimation code to not read past the end but just not try do drop non-existent frames. Don't I? Or do you have reason to believe I forgot that (easily possible)? Have you seen it make blank/garbage frames at the end?

The decimation code was actually added by request for Avisynth only. There is no equivalent in GreedyHM/DScaler, so it probably hasn't been tested as much. But I wasn't aware of any other reported problems there.

- Tom

[ssjbrolly]

I mainly encode from PAL DVD sources using GKnot, I tryed some time ago to encode a NTSC source and got bad results with GKnot.
So I was curious on trying Decomb as it seems to be working preety well, I have a couple of questions tough...

If I have a NTSC source (From DVD2AVI), I should use Telecide and then Decimate15 to perform IVTC right? But should I still use FieldDeinterlace after that or wouldn't this be necessary?

If I have a FILM > 95% (From DVD2AVI), should I even bother to use Decomb or a simple Forced FILM on DVD2AVI and a deinterlace method of GKnot would be enough? Or even only using FieldDeinterlace method of Decomb(If I do this should I still use Force Film on DVD2AVI?)

I don't have many experience with IVTC since as I said I usually don't encode from NTSC sources so if you could give some hints I'd appreciate it.

[Guest]

@ssjbrolly


If I have a NTSC source (From DVD2AVI), I should use Telecide and then Decimate15 to perform IVTC right? But should I still use FieldDeinterlace after that or wouldn't this be necessary?
Just because the source is NTSC, that doesn't necessarily mean that you need to apply IVTC. What matters is whether or not there are telecined progressive frames in the stream. If you don't know what that means, you should find out before attempting to deal properly with your clips. Otherwise, it's like trying to do medicine without an MD degree!

Here's how you can tell if you have progressive frames. Find a high-motion part of your clip (look at the clip without any processing!). Step frame by frame. If you see *some* frames that are moving relative to their previous frame, AND they do not show combing, then you most likely have a telecined stream. Once you have established that the stream has progressive frames, you can apply Telecide() to recover as many of them as possible. You apply Decimate() if the original material was 25fps and you want to return to that frame rate. You should never use FieldDeinterlace after Telecide because the exact same thing is achieved through Telecide's default behavior (postprocess=true).
If I have a FILM > 95% (From DVD2AVI), should I even bother to use Decomb or a simple Forced FILM on DVD2AVI and a deinterlace method of GKnot would be enough? Or even only using FieldDeinterlace method of Decomb(If I do this should I still use Force Film on DVD2AVI?)
Assuming you do in fact have progressive source (!), I would try Forced Film and then look at the result of that alone. If you see no combed frames, then do nothing else. If you see some but not a lot of combed frames, you could apply FieldDeinterlace(full=false). If you see a lot of combed frames, then you might want to turn off Forced Film and use Telecide(postprocess=true).

If your source is not in fact telecined progressive source, then just apply FieldDeinterlace(full=true).

I don't know whether the Gordian Knot deinterlacer is adaptive so I cannot advise you about it.

Decimate15() is from an earlier version of Decomb. You should upgrade to Version 3.0. You won't regret it. :-)

Looks like I need to add a Wizard (decision flowchart) to my help file.

[Guest]

@trbarry

Hi Tom. I'm looking at your code and behavior now and will report back soon. Quite possibly you are doing something different from the vi.num_frames trick that solves the problem I mentioned. I should have checked before commenting. Sorry.

[Guest]

@trbarry

I thought I had a check in the decimation code to not read past the end but just not try to drop non-existent frames. Don't I? Or do you have reason to believe I forgot that (easily possible)? Have you seen it make blank/garbage frames at the end?
Tom, your code is just fine! It is all my fault and I am sorry for making that comment (I've edited to remove it from the post). The thing is I had a miscoding in one part of my code and the little trick I described canceled it out, but I attributed it to an inability of Avisynth to read past the declared num_frames. But as you so cogently observed [:-)], that would mean that the frames would appear blank or garbage, and they don't! So hearing you LOUD AND CLEAR on that I inspected *my* code and found the problem. There is no misbehavior in anyone's released code; that is the bottom line. Again, so sorry.

To possibly regain some respect... :-) I suggest that your decimation code appears needlessly complex, with the tests for out-of-sync and random access, etc. Can't you just do this:


PVideoFrame __stdcall Decimate::GetFrame(int inframe,
IScriptEnvironment* env)
{
int dropframe, useframe;

/* Determine the correct frame to use and get it. */
useframe = inframe + inframe / (cycle - 1);
dropframe = FindDuplicate((useframe / cycle) * cycle, env);
if (useframe >= dropframe) useframe++;
PVideoFrame src = child->GetFrame(useframe, env);

return src;
}

where FindDuplicate(frame, env) inspects 6 frames, (frame - 1) through (frame + cycle - 1), and returns the right frame to remove. Of course, it caches the result and only recalculates for each new cycle.

[Guest]

@Blight

I have coded your idea about not removing duplicates coming out of Telecide, but rather replacing them with an interpolated (blended) frame as discussed earlier in this thread. It doesn't look so bad! In fact, it looks surprisingly good.

You can download it at http://sauron.mordor.net/dgraft/decomb301.zip

I have not officially released it so if anyone gets it to play with, please do not re-distribute it or otherwise publish it. If people think it is worth including in the official release I will do so. Please comment here on what you think of this feature. Thank you.

[trbarry]

To possibly regain some respect... :-) I suggest that your decimation code appears needlessly complex, with the tests for out-of-sync and random access, etc. Can't you just do this: ...

Yes, that might be better but I actually added the Decimate code with the intention it would be temporary. It would be much more efficient embedded into the Update_Fieldstore function deep inside the Greedy code. But I wanted a quick and simple add-on for the moment that didn't require me to regression test everthing else that Greedy does.

And besides, I am under an ancient curse. No matter what language I program in, it is destined to come out looking like I wrote it in assembler. I've learned to live with that and try to make up for it with lots of comments. ;)

- Tom

[ssjbrolly]

Thanks for the reply, it really helped to clarify somethings, this might sound dumb, but I still have a doubt regarding progressive/telecined streams...

Originally posted by neuron2
Here's how you can tell if you have progressive frames. Find a high-motion part of your clip (look at the clip without any processing!). Step frame by frame. If you see *some* frames that are moving relative to their previous frame, AND they do not show combing, then you most likely have a telecined stream.


I usually use DVD2AVI to check for interlaced frames, so if I see any combing artifacts on the clip that stream is interlaced and theres no need to IVTC right? But what exactly do you mean by a frame moving relative to the previous one? (I think I'm totally missing the point of what's a progressive and telecined progressive frame...)

Originally posted by neuron2
You apply Decimate() if the original material was 25fps and you want to return to that frame rate.


Wouldn't this be 23,976 fps if I have a 29,970 fps NTSC source?

Originally posted by neuron2
Looks like I need to add a Wizard (decision flowchart) to my help file.


That might be useful :D

I've downloaded Decomb 3.0 now and have been reading the help file, wich brings me to another question... what exactly are the advantages of using Progressive Frame Recovery instead of IVTC? I thoght that when there are progressive frames we should allways IVTC...

Thanks again for the help.

[Blight]

neuron2:
You already coded it, so keep it in ;)

[Guest]

@Blight

OK.

@ssjbrolly

I usually use DVD2AVI to check for interlaced frames, so if I see any combing artifacts on the clip that stream is interlaced and theres no need to IVTC right? But what exactly do you mean by a frame moving relative to the previous one? (I think I'm totally missing the point of what's a progressive and telecined progressive frame...)
I don't know what you are setting for DVD2AVI. You need to look at the raw clip as I described. Just because you see combing you can't conclude that it is pure interlaced video. It is the pattern of the combing that will give you the clues you need. By a frame moving I mean you are viewing a series of frames in which there is consistent motion in the scene, such as a car traversing the screen. A progressive frame is one in which both fields are from the same temporal moment, so there is no combing. Telecined progressive frames are progressive frames that have been passed through a 3:2 pulldown process to increase their frame rate to match broadcast rates. Some of the frames resulting from this appear combed but the original progressive frames can be recovered through a process called field matching. The extra fields added by the telecining result in a duplicate frame for every 4 original frames, and the duplicates can be removed with Decimate.
Wouldn't this be 23,976 fps if I have a 29,970 fps NTSC source?
Yes.
I've downloaded Decomb 3.0 now and have been reading the help file, wich brings me to another question... what exactly are the advantages of using Progressive Frame Recovery instead of IVTC? I thoght that when there are progressive frames we should allways IVTC...
In Decomb, IVTC simply is Telecide() + Decimate(). Telecide does the progressive frame recovery as described above. Decimate removes the resulting duplicate frames. Your last guideline is not universally valid: for example, you can have a PAL 24fps stream of progressive frames that is phase shifted by one field and therefore appears combed. You don't want to do a classic IVTC. You only want to undo the phase shift. Decomb can do this by applying only Telecide and omitting Decimate. In this case, Telecide does the field matching and restores the original frames, but no duplicates are produced, so Decimate is not required.

[Blight]

neuron2:

Here's a first Draft (http://www.inmatrix.com/articles/ivtcsynth.shtml) of an article I've written.

I'd appriciate any comments.

[b0b0b0b]

Originally posted by Blight
neuron2:

Here's a first Draft (http://www.inmatrix.com/articles/ivtcsynth.shtml) of an article I've written.

I'd appriciate any comments.


Is it the case that you should always crop after ivtc, but you may crop before regular deinterlace?

When you enumerate the decomb options, maybe it would help to put either true or false in all caps to illustrate what the defaults are.

[Blight]

I tried to write it full-proof, so I didn't discuss defaults at all and instead wrote the defaults as recommended settings.

And as for cropping. That's a bit of a problem since you don't want people to accidently put the wrong width before the telecide.

Which brings up an interesting question for me.

If a frame gets removed by Decimate, does any processing occur on it (i.e. crop/resize) if they were listed further down the list?

If so, it might be faster to resize/crop after telecide and before decimate as you would be comparing less video data. But this would only be faster if the resize/crop are being called even though the frame is discarded.

Can anyone verify this?

[Guest]

Decimated frames never make it past the Decimate call.

[Uli]

Just wanted to report:
I've coded the anime 'gun smith cats' RC1. It's a weird stream of about 80 - 90% NTSC and FILM with agressive interlacing artefacts. Made the following script using decomb301:

LoadPlugin("MPEG2DEC.dll")
LoadPlugin("decomb.dll")
Mpeg2Source("GSC.d2v")
Telecide()
Decimate(5)

The resulting 23.976 FILM stream is absolutly perfect :D
Never before i've seen such a perfect reconstruction of a partially telecined anime.

thanks again, Uli

[daxab]

I'm a big fan of Decomb, which seems to work really well with clean source (i.e., DVD). However, I'm still having trouble with noisy source. For instance, a recent capture of "24" stutters quite a bit with Decomb, but is relatively smooth with GreedyHMA.

Any tips for noisy source?

The other question I have is about jaggy diagonals in frames that have gone through Telecide().Decomb(). The source is anime DVD, so the diagonal line should be clean, and it is on non-reconstructed frames. Is this to be expected?

[Guest]

@daxab

If you can make an input (unprocessed) clip that shows the problems available to me, I can answer your questions. Failing that, I have no way to address them. Please get in touch with me by email.

[hakko504]

Originally posted by daxab
The other question I have is about jaggy diagonals in frames that have gone through Telecide().Decomb(). The source is anime DVD, so the diagonal line should be clean, and it is on non-reconstructed frames. Is this to be expected?
Sometimes, yes. Some anime have the background and all drawn parts filmed in 23.976fps and then the CGI is added at 29.97 i.e. after telecining. That would produce something like this:

back: 1t1b 1t2b 2t3b 3t4b 4t4b (film telecined)
front: 1t1b 2t2b 3t3b 4t4b 5t5b (NTSC interlaced)

Now, if you IVTC this then you remove the superfluous half frames and put the others together making this:

back: 1t1b 2t2b 3t3b 4t4b (original film)
front: 1t1b 3t2b 4t3b 5t5b (fields missing from NTSC)

In this case frame 2&3 could produce the jagged lines you mention, but some of it could be removed by using a deinterlace.

[Blight]

Like I said once in a post regarding Telecide (the VDub filter), it had aweful problems with a noisy VHS cap ... stuttering like crazy. Sadly, I no longer have the source (it was a PAL cap btw and I was trying to use telecide to phase shift).

[Guest]

@Blight

All the more reason for daxab to get me a clip! It's quite possible that I can make things better, but I have not seen this problem in my own testing, and without a clip, what can I do?

Looking forward to your assistance, daxab! :)

[daxab]

@neuron2

I have sent you an email with a link to the clip. Please let me know if you have any trouble getting it. It's compressed with the Indeo 5.1 codec.

@hakko504

Yikes! Hence the notorious difficulty of anime. I guess in that situation you just do a 29.97 fps interlaced encode.

In my case I don't think there is any CGI, but I could be wrong. It's Battle Athletes Victory, and what I notice is a series of frames like so:

a b X d

where a, b, and d have clean lines, and X looks good but the same lines that are clean in a, b, and d are jaggy. I'll try to put together a clip that shows the effect.

[manono]

Hi daxab-

Regarding the anime-you should always check the source material for these anime DVDs to make sure they're not screwed up. I was complaining once to neuron2 about the exact same thing and he told me to check the source, and by golly, while scrolling through the .d2v, there it was. Or check the .avs before applying Decomb.

If Decomb was responsible, you might try and weaken the deinterlacing algo with something like this:

Telecide(false,false,true,30)
Decimate(5)

15 is the default value, and I found that with certain anime material it was too strong and sometimes deinterlaced good frames (although I was testing with an older version some time ago). Isn't BAV wonderful?

[Guest]

@manono

Thanks for pointing that out, manono. Of course, I'm always willing to inspect people's problem clips because there is always the potential there to learn something new and improve the tool. Notwithstanding that, people really *do* need to carefully determine the nature of their source material before deciding on the appropriate processing, and especially before raising any queries about the tool's behavior.

[BBWoof]

I'm really happy to report that with v3.0 and putting the ( ) at the end of my functions, I'm running at at least 10% faster then before I ever complained in the first place :cool:

[Gamblor]

Hello everyone,

Mr. Graft, thank you for your effort in developing a filter that is in such high demand. It's fun to use something with so much heart.

Meanwhile, I am hoping to get some help with the 'postprocess' in Telecide() of Decomb version 3.0. I would like to turn it off to test the effects, but when I set the value to false,

"Telecide(false,false,false,15,true,false,false)"
or
"Telecide(false,false,false)" ,

I still see deinterlace blending. When I set 'postprocess' to false, shouldn't I see the original intensity of combing wherever combed frames sneaks through?
Right now, when I look at a combed output frame, it is still being blend-deinterlaced but I don't want it to.

Has anyone else tried to turn OFF 'postprocess' but without effect?
Please let me know if screenshots are wanted.

Thank you for everyone's time.
Cheers!

Cal

[Guest]

@Gamblor

You probably have blended *fields*. Do a SeparateFields() and see if there are blended fields. Then report back. I can assure you that the postprocess option is not broken.

[Gamblor]

Hi Mr Graft,

Thanks for your swift reply. Very impressive. :)
I am looking at SeparateFields() right now but I'm not sure I understand how to look for blended fields after doing SeparateFields(). Could you please give me a few more pointers?

Cal

[Guest]

Just look at the fields and see if any are combinations of two pictures, as if the two pictures were overlayed on each other. If not, then you will have to make an input clip available for inspection.

[Gamblor]

Thank you for your time. I am so sorry to be keeping you but I don't believe I am seeing any blended fields.

I am preparing screenshots and an MJPEG clip for you to examine.
Should I email you the information pertaining to the site hosting these files of mine?

Cal

[Guest]

Yes, please, mail the link to me. Just make sure to send the INPUT clip, not a processed clip. And also please explain in your mail how I should duplicate your problem. You are aware that the field matching process can remove combing that is apparent in the input clip even if postprocessing is off, right?

[Krajensky]

@daxab:

My local FOX station comes in badly also...I just (blatantly) stole the medium denoising algos from GordianKnot:

TemporalSmoother(3)
SpatialSoftenMMX(1,4,6,false,false,4,4,6,8)
(Required libraries are mpeg2dec.dll and avisynth_spatial.dll)

I had a really messed up CBS cap that this cleared up quite well - though it leaves some amount of gray artifacts on black backgrounds, so I added a levels to fix that, and add contrast.

One other thing I can think of is maybe the field order is somehow wrong? Did you crop before using decomb?

Krajensky

[Gamblor]

Hi Mr Graft,

From my understanding, I am aware that ideally when postprocessing is disabled, the field matching process will remove combing. My dilemma is that when postprocessing is disabled, I should not be seeing any blending when a combed frame sneaks through because that's not what the field matching process does.

I am in the middle of preparing a package containing my material for you to examine.
Cheers!

Cal

[jarthel]

hi. I'm getting errors in decomb when I open the avs file in nandub. It keeps on saying "telecide:width must be multiple of 4; use crop" and it's on the resize line in avisynth. The resize parameters are 640 by 480. I'm sure 640 is a multiple of four.

The crop parameters is also multiples of four.

here the avs file -->>

--------------
#
# Created with Gordian Knot
#
# http://thewef.nav.to
#
# PLUGINS
# get them from http://users.win.be/dividee
LoadPlugin("D:\DOWNLO~1\windows\UTILIT~1\divx\GORDIA~1\mpeg2dec.dll")
#LoadPlugin("D:\DOWNLO~1\windows\UTILIT~1\divx\GORDIA~1\InverseTelecine.dll")
#LoadPlugin("D:\DOWNLO~1\windows\UTILIT~1\divx\GORDIA~1\Avisynth_Spatial.dll")
LoadPlugin("D:\DOWNLO~1\windows\UTILIT~1\divx\GORDIA~1\decomb.dll")
#LoadPlugin("C:\WINDOWS\System32\vobsub.dll")
#
# SOURCE
mpeg2source("D:\dvdrips\kenshin27\kenshin27.d2v")
#
# TRIM
#trim(startframe,endframe)
#
# IVTC
#InverseTelecine(40,10,15)
# or use
#GreedyHMA(1,0,4,0,0,0,0,0)
#
# CROPPING
crop(12,4,698,476)
Telecide()
Decimate(5)
#
# DEINTERLACING
#SmartDeinterlace(2,15,true,true,true)
# or use
#VerticalReduceBy2
# or maybe
#GreedyHMA(1,0,0,0,0,0,0,0)
#
# SUBTITLES
#VobSub("FileName")
#
# RESIZING
BilinearResize(640,480)
#
# DENOISING: choose one combination (or none)
# 1) little noise (fast)
#TemporalSmoother(2,1)
#
# 2) medium noise (slow)
#SpatialSoftenMMX(1,4,6,false,false,4,4,6,8)
#TemporalSmoother(2)
#
# 3) heavy noise (very slow, you have been warned)
#SpatialSoftenMMX(2,4,6,false,false,4,4,6,8)
#TemporalSmoother(3)
#SpatialSoftenMMX(1,4,6,false,false,4,4,6,8)
#
# BORDERS
#AddBorders(left,top,right,bottom)
#
# COMPRESSIBILITY CHECK
# !Snip Size has to be 13 for use in GKnot!
#SelectRangeEvery(260,13)
#
# FOOL CCEnc
#ResampleAudio(44100)

------------------------------------

Any suggestions? Thanks

[Guest]

@jarthel

My calculator tells me that 698 divided by 4 is 174.5, which means it is not a multiple of 4. Appearances can be deceiving. :)

[Guest]

@daxab

Thank you for the noisy clip that exposes a weakness in Decomb. :)

I have determined that the problem here is in Decimate and not in Telecide. I made some changes that make it handle this clip properly but I need to regression test the new version before releasing it. Also, my web site is going down for maintenance this weekend.

Decimate doesn't check every pixel; it subsamples the frames for speed. My subsampling was a little too aggressive (trying to match GreedyHMA for speed!). Also, my threshold for ignoring noise was a little low.

Watch here for a new release.

If you'd like to send me your jaggy clip, I'd be happy to take a look at it. Thanks again and sorry for the earlier confusion on my part about the nature of your clip.

[Guest]

Ok, I've placed a test release on
http://buehlerbreakers.net/decomb302.zip

This appears to work better with your noisy clip. Please give me your feedback. Thank you.

[Guest]

@Gamblor

You sent me a clip ostensibly demonstrating that the postprocess option was not working, i.e., that setting postprocess=false did not stop frames that fail field matching from being deinterlaced. You pointed me to one particular frame. I analysed your clip and determined quite easily that the frame was removed by Decimate and that is why you did not see it in the output. In fact, you were looking at the following frame when you thought you were looking at the combed frame that failed the field match. I then pointed out to you two other frames that failed the field match, and which showed combed as expected with postprocess=false and blended as expected with postprocess=true. Conclusion: the postprocess option is working as expected and your complaint is groundless.

[Gamblor]

Yes, Mr. Graft, I believe we are still addressing my inquiry via email. I have chosen not to reply to the forum clarifying the issue yet because I do not understand your email reply to me. I imagine it's only fair to me and everyone else that I only post a follow-up message on here if and only if I actually understand what is happening. Of course I do not doubt that there is no problem at all, and it is simply am oversight in the usage of this filter on my part. In which case, I would sincerely regret taking up your time.

Furthermore, I apologise if my ignorance is bothering you. I am seeking to enlighten myself with your project as it is a very exciting production indeed. Please excuse my lack of technical knowledge since I am unfamiliar with low-level details.

Yours truly,
Cal

[Guest]

I clearly demonstrated to you that the postprocess option is not broken, which you began this thread by asserting. You refused to accept my demonstration for unstated reasons and instead deflect the issue with some new nebulous complaint about how a frame "looks". [Your quotation marks.]

Let's resolve the first issue first. Do you still think the postprocess option is broken? Then we can address your new issue.

You know what they say, ignorance is no excuse. :)
It is not my responsibility to educate you, but it is your responsibility not to make unfounded allegations about people's carefully tested tools, and to correct them when proven to be unfounded.

[daxab]

@Krajensky

Thanks for the tip. I have tried the SpatialSoftenMMX filter with, for me, mixed results. I don't mind the speed penalty, but I do mind the detail loss. I know, I know -- can't do noise reduction without some detail loss (possibly with the exception of careful filters on anime source).

@neuron2

Thanks for the new build. In my original clip, there were 3 stutters in the first 60 seconds. With the 302 release all 3 stutters are fixed -- oustanding work.

[Guest]

@daxab

Great! Thanks again, daxab; your feedback has been invaluable in improving Decomb.

[Gamblor]

Dear Mr. Graft,

I wish to start by saying that your latest email of only one-sentence has clarified much of my confusion, thank you, and I will acknowledge that 'postprocess' is working properly.

In response to your last post to me, I think you are wrongfully making the assumption that people are easily educated in a technical field. You are also discriminating against less fortunate and lesser educated people who are putting up the courage to make observations. If I don't understand how your project works, should I not have dared to ask any questions? If it is my responsibility to not make "unfounded allegations" yet I do not have the understanding to ask proper technical questions, then what a vicious cycle this must be.

Please take note that my initial question was not addressed to you directly, Mr. Graft. I was seeking enlightenment from everybody and anybody in this forum. However, you chose to respond to me, hence I was under the impression that you were indeed here to help educate me. If a forum is not there to aid in education, I'm afraid I do not see the point of a forum. In retrospect, your latest email finally addressed my lack of understanding and I appreciate that.

Furthermore, it seemed to me all along that you didn't understand my query in the private email so I was merely attempting to clarify my position in subsequent emails. I've stated several times that I simply do not understand your explanation, which does not imply I am refuting it. I couldn't even reproduce the examples you've given me, and as the uneducated person that I am, I became fearful of telling you that your example seemed to be faulty. Instead, I expressed my lack of understanding and wished to seek further advice from you by attempting to clarify my original query.

My degree of doubt on 'postprocess' was never to the point of a strong, cogent complaint. I was asking questions "hoping to get some help" with it because obviously I was uncertain about my own observations. It seems clear though that you strongly believed that I actually understood your explanation and it was my impolite nature that I haven't acknowledged your conclusion. In fact, it was not until your latest email of only one sentence that I finally understand your explanation! I thank you for that.

Initially I had intended to try this filter as part of my hobby but as a hobby, I don't have enough time to spend on it to "educate" myself in all its glory. I will now acknowledge that 'postprocess' is NOT broken due to reasons stated earlier by you. To save everyone grief, I will keep my questions to myself now and not post to this forum anymore. So please forget everything I asked because it was all bogus, and Decomb 3.0 is just as spiffy as ever.

Cheers to you all. Although I am at a loss, I really do appreciate everyone's time.

Good day.

Cal

[Guest]

Now, now, Gamblor, there's no need to overreact.

I think most here will agree that doing good rips and encodes is a highly technical art and that you cannot just use these complex tools in a casual hobbyist mode and then come post questions based on a very low degree of expertise and prior research. People regularly get flamed for that here. :)

It is very easy for posts like yours to take on a life of their own, with people saying "Oh, I read on the doom9 forum that Decomb's postprocessing is broken". So you will please understand a tool developer's concern that issues are treated fully and the resolution properly documented.

And you never actually *told me* that you didn't understand my response and what you didn't understand about it.

So, no need to go away. We can still both learn from each other.

And, oh, no need to keep calling me Mr Graft. It makes me feel old. You can call me neuron2. :)

Let's smoke the peace pipe and move forward from here.

[Krajensky]

@daxab:

Sorry, I forgot one thing...using SpatialSoften before Decomb will probably confuse it more than it will help...if you use it be sure to place it after the deinterlacing/decombing.

TemporalSmoother-Decomb-Decimate-SpatialSoften is a good order for really noisy sources. Otherwise skip the spatialsoften.

Krajensky

[daxab]

@Krajensky

Agreed about putting SpatialSoftenMMX after Decomb. In another thread, it was also advised to put TemporalSmoother after your ivtc filter, so as not to smooth out the interlacing data. But I think you can put it before if it's not too strong.