If I may pitch in: why not separate issues? I could imagine a generic convolutional nn filter which gets given topology and weights via some config file. Then provide files separately for this particular trained network.
Gruß! Daniel Oberhoff > Am 03.07.2018 um 14:11 schrieb Gyan Doshi <gyando...@gmail.com>: > > >> On 03-07-2018 12:49 AM, Jean-Baptiste Kempf wrote: >> On Mon, 2 Jul 2018, at 20:52, Pedro Arthur wrote: > >>>> This code is not open source, and is not compatible with LGPLv2.1: >>>> >>>> "If you use/adapt our code in your work (either as a stand-alone tool or >>>> as a component of any algorithm), >>>> you need to appropriately cite our ECCV 2014 paper or arXiv paper." >>>> >>>> Reimplementation of the code in a different language does not remove IP. >>> The paper is properly cited in libavfilter/vf_sr.c. >>> >>> I not specialist in IP rights but there is nothing novel in the code >>> (TBH there is no code at all, look at srcnn.m) it is just plain >>> convolution, basic math machinery, we are just applying a bunch of >>> filter convolution to an image. >> Well, either it is based on a paper and the matlab code, or it is not. >> If it is, it's a big issue, since this is not open source compatible. >> If it is just convolution, then why is it based on this paper? >> What is the source of those numbers? >>> If you're referring to using his trained data, Ok, we could train our >>> own weights if it is really an issue. >> Sorry, but you need to be able to give the source of your code. Aka the >> original source that can create the code. > > I was planning to document this filter this coming weekend, but if there's > serious doubt over its inclusion, I'll wait. > > Gyan > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
