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. |
18th June 2004, 06:34 | #21 | Link |
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.
|
18th June 2004, 18:26 | #22 | Link |
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 |
23rd June 2004, 17:48 | #23 | Link |
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 |
25th June 2004, 12:22 | #24 | Link |
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.
|
25th June 2004, 12:39 | #25 | Link |
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. |
3rd May 2005, 05:53 | #26 | Link |
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. |
6th May 2005, 07:20 | #27 | Link |
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 |
21st June 2005, 06:29 | #28 | Link |
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.
|
20th July 2005, 21:22 | #29 | Link |
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. |
20th July 2005, 22:45 | #31 | Link |
AviSynth plugger
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. |
21st July 2005, 08:16 | #32 | Link |
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. |
21st July 2005, 22:58 | #33 | Link |
AviSynth plugger
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. |
21st July 2005, 23:33 | #34 | Link | |
Clouded
Join Date: Jul 2003
Location: Cambridge, UK
Posts: 1,148
|
Quote:
|
|
18th November 2005, 04:04 | #36 | Link |
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 |
18th November 2005, 09:07 | #38 | Link | |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
Quote:
__________________
- 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!) |
|
19th November 2005, 00:42 | #40 | Link |
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. |
Thread Tools | Search this Thread |
Display Modes | |
|
|