On 09/14/2012 05:06 PM, Marko Cebokli wrote:
> Hello Francesco,
>
> sad to hear Transcode is fading away, I noticed that there were no new
> updates, but did not know it has gone that far.

Yeah, unfortunately that the way it is. The process of porting filters
from transcode
to frei0r is indeed one try to save something good from the project and
to have
some good karma :)

> I was planning to make a patch for the stabilizer, to improve edge handling,
> since I still prefer to use Transcode's two pass stabilizer than any other
> Linux based stabilization.

Georg Martius (author of vid.stab, the filter we are talking about)
has a github repo here: https://github.com/georgmartius/vid.stab
and as far as I know this is the reference repository.
For the record, I also have an always-in-sync fork here just for minor
hacks here: https://github.com/mojaves/vid.stab

I already wrote some code to interface vid.stab with frei0r:
https://github.com/mojaves/tycho-plugins/tree/master/srcvs/filter

Just two caveats:
- the code uses some bits of the extensions we're talking about
and some (minor, ported, self contained) transcode utility libraries
- the code assumes vid.stab is avalaible somewhere as separate source tree

But if the code looks good enough can be adapted to the plain frei0r
interface
with a few tweaks.

> As for the ports, we already have hqdn3d ported to Frei0r, a couple of face
> maskers, a levels plugin, and a couple of quite versatile lens distortion
> correctors.
> Denoisers other than hqdn3d (and denosie3D, which is very similar) and
> sharpeners other than simple USM would be welcome I think, I am working myself
> on some right now.

OK understood, is less or more what I thught. So, seems there isn't much
to save from the transcode filter set after all.
> As far as extending the Freior API I would (STRONGLY?) object to bringing YUV
> (Y'CrCb) type color spaces into the interface. Requiring the plugins to
> support several color spaces causes a horrendous bloat to the code, especially
> as there are a zillion different YUV type color spaces (packings). If we start
> by admitting one, this might open the floodgates, I am afraid.
> And there is nothing much to be gained from YUV, except maybe some speed, and
> some gamut nobody really needs. In all other respects, YUV is inferior to RGB.

I see your point and I think I'm gonna shred the YUV thing from my
extension set.

I anyway added some other goodies which could be interesting for the
community,
like (semi)automatic option handling for C plugins (ref:
https://github.com/mojaves/tycho-plugins/blob/master/include/frei0rx_param.h)

But I think I need to write down some docs before to discuss this :)

Bests,

--
Francesco Romani // Ikitt