That is what Olive video editor does (free/libre).
1 Like
This is what audio video pipelines, like direct show, have been doing for years, and it works well! In this ecosystem, plugins are typically called codecs.
You have to be carefull on interfaces âcontractsâ, maybe define categories for example to ensure a kind of consistency. A well-thought framework is mandatory.
Gnu Radio is another very good example.
1 Like
Wow, thanks for pointing that out! Finally, a FOSS video editor that isnât using an int8 internal pipeline.
1 Like
Well in the example given of vkdt module, it seems that it is almost a plugin.
The glsl code can be compiled by the program itself and passed to th gpu.
The interface seems to be described by simple text file, so vkdt would be able to read it an create the interface for the module, may be with some limits in funcionality, but enough for making tests.
As you say it would be great to be able to test some contribution like sigmoid without waiting for developers to add it to main stream (in case the do).
As long as you are using not supported plugin, any problem it could cause would not be attributed to main stream modules.
A way to envelope that plugins in a security shell and catch exceptions to tell the user the problem comes from that plugin would be needed.
1 Like
Why not distribute the plugins along with the rest of the source code to help ensure compatibility?
Because it needs the approval of the devs and it will be then an official module and would have to be maintained by the team.
The problem with sigmoid, for example is that you cannot test it or use it if you like it, you have to download the fork, compile it (or get a precompiled version made by someone).
As you cannot be sure the version would be the same and ther would be compatibility problems with database, you have to use it with a subset of your photos and a separate database.
If there is a plugin mechanism, the developer of the plugin is responsible of distributing it and maintain it.
1 Like
So youâll need a group to test, curate, and maintain the list of plugins?
I donât understand, the independent plugin would be curated and maintained by its programmer and tested by the users interested in it.
It would be much easier for users to install a new plugin than having to recompile a fork and deal with the fork and the main stream program.
There are many software that works with plugins in many fields (Photoshop being one in our field) and they are great for users.
I donât know if developing a plugin interface for a raw developer would be more complicated, but from a user standpoint it will be interesting and usefull.
Yeah, thatâs exactly the point.
That is exactly why I did not test sigmoid too much, but with a few images, and could not follow its evolution.
Gimp has plugins and has a ton of them. Finding them and the correct version (and a binary if you want any sort of speed) is a pain.
Having plugins scattered all over the place with varying levels of conformance will be a poor user experience.
That is not a reason.
If you do not want to find them, just use the provided ones.
There can be repositories of third party plugins and they can be incorporated to main stream as soon as they are stable enough and main devs consider them good enough.
A pain is having lots of modules obsolete and conserved just for compatibility.
If they were plugins they could be deprecated and added only when the user wants them.
A pain is having tons of different open source software for developing and having to seek for them and test them until you encounter what you like, but worse is not having them and not finding one that you like. That is the very nature of open source.
1 Like