I fully agree too. Best, Jean-Michel
Jean-Michel Morel moreljeanmic...@gmail.com On Tue, Jul 4, 2017 at 4:10 PM, Jose Luis Lisani <joseluis.lis...@uib.es> wrote: > I agree with Miguel suggestions about the Submission Procedure and the > Software Guidelines. > I can update the information appearing in the web page, but first we > should all agree in the new guidelines. > > Miguel proposes: > > Note that the submitted code must at least fulfill these minimal >> conditions: >> >> - Be written in C/C++, Python, or MATLAB with minimal dependencies. >> - Must compile and run at least in a Debian Stable distribution. >> >> The editor will guide the authors throughout the publication process >> giving technical support when needed. >> > > Any additional remarks? > > Best, > José Luis > > > > > On 04/07/17 14:57, Miguel Colom wrote: > >> Dear all, >> >> I've been reviewing our Submission Procedure in >> http://www.ipol.im/meta/submission/ and I think we should change it. >> >> It says the following: >> <<< >> Note that to be able to obtain an online demo, code must at least fulfill >> these minimal conditions: >> >> be written in C89, C99 or C++98, usable on a 64-bits Linux system; >> use only libtiff, libjpeg, libpng, libgsl, eigen, zlib, fftw, cblas and >> clapack external libraries or be distributed with any other needed library; >> be usable non-interactively from the command-line; >> need at most 1 GB memory and 30 s computation; >> read/write PNG, TIFF, PNM, EPS, SVG, VRML or PLY format. >> >>> >>>>> >> It's not true any more that we only accept C/C++ code, and there's no >> reason why the algorithms can't go further than 1 Gb of RAM usage, since we >> have a lot of memory in the servers. They should not use an exaggerated >> amount of memory, though. >> >> In my opinion, this text is limiting the potential submission in IPOL: >> - We accept not only C/C++ but also Python and MATLAB and we're open to >> other languages eventually. >> - All those technical terms give the impression that we're going to >> reject anything which does not follow exactly the norm of the compile (C89, >> C99, C++98), which is not true. >> - We give a list of allowed libraries, but these technical details should >> be discussed with the editor, not put here as a strong requirement. The >> editor should tell the editor what is possible and what is not, instead of >> writing "only libtiff, libjpeg, libpng, libgsl, eigen, zlib, fftw, cblas >> and clapack external libraries". >> - We say "need at most 1 GB memory and 30 s computation". Again, this is >> flexible. It seems that if your algorithm takes 45 seconds it's going to be >> rejected. And that's not true at all. It should be a discussion with the >> editor instead of a hard limit. >> - "read/write PNG, TIFF, PNM, EPS, SVG, VRML or PLY format." --> Same >> comment here. Actually, the system can perform many conversions if needed. >> >> I suggest to change all that complicated text by: >> <<< >> Note that the submitted code must at least fulfill these minimal >> conditions: >> >> - Be written in C/C++, Python, or MATLAB with minimal dependencies. >> - Must compile and run at least in a Debian Stable distribution. >> >> The editor will guide the authors throughout the publication process >> giving technical support when needed. >> >>> >>>>> >> The same information appears in the Author Manual: >> https://tools.ipol.im/wiki/ref/author_manual/ >> >> I think we should change it as soon as possible, since it's limiting a >> lot future submissions. >> >> Best, >> Miguel >> >> >> >> >> > >
-- IPOL - Image Processing On Line - http://ipol.im/ contact e...@ipol.im - http://www.ipol.im/meta/contact/ news+feeds twitter @IPOL_journal - http://www.ipol.im/meta/feeds/ announces annou...@list.ipol.im - http://tools.ipol.im/mm/announce/ discussions discuss@list.ipol.im - http://tools.ipol.im/mm/discuss/