Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 18th June 2004, 06:34   #21  |  Link
tritical
Registered User
 
Join Date: Dec 2003
Location: MO, US
Posts: 999
That was versus d2=true with v0.9.3? That's strange, I still get that v0.9.4 is 10-15% faster with d2=true then v0.9.3 with d2=true (on my computer with all the other settings at default). Also, v0.9.4 and up should give technically more accurate results when d2=true then v0.9.3. As for when d2=false, which is what it is on by default, there wouldn't be any difference at all between that in v0.9.3 and v0.9.4, and it would be exactly the same as normal operation in v0.9.2.
tritical is offline   Reply With Quote
Old 18th June 2004, 18:26   #22  |  Link
You Know
Registered User
 
Join Date: Jun 2004
Posts: 75
I have not use d2=true because i have not seen this new parameter...

Standard setting are best for my job...I work only on anime

I reading that "d2 set on false work better for uniformly colored areas with sharp edges", so i think I do not never test think parameter.

I have P4 HT 2.4GHz 800BUS
You Know is offline   Reply With Quote
Old 23rd June 2004, 17:48   #23  |  Link
DarkWave
Registered User
 
Join Date: Jan 2003
Posts: 35
hi,

i´m encoding an old film atm using your bilateral-filter.
after doing lot's of test using different parameters i was wondering, which ones will be the best for non-animé film...

i already tried all params including default, 5/3, 3/1, with and without D2=true/false, but the final results all still had some kind of oil-painting effect...

tried this one on an old disney-movie - great

DW
DarkWave is offline   Reply With Quote
Old 25th June 2004, 12:22   #24  |  Link
tritical
Registered User
 
Join Date: Dec 2003
Location: MO, US
Posts: 999
Actually, I haven't tested it on anything but anime, and anime sources are about all I have. I'll see if I can find something else to test it on later tonight, though I wouldn't really have much to suggest that you haven't tried I don't think. First thing would probably be decreasing diameter/diameterC down to 3 and work from there adjusting the sDev/iDev settings. If you get the oil painting effect even with low sDev/iDev settings with a diameter of 3 there probably isn't a whole lot else to do. It may just not work that well on non-anime/cartoon sources.
tritical is offline   Reply With Quote
Old 25th June 2004, 12:39   #25  |  Link
MfA
Registered User
 
Join Date: Mar 2002
Posts: 1,075
Yeah, that was my problem with it too originally ... which is why I didnt pursue making it a little more practical.

Since you made a decently fast C version, Im just tinkering with my templated version making a REALLY slow version using gamma corrected luma (not really accurate, but if I go to RGB it will become as slow as a mf script) to see if that helps.

Last edited by MfA; 25th June 2004 at 14:42.
MfA is offline   Reply With Quote
Old 3rd May 2005, 05:53   #26  |  Link
tritical
Registered User
 
Join Date: Dec 2003
Location: MO, US
Posts: 999
Gonna dig up this thread after almost a year . Actually, I was trying to use TBilateral a few days ago, for the first time in about a year, and decided there needed to be an easier way to tweak the settings. Thus, I added a gui with preview. Also, there was a bug with the sDev and iDev settings being switched when calculating the weight tables. Anyways, v0.9.6 is linked in the first post.

The gui interface does have a few limitations, diameterL/diameterC are limited to a maximum of 21 when using the gui and the Dev settings also have maximum's but those should be plenty high unless you want a complete super blur. If anyone needs higher diameter settings in the gui I can increase them, but by 21 its going slow enough to be almost unusable... at least for me.
tritical is offline   Reply With Quote
Old 6th May 2005, 07:20   #27  |  Link
Kagura
Perennially Silent Member
 
Join Date: Oct 2004
Location: Protector of Skuld and Guardian of Her Hammer
Posts: 64
In general, I've found that tbilateral maintains great edge structure and detail. However, it turns out that around the edges is where most of the noise is found! Thus, tbilateral misses some of those. =(
__________________
Proud Member of the Scandanavian Contingent
Kagura is offline   Reply With Quote
Old 21st June 2005, 06:29   #28  |  Link
tritical
Registered User
 
Join Date: Dec 2003
Location: MO, US
Posts: 999
Thought I'd bump this thread for v0.9.8 of tbilateral (linked in the first post), since I missed v0.9.7. It implements quite a bit of new stuff mentioned in this thread: http://forum.doom9.org/showthread.php?t=94910 (ppClip; use a pre-processing step via an external filter), and from this thread: http://forum.doom9.org/showthread.php?t=96015 (kernS, kernI, resType; new selectable kernels and new selectable methods for obtaining the final value). The gui has also been redone slightly to accommodate the new options.
tritical is offline   Reply With Quote
Old 20th July 2005, 21:22   #29  |  Link
tritical
Registered User
 
Join Date: Dec 2003
Location: MO, US
Posts: 999
Another bump. After almost exactly one year since the last version, I've made a new version of TTempSmooth, v0.9.3. It adds scenechange detection (isse optimized, no speed cost compared to the normal speed of ttempsmooth), a visualize blur option, debug output, and a strength option to adjust spatial weighting in the same way as mdiff does for difference weighting. I switched from having it use a maximum diameter to a maximum radius which can now be set to anything from 1 to 7 (the previous limit via maxd was equivalent to a range of 2 to 4). Even with all the changes, the default values are mainly the same... except for lmdiff/cmdiff being 2/3 instead of 3/4. Thus, results with default values should be almost exactly the same as v0.9.2 except for some difference around scenechanges.

TBilateral also went up to v0.9.10 a couple weeks ago (the last version giving a 10-15% or so speed increase).

Both filters are linked to in the first post of this thread.
tritical is offline   Reply With Quote
Old 20th July 2005, 22:35   #30  |  Link
E-Male
mad computer-scientist
 
Join Date: Mar 2002
Posts: 1,375
i'm low on time, but i'll check ttempsmoth ASAP, liked it's results
E-Male is offline   Reply With Quote
Old 20th July 2005, 22:45   #31  |  Link
Fizick
AviSynth plugger
 
Fizick's Avatar
 
Join Date: Nov 2003
Location: Russia
Posts: 2,183
Tritical,
It seems you waited until Wilbert add ttempsmooth 0.92 documentation to avisynth manual to make it obsolete.
__________________
My Avisynth plugins are now at http://avisynth.org.ru and mirror at http://avisynth.nl/users/fizick
I usually do not provide a technical support in private messages.
Fizick is offline   Reply With Quote
Old 21st July 2005, 08:16   #32  |  Link
tritical
Registered User
 
Join Date: Dec 2003
Location: MO, US
Posts: 999
Nice timing huh?

Actually, I like the look/style of the html based help files enough that I am planning to replace the current .txt help files. I am in the process of updating/reorganizing/fixing those docs... I have most of it done except for this new version of ttempsmooth and the 3 bigger doc files (tdeint, tfm/tdecimate) which are taking some time. I told Wilbert that I would try to keep them up to date so using them as my actual help files should make that process much easier.
tritical is offline   Reply With Quote
Old 21st July 2005, 22:58   #33  |  Link
Fizick
AviSynth plugger
 
Fizick's Avatar
 
Join Date: Nov 2003
Location: Russia
Posts: 2,183
I think, that it will be very useful, if somebody write documentation, how to write plugin html documentation (may be in SimpleSample thread, so SI may be ?
__________________
My Avisynth plugins are now at http://avisynth.org.ru and mirror at http://avisynth.nl/users/fizick
I usually do not provide a technical support in private messages.
Fizick is offline   Reply With Quote
Old 21st July 2005, 23:33   #34  |  Link
mg262
Clouded
 
mg262's Avatar
 
Join Date: Jul 2003
Location: Cambridge, UK
Posts: 1,148
Quote:
Originally Posted by Fizick
I think, that it will be very useful, if somebody write documentation, how to write plugin html documentation (may be in SimpleSample thread, so SI may be ?
That sounds like a very good idea to me. Perhaps also a template HTML file so that the documentation for different filters would be organised similarly and/or have a similar look? (I'm not suggesting that anyone be forced to adopt it.) I think dgdecode.HTML that comes with version 1.4.0 looks very nice myself, the only caveat being that it's possibly a bit too much information for one file.
mg262 is offline   Reply With Quote
Old 22nd July 2005, 09:25   #35  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
I will look at this when i'm back from holidays.
Wilbert is offline   Reply With Quote
Old 18th November 2005, 04:04   #36  |  Link
tritical
Registered User
 
Join Date: Dec 2003
Location: MO, US
Posts: 999
Heh, never did update any docs... I am still planning to do it eventually .

Anyways, I noticed a bug in v0.9.3 of ttempsmooth and previous versions... it doesn't handle interlaced yv12 input correctly. It works internally on point upsampled 4:4:4, and it was treating all input as progressive which would lead to chroma lines 0 and 1 being assigned to lines 0/1, 2/3 instead of 0/2, 1/3 of the 4:4:4 frames for interlaced yv12. That doesn't effect the temporal averaging, but screws up which pixels pass the motion checks because the luma and chroma motion thresholds are checked together when deciding what pixels to include in the average. Therefore, I made a new version (v0.9.4) (link in the first post) with an "interlaced" parameter and a couple other modifications... changes:
Code:
  + Added interlaced parameter (fix incorrect interlaced yv12 chroma handling)
  + Added pfclip parameter
  + Added MMX scenechange routines (for those that don't have an isse capable cpu)
  - Changed default scthresh value to 12.0
The pfclip parameter is like ppClip in TBilateral... it allows you to specify a separate clip to use for calculating pixel differences (motion checks, scenechange detection, and inverse difference weighting). The weights calculated with the pfclip values are then applied to the original input clip's pixel values when calculating the output.
tritical is offline   Reply With Quote
Old 18th November 2005, 05:17   #37  |  Link
hartford
Registered User
 
hartford's Avatar
 
Join Date: Nov 2003
Posts: 324
Thanks.

Thought that the "weird" settings that I used was some misunderstanding on my part.

Now I'll need to "disabuse" myself of that
hartford is offline   Reply With Quote
Old 18th November 2005, 09:07   #38  |  Link
Didée
Registered User
 
Join Date: Apr 2002
Location: Germany
Posts: 5,389
Quote:
Originally Posted by tritical
The pfclip parameter ... allows you to specify a separate clip to use for calculating pixel differences
Yippieh! Thanks! (Gonna try LTbS outa R24 for that.)
__________________
- 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!)
Didée is offline   Reply With Quote
Old 18th November 2005, 10:58   #39  |  Link
yaz
n00b ever
 
Join Date: May 2002
Posts: 627
vouw ... thx a lot ! best gets even better

thx
y
yaz is offline   Reply With Quote
Old 19th November 2005, 00:42   #40  |  Link
tritical
Registered User
 
Join Date: Dec 2003
Location: MO, US
Posts: 999
I am considering changing how pfclip works to be exactly like ppClip in TBilateral, but a little explanation is needed first...

In TBilateral each pixel in the filtering window gets assigned a weight based off two things 1.) distance from the center pixel 2.) difference between it and the center pixel... the filtered value is simply the sum of pixel*dis_weight*diff_weight for all pixels in window. Using this method, the center pixel itself always gets the same amount of weight (and the largest) because its difference is always 0 and it's distance is always 0 (though in my implementation its distance weight is the same as that of its four nearest neighbors). ppClip changes how the pixel difference weights are calculated. Instead of using the original center pixel value to compute differences, the corresponding (location wise) pixel value from ppClip is used instead. Now when the difference weights are computed, each pixel inside the filtering window on the original clip is tested to see how different it is to the ppClip pixel and not the center pixel. In this scheme it is possible for the center pixel to get almost no weight if its value is significantly different than the corresponding value in ppClip, and it is also possible for the other pixels in the window to get large weights even if they are significantly different than the center pixel.

TTempSmooth works pretty much the same way as TBilateral, but in the temporal domain, with different weighting functions, and it searches from the center out (stopping when it finds a pixel not passing the motion test) instead of always including every pixel in its filtering window. Currently, when pfclip is specified, all motion tests and pixel differences are computed on frames from the pfclip (no pixels from the input clip are used). That means that the pixel differences are between the neighbor frames and the center frame of the pfclip. The weights computed via using the differences and motion checks from the pfclip frames are then applied to the pixel values from the original input clip frames in order to compute the final filtered value.

In order to work the same way that ppClip in TBilateral does, the motion tests and pixel differences should not test between pfclip frames, but should test the difference between the original input frames and the center frame of the pfclip. A problem arises though from the center out search method... what if a center frame pixel no longer passes the motion test? In my mind it doesn't make sense to include the center frame pixels as part of the outwards search, thus the solution would be to always test the immediate neighbors regardless of whether the center pixel passes. Another problem is that it is possible for the pfclip pixel to not be within threshold of any of the input clip pixels (all pixels get zero weight)... in such cases the original input clip pixel would be used as is.

I am not sure which type of operation is more useful, but unless someone objects I'm gonna post a new version tommorrow that works as described in the last paragraph above.

Last edited by tritical; 19th November 2005 at 00:45.
tritical is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 00:38.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.