Re: [IPOL discuss] [IPOL edit] Suggested changes in Submission Procedure/Author Manual
Quoting Pascal Getreuer : Dear Miguel, Thank you for organizing this effort to modernize the IPOL software guidelines. It sorely needs to be done. As a high level comment, I agree with the general theme of relaxing constraints to encourage more submissions. I also agree with Pascal Monasse's comment advising against removing "all the restrictions unilaterally". Of course. Actually, I proposed to make some of the changes immediately because they were already approved by the Editorial Board (such as allowing MATLAB or Python) and I think it's important to change it as soon as possible. About other changes, note that I've send it to the discussion list. Let me remind that the point of having the guide is to "facilitate the production and review of verifiable and usable software for reproducible research." Any rule that doesn't contribute toward that is unnecessary, but on the other hand, you don't want a complete willy-nilly free-for-all, so please consider * portability -- if the code has obscure platform requirements, the research isn't really "reproducible" * readability -- if the code works but is a convoluted mess, reviewers and users will have a hard time following what it does, and it won't be "verifiable" * usabillity -- if the code lacks a clear README or only interoperates with an obscure file format, users won't know how to use it I agree, of course. My point is that the editor should have a more active role and use these points as a checklist. These rules should be in the guidelines for the authors, but instead of writing them as "you must..., it's mandatory that..., etc" they should explain that their editor will help them to have a code of quality by using these guidelines. This implies changes in the writing of the text and most probably rearranging the sections. - We accept not only C/C++ but also Python and MATLAB and we're open to other languages eventually. Yes, the docs are badly out of date. The IPOL main page has an announcement from 2015(!) "From now on, IPOL will accept Matlab source code. Very soon, we will update the submission procedure accordingly." without corresponding indication in the software guide. - 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. Still, having standard conforming code for C and C++ seems important to me for portability. Naturally, as Python and Matlab have no such strict standards, this does not apply to them. Like Pascal said, portability is important. Please nail things down a bit to keep that. Do you want authors to make unlimited use of nonstandard C++ extensions? #pragmas? inline assembly? Probably not. Of course not. But the editor should guarantee that the code doesn't contain those. If we guidelines seem to be really hard to follow, in practice we'll have any of these: 1) Please not submitting because they're not technically competent to follow these strict guidelines 2) People submitting anyway and Editors who don't really check the code. Thus, let's keep the guidelines but let's also turn them into a checklist for the Editors. For C++, I suggest to loosen the guidelines to explicitly allow C++11 (possibly also C++14 and C++17). It is a huge step forward for the language from C++98. For Matlab, the toolboxes are often individually purchased and very expensive. Encourage authors to use only what they need. Encourage Octave-compatible Matlab code where possible. If I'm not wrong, in the last Editorial Board meeting it was decided that all the MATLAB code submitted should work in Octave too. We should remove lines such as: - max 80 characters per line, max 1000 lines per file Again, why? We do not want messy code, this is not too much to ask from authors. Whether code fits in 80 chars or uses -Wextra in the makefile is pretty superficial, and I am strongly in favor of removing such rules. But we want to encourage readable code, and there should be some explicit guidelines. It helps the reviewers focus on what we care about and gives something authoritative for reviewers to lean on if they need to persuade an author to clean up messy code. Based on code I have seen as an IPOL reviewer, the main guidelines I would make are (1) "please indent code" (it is super easy to do, there are automatic tools for it, and it really does help readability), and (2) "please give variables and functions reasonable English names, and try to make them correspond to the article". I'll create a Google Doc with the proposed text and I'll send the link to edit it. I look forward to your Doc! I have a preliminary Doc with my proposal for the guidelines. I didn't write the URL publicly because this discussion list is public and I don't want that it gets vandalized! Pascal: I'll send you the URL in a separate email. If anybody else wants the edit the Doc, please send an
Re: [IPOL discuss] [IPOL edit] Suggested changes in Submission Procedure/Author Manual
Dear Miguel, Thank you for organizing this effort to modernize the IPOL software guidelines. It sorely needs to be done. As a high level comment, I agree with the general theme of relaxing constraints to encourage more submissions. I also agree with Pascal Monasse's comment advising against removing "all the restrictions unilaterally". Let me remind that the point of having the guide is to "facilitate the production and review of verifiable and usable software for reproducible research." Any rule that doesn't contribute toward that is unnecessary, but on the other hand, you don't want a complete willy-nilly free-for-all, so please consider * portability -- if the code has obscure platform requirements, the research isn't really "reproducible" * readability -- if the code works but is a convoluted mess, reviewers and users will have a hard time following what it does, and it won't be "verifiable" * usabillity -- if the code lacks a clear README or only interoperates with an obscure file format, users won't know how to use it > - We accept not only C/C++ but also Python and MATLAB and we're open > to other languages eventually. Yes, the docs are badly out of date. The IPOL main page has an announcement from 2015(!) "From now on, IPOL will accept Matlab source code. Very soon, we will update the submission procedure accordingly." without corresponding indication in the software guide. >> - 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. > > Still, having standard conforming code for C and C++ seems important to me for > portability. Naturally, as Python and Matlab have no such strict standards, > this does not apply to them. Like Pascal said, portability is important. Please nail things down a bit to keep that. Do you want authors to make unlimited use of nonstandard C++ extensions? #pragmas? inline assembly? Probably not. For C++, I suggest to loosen the guidelines to explicitly allow C++11 (possibly also C++14 and C++17). It is a huge step forward for the language from C++98. For Matlab, the toolboxes are often individually purchased and very expensive. Encourage authors to use only what they need. Encourage Octave-compatible Matlab code where possible. >> We should remove lines such as: >> - max 80 characters per line, max 1000 lines per file > > Again, why? We do not want messy code, this is not too much to ask from > authors. Whether code fits in 80 chars or uses -Wextra in the makefile is pretty superficial, and I am strongly in favor of removing such rules. But we want to encourage readable code, and there should be some explicit guidelines. It helps the reviewers focus on what we care about and gives something authoritative for reviewers to lean on if they need to persuade an author to clean up messy code. Based on code I have seen as an IPOL reviewer, the main guidelines I would make are (1) "please indent code" (it is super easy to do, there are automatic tools for it, and it really does help readability), and (2) "please give variables and functions reasonable English names, and try to make them correspond to the article". > I'll create a Google Doc with the proposed text and I'll send the link to edit it. I look forward to your Doc! Best, Pascal On Thu, Jul 6, 2017 at 2:57 AM, Miguel Colom wrote: > Quoting Jean-Michel Morel : > > Dear all, >> Enric is absolutely right to ask for a formal vote on a final text. >> The preparation of the text might be done with an online google doc? >> > > All right, then. > I'll create a Google Doc with the proposed text and I'll send the link to > edit it. > > Best, > Miguel > > > > > > >> >> Jean-Michel Morel >> moreljeanmic...@gmail.com >> >> On Thu, Jul 6, 2017 at 10:47 AM, Loic Simon >> wrote: >> >> Dear Miguel, Dear Enric, >>> >>> I think that Miguel should send a draft of his proposed modifications and >>> it can be validated/amended by editorial board members without need of a >>> meeting. That would allow to at least correct quickly the misleading >>> information, and we can start a sound discussion on other points on which >>> there is no consensus. >>> >>> Best, >>> >>> Loïc >>> >>> On Thu, Jul 6, 2017 at 10:41 AM, Miguel Colom >>> wrote: >>> >>> Quoting Enric Meinhardt-Llopis : Dear all, > > You are talking about major changes to IPOL here. Should we summon > the whole editorial board to approve these changes? (arrange a > meeting, or send a mail to everybody with a poll to explicitly accept > each of the changes) > > Maybe not all the people in the editorial board are reading this > mailing list, or maybe they are not reading it this week. > > I want to have a voice in these changes but I'm not sure that this > mailing list reaches everybody. > > Dear Enric, I think that to remove the false information in the I
Re: [IPOL discuss] [IPOL edit] Suggested changes in Submission Procedure/Author Manual
Quoting Jean-Michel Morel : Dear all, Enric is absolutely right to ask for a formal vote on a final text. The preparation of the text might be done with an online google doc? All right, then. I'll create a Google Doc with the proposed text and I'll send the link to edit it. Best, Miguel Jean-Michel Morel moreljeanmic...@gmail.com On Thu, Jul 6, 2017 at 10:47 AM, Loic Simon wrote: Dear Miguel, Dear Enric, I think that Miguel should send a draft of his proposed modifications and it can be validated/amended by editorial board members without need of a meeting. That would allow to at least correct quickly the misleading information, and we can start a sound discussion on other points on which there is no consensus. Best, Loïc On Thu, Jul 6, 2017 at 10:41 AM, Miguel Colom wrote: Quoting Enric Meinhardt-Llopis : Dear all, You are talking about major changes to IPOL here. Should we summon the whole editorial board to approve these changes? (arrange a meeting, or send a mail to everybody with a poll to explicitly accept each of the changes) Maybe not all the people in the editorial board are reading this mailing list, or maybe they are not reading it this week. I want to have a voice in these changes but I'm not sure that this mailing list reaches everybody. Dear Enric, I think that to remove the false information in the IPOL pages (Software Guidelines, FAQ, help, etc.) is urgente and should be done now. Some of that false claims are that we don't support MATLAB, among others. We wouldn't be deciding anything new, but just correcting the docs. About summoning all the Editorial Board or emailing them, as you wish. My opinion is that we should be way more agile, in the sense that if we detect that our information is false, that we can improve it quickly, and someone has already taken the responsibility to do it, then it should be done immediately. I'm afraid that if we don't be that agile, most of the time things won't be done at all because we'll be waiting for eventual discussions that won't ever happen and in the worst case this wait will block the actions. My proposal is to simply update the docs and to rearrange some parts (move the C/++ to a dedicated part). Given said that, if you really think that it's necessary that all the Editorial Board votes, let's do that then. I'm not opposed at all. Best, Miguel Best, Enric 2017-07-04 16:10 GMT+02:00, Jose Luis Lisani : 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. -- 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/ -- 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/ -- 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/ -- 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/
Re: [IPOL discuss] [IPOL edit] Suggested changes in Submission Procedure/Author Manual
Dear all, Enric is absolutely right to ask for a formal vote on a final text. The preparation of the text might be done with an online google doc? I can provide the list of members the editorial board. By the way it is outdated and if we do something formal for once, I'd welcome propositions for new members of the editorial board (and I'll propose to remove those that are inactive). To be a member of the editorial board you need be a doctor and have published one paper in IPOL, and be proposed by other editors, and accepted by vote. Best, Jean-Michel Jean-Michel Morel moreljeanmic...@gmail.com On Thu, Jul 6, 2017 at 10:47 AM, Loic Simon wrote: > Dear Miguel, Dear Enric, > > I think that Miguel should send a draft of his proposed modifications and > it can be validated/amended by editorial board members without need of a > meeting. That would allow to at least correct quickly the misleading > information, and we can start a sound discussion on other points on which > there is no consensus. > > Best, > > Loïc > > On Thu, Jul 6, 2017 at 10:41 AM, Miguel Colom > wrote: > >> Quoting Enric Meinhardt-Llopis : >> >> Dear all, >>> >>> You are talking about major changes to IPOL here. Should we summon >>> the whole editorial board to approve these changes? (arrange a >>> meeting, or send a mail to everybody with a poll to explicitly accept >>> each of the changes) >>> >>> Maybe not all the people in the editorial board are reading this >>> mailing list, or maybe they are not reading it this week. >>> >>> I want to have a voice in these changes but I'm not sure that this >>> mailing list reaches everybody. >>> >> >> Dear Enric, >> >> I think that to remove the false information in the IPOL pages (Software >> Guidelines, FAQ, help, etc.) is urgente and should be done now. Some of >> that false claims are that we don't support MATLAB, among others. We >> wouldn't be deciding anything new, but just correcting the docs. >> >> About summoning all the Editorial Board or emailing them, as you wish. >> My opinion is that we should be way more agile, in the sense that if we >> detect that our information is false, that we can improve it quickly, and >> someone has already taken the responsibility to do it, then it should be >> done immediately. >> >> I'm afraid that if we don't be that agile, most of the time things won't >> be done at all because we'll be waiting for eventual discussions that won't >> ever happen and in the worst case this wait will block the actions. >> >> My proposal is to simply update the docs and to rearrange some parts >> (move the C/++ to a dedicated part). >> >> Given said that, if you really think that it's necessary that all the >> Editorial Board votes, let's do that then. I'm not opposed at all. >> >> Best, >> Miguel >> >> >> >> >>> Best, >>> Enric >>> >>> >>> >>> 2017-07-04 16:10 GMT+02:00, Jose Luis Lisani : >>> 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. >>> -- >>> 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/ >>> >>> >> >> >> -- >> 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/ >> > > > -- > 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/ > > -- 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/
Re: [IPOL discuss] [IPOL edit] Suggested changes in Submission Procedure/Author Manual
Dear Miguel, Dear Enric, I think that Miguel should send a draft of his proposed modifications and it can be validated/amended by editorial board members without need of a meeting. That would allow to at least correct quickly the misleading information, and we can start a sound discussion on other points on which there is no consensus. Best, Loïc On Thu, Jul 6, 2017 at 10:41 AM, Miguel Colom wrote: > Quoting Enric Meinhardt-Llopis : > > Dear all, >> >> You are talking about major changes to IPOL here. Should we summon >> the whole editorial board to approve these changes? (arrange a >> meeting, or send a mail to everybody with a poll to explicitly accept >> each of the changes) >> >> Maybe not all the people in the editorial board are reading this >> mailing list, or maybe they are not reading it this week. >> >> I want to have a voice in these changes but I'm not sure that this >> mailing list reaches everybody. >> > > Dear Enric, > > I think that to remove the false information in the IPOL pages (Software > Guidelines, FAQ, help, etc.) is urgente and should be done now. Some of > that false claims are that we don't support MATLAB, among others. We > wouldn't be deciding anything new, but just correcting the docs. > > About summoning all the Editorial Board or emailing them, as you wish. > My opinion is that we should be way more agile, in the sense that if we > detect that our information is false, that we can improve it quickly, and > someone has already taken the responsibility to do it, then it should be > done immediately. > > I'm afraid that if we don't be that agile, most of the time things won't > be done at all because we'll be waiting for eventual discussions that won't > ever happen and in the worst case this wait will block the actions. > > My proposal is to simply update the docs and to rearrange some parts (move > the C/++ to a dedicated part). > > Given said that, if you really think that it's necessary that all the > Editorial Board votes, let's do that then. I'm not opposed at all. > > Best, > Miguel > > > > >> Best, >> Enric >> >> >> >> 2017-07-04 16:10 GMT+02:00, Jose Luis Lisani : >> >>> 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. >>> >> -- >> 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/ >> >> > > > -- > 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/ > -- 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/
Re: [IPOL discuss] [IPOL edit] Suggested changes in Submission Procedure/Author Manual
Quoting Enric Meinhardt-Llopis : Dear all, You are talking about major changes to IPOL here. Should we summon the whole editorial board to approve these changes? (arrange a meeting, or send a mail to everybody with a poll to explicitly accept each of the changes) Maybe not all the people in the editorial board are reading this mailing list, or maybe they are not reading it this week. I want to have a voice in these changes but I'm not sure that this mailing list reaches everybody. Dear Enric, I think that to remove the false information in the IPOL pages (Software Guidelines, FAQ, help, etc.) is urgente and should be done now. Some of that false claims are that we don't support MATLAB, among others. We wouldn't be deciding anything new, but just correcting the docs. About summoning all the Editorial Board or emailing them, as you wish. My opinion is that we should be way more agile, in the sense that if we detect that our information is false, that we can improve it quickly, and someone has already taken the responsibility to do it, then it should be done immediately. I'm afraid that if we don't be that agile, most of the time things won't be done at all because we'll be waiting for eventual discussions that won't ever happen and in the worst case this wait will block the actions. My proposal is to simply update the docs and to rearrange some parts (move the C/++ to a dedicated part). Given said that, if you really think that it's necessary that all the Editorial Board votes, let's do that then. I'm not opposed at all. Best, Miguel Best, Enric 2017-07-04 16:10 GMT+02:00, Jose Luis Lisani : 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. -- 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/ -- 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/
Re: [IPOL discuss] [IPOL edit] Suggested changes in Submission Procedure/Author Manual
Dear all, You are talking about major changes to IPOL here. Should we summon the whole editorial board to approve these changes? (arrange a meeting, or send a mail to everybody with a poll to explicitly accept each of the changes) Maybe not all the people in the editorial board are reading this mailing list, or maybe they are not reading it this week. I want to have a voice in these changes but I'm not sure that this mailing list reaches everybody. Best, Enric 2017-07-04 16:10 GMT+02:00, Jose Luis Lisani : > 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. -- 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/
Re: [IPOL discuss] [IPOL edit] Suggested changes in Submission Procedure/Author Manual
Quoting Luis Alvarez : I would be more than happy to listen any idea to increase the number of papers published in IPOL and I think that to strongly simplify the IPOL code guidelines goes in such direction. Dear Luis, The problem of having more articles is related to the impact factor of the journal, and the impact factor relies also on the number of published articles. It's a vicious circle. Some actions we could or should try: - Fix the software guidelines to remove all the false information ("only C/C++", etc) which is preventing the authors to send their codes and to avoid showing all the technical information as general strong requirements. The editor should guide and help the author with that checklist. - Improve the look of the main page in http://www.ipol.im At this moment is looks poor. It's functional and does its job, but it could be way better. For example, we could imagine the list of published articles where each of them is a row with a little picture on the left, and the title and the abstract on the right. At this moment, the users needs to click on an article to get into the details. However, I reckon that other journals (such as IEEE TIP) are not much different: http://ieeexplore.ieee.org/xpl/RecentIssue.jsp?punumber=83 But there's no reason why we couldn't make the main page better. - In the main page write clearly which databases are indexing us. We don't have an official "Impact Factor" yet, but we're indexed by important databases, including the Emerging Citation Index. This should not be simply put as news in the page, but a section itself. Say, in the top menu, a new entry "Indexation" which could go to a dedicated page with the list of indexers, linking to them. - After we release an issue (each year), the EIC could write a short editorial (say, one page) talking about the novelties on the field, or even the novelties on IPOL itself (the demo system, new languages or libraries accepted), the perspectives of the journal, news on the indexation (SCOPUS and others). And we could create a large PDF with that cover page editorial and all articles in the issue. - Organize a workshop on Reproducible Research, to increase the visibility of the journal. I accept to be one the organizers if we do it. - Increase the corpus of topics or type of data in the journal. Actually, we're already doing this with the new data types that the new interface will support soon: audio, vídeo, 3D. - Add a forum at each article's page, where the users can post messages and start discussions on the topics of the article. - Suggested by Guillermo Sapiro and Gregory Randall: statistics on the number of times an article has been downloaded, and show it on the website. It's an indirect measure of impact of the codes. Honestly, I don't know if any of these actions could finally increase the number of published articles, but it's just some ideas. 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/
Re: [IPOL discuss] [IPOL edit] Suggested changes in Submission Procedure/Author Manual
Dear all, Below you will find a chart with the number of IPOL papers published per year. The number of papers IPOL published is a strong limitation in order to get IPOL indexed in JCR which in opinion should be the main goal of the journal in order to be recognized as a mature and relevant journal in the field. Of course, the "80 character by line" or the "-Wall -Wextra -Werror" philosophy does not help to increase the number of papers. In my opinion we should focus in the algorithm design and that the code is well organized, understandable and it follows the algorithm description and any other restriction about the code should be removed from the journal website. I would be more than happy to listen any idea to increase the number of papers published in IPOL and I think that to strongly simplify the IPOL code guidelines goes in such direction. Regards Luis Alvarez El 04/07/2017 a las 15:55, Pascal Monasse escribió: Dear all, I agree that the manuals/guidelines/web pages need serious update, but I would not advise to remove all the restrictions unilaterally. I answer point by point in the following. 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. OK for C/C++, we have been accepting other languages for a long time. Concerning the RAM usage, indeed the servers can support much more than 1Gb, but that is not the only criterion. We would like the code to be able to run on regular machines, not only big servers. We could discuss whether 1Gb is too low a target for current machines, but I think that setting such a target is a good thing. It could still not be a hard requirement, but just a recommendation, that is allowed to be overridden if the editor agrees. - We accept not only C/C++ but also Python and MATLAB and we're open to other languages eventually. Indeed, we need to update the docs. - 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. Still, having standard conforming code for C and C++ seems important to me for portability. Naturally, as Python and Matlab have no such strict standards, this does not apply to them. - 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". Again, for portability, it is important to delimit the dependences that are allowed. It is said in the guidelines that other libraries must be included in the package, so I think it is not too restrictive. - 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. That could be up to discussion with the editor, but again the 30s computation should be a strongly recommended target. This may oblige the authors to restrict strongly the input loads of their demo, but if a demo takes more than 30s, people will not have the patience to try it. - "read/write PNG, TIFF, PNM, EPS, SVG, VRML or PLY format." --> Same comment here. Actually, the system can perform many conversions if needed. Yes it can, but do we want to multiply the formats? This should cover most needs, this list can be expanded based on authors' requirements in accordance with the editors, but sticking to widely used formats is normally a good thing. We should remove lines such as: - C89, C99 or C++98 code tested with gcc -std=xxx -Wall -Wextra -Werror Why? It is a good requirement for code quality, not overly difficult to comply with. We should remove lines such as: - compilation with make or cmake, only standard options, make uses $(CC) or $(CXX) Why multiply arbitrarily the build methods? At least for C and C++ code, we want to stick with the dominant build methods. We should remove lines such as: - max 80 characters per line, max 1000 lines per file Again, why? We do not want messy code, this is not too much to ask from authors. We should remove lines such as: - 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! OK for that one, after all it is just a question of what the server can support. - 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! Agreed. - Other
Re: [IPOL discuss] [IPOL edit] Suggested changes in Submission Procedure/Author Manual
Dear All, Thanks it looks also fine for me. Just perhaps keep the incitation to avoid the warnings "-Wall -Wextra -Werror » in c/c++ that could be great that the authors take the time to limit the generated warnings. (it can be source of problem later or source of non compilation on other more restrictive compilator). The editor can request it during the submission but we can save time if we mention add it. Best, Bertrand > Le 4 juil. 2017 à 16:25, Jean-Michel Morel a > écrit : > > 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 > 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/ -- 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/
Re: [IPOL discuss] [IPOL edit] Suggested changes in Submission Procedure/Author Manual
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 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/
Re: [IPOL discuss] [IPOL edit] Suggested changes in Submission Procedure/Author Manual
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/
Re: [IPOL discuss] [IPOL edit] Suggested changes in Submission Procedure/Author Manual
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 : 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/