We should also change the Software Guidelines:
https://tools.ipol.im/wiki/ref/software_guidelines/#implementation
We should remove lines such as:
- C89, C99 or C++98 code tested with gcc -std=xxx -Wall -Wextra -Werror
- only libtiff, libjpeg, libpng, zlib, fftw, libgsl, libeigen, cblas
and clapack external libraries
- compilation with make or cmake, only standard options, make uses
$(CC) or $(CXX)
- max 1 GB memory, max 30 s computation in the demo environment
- can read/write in PNG, TIFF, PNM, EPS, SVG, VRML or PLY format
- max 80 characters per line, max 1000 lines per file
- This file archive can either be a single volume .ZIP compressed
archive or a GZIP compressed tar archive2. The size of the compressed
archive file should be less than 2 MB --> There's no reason to limit
to 2 Mb!
- A published software must not be distributed with binary
precompiled files if these files can be obtained from source code -->
Actually, it should NEVER contain precompiled files!
- The source code of a published software must follow the published
standard syntax of one or more compiled programming languages. Only
C89, C99, and C++984 can currently be processed --> This is false
- Other techniques for accelerated computing, like OpenCL and OpenACC,
are not supported by the journal --> We support it in the new system
if we manage to have a server with a GPU.
In my opinion the Software Guidelines are not only outdated, and
contains false claims, but are also unnecessarily strict.
Again, this is should be fixed, since it's blocking without any reason
a lot of eventual submissions.
Best,
Miguel
Quoting Miguel Colom <miguel.co...@cmla.ens-cachan.fr>:
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/
