Request: could someone code up new crop() filter ?

[vhelp]

At present, the current crop(a,b,c,d) is quite cryptic to me.

Sometime, I just want to quickly crop a given clip at an arbituary size,
though I usually account for the boundery marks (ie, 4 pix; 8 pix; etc)

In virtualDUB, its easy. And, you can in one shot, top/bot/LF/RT, and
with easy language. You can do it at any number of pixel lines, and
vidub won't bark at ya for not adhering to the boundery laws.

For instance.. if I want to crop 40/54 (top/bot) I would use:
crop(0,0, 40,54) bringing my video size to 720 x 386
then, in TMPGenc, if there were issues with the resolution, I would
make final adjustments with it's Center Video and crop/mask the affending
pixel lines. This always works perfect for me. But, I am trying to
move towards AVIsynth, and cropping is a big factor in many of my
video projects, but w/ AVIsynth's current built-in crop() filter,
its not for me. Anyways..

There are many different variations that I use, and I use vdub for
all of them because AVIsynth's way of cropping is too cryptic and
not easy to setup and deal with on the fly. You have to sit there
and think about the params a bit, before you proceed. This has the
adverse effect to ruening the moment or my train of thought for the
given video project. I've found myself just abandoning AVIsynth
for this reason, and many others. But I'm trying to change that :)

A new cropTBLR() similar to virtualDUB's would help me (and others)
out a lot.

So, can someone quickly develop a new crop filter please ??

Here's to anyone considering.. :thanks:

-vhelp

[Guest]

Write an Avisynth script function; it's trivial.

[vhelp]

>> Write an Avisynth script function; it's trivial.

Yes. To you it is. To me.. it is not.

I have lots of filter ideas, but I lack some of the *trivial*
parts that is supposively easy. I know I can do it, in time.
But, that seems months ahead, with me doing it. And, at this
time, I can not do it.

-vhelp

[vhelp]

Now, in delphi, I could do it.

I would start with two bitmaps.

bitmap A would be my 720 x 480 (that's my source)

bitmap B would be the waiting 720 x 386 (based off my crop calculation)
and, which would eventually be the copy of the cropped 720 x 386 pixle
data from bitmap A.

Basically, I would screen_copy(0,0, 40,54) the area to be cropped, and
then bitblp() it into bitmap B.

This is my quick and dirty method of obtaining a cropped area of a
given bitmap. It's not so easy in AVIsynth language. Plus, I do
not wish to create filters (function) scripts. I want to create
DLL functions.

-vhelp

[stickboy]

Try my CropWrapper function (http://www.avisynth.org/stickboy/), part of jdl-wrappers.avsi.
Originally posted by vhelp:
Plus, I do not wish to create filters (function) scripts. I want to create DLL functions.Uhhh... oh-kay. Your loss, I suppose.

[mg262]

@vhelp,

Is this of any use: if you put a script file containing script functions in the plug-ins autoload directory, and give it the extension .avsi, then those functions will be autoloaded in the same way as plug-ins... so it's transparent to the average user. (Hence the extension on stickboy's cropwrapper.)

[Didée]

There are many different variations that I use, and I use vdub for all of them because AVIsynth's way of cropping is too cryptic and not easy to setup and deal with on the fly.
Well, here's where a quote from Confucius fits very well:

"Don't waste your time searching for an obstacle: perhaps there is none."

Really, I fail to see your problem. Your problem of
For instance.. if I want to crop 40/54 (top/bot) I would use:
crop(0,0, 40,54) bringing my video size to 720 x 386...
in AviSynth simply is written as

crop(0,40,-0,-54)

which I don't consider as cryptic, but rather logical. Would you say you cannot drive any other car than your own one, because all other cars have slightly different operational controls? I bet you won't, and can drive other cars than your own very well. ;)

Finally, the following function gives you the desired functionality:

function cropLRTB(int l_vhelp, int r_vhelp, int t_vhelp, int b_vhelp)
{ return crop( l_vhelp, t_vhelp, -r_vhelp, -b_vhelp) }

Placing this function in your script (or saving it to "cropLRTB.avsi" and import()-ing it), you can use

cropLRTB(0,0,40,54)

just like you want to do.

The downside is: typing "LRTB" takes more time than using AviSynth's native crop() command correctly :p

[Guest]

The downside is: typing "LRTB" takes more time than using AviSynth's native crop() command correctly Didn't you mean "cropLRTB"? :)

[Didée]

No. "crop" has to be typed, anyway. The overhead lies in typing "LRTB". ;)

[Guest]

No. "crop" has to be typed, anyway. The overhead lies in typing "LRTB". ;) Oh, of course. Silly me.

[hartford]

Dumping the "-" would be nice, ie, instead of Crop(0,0,-0,-0), nicer would be Crop(0,0,0,0)

Would "fit" with AddBorders().

[Video Dude]

You need the "-" since there is more then one way to use crop.


Crop(left, top, width, height)

Crop(left, top, -right, -bottom)



Say you have a a 720x480 video and want to crop to 704x480
then the next two Crop statements are equal:

Crop(8, 0, 704, 480)

Crop(8, 0, -8, -0)

[stickboy]

Really, I fail to see your problem. Your problem of

in AviSynth simply is written as

crop(0,40,-0,-54)

which I don't consider as cryptic, but rather logical.Negative values are nonsensical and aren't what I'd consider intuitive or logical (especially a notion of negative zero!). That Crop has a special meaning for them is kind of a hack.

[Mug Funky]

the -0 can be replaced by 0 without problems.

now, negative numbers would make sense if it was assumed to be "width - x" and "height - y" with the "width" and "height" removed. but i'm plenty used to how avs's crop works, and i wouldn't want anyone to change it and break all our scripts.

[edit]

also, if you crop using the resizers, you can indeed crop by negative numbers. it's rather like using "addborders()" except the extra pixels are just repeats of the nearest image pixel. this is extremely useful for resizing NTSC 525 to PAL 625 and accounting for the blanking intervals (like a standards converter does). it means you get 1.5 pixels of black at the top and bottom of the PAL image.

[mg262]

I think the original post may have been more about the necessity for mod-x widths and heights and was a request for someone to build a wrapper that took 'illegal' values for these and then did something sensible with them (like adding black borders)... @vhelp?

[vhelp]

Yes to Neuron2, that is what I ment.. cropLRTB()

All's I wanted for x-xmas was a simple DLL (not function) filter, as an
alternative to the already cryptic crop() :scared:

I never knew that typing the extra char's would be considered overhead( another :scared: )
to make it unworthy.

Ok. Here is my last and final suggestion..

xCrop()

Thanks again,
-vhelp

[Guest]

Every time someone doesn't like the core syntax, we'll have to release a third-party equivalent with the desired syntax? Or is it just your needs that are special?

[vhelp]

For a forum that is soo diverse and in many ways, openly and willing
to create filters; functions; and expressions of ones ideas; even
if crazy-sounding at times, I am surprised; confused; and sad with
all the run arounds I have received since I made this request :confused:

I did not anticipate this small request to become a contraversal topic,
when in short, all consensus could have resulted in a simple and quick
"no" :eek:

I appreciate all those who contributed their thoughts and alternative
methods. I really do. I thank you all, for them.

And now.., withdraw my request for an new alternative crop() filter (plugin)
for AVIsynth. No hard feelings intended :scared:

As always, thank you. (its still a great forum) :)

-vhelp

[Nic]

Create your own crop filter...that's madness, what idiot would do that....
http://forum.doom9.org/showthread.php?p=166565&highlight=niccrop#post166565

I didn't understand the Crop filter at the time, hakko in that thread corrected me. The reason Crop uses negative numbers was to make sure it was backwards compatible as many people were using Crop in its original form. You soon get used to it, and i'm sure you will too vhelp. Or someone can rip out NicCrop from MPEGDecoder and rename it to xCrop for you (but that's a little hassle) ;)

-Nic

[stickboy]

All's I wanted for x-xmas was a simple DLL (not function) filter, as an
alternative to the already cryptic crop() :scared:You already got two people to provide you with script functions that do exactly what you want! What's wrong with them? What is your obsession with DLLs?
the -0 can be replaced by 0 without problems.Oh, right. The parser makes them equivalent. Duh, what was I thinking. Well, anyway, I certainly don't think Crop's syntax should be changed, I just don't agree that it's logical.

Edit:
Quote attribution corrected. Whoops. :)

[foxyshadis]

I guess he thinks that the overhead of a function call and translation of arguments is a major loss that will add minutes on to encoding time. I'm sure if he was encoding billion frame videos it might, but he might run into other problems before that. ^.~

Rename cropLRTB to xCrop, stick it in your scripts, benchmark it if you're really anal, and go on with life.

[mg262]

Originally Posted by mg262
the -0 can be replaced by 0 without problems.
Weren't me, mate :)

But I agree on both counts... the current syntax is silly, but we're stuck with it because we can't break half the scripts in existence (at least before version 3?)

@vhelp,

I think that people are having real trouble understanding why you want a DLL rather than a script function... in general DLLs are less transparent than script functions and can be modified by fewer users, so script functions are preferred except in cases where speed is an issue -- which is certainly not the case here. Even if someone were to write a DLL, it wouldn't do anything other than calling the built-in crop with a negated argument, which is exactly what the script function does... so, although I appreciate that you've withdrawn your request, I would personally really like to know why you are so keen on script functions.

[Leak]

calling the built-in crop with a negated argument, which is exactly what the script function does...

Also, this call with a negated argument is done exactly once, namely when parsing the script and setting up the filter chain, not every frame... so I wouldn't even think of starting to write a filter for that... :confused:

Also, what's wrong with the notion of a crop from the right or bottom side being done with a negative number? You're going in the negative X and Y direction from the border, after all...

np: Richard Devine - Helix Stair Helve (Cautella)

[IanB]

Just to clarify, functions cost nothing in execution time and only a very small amount in "compilation"/constructor time. So the CropLRTB() function above would costs nothing in execution.

IanB