Talk:Internal filters

From Avisynth

IMHO, we need in some more detailed classification (but no so detailed as in drafs of External_plugins).

Here is my draft: User:Fizick/Internal_filters

I divided "image prosessing" section, rename "editing" section and move Reverse and Subtract to main items.

--Fizick

Don't you think we need to use the same classifications for all filters?

If the choices used in the 3rd column are not the same for all filters, those categories become a lot less useful.

If you want to see ONLY the source filters that are internal, that is still possible in this scheme. You can do an intersection: [1] Recursive browsing is also possible: [2]

--RichardB 03:34, 11 May 2007 (PDT)

Both can be used actually, since a page can belong to as many categories as wanted. The first is a classification on the property "origin", the second on the property "purpose" of the filter. And IMO both are needed, because - if we use the database analog of a table of filters, where the primary key is the filter's name and all other properties (origin, purpose, etc.) are the secondary keys - depending on case one might want to search the filter's table on different key(s).

"origin" is a property with well defined categories in the sense that there can be no overlap between categories; a filter will either be internal or external and in the later case either plugin or script (there is of course the possibility of mixed implementations). "purpose" on the other way has the potential to create overlaps between categories (a filter may belong to >= 2 categories) but it is a very useful property to search on. Thus, I would tend to the following proposal for filter's categories:

"origin" and "implementation" properties:

• Category:Filters -> for every filter (ie a clip producing or transforming function, either c++ based or script-based), so that a search by name on all filters is possible.

• Category:Internal filters -> for every internal filter.
• Category:External filters -> for every external filter, either c++ based or script-based.

• Category:C/C++/Assembly-based -> for every external filter that is C/C++/Assembly based.
• Category:Script-based -> for every external filter that is script-based.
• Category:Mixed-based -> for every external filter that is a mixture of a C/C++/Assembly core with a thin script-based wrapper.

• Category:Script functions -> for every function (either c++ or script-based) that does not produce or transform a clip (with the exception of clip properties, see below).

• Category:Internal functions -> for every internal script function (they are all C++, thus no sub-categories are needed).
• Category:External functions -> for every external script function, either c++ based or script-based.

• Category:C/C++/Assembly-based -> for every external script function that is C/C++/Assembly based.
• Category:Script-based -> for every external script function that is script-based.
• Category:Mixed-based -> for every external script function that is a mixture of a C/C++/Assembly core with a thin script-based wrapper.

• Category:Clip properties -> for every function (either c++ or script-based) that returns a property of a clip.

• Category:Internal properties -> for every internal clip property (they are all C++, thus no sub-categories are needed).
• Category:External properties -> for every external clip property, either c++ based or script-based.

• Category:C/C++/Assembly-based -> for every external clip property that is C/C++/Assembly based.
• Category:Script-based -> for every external clip property that is script-based.
• Category:Mixed-based -> for every external clip property that is a mixture of a C/C++/Assembly core with a thin script-based wrapper.

The above setup needs only 9 categories (3 for filters, 3 for functions, 3 for properties) plus 3 categories for the implementation and each page will have only 3 categories, which is not that much. In exchange filters, functions and properties will be very easy to search.

purpose property:

• Fizick's categories (or any derived scheme) are adequate; they are supplementary indexes - very useful for the case when one knows what he/she wants to do but does not know the filter/function that is needed to do the job - that can easily be enriched with other classifications in the future, as the need arises.

Gzarkadas 05:55, 11 May 2007 (PDT)

Yes, of course both can be used. In my table above, I was showing what I want, not a problem :) I propose every filter have exactly one category from column 2 (what you called "origin" -- I changed the table to match) and at least one category from column 3 ("purpose").

What I don't want is confusion as to what the possible choices are. We need 1 system for origins, and 1 system for purposes. In other words, even if filters end up belonging to several "purpose" categories, the set of "purpose" choices should be consistent. Back to the database analogy, lots of secondary keys is fine, but we still need a schema :) More to the point, we need to choose whether the options for column 3 ("purposes") will be chosen from the ones currently on Internal_filters or the ones currently on External_plugins.

I think your "origin" schema is too complex. What is an example of a Mixed-Based? I can't think of any. And why do we need so much duplication across levels? Let the CategoryTree extension I linked above handle the recursion.

To recap from Doom9, here was my proposed "origin" tree:

Filters
 |----Internal filters
 |----External filters
         |------External plugins
         |------Script functions

There are only 3 choices (Internal, External_plugins, Script_functions) because only the leaf nodes would be assigned to filter pages. Intermediate nodes like External_filters would be a category page that were themselves part of their parent category (Filters).

If we want to capture other details, such as whether or not a script returns a clip, that should be part of the "purpose" hierarchy, or perhaps a totally separate hierarchy.

--RichardB 10:40, 11 May 2007 (PDT)

It seems complex because there is a hidden function type property. I resume the scheme below in tree notation:

function type
|----filter          (produces/transforms a clip)
|----clip property   (accepts a clip and returns a non-clip value)
|----script function (every other case)

origin
|----internal        (Avisynth distribution)
|----external        (other authors)

implementation
|----C++/C/Asm
|----script
|----both (this is the mixed case, which although rare it is possible)

The payoff is that it is all-inclusive; there aren't cases left out. In addition some leafs of the possible combinations are already in the wiki (for example Script functions, Clip properties and need not be repeated in the filters section.

The filters section could just be (in tree notation):

Filters
 |----Internal filters
 |----External filters

and all the rest information inside the categories of each page, possibly amended by a template at the start of the filter stating origin and implementation.

That way only two manually edited tables need to be created (one already exists for internal filters) that group the filters on purpose; the rest would just be links to autogenerated by the wiki categories pages. Gzarkadas 15:32, 11 May 2007 (PDT)

There is also another issue for discussion:

Plugins may contain more than one filter (for example MaskTools). If we classify filters individually, as is the case with internal filters (and IMO is implicit to this whole discussion), then "External plugins" is not an appropriate category, since plugins are in general containers of filters.

IMO plugins should be classified in a separate hierarchy along with all other possible containers (such as script libraries). To be economical, single filter plugins may be ommited from there. Gzarkadas 15:32, 11 May 2007 (PDT)

I don't agree. 1 page per plugin makes the most sense to me, regardless whether the plugin is a collection of many filters. What category is Decimate? It only makes sense as part of the Decomb collection. Do we really want a separate page for all 26 TransAll filters? I don't think so. Yes, this means collection plugins (MaskTools) and single-filter plugins (FFT3DFilter) will have the same Origin Category: 'Plugins'. I think that's fine. If you want to also tag collection plugins with another category, that's fine too. --RichardB 00:09, 25 May 2007 (PDT)

Thanks for some discusion. But firsly I wanted to discuss my classification (purpose or action) only.

At doom9 Wilbert said, that internal filters must have specific classification. I am not sure, but in this case I put my suggestion above.

External filters classification is a another (important) question. I must try think more and put my suggestion a little later (I do not like 'Restoration' category). May be common classification with internal. Many (most) plugins are from Special category of Internal classifucation. Generally, we may remove from future version of avisynth some obsolete special fiters.

But 'Script functions' and 'non-clip Properties' are certainly not for these 'purpose' classification (and there are not so many non-internal). they are not FILTERS. An why use so complex? --Unreal666 13:54, 2 April 2012 (UTC)--Unreal666 13:54, 2 April 2012 (UTC)--Unreal666 13:54, 2 April 2012 (UTC)--Unreal666 13:54, 2 April 2012 (UTC) IMO origin Categories:

Filters
 |----Internal filters
 |----Plugin filters
 |----Script filters

Good point about plugin's functions!

But 'External plugins' is bad name. What is 'Internal plugins'? Directshowsource? Fizick 18:08, 11 May 2007 (PDT)

Ok. How about just 'Plugins' ? --RichardB 00:09, 25 May 2007 (PDT)

> UToY / VToY Copies chroma U/V plane to Y plane (image is now half as big)

It depends on YUV format.

I fixed this.

--Unreal666 16:09, 2 April 2012 (UTC)