Automatic colorspace conversion

[CAFxX]

Someone proposed it (http://forum.doom9.org/showthread.php?p=318381#post318381) a while ago, and now it has come back into my mind.
In that thread, Sh0dan explained then why he wouldn't implement it: a colorspace conversion is too costly both quality and performancewise to do it without user interaction
While its explanation is undoubtably right, I think it misses a point.
(for the sake of simplicity, let's assume we have two types of users: normal users - those who come here asking "how do I deinterlace this?" or something similar, grab the script they're provided and go home happy - and "pro" users - those writing thousand-lines scripts, and answering the afore-mentioned questions)
For the normal user this would mean that avisynth (the plugin actually, I'll explain this soon) chooses the best conversion. So many times when I first started learning avisynth I made idiotic conversions (sometimes I still find some of those old scripts and I really can't understand why I did them that way) that surely slowed the script down much more than if avisynth (correctly) did them.
For the "pro" user (that would be aware of this mechanism) this would simply mean writing less code.

Code-wise the idea would be to implement an alternative to GenericVideoFilter, which would accept in the constructor the supported and preferred colorspaces.
In the above case, we have three scenarios:
the filter's input is in a unsupported cs
the filter's input is in a supported cs, but not the preferred one
the filter's input is in the preferred cs
For the first and third case, there are no problems. For the second we shall give the user the ability to control this behaviour.
This leads us somewhat to a "configuration option" that should be settable from inside scripts.
Something like:
AutomaticColorspaceConversion(warning=true, preferred=false, enabled=true, ...)
(default values are casual)
where <enabled> would control automatic conversion, <preferred> would control if a supported cs should be converted to a preferred cs, <warning> would enable/disable an alert box/log file where the user would be warned of the automatic conversions performed and so on.
Moreover, the alternative GenericVideoFilter could be instructed to check whenever an explicit colorspace conversion was invoked immediately before and in that case disable automatic conversion (or maybe just the conversions to preferred cs).
In this way we give everyone (both developers and users) the power to control this mechanism. Plugins shall be recompiled with filters instantiated from the alternative GenericVideoFilter, and users will have to enable this explicitely (maybe just by putting it in an .avsi).
The only possible con I can spot is that plugin developers may become even more lazy and refuse to implement colorspace-specific versions of their algorithms. Though, this happens even today so...

Enough talking for me today... now it's your turn!

[IanB]

Yes, you have described the model in use for audio filter auto-conversions. That model has the unfortunate effect of silently zapping high res audio back to 16 bits if there is no float implementation of the algorithm (e.g. Old ResampleAudio before I did a float version, grrr. SSRC does float but has no fast 16 bit.)

In video there is frequently never a best choice for default behaviour. Very similar arguments apply to the rules in this forum about asking for best.

Personally, I feel such a feature would cause more harm than good for the general community. Filter authors are always free to autoconvert in there constructor code, but I would discourage such practice.

[CAFxX]

Yes, you have described the model in use for audio filter auto-conversions. That model has the unfortunate effect of silently zapping high res audio back to 16 bits if there is no float implementation of the algorithm
That's where the (disableable) warning popups should help.

In video there is frequently never a best choice for default behaviour. Very similar arguments apply to the rules in this forum about asking for best.
My fault, I used the wrong word. I should have said "the conversion doing the less harm". RGB32->RGB24 does not harm quality-wise. RGB32->YV12 does, as we all know. In fact, when in the previous post I was talking about the "best" conversion, I wasn't just talking performance-wise, but also quality-wise.
And yes, I know there are grey areas where nobody can say which conversion is the "best". But, as I already said, this behaviour could be overridden in a number of ways (e.g. making an explicit conversion before the filter - this btw should preserve compatibility with any script written prior the advent of this mechanism)

Personally, I feel such a feature would cause more harm than good for the general community. Filter authors are always free to autoconvert in there constructor code, but I would discourage such practice.
Actually this is precisely what we're talking about (autoconverting in the constructor).

Anyway, I see no particular interest for this feature, so I guess it won't make its way in the official avisynth.
Maybe I'll try on my own to do some kind of middle-layer library that requires no changes to the core.

[IanB]

That's where the (disableable) warning popups should help.Note: In the general case Avisynth must never pop a Message/Dialog Box. It is an internal (extension) component of the Windows VFW AVI interface.RGB32->RGB24 does not harm quality-wise.This loses the Alpha channel....RGB32->YV12Interlaced??? Rec709???

As I said hiding the colour space conversions is really a disservice to the community. Yes it can be confusing for a novice, but it is very important that they at least know there is an issue they need to ask about.

env->Invoke("ConvertToYUY2", args); is what you want to build your solution.

[Richard Berg]

The solution here is wrapper functions.


function FilterWrapper(clip c, bool "showWarnings" = false)
{
c.IsRGB() ?
\ c = showWarnings ? MessageClip("converting to RGB") + c : c
\ c = c.ConvertToYUY2
: NOP
c.Filter()
}