View Full Version : Convolution3D
vlad59
4th December 2002, 16:13
Thanks all for your kind words :D :D :D
As soon as C3D YV12 beta 3 seems to be stable enought. I'll ask Sh0dan to add it in avisynth 2.5 and maybe to have CVS access.
Satlover
4th December 2002, 22:54
Sorry I have to ask this but can some one help me where can I find the
C3D YV12 beta 3?
avisynth 2.5 ?
At the moment I am using avisynth 2.07
Dreassica
4th December 2002, 22:59
Check the YV12 FAQ topic which is Sticky at the top of this forum section. There u wil find all the links u will need.
Satlover
4th December 2002, 23:40
I have got my script to work, Not sure about the following for a 3CD rip (752x432)
1) Which filters? the MPEG2Dec3.dll or MPEG2Dec3 YV12.dll
2) Convolution3D.dll or Convolution3D_YUV12.dll
(what settings?)
3) Lanczos3 resize or bicubicresize ?
LoadPlugin("C:\DVD\AviSynth2\plugins\MPEG2Dec3 YV12.dll")
LoadPlugin("C:\DVD\AviSynth2\plugins\Lanczos3.dll")
LoadPlugin("C:\DVD\AviSynth2\plugins\Convolution3DYV12.dll")
vid=mpeg2source("F:\video.d2v")
#vid=LumaFilter(vid) #(for iago :-) same as lumaoff=-2
vid=Crop(vid,1,70,-1,-70) #(keep even crop values, at least horizontally)
vid=lanczosResize(vid,752,432) #keep as multiples of 16
#vid=bicubicresize(vid,752,432,0,0.5) #you might like this
Return vid
Any inputs would help a begginner
Thanks
cult
5th December 2002, 16:48
LoadPlugin("C:\DVD\AviSynth2\plugins\MPEG2Dec3 YV12.dll")
LoadPlugin("C:\DVD\AviSynth2\plugins\Convolution3DYV12.dll")
mpeg2source("F:\video.d2v")
LumaFilter()
Crop(vid,1,70,-1,-70)
Convolution3d (preset="movieHQ")
bicubicresize(752,432,0,0.5)
you dont need to load lanczos as it is implented in avisynth.you can replace bicubicresize(752,432,0,0.5) with LanczosResize(752,432)
Satlover
5th December 2002, 18:34
Thanks allot cult, strange I got an error message. No function named lumafilter. Guess I'ts a dll I need.
mikeson
5th December 2002, 18:59
@Satlover:
vid=lanczosResize(vid,752,432)
What is the original video resolution?
If your source is DVD I believe it is 720x576, so why are you extending to something like 752x432? You gain nothing but bigger picture without detail increase, so overall quality will be worse, because codec has to spend more bitrate. ;)
mikeson
5th December 2002, 19:10
@Satlover:
strange I got an error message. No function named lumafilter. Guess I'ts a dll I need.
It's really weird, because LumaFilter is MPEG2Dec3YV12 function.
Are you sure you've got latest version?
Satlover
5th December 2002, 19:25
Yes you are right, 720x576 is correct. So now I have 720x432 if I use 720x576 the screen widens. Thanks for pointing that out!
Satlover
5th December 2002, 19:29
I am now getting great results with this. Thanks for all the help, comments are welcome :-)
LoadPlugin("C:\DVD\AviSynth2\plugins\MPEG2Dec3.dll")
LoadPlugin("C:\DVD\AviSynth2\plugins\Convolution3DYV12.dll")
mpeg2source("F:\1.d2v")
Sharpen(0.5)
LumaFilter(-2, 1.02)
Crop(2,70,-2,-70)
Convolution3d (preset="movieHQ")
LanczosResize(720,432)
mikeson
5th December 2002, 19:41
@Satlover
Yes you are right, 720x576 is correct. So now I have 720x432 if I use 720x576 the screen widens. Thanks for pointing that out!
I'm glad to help. ;)
Sharpen(0.5)
Consider using trbarry's UnFilter. I think it is great filter IMHO. ;)
Marc FD
8th December 2002, 17:40
hi ^^
i coded a conv2d filter for my XviD DFD-optimised prefilter,
and i decided to do 3d with (when you have 2d, 3d is easy),
and i coded 3 hours today to finish it. it's a 3d convolution
with 27 real checkpoints per pixel and 111/121 matrix.
speed behaviour is _very_ strange.
so i've three questions :
@vlad
1) is convolution3d doing 27 REAL checks per pixel ??
2) is convolution3d a release build ??
2) is convolution3d really MMX optimised ??
3) can i use "c3d" or "conv3d" or something like that in the name of my filter ??
@all
4) i dunno how to name my filter... "c3d"(2?) ? or "convolution3d(2)" ? or something like that. i'm opened to any suggestion.
(at this rate i'll name my filters noname1,noname2,... ^^)
i could release it now, but i don't have a name (current is "c3d")
vlad59
8th December 2002, 19:38
Originally posted by Marc FD
@vlad
1) is convolution3d doing 27 REAL checks per pixel ??
2) is convolution3d a release build ??
2) is convolution3d really MMX optimised ??
3) can i use "c3d" or "conv3d" or something like that in the name of my filter ??
@all
4) i dunno how to name my filter... "c3d"(2?) ? or "convolution3d(2)" ? or something like that. i'm opened to any suggestion.
(at this rate i'll name my filters noname1,noname2,... ^^)
i could release it now, but i don't have a name (current is "c3d")
For the question :
1) Yes
2) It should be, I hope.
2) Yes
3) I would prefer another name to avoid some misunderstanding but I have no idea for this (I'm really bad in choosing filters name).
What do you mean but strange speed behaviour ?
Marc FD
8th December 2002, 19:58
>3) I would prefer another name to avoid some misunderstanding but I have >no idea for this (I'm really bad in choosing filters name).
okay.. it's very close to convolution3d, but it's definitively not the same filter, because i coded it from scratch and i never taked a deep look into convolution3d source (that's why i don't know how it works)
>What do you mean but strange speed behaviour ?
it's very strange, i'd like to be sure it's not a dumb error....
i'll explain later... i need to fix something, and to find the name.
vlad59
8th December 2002, 21:17
@Marc
I forgot I was mainly talking about Convolution3D for avisynth 2.5 (YV12). The YUV2 version is also optimized but the code is crappier.
The YV12 version is also still optimizable (don't know if it's good english ... :p ), I gained +2~3 % this weekend just by switching some MMX instruction order.
I'm eagerly waiting for your filter.
Marc FD
8th December 2002, 21:57
...
i lost 1 hour to debug something really dumb, but now it works VERY well.
i'll try to package a preview ^^
Marc FD
8th December 2002, 22:08
(attached "tiya3dd.zip")
@all
try this stuff : that's how i do 3d filtering in 6 hours coding.
enjoy.
Marc FD
8th December 2002, 22:23
another questions, vlad :
- so you didn't separated the matrix at all ??
- when you do your 27 checks, are you always using the center pixel as reference ??
Guest
8th December 2002, 22:42
Marc, can you please start a separate thread for your filter? It is considered bad form to hijack threads. Thanks!
vlad59
9th December 2002, 06:49
Originally posted by Marc FD
another questions, vlad :
- so you didn't separated the matrix at all ??
- when you do your 27 checks, are you always using the center pixel as reference ??
1) I don't understand your question ???????????
2) Yes 27 real check always with center pixel.
EDIT : When I use your filter I have a non empty FPU state error (emms missing) in Vdub !!!! Am I the only one ?
Marc FD
9th December 2002, 13:04
EDIT : When I use your filter I have a non empty FPU state error (emms missing) in Vdub !!!! Am I the only one ?
yes i forgot the emms at the end. in fact i didn't forgot it, it was just a preview and it was working, so...
@don
you're right. (but i missed a name. found one myself finally ^^)
i apologize, i'll do a new thread with a stable version with readable readme ^^
CruNcher
9th December 2002, 22:28
I experienced a problem with Vlads convolution which i have not with the filter from Marc after using Convolution YV12 1 Right Line gets Cutted away and some wierd White lines appear in this black region at playing the Xvid really strange effect also 1 white dot above this black region and 1 below this black region are encoded
this affect is not appearing wiht Marcs Filter so i think its a convolution error ?
vlad59
9th December 2002, 22:36
Strange effect .....
Are you using beta 3
Can you post your avs script (because the width constraint was only removed with beta3 so I may have forgot something).
And expect more speed in beta4, I really made some bad code in beta3 ....
CruNcher
9th December 2002, 22:45
LoadPlugin("MPEG2Dec3YV12.dll")
LoadPlugin("DecombYV12.dll")
LoadPlugin("tiya3dd.dll")
LoadPlugin("avsmon25a.dll")
MPEG2Source("test.d2v",idct=5,iPP=true,cpu=5)
crop(10,1,698,572)
FieldDeinterlace(full=true,chroma=true,blend=true)
#tiya3dd(1,10,10,30)
Convolution3d(preset="vhsBQ")
LanczosResize(512,384)
MonitorFilter
thats the avs i used every filter is the newest version i hope
1.0.0.3 Version number of your filter YV12 & SMP Build
PS: Yes i know that are very aggresive settings but i want maximum compressability and for everyone who wants to know this is running @
4 Fps on my P4 1.8 :D
The Edge
9th December 2002, 23:10
I'm also having a problem with Vlad's convolution3D.
I notice if I use it before resize, I get a fuzzy line top and bottem of image and a white dot on the bottem left corner.
If I then put convolution AFTER the resize, no problems.
Same with simple, sharp or Lanczos Resize. No other AviSynth features in use.
Not a codec issue as when avs is opened in VDub, i notice this fuzzy line. I can post a screen shoot if you wish.
Also, does not matter what settings I choose with C3D.
Edge
CruNcher
10th December 2002, 00:43
Jep can confirm thats a solution :)
The Edge
10th December 2002, 00:54
P.S.
My 1CD encodes of "Minorty Report" and "Vanilla Sky" look great thanks to Convolution3D.
Thanks Vlad :)
Edge
kilg0r3
10th December 2002, 10:12
@The Edge :)
i know this is not the place, yet could you post your script and codec settings for these movies?
JimiK
10th December 2002, 13:05
As you all may know, sometimes filters have problems when you feed them with an uneven number of lines. That could be a reason that it works after resize and not before. My solution for this problem is the following: Of course you want to crop before using filters to gain speed. And you want to get rid of every part of the black bars. So you crop them and get an uneven number of lines. To gain some speed and still feed an even number into the filters you could to try it this way.
crop(8,64,0,-72) #dividable by 8
filters...
crop(1,5,-2,-2) #no more black bars
resize
Even if there are black bars after the first crop, you threw away lots of unused stuff. The picture size is dividable by 8 and the second crop cuts of the last black bars before resize.
Best regards,
JimiK
kilg0r3
10th December 2002, 13:43
1. I'd suggest to simply crop to even numbers. i even always crop to mod8, especially when not resizing my 2cd rips
2. The problem seems to occur when c3d is used before the _resizer_. are there people resizing to uneven values???
[Southern Germanan reproval] erscht läse donn schraiwe. s'negschte mol, gell. [/Southern Germanan reproval]
The Edge
10th December 2002, 21:46
Convolution3D used before resize.
LoadPlugin("C:\GORDIA~1\mpeg2dec.dll")
LoadPlugin("C:\GORDIA~1\Convolution3d.dll")
mpeg2source("D:\VOBs\ALI\project.d2v")
crop(11,75,700,427)
Convolution3D (0, 3, 4, 3, 4, 2.8, 0)
LanczosResize(512,208)
The Edge
10th December 2002, 22:28
Convolution3D used after resize.
LoadPlugin("C:\GORDIA~1\mpeg2dec.dll")
LoadPlugin("C:\GORDIA~1\Convolution3d.dll")
mpeg2source("D:\VOBs\ALI\project.d2v")
crop(11,75,700,427)
LanczosResize(512,208)
Convolution3D (0, 3, 4, 3, 4, 2.8, 0)
The Edge
10th December 2002, 22:35
Having alot of difficultly posting today.
It is much more easier to see this effect with a sample .avi
@kilg0r3
Don't know if I have them still saved on my hdd but I'll have a look.;)
Edge
JimiK
10th December 2002, 23:09
@kilg0r3
What do you mean with "first read then write"? After it's written in german I think you mean me. First I have to say that just cropping to even numbers is absolutely required if you don't resize, because most codecs don't like und uneven input.
"The problem seems to occur when c3d is used before the _resizer_": I don't think anybody would resize to an uneven number of lines. I just wanted to present a solution for people that want to use filters after crop, but before resize. I'm one of the persons that are convinced that the quality is better when using filters before resize.
Best regards,
JimiK
vlad59
11th December 2002, 08:44
I think that with C3D v1.01 and C3DYV12 beta 3 the width has to be mod-2.
@the Edge
I think you're using the YUV2 version of C3D ..... And I was checking with the YV12 -> gonna recheck tonight.
sh0dan
27th December 2002, 12:09
@vlad: I hope you haven't left us - haven't seen you around in a while.
Anyway, I have been thinking about how to improve the speed of your filter, and something stroke me.
If you are game for a wild experiment I think we could speed up your filter very much. It would also simplify your filter very much.
The key to success ;) lies in preparing your data prior to processing it. By that I basicly mean repacking your data for much faster (and non-branching) access.
You are processing up to 27 pixels to produce one pixel - these pixels are scattered all around both spatial and temporal.
If you instead started your filter out by putting these 27 pixels in a row you wouldn't have to change your read pointers all the time.
For cache efficiency you should process one line at the time.
Create an array sized (32*rowsize) (8 byte aligned) [called a1]
Create an arrray of 32 bytes (this is for your thresholds) [a2]
Create an arrray of 32 bytes (this is for your weights) [a3]
Creare an array to store your data.
Then copy the pixels from the source images into array a1 - you can safely use plan C here - I don't think you'll get much of a speedup here.
Now place the appropriate thresholds in a2 and the weights in a3.
As you can see now you have all your data aligned up properly, and you can do all your processing in one pass. Actually you can safely do 8 pixels in parallel. (and don't mind the extra 5 pixels processed, just set threshold to 0)
If you need to look up the final pixel value, store the accumulated data in the destination array, and do the final lookup in C, when the entire line has been processed. Make your lookup table as small as possible!
If you are _really_ clever - you even try not adding the cases where threshold=0 to a1,a2 and a3. However I'm not sure how much you would gain, since your algorithm would become more complex. Only do so if you are sure you can save 8 or 16 bytes.
ps. please do an isse implementation when doing min/max functions - it's so much faster ;)
pps. this could also be an excellent excuse for you to change PlugInInit to PlugInInit2 and remove the case sensitive presets :)
edit: only planar makes it possible :)
Marc FD
29th December 2002, 22:46
arhg XD..
i don't understand anything...
say me if it gives more than a +50% speedup (that's what i get with my c3d implementation), i'm interessed ^^
sh0dan
29th December 2002, 23:37
In temporalsoften it provided a speedup of several hundred percent, using a quite similar approach (single line / multiple pass processing), and (depending on your current implementation), it'll probably give at least a 100% speedup.
Marc FD
30th December 2002, 00:10
strange, i don't get it.
my c3d implementation is very simple (10x less code than vlad) but gives (sometimes) the same results than vlad's one.
i don't use any max/min, what's the use of these ?
why do you unpack the pixels ?? i keep vectorized acces, and i unpack only internally for accumumation. maybe creating a unpacked array will speedup the whole thing, but i'm not sure at all, because i would need to fetch 300% more data, it may be a too big overhead.
maybe it'ld be good to prepare a interleaved work area ? but it'll be 27x bigger than a single line, and preparing it will need a lot of time...
i think i don't understand your suggestion. maybe i should look deeper in the temporalsoften code ^^.
sh0dan
30th December 2002, 00:24
It's very hard to say, without seeing your code.
What I'd _imagine_ is that you are spending a lot of time rearranging data for your spatial blur. Either you are getting many misaligned reads (not doing 8-byte aligned movq's or not doing 4 byte aligned movd). Otherwise you are probably shifting a lot around.
This method will allow you to do all your processing without unpacking/moving or shifting any data before you have to do the accumulation.
Regairding the data size - it'll actually reduce data load. If you process _one line at the time_, and overwrite the unpacked data, it'll remain in cache as long as your code runs - so there will be no memory usage between load/store - all inbetween will be caught by the cache, if you read/write your data aligned.
bb
30th December 2002, 00:27
Actually, sh0dan's ideas for optimization reflect what I proposed a long time ago... I'm really curious how this will work out. I guess Convolution3D is one of the most used filters, so your efforts will be much appreciated. Keep up the good work.
bb
Marc FD
30th December 2002, 01:40
>It's very hard to say, without seeing your code.
sure.
>What I'd _imagine_ is that you are spending a lot of time rearranging >data for your spatial blur. Either you are getting many misaligned >reads (not doing 8-byte aligned movq's or not doing 4 byte aligned >movd). Otherwise you are probably shifting a lot around.
right. misaligned movq's. 18 unaligned and 9 aligned per loop (8 pixels/loop).
>This method will allow you to do all your processing without >unpacking/moving or shifting any data before you have to do the >accumulation.
? i don't care, i do it in the same time than accumulation anyway.
>Regairding the data size - it'll actually reduce data load. If you
>process _one line at the time_, and overwrite the unpacked data, it'll
> remain in cache as long as your code runs - so there will be no
>memory usage between load/store - all inbetween will be caught by the
>cache, if you read/write your data aligned.
okay, but you'll spend a lot of time to interleave... i don't see why it would be faster to do it before.
>Actually, sh0dan's ideas for optimization reflect what I proposed a
>long time ago... I'm really curious how this will work out.
me too. but i'd like to understand it first ^^
vlad59
3rd January 2003, 18:29
@Sh0dan
As you can see in another C3D thread I made a new release of C3D, it includes the min/max function and 8 bytes in parallel instead of 4 before.
I'm surprised about your request about case non-sensitive presets, it should have been fixed in beta3
I also added a fast mode with 11 checks instead of 27 for more speed.
As I'm getting a little more time, I reread your post and I really don't know if it will give a major speedup (but I'll test it anyway). I would have helped a lot un yuv2 but not in yv12.
Strange I'll have to test it.
Another strange thing with C3D is as soon as I try to add a __declspec(align(8)) to have aligned const -> my dll crash ..... really strange :confused:
Anyway happy to be back and thanks for helping me to update C3D
N_F
11th March 2003, 10:28
@vlad59
Quick question: Do you consider C3D finished or are you still working on it?
Ewi
11th March 2003, 17:13
Another question: I can't find any recent usage experiences. Is this Beta for most people rather stable? As it is perhaps one of the most used filters this seems to be interesting and perhaps this is an important factor for a wider usage of AviSynth 2.5, cause many people want 'their' beloved filters.
How far is MarcFD implementation of C3D? Is it almost at the same level or perhaps already more stable?
Thank you in advance...
vlad59
11th March 2003, 18:00
Hi all,
It's been a long time.
I'm very very busy and I think I'll be away for a long time. For me C3D was always under heavy developpement. But as I've no more to spend on it, I will make a public release of the version I was working on. And let's hope someone will continue my work.
IIRC MarcFD's Deen was not as precise as C3D during the threshold check but it was faster, but I have to admit that I never used it or any avisynth filter for the last 2 months :( .
Bye to all and thanks you for all the good time I spend reading and writing in this forum.
bilu
11th March 2003, 18:02
@Ewi
There is already an implementation of C3D for AVS 2.5 .
In AVS 2.07 I preferred Fluxsmooth over C3D mainly for speed reasons but in AVS 2.5 C3D is faster, and works very well. :)
Vlad, you posted first. :)
Best regards,
Bilu
Ewi
11th March 2003, 20:21
Really sad to here that, Vlad... C3D is so far the external filter I used mostly. I don't really know you but I think it was always the fact that you were never arrogant to people not knowing the basics and you were always open for suggestions and help from others.... So, although I'm not really one of the Doom9-important-persons, I would like to say, that I hope we will see you again here...
Thank you...
Marc FD
16th March 2003, 20:22
>IIRC MarcFD's Deen was not as precise as C3D during the threshold
>check but it was faster,
well, AFAIK, precision in Deen is as high as it could ever be ^^.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.