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 Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 20th August 2005, 23:06   #1  |  Link
Manao
Registered User
 
Join Date: Jan 2002
Location: France
Posts: 2,856
MaskTools 2.0a48

Hi,

As I said in the Avisynth 2.6 thread, I'm working on the MaskTools again. The code has been rewritten from scratch, mainly to make it easily portable to the upcoming Avisynth 3.0.

All inline asm has been ported to nasm. Some filters have disappeared. Some behaviors have changed. All named have changed, to allow you to use both MaskTools v1.5.8 and 2.0a.

Refers to the readme.txt to have a quick summary of the filters and what have changed since the 1.5.8.

This thread is here to collect bug reports and feature requests.

Here is the link to the new version : http://manao4.free.fr/masktools-v2.0a48.zip

Changes from alpha 47 to alpha 48 :
Code:
 * added : signed and unsigned binary shifts to LUTs, ceil/floor/trunc float -> int conversions. @ is now equivalent to °
Changes from alpha 46 to alpha 47 :
Code:
 * added : signed and unsigned binary operators to LUTs
Changes from alpha 45 to alpha 46 :
Code:
 * fixed : with mt_lutf, "std" mode wasn't working. Could also affect "std" with mt_luts and mt_lutsx
Changes from alpha 44 to alpha 45 :
Code:
 * fixed : mt_clamp on sse2 platforms with resolution not multiple of 64
 * added : mode parameter to mt_lutspa, to clean up biased/relative mess
Changes from alpha 43 to alpha 44 :
Code:
 * added  : new very flexible mode to mt_luts and mt_lutsx
Changes from alpha 42 to alpha 43 :
Code:
 * fixed : optimized versions of small horizontal resolutions with mt_edge, mt_xxpand and mt_xxflate
 * fixed : avisynth 2.6 support (likely broken since avisynth 2.6 alpha 2 at least)
 * added : hprewitt mode to mt_edge
 * added : "biased" option to mt_lutspa
 * optimized : prewitt and hprewitt mode for mt_edge
Changes from alpha 41 to alpha 42 :
Code:
 * added : specialized modes for mt_binarize
 * added : specialized modes for mt_logic
Changes from alpha 40 to alpha 41 :
Code:
 * (re)optimized : mt_edge with custom kernels and divisors that are a power of two</li>
 * fixed : mt_edge with custom kernels (has always been broken in C, which became obvious once asm was removed)</li>
 * fixed : no more crashes when an input clip isn't YUV planar
Changes from alpha 37 to alpha 40 :
Code:
 * optimized : mt_xxpand vertical/horizontal/both modes are asmized
 * optimized : mt_xxflate are asmized
 * optimized : mt_motion with sse2
 * potential fix : mt_merge with mod8 width
 * potential : 64 bits build included
Changes from alpha 36 to alpha 37 :
Code:
 * fixed : mt_polish wasn't handling "z", "min", "max", "clip" and "round"
 * added : mt_infix, which convert from polish to infix notation
 * changed : built with MSVC 2008
Changes from alpha 35 to alpha 36 :
Code:
 * fixed : "pi" wasn't properly defined for all luts
Changes from alpha 34 to alpha 35 :
Code:
 * added : mt_lutspa
Changes from alpha 32 to alpha 34:
Code:
 * added : support for interleaved2planar hack, enabling 422 support
 * changed : both avisynth 2.5 and 2.6 version are built
Change from alpha 31 to 32
Code:
 * added : mt_lutxyz
 * added : mt_lutsx
 * fixed : small memory leak in mt_luts
Change from alpha 30 to alpha 31
Code:
 * fixed : mt_hysteresis was randomly crashing.
 * fixed : mt_polish is back.
 * added : round, clip, min, max and = for lut.
 * adapted : to msvc8 / yasm.
Change from alpha 29 to alpha 30
Code:
 * fixed : luts was crashing if some pixels didn't have any neighbours in the pixels list.
 * added : mt_freerectangle, mt_freeellipse and mt_freelosange helpers.
Change from alpha 28 to alpha 29
Code:
 * fixed : intern float to integer conversion that were badly rounding negative
 number. That resulted in -1.0 been rounded into 0 (!). Most notably affected was
 mt_convolution. Thanks redfordxx for pointing that out.
Change from alpha 27 to alpha 28
Code:
 * fixed : asm optimizations for mt_inpand/mt_expand/mt_edge ( mostly )
Changed from alpha 26 to alpha 27 :
Code:
 * fixed : mt_binarize asm optimizations that borked with some thresholds
Changed from alpha 25 to alpha 26 :
Code:
 * fixed : avs closing issue
Changed from alpha 24 to alpha 25 :
Code:
 * added : new html documentation.
 * fixed : wrong frame issue.
 * fixed : mt_merge with luma=true.
Changed from alpha 23 to alpha 24 :
Code:
 * fixed : issues with MT.dll ( thanks tsp, Boulder, vanessam and all those who suffered the bug )
 * fixed : check for YV12 colorspace, and report an error if it isn't ( thanks Boulder )
 * speed up : median mode for luts ( once again, thanks to tsp )
Changelog from alpha 22 to alpha 23:
Code:
 * fix & speed up : median mode, thanks to tsp's insightful remarks. Note to self : think
less like a mathematician, and more like a programmer. Simpler, faster & not bugged.
Changelog from alpha 21 to alpha 22 :
Code:
 * added : "med"/"median" mode to luts/lutf
 * changed : luts doesn't necessarily consider the center pixel
 * changed back : forms helpers prepends (0, 0). 
 * changed : forms helpers now have a bool "zero" parameter, defaulted to true
 * added : bool "luma" parameter to mt_merge, which makes it use the luma mask for
all three planes, and which forces chroma modes to "process" ( u=v=3 )
Changelog from alpha 20 to alpha 21
Code:
 * fixed : some filters were requesting wrong frames, thus creating ghosts
Changelog from alpha 19 to alpha 20 :
Code:
 * bugfix release
Changelog from alpha 18 to alpha 19 :
Code:
 * code refactoring
 * fixed : bug with asm and width lower than 64
 * fixed : doesn't prepend (0, 0) pixel to the forms helpers
 * added : "min/max" mode to mt_edge. The edge value is local max - local min ( taken on a
3x3 square ).
 * added : mt_lutf : a frame lut
 * added : mt_luts : a spatial lut
Changelog from alpha 17 to alpha 18 :
Code:
 * added : mt_makediff, mt_adddiff, mt_average and mt_clamp, ported from mg262's
limitedsupport plugin. The asm code is his, though it has been ported to nasm. They
respectively amount to MakeDiff, AddDiff, SimpleAverage and Clamp.
 * added : mt_edge : "prewitt" kernel, taken from mg262's Prewitt filter. Unlike mg262's filter,
there's no multiplier ( it's always 1 ), but mt_edge's thresholds still apply. Results,
and speed, are identical except for the borders, which are now filtered.
 * added : "chroma" parameter, taken from mg262's excellent idea. It's a string that,
if used, overrides U and V values. It can be either "process", "copy", "copy first",
"copy second" or a number. "copy" and "copy second" work alike.
 * added : vmToon-0.74, adapted to masktools 2.0.
 * added : LimitedSharpenFaster, with LimitedSupport functions imported into the masktools.
Changelog from alpha 16 to alpha 17 :
Code:
 * changed : behavior of mt_edge with a custom kernel : the automatic normalization factor
is now the sum of the absolute value of the coefficients, ceiled to the next power of two 
if that power is <= 128 ( else, it isn't ceiled ).
 * added : cartoon mode for mt_edge
 * added : modified mfToon script, for masktools v2. mfToonLite's speed goes from 30 fps
to 70 fps, mfToon from 4.5 to 6.5.
Changelog from alpha 15 to alpha 16 :
Code:
 * fixed : some asm code used in invert, binarize and memset to a particular value.
Bug made the first 8 pixels of the picture to be incorrect. Also, avoid another nasty issue
that arise when cropping ( not my fault this time, though ).
Changelog from alpha 14 to alpha 15 :
Code:
 * fixed : bugs from inflate & deflate ( thx you know you )
 * reversed : inflate and deflate now match their masktools' v1 counterparts' behavior.
( if anybody used the new buggy one, let him speak quickly )
Changelog from alpha 13 to alpha 14 :
Code:
 * fixed : random crashes with some width and asm functions ( thx Didee )
Changelog from alpha 12 to alpha 13
Code:
 * fixed : mt_merge order swapped for mask operation ( no comment... )
Changelog from alpha 11 to alpha 12
Code:
 * fixed : bug with some width ( mod4 ) for the non processing mode ( != 1 or 3 )
 * changed : mt_merge order swapped for mask operation
Changelog from alpha 10 to alpha 11
Code:
 * fixed : mt_convolution's multiple instanciation bug
Changelog from alpha 9 to alpha 10
Code:
 * fixed : offY was always set to offX
 * fixed : offsets quirk
 * fixed : mt_convolution was crashing with floats
 * changed : luts' equal operator is now equivalent to abs(x - y) < 0.000001
 * added : bool saturate(true) parameter to mt_convolution
 * added : float total(1.0) parameter to mt_convolution
Changelog from alpha 8 to alpha 9
Code:
 * fixed : mt_lut, mt_lutxy : even faster loading
 * fixed : mt_convolution : negative coefficients were offseted by 1
 * fixed : mt_convolution : division by zero if the sum of the coefficients was 0.
Changelog from alpha 7 to alpha 8 :
Code:
 * fixed : mt_edge in custom mode wasn't working properly 
 * fixed : mt_edge in custom mode, optimized wasn't working properly either
 * fixed : mt_lutxy was slow to load, it's better now
Changelog from alpha 6 to alpha 7 :
Code:
 * fixed : forgot to add functions to the parser. Thanks Didee for pointing that out
Changelog from alpha 5 to alpha 6
Code:
 * fixed : mt_polish ( sin(x+y) wasn't properly converted, while sin((x+y)) was)
Changelog from alpha 4 to alpha 5
Code:
 * added : helpers for creating string for inpand / expand custom modes :
   - mt_circle
   - mt_square
   - mt_diamond
   - mt_ellipse
   - mt_rectangle
   - mt_losange
 * added : helper for lut : consersion from infix to reverse polish notation : 
   - mt_polish
Changelog from alpha 3 to alpha 4
Code:
 * Added : custom modes for inpand / expand
Changelog from alpha 2 to alpha 3 :
Code:
 * Fixed : mt_invert, mt_binarize, mt_lutxy, which weren't working properly anymore
 * Fixed : offset created by incorrect rounding in mt_convolution
 * Fixed : mmx version of edges filters ( soft thresholding, and roberts )
 * Fixed : mmx version of motion edge ( soft thresholding )
 * added : mt_mappedblur
Changelog from alpha 1 to alpha 2 :
Code:
 * added functions to luts : sin, abs, cos, tan, exp, log, acos, atan, asin
 * added "vertical", "horizontal" and "both" mode to mt_inpand / mt_expand
 * added mt_convolution
 * fixed mt_merge behavior for y, u, v = 2.
 * added y, u, v = 4, for masked merge : copy the second clip channel. It's worth for any two clips input filters.
 * internal changes ( code reorganization )
Edit : url updated

Last edited by Manao; 31st December 2010 at 18:22.
Manao is offline   Reply With Quote
Old 21st August 2005, 06:39   #2  |  Link
Mug Funky
interlace this!
 
Mug Funky's Avatar
 
Join Date: Jun 2003
Location: i'm in ur transfers, addin noise
Posts: 4,555
w00t! just d/l'd and i'll check it out ASAP.
__________________
sucking the life out of your videos since 2004
Mug Funky is offline   Reply With Quote
Old 21st August 2005, 15:20   #3  |  Link
unskinnyboy
Registered User
 
unskinnyboy's Avatar
 
Join Date: Feb 2004
Location: NTSC R1
Posts: 2,046
Awesome! On it!
__________________
unskinnyboy is offline   Reply With Quote
Old 21st August 2005, 22:54   #4  |  Link
unskinnyboy
Registered User
 
unskinnyboy's Avatar
 
Join Date: Feb 2004
Location: NTSC R1
Posts: 2,046
@Manao: This version doesn't seem to work with LimitedSharpen. I get this:



Usually this error comes when the MaskTools are not updated (?). But here, is it because of the change in Luts? How do I get this to work with LimitedSharpen now?

P.S: I hope I posted in the right place.
__________________
unskinnyboy is offline   Reply With Quote
Old 21st August 2005, 23:22   #5  |  Link
scharfis_brain
brainless
 
scharfis_brain's Avatar
 
Join Date: Mar 2003
Location: Germany
Posts: 3,653
Uhm, read Manaos 1st post more carefully.
Read the readme of Masktools 2.0a
__________________
Don't forget the 'c'!

Don't PM me for technical support, please.
scharfis_brain is offline   Reply With Quote
Old 21st August 2005, 23:25   #6  |  Link
Didée
Registered User
 
Join Date: Apr 2002
Location: Germany
Posts: 5,389
unskinnyboy - read the txt in the package, it cannot work out-of-the-box. All filter names have changed, so you'd have to edit all calls to MaskTools' filters in LS by yourself.

Manao: --> <--
I've prepared a small feature suggestion regarding in|expand, but right now it's out of reach, on the other machine ... will post it probably on Tuesday. Basically, it's about the possibility of splitting them into horizontal/vertical operation only. Hopefully this not too extravagant.
__________________
- 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 21st August 2005, 23:34   #7  |  Link
unskinnyboy
Registered User
 
unskinnyboy's Avatar
 
Join Date: Feb 2004
Location: NTSC R1
Posts: 2,046
Ah ok. As I thought..wanted to confirm nonetheless..:|

@Didée, Will you be rewriting LS for this version of MaskTools?
__________________
unskinnyboy is offline   Reply With Quote
Old 22nd August 2005, 06:13   #8  |  Link
AVIL
Registered User
 
Join Date: Nov 2004
Location: Spain
Posts: 408
Feature request

Hi,

I've read the readme.txt file with the filters included in the new release. YV12Convolution is not ported to this new tools. I use it, and think is useful because his generality.

I tink also it could be useful a thresholded blur. A filter much like mt_inpand/mt_expand but averaging only those pixels with a value near at the center's value by, at most, a parametred threshold. The rest of the pixels will be discarded for the averaging. It can be parametred also the behaviour of the filter in the case when none neighbour went into average. By example replacing center by 0 or not touching center's value.

Anyway, that's tools are unvaluable. Thanks.
AVIL is offline   Reply With Quote
Old 22nd August 2005, 06:21   #9  |  Link
Manao
Registered User
 
Join Date: Jan 2002
Location: France
Posts: 2,856
Indeed, YV12Convolution hasn't yet been ported. It'll be, soon I guess.

For the thresholded blur, I can do it, but it already exists. The beavior you're describing looks a lot like deen(a2d / w2d / c2d) behavior, and I don't want to reinvent the wheel ( especially when the existing wheel is fast )
Manao is offline   Reply With Quote
Old 22nd August 2005, 07:57   #10  |  Link
AVIL
Registered User
 
Join Date: Nov 2004
Location: Spain
Posts: 408
Hi,

My goal with the thresholded blur is making "edge aware" averaging. All the pixels very different to the center's one (possible edge) are completely discarded (not zeroed) from the average. For my purpose the center must be excluded also.

Convolution3D and (I suppose) Deen don't discard pixels, limit it to the threshold instead. And process the center also. The result is different, mostly if the center is very different from neighbours (isolated dots).
AVIL is offline   Reply With Quote
Old 22nd August 2005, 08:56   #11  |  Link
Manao
Registered User
 
Join Date: Jan 2002
Location: France
Posts: 2,856
Ok, in that case, I'll see what I can do.
Manao is offline   Reply With Quote
Old 22nd August 2005, 09:34   #12  |  Link
Didée
Registered User
 
Join Date: Apr 2002
Location: Germany
Posts: 5,389
Quickly - -

AVIL: The idea of edge-aware averaging is certainly good, but surely it is more complex ... there arise *many* questions of what to do, what not, and why and how ...
Probably it would be a good idea to make up a separate thread for that. For sure I would participate if you make one

>> Convolution3D and (I suppose) Deen don't discard pixels, limit it to the threshold instead

No. I'm pretty sure (for C3D: absolutely) that pixels within <thresh> contribute to the avaraging, and pixels outside of <thresh> do not. They are not "include-everything-and-limit-the-result" filters.
This' for both filters, and ...

>> And process the center also

both treat <thresh> based on the center pixel, of course. Deen, however, has the possibility to reduce <thresh> as pixels go farther away from the center.


Manao: What I already have thought about is, perhaps, a filter that works similar to the new edgemask-thresholding you did introduce: A kind of blur filter where, for every pixel, the thresholds of what-to-include are given by either one additional clip (thresh radius is specified by this clip) or two additional clips (by which absolute upper & lower thresholds are specified).
This would rise possibilities like selfmade edge-aware blurring (or sharpening), selfmade bilateral filtering, and probably some more I currently can't think of.

However, this definetly should be a separate filter, not part of the MaskTools, IMO.
__________________
- 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 22nd August 2005, 11:59   #13  |  Link
AVIL
Registered User
 
Join Date: Nov 2004
Location: Spain
Posts: 408
@Didée

I'm trying to denoise a video with two copies. Instead of make a mix with overlay, I choose from every copy the pixel who best match an ideal value. I calculate this value averaging the neighbourgs. But the edges (and spurious pixels) distort the prediction. So I wish ignore them.

My information about C3D comes from :

Tutorial about C3D

This page states that the surrounding pixels are used always, but with a value adequate to the threshold. And by comparating C3D with average procedure make by scripting with mvtools I agree with the author of the page.

Anyway thanks for your offer.
AVIL is offline   Reply With Quote
Old 22nd August 2005, 13:27   #14  |  Link
Didée
Registered User
 
Join Date: Apr 2002
Location: Germany
Posts: 5,389
No.

Code:
x1=blankclip(color=$666666,width=640,height=240).converttoyv12()
x2=blankclip(color=$AAAAAA,width=640,height=240).converttoyv12()
before=interleave(x1,x2).assumefieldbased.weave()
after=before.convolution3d(1,16,16,16,16,3,0)
interleave(before,after)
There is zero change. Period. Now try the same with Deen.

Please inform that page's author that he is spreading misinformation. (The page won't even load for me...)


edit (to Manao below): That's unfair, I had no chance to read that page
__________________
- 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!)

Last edited by Didée; 22nd August 2005 at 13:52.
Didée is offline   Reply With Quote
Old 22nd August 2005, 13:50   #15  |  Link
Manao
Registered User
 
Join Date: Jan 2002
Location: France
Posts: 2,856
Actually, the page is correct, but both of you misanderstood it ( I cheated, I'm french ) : it says that all value above the threshold are replaced by the center pixel's value. So in Didee'd sample test, nothing is changed.
Manao is offline   Reply With Quote
Old 23rd August 2005, 10:49   #16  |  Link
AVIL
Registered User
 
Join Date: Nov 2004
Location: Spain
Posts: 408
I'm sorry

@Didée

I apologize for give a link in french. Actually, I work in a french multinational enterprise ("chez Renault") and don't mind that not everybody can read french pages.

@ all

Anyway, I'd prefer not to process the central pixel because it can be spurious. In this case, no neighbourg can be selected, and the adecuate value for my purposes is more difficult to state. Perhaps the average value of the neighbours or the median value (more edge-aware). Actually, I have resolved the process with scripting but involves 8 or 9 convolutions (fast due to yv12convolution) to separate every neighbourg in a different clip and average it with kassandro's corrector filter (for thresholded average). It works but is slow.

Bye
AVIL is offline   Reply With Quote
Old 23rd August 2005, 10:54   #17  |  Link
Manao
Registered User
 
Join Date: Jan 2002
Location: France
Posts: 2,856
Convolution is coming tonight, hopefully. But i never considered yv12convolution to be fast ( no mmx code ).
Manao is offline   Reply With Quote
Old 23rd August 2005, 11:35   #18  |  Link
AVIL
Registered User
 
Join Date: Nov 2004
Location: Spain
Posts: 408
@Manao

Thanks for your quick response. I'd say yv12convolution is fast because the comparation with the alternative (generalconvolution) that involves colourspace conversion (RGB32 only).
AVIL is offline   Reply With Quote
Old 23rd August 2005, 12:24   #19  |  Link
Didée
Registered User
 
Join Date: Apr 2002
Location: Germany
Posts: 5,389
AVIL - the problem wasn't the page in french, but rather the "page not found" I was getting. >today< it loads for me, but too late ...


Manao -

>> i never considered yv12convolution to be fast ( no mmx code )

Ah. Would this answer your own wondering, time back, why I'm often using DEdgeMask where YV12Convolution would be the obvious filter?


Okay ... here my little suggestion for inpand and expand:

As noted, it would be nice to have the possibility to in/expand only horizontally, or only vertically. When working e.g. with comb masks, or horizontal-only/vertical-only edgemasks, the advantages are obvious.

Plus there's one thing more behind it. When internal code for one-dimensional in/expanding is available, then an additional operation could be implemented: a merging of [normal expand] + [horizontal+vertical expand].
Why? to get "round corner" expanding. Currently, a chain of 10*expand() will turn e.g. a point into a 21*21 square. With "round corner" expanding, one would get a circle of diameter 21. There are cases where this would be desireable, because the "distance" of the filtering is of equal length in all directions, then. For simple expanding, there is a distance deviation of sqrt(2) - - too long in diagonal direction.

For the case of expand, I put together a scripted variant ... of course its pretty slow, but hey, it deals for visualization only.
Code:
function expand2(clip clp, int "direction", int "Y", int "U", int "V")
{
direction = default(direction, 3)
Y =         default(Y,3)
U =         default(U,1)
V =         default(V,1)

    direction==0 ? clp.expand(Y=Y,U=U,V=V)
\ : direction==1 ? clp.expand_H(Y=Y,U=U,V=V)
\ : direction==2 ? clp.expand_V(Y=Y,U=U,V=V)
\ : direction==3 ? logic( clp.expand_H(Y=Y,U=U,V=V),
                    \     clp.expand_V(Y=Y,U=U,V=V),
                    \     "max",Y=Y,U=U,V=V)
\ : direction==4 ? yv12lutxy( clp.expand(Y=Y,U=U,V=V),
                    \         logic( clp.expand_H(Y=Y,U=U,V=V), 
                    \                clp.expand_V(Y=Y,U=U,V=V),
                    \                "max",Y=Y,U=U,V=V),
                    \          "x 71 * y 100 * + 171 /",Y=Y,U=U,V=V)
\ :                clp.subtitle("illegal direction :p")
}
function expand_H(clip clp, int "Y", int "U", int "V")
{
Y = default(Y,3)
U = default(U,1)
V = default(V,1)
logic( clp, logic( clp.yv12convolution("1 0 0","1",Y=Y,U=U,V=V),
 \                 clp.yv12convolution("0 0 1","1",Y=Y,U=U,V=V),
 \                 "max",Y=Y,U=U,V=V),
 \     "max",Y=Y,U=U,V=V)
}
function expand_V(clip clp, int "Y", int "U", int "V")
{
Y = default(Y,3)
U = default(U,1)
V = default(V,1)
logic( clp, logic(clp.yv12convolution("1","1 0 0",Y=Y,U=U,V=V),
 \                clp.yv12convolution("1","0 0 1",Y=Y,U=U,V=V),
 \                "max",Y=Y,U=U,V=V),
 \     "max",Y=Y,U=U,V=V)
}
Procedure:

expand2(direction=0) --> normal expand()

expand2(direction=1) --> horizontal-only expand()

expand2(direction=2) --> vertical-only expand()

expand2(direction=3) --> horizontal+vertical expand() ("triangular" effect when chaining several instances)

expand2(direction=4) --> "round corner" expand()


I think this would be sensible to implement ... in one form or the other, not necessarily the way I did above. Are there any hurdles I don't see?
__________________
- 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 23rd August 2005, 12:52   #20  |  Link
Manao
Registered User
 
Join Date: Jan 2002
Location: France
Posts: 2,856
Didee : OK, so basically, you want the following kernels for inpand / expand :
Code:
      1    1    111
111   1   111   111
      1    1    111
That will be easy to add.
Manao 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 16:45.


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