From nicolas.limare at cmla.ens-cachan.fr Tue Feb 1 13:46:22 2011 From: nicolas.limare at cmla.ens-cachan.fr (Nicolas Limare) Date: Tue, 1 Feb 2011 21:46:22 +0900 Subject: [IPOL discuss] citations in IPOL articles In-Reply-To: <4D42E655.2050303@iwr.uni-heidelberg.de> References: <4D42E655.2050303@iwr.uni-heidelberg.de> Message-ID: <20110201124622.GA29812@nashi.hw.39mm.net> 1. First, a short answer to Pascal >> I have found a method for doing this, but it is rather ugly. Here is >> an example: >> >> "# References >> 1. Historic paper >> 2. Another paper >> ... >> The proof of this result can be found in [1]." >> >> >> Is there a better way to do this? You can manually insert anchors into the reference list, and then use these anchors for internal links. 8<----------8<----------8<----------8<----------8<----------8<---------- # References 1. Natsume Foo, Historic Paper, Journal of Blah 2. John Bar, Another Paper, Journal of Articles ... The proof of this result can be found in Foo's article. 8<----------8<----------8<----------8<----------8<----------8<---------- This way, you have one stable identifier per reference. And I think it is better to use real text in the reference hyperlinks. Numbered references like "[1]" were useful in the paper era when we needed to search a reference in the reference list, but is not required anymore with hyperlinks. You can even do better with more HTML: use the "ref_xxx" names to identify the references in the list instead of empty anchor tags. 8<----------8<----------8<----------8<----------8<----------8<---------- # References
  1. Natsume Foo, Historic Paper, Journal of Blah
  2. John Bar, Another Paper, Journal of Articles
... The proof of this result can be found in Foo's article. 8<----------8<----------8<----------8<----------8<----------8<---------- I'm afraid this is the best we can do for the moment, with the current tools. 2. Now, answering to Daniel > From my point of view it would most certainly be the best way to simply > use bibtex-style references and a cite-tag in the markup. I completely agree, BibTeX is the de-facto standard and should be supported. One little problem with BibTeX is it lacks standardization for electronic reference attributes such as URLs or DOIs. > Things brings us back to the question about the requirements and choice > of a content managament system. > > I am currently trying to find a sustainable way to develop the > web-interface. As I understood up to now, there are basically three > "systems" > > Demo Frontend (HTML+Ajax, Java, ...?) > Demo Backend (Python-based code) > Article CMS (IkiWiki) For the moment the Demo frontent is only HTML. It could include Javascript/Ajax/... if someone is willing to support it. I don't think we should use Java, because a java applet is only inserted into a web page and doesn't integrate with the surrounding environment (HTML/CSS/JS), because the future of Java is quite unclear since Oracle bought Sun, and because most of the things we need for the frontend can probably be done with JavaScript+HTML5. > I suggest to leave the Demo part as it is right now and would like to > discuss the choice for content management. > Therefore, I would ask you to comment on the requirements first in order > to try to make a "bias-free" decision in terms of prior knowledge how to > use the system. Next step would be to "bias" these results by looking at > who knows how much about each system and would dare to take some > responsibility there. > > Can somebody reiterate the list of possible system choices and the one > containing the long-term requirements? I have three lists of requirements, from three points of view: author, editor and administrator. A. The core requirements for the author are: * the ability to edit an article page with rich text, media (image, video, ...), formulas, references, ... * the ability to upload some files for inclusion in the page * an easy to use syntax Authors would also like to recycle the the texts they already wrote in LaTeX for IPOL without too much work. B. The core requirements for the editor are: * user management, ie the possibility to identify people, for... * access management, ie the possibility to define and modify who can read and/or edit any content (page or uploaded file) of the system, in a flexible way (for authors, editors, reviewers, ...) * retain the history of the modifications C. The core requirements for the admin are: * supported, reliable software solution * with few dependencies * manageable with console system tools These are only the core features. I can think of tons of interesting things to be done with this system, such as * structured content of the articles, ie not putting everything as a long text but having special fields to fill for the references, for the source code, etc. * triggering actions on update, for example recomputing all the embedded images when the source code is updated (this would be real reproducible research articles) or updating the doxygen documentation when needed * mail notification on edition * support for rich metadata (Dublin Core) * user forum and review * ... The possible choices proposed were Mediawiki, Django, Drupal, Plone, Joomla. There are lots of other options, as seen on http://en.wikipedia.org/wiki/List_of_content_management_systems http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks -- Nicolas LIMARE http://nicolas.limare.net/ pgp:0xFA423F4F -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From getreuer at gmail.com Sun Feb 6 19:40:47 2011 From: getreuer at gmail.com (Pascal Getreuer) Date: Sun, 6 Feb 2011 19:40:47 +0100 Subject: [IPOL discuss] slider inputs for IPOL demos Message-ID: For some IPOL demos, it would be convenient to use slider inputs for real-valued parameters. By a slider input, I mean the kind of widget like a volume meter or a scroll bar. For example, a denoising demo might ask for the amount of noise to add using a slider input. I propose here a simple implementation of sliders using JavaScript. Please try the demo on my webpage: http://www.math.ucla.edu/~getreuer/slider.html == Problems == A disadvantage about sliders is that they are imprecise---it is hard for a user to select the value 4.00 exactly and not 3.98 or 4.07. This problem is solved by linking the slider to an editable text box. Then the user benefits from the convenience of the slider bar and has the text box in case precise entry is needed. On the web, sliders also have a technological problem. While most standard widgets are supported by HTML4, sliders are not. HTML5 will add support for sliders, but until then, sliders require JavaScript. I have looked at several implementations, and the essence of it is 1. Create a DIV or an IMG that will function as the draggable slider thumb, set its CSS position property to "relative," and set onmousedown to a JavaScript function that will initiate dragging. 2. In the onmousedown function, set document.onmousemove and document.onmouseup to functions that will handle the dragging. 3. In these handler functions, get the mouse coordinates from (event.screenX,event.screenY) and change the CSS left property of the slider thumb to move it around. Although this should be simple, most implementations on the web are pretty complicated. Some sliders implementations have significant amounts of interface code for stylizing the sliders. Some sliders are implemented as one part of a larger UI framework (mountains of code). Many good sliders have restrictive licenses. There are also free sliders, but naturally these are not as thoroughly tested for browser compatibility. == A Solution == Ideally a slider for IPOL demos should satisfy (in order of highest to lowest priority) 1. work in as many browsers as possible, and degrade gracefully where not supported 2. have a free license 3. have a simple implementation 4. enable the slider to link with an edit text box 5. be attractive and efficient I have developed a 200-line implementation that, to the best of my abilities, satisfies these goals: http://www.math.ucla.edu/~getreuer/slider.html It works successfully in the browsers that I have available: IE8, Firefox 3.6, Chrome 8 and 9, Safari 5 (Windows version), and Opera 11. It degrades gracefully if JavaScript is disabled. In that case only the text box is shown (for example, this works correctly in Firefox with the NoScript plugin and in the Lynx browser, which has no JavaScript support). Visually it is not especially attractive but reasonable. A limitation is that, unlike a standard slider, you cannot move the slider by clicking in the open areas of bar. Only the slider's thumb is interactive. Another limitation is that the slider does not respond to the mouse scroll wheel or to the keyboard. These features are possible (there exist sliders like this on the web), but they come at the cost of more JavaScript code, which it seems would increase the chances of browser compatibility issues. I am not a web expert, I know little about which JavaScript features have browser compatibility issues. I welcome any feedback or suggestions. I am aware that IPOL generally avoids JavaScript, but I see some small amounts of JavaScript are in already use. For example, the IkiWiki "!toggle" link for expanding a section of hidden text uses JavaScript. I think the key requirement is that the site is still usable without JavaScript. What are your thoughts about using this slider in IPOL demos? Pascal Getreuer From nicolas.limare at cmla.ens-cachan.fr Mon Feb 7 10:10:16 2011 From: nicolas.limare at cmla.ens-cachan.fr (Nicolas Limare) Date: Mon, 7 Feb 2011 18:10:16 +0900 Subject: [IPOL discuss] Fwd: "Time out" Message-ID: <20110207091016.GJ3972@nashi.hw.39mm.net> Dear IPOL-ers, I translate hereafter a message from Jean-Michel; I think the answers can be useful to everyone. We frequently habe "time out" on our demos. I suppose that many will be fixed with the more powerful server, but however, I think that users are not properly informed. Once a demo is launched, in addition to the small spinning top, there should de a message such as: "In case this execution takes more than 60 seconds, it will be interrupted" And the window that appears in case of time out with "Error 504: Gateway Timeout. This part of IPOL Is Temporary unavailable ... " is inaccurate since this is generally interrupted by time out and not a server error. So in this case could we send a better message like: "Sorry, the execution of the algorithm on your data was taking more than 60 seconds, and has therefore be automatically interrupted. Please, try again with smaller or less complex data." ----- Forwarded message from Jean-Michel Morel ----- Date: Sat, 05 Feb 2011 16:50:10 +0100 From: Jean-Michel Morel To: Nicolas Limare , Jose Luis Lisani Subject: "Time out" Chers Jos? Luis et Nicolas, Il se produit fr?quemment des "time out" sur nos d?mos. En principe je suppose que beaucoup se r?glerons avec le serveur plus puissant mais, n?anmoins, je pense que les utilisateurs ne sont pas proprement inform?s. D?s qu'une d?mo est lanc?e, outre la petite toupie qui tourne, il faudrait ? cot? un message du type: "In case this execution takes more than 60 seconds, it will be interrupted". Et la fen?tre qui appara?t en cas de time out avec le "Error 504: Gateway Timeout This part of IPOL is temporary unavailable, ... " est inexacte puisque s'agit en g?n?ral d'une interruption par Time out et non pas d'un d?faut du serveur. Donc dans ce cas pourrait-on envoyer un message plus conciliant du type: "Sorry, the execution of the algorithm on your data was taking more than 60 seconds, and has therefore be automatically interrupted. Please, try again with smaller or less complex data". Amiti?s, JM ----- End forwarded message ----- -- Nicolas LIMARE http://nicolas.limare.net/ pgp:0xFA423F4F -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From monasse at imagine.enpc.fr Mon Feb 7 10:37:30 2011 From: monasse at imagine.enpc.fr (Pascal Monasse) Date: Mon, 7 Feb 2011 10:37:30 +0100 Subject: [IPOL discuss] input image format in demos Message-ID: <201102071037.30362.monasse@imagine.enpc.fr> Hello all, I have a question about input image format in IPOL demos' python code. It seems you can select the format by setting the string app.input_ext (for example '.ppm' in graph cuts demo) but that first the images are saved in PNG format, and then additional files with required format (here PPM) are generated. Is this assumption correct? Best, Pascal From nicolas.limare at cmla.ens-cachan.fr Mon Feb 7 11:31:02 2011 From: nicolas.limare at cmla.ens-cachan.fr (Nicolas Limare) Date: Mon, 7 Feb 2011 19:31:02 +0900 Subject: [IPOL discuss] Time out In-Reply-To: <20110207091016.GJ3972@nashi.hw.39mm.net> References: <20110207091016.GJ3972@nashi.hw.39mm.net> Message-ID: <20110207103102.GK3972@nashi.hw.39mm.net> > We frequently habe "time out" on our demos. I suppose that many will > be fixed with the more powerful server, but however, I think that > users are not properly informed. No, the new server will only improve the performance of parallel algorithms. There will be more CPUs, but each CPU won't be faster than a CPU on the current server, so a program using only 1 CPU won't have better performances on the new server. And the situation won't improve. The processors on the next generations of machines won't go faster, there will only be more processors. This has been true for a few years now, and will probably last for a while. For the record, only ASIFT really does real (OpenMP) parallel processing for the moment. Some demos use "quick and dirty" parallel processing by splitting the image, but I'd like to see these hacks gradually disappear. > Once a demo is launched, in addition to the small spinning top, there > should de a message such as: "In case this execution takes more than > 60 seconds, it will be interrupted" I just added this sentence. > And the window that appears in case of time out with "Error 504: Gateway > Timeout. This part of IPOL Is Temporary unavailable ... " is > inaccurate since this is generally interrupted by time out and not a > server error. This page should never appear. The shortest answer is: ?demos should properly use the timeout system?. The detailed answer starts with a little explanation about the demo system network and timeout. See the end of this message for an answer in 3 sentences. There are 2 layers between the network users and the demo: users --- www.ipol.im --- demo.ipol.im --- demo proxy proxy These proxy are some transparent service redirections: * The proxy on www.ipol.im redirects all the requests to http://www.ipol.im/pub/demo to the demo.ipol.im server. With this redirection, the demos and other pages seem to be on the same machine (ie on http://www.ipol.im/) even if they are hosted on different servers, in different places: one in a datacenter in Paris, one in the ENS server room * The proxy on demo.ipol.im connects the demo program to the external network environment. It handles all the network load (and possible abuses) while the demo programs run quietly. Error 504 is a standard status code[1], sent by a proxy then it did not receive an answer from the backend server. In our case, the first proxy on www.ipol.im sends this page when it received no answer from demo.ipol.im. It is supposed to only happen when there is something gone wrong on the demo server (server off, rebooting, network disturbances, ...), and that's why the message says "temporarily unavailable". [1]http://tools.ietf.org/html/rfc2616#section-10.5.5 Of course, we don't want to see this message when the demo are running but slow. Easy! The "Error 504" appears when the demo server didn't answer within 90 seconds (the proxy timeout), so we must ensure the demos reply before, and this is possible with the current code. Most of the processing time comes from running the algorithm programs as subprocesses, so we control the execution time with the timeout option parameter of the wait_proc() function. If the process takes more than the timeout delay, it will be interrupted and a TimeoutError exception is raised: timeout = 60 p = self.run_proc([foo, bar]) try: self.wait_proc(p, timeout) except TimeoutError: return self.error(errcode='timeout', errmsg="The program took too much time.") A better way to do it is (see app/my_affine_sift/app.py): * use the self.timeout attribute defined for each app class * catch the timeout error from the self.run() function * pass the timeout parameter to the self.run_algo() function def run(self): try: self.run_algo(timeout=self.timeout) except TimeoutError: return self.error(errcode='timeout', errmsg="The program took too much time.") except RuntimeError: return self.error(errcode='runtime', errmsg="The program ended in an execution error") return self.tmpl_out("run.html") def run_algo(self, timeout=False) p = self.run_proc([foo, bar]) self.wait_proc(p, timeout) return So, to avoid the infamous "Error 504" page, demos should always specify a non-null timeout when waiting for a process. And be careful if you run 3 processes sequentially, you should divide the timeout to ensure a global timeout, and the demo editor expertise is required to know which process is expected to need more time. p1 = self.run_proc([foo, bar]) self.wait_proc(p1, timeout/2) p2 = self.run_proc([foo, bar]) self.wait_proc(p2, timeout/4) p3 = self.run_proc([foo, bar]) self.wait_proc(p3, timeout/4) Finally, to avoid this process timeout for most of the images, you should ensure the processed data size is within a reasonable limit, either via the input restrictions (max_size attributes) or via a custom control if you manipulate the input (crop, ...) Another timeout is configurable at the Cherrypy level, but I thought it would be overkill. And as usual, this is just the way I spontaneously implemented it; it can be modified, your contributions are welcome. -o-0-o- In brief: * there is a hard external timeout of 90 seconds on all the demo pages, always active : Error 504 * we avoid the hard timeout with a soft internal timeout on the process executions; activated on demand in wait_proc(), the suggested timeout configuration is 60 seconds * we avoid the soft timeout by controling and reducing the input size Todolist: * notify by email the demo authors of any timeout triggered * gather statistics about these timeouts with other operation infos[2] [2]http://tools.ipol.im/munin/ipol/fuchsia.html#Ipol -- Nicolas LIMARE http://nicolas.limare.net/ pgp:0xFA423F4F -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From morel at cmla.ens-cachan.fr Mon Feb 7 11:40:44 2011 From: morel at cmla.ens-cachan.fr (Jean-Michel Morel) Date: Mon, 07 Feb 2011 11:40:44 +0100 Subject: [IPOL discuss] Time out In-Reply-To: <20110207103102.GK3972@nashi.hw.39mm.net> References: <20110207091016.GJ3972@nashi.hw.39mm.net> <20110207103102.GK3972@nashi.hw.39mm.net> Message-ID: <4D4FCC2C.3000906@cmla.ens-cachan.fr> This makes it, thanks! I suggest that this instruction to authors about time out be added in the IPOL "instructions to authors". All the best, Jean-Michel Nicolas Limare a ?crit : >> We frequently habe "time out" on our demos. I suppose that many will >> be fixed with the more powerful server, but however, I think that >> users are not properly informed. > > No, the new server will only improve the performance of parallel > algorithms. There will be more CPUs, but each CPU won't be faster > than a CPU on the current server, so a program using only 1 CPU won't > have better performances on the new server. > > And the situation won't improve. The processors on the next > generations of machines won't go faster, there will only be more > processors. This has been true for a few years now, and will probably > last for a while. > > For the record, only ASIFT really does real (OpenMP) parallel > processing for the moment. Some demos use "quick and dirty" parallel > processing by splitting the image, but I'd like to see these hacks > gradually disappear. > >> Once a demo is launched, in addition to the small spinning top, there >> should de a message such as: "In case this execution takes more than >> 60 seconds, it will be interrupted" > > I just added this sentence. > >> And the window that appears in case of time out with "Error 504: Gateway >> Timeout. This part of IPOL Is Temporary unavailable ... " is >> inaccurate since this is generally interrupted by time out and not a >> server error. > > This page should never appear. The shortest answer is: ?demos should > properly use the timeout system?. The detailed answer starts with a > little explanation about the demo system network and timeout. See the > end of this message for an answer in 3 sentences. > > There are 2 layers between the network users and the demo: > > users --- www.ipol.im --- demo.ipol.im --- demo > proxy proxy > > These proxy are some transparent service redirections: > * The proxy on www.ipol.im redirects all the requests to > http://www.ipol.im/pub/demo to the demo.ipol.im server. With this > redirection, the demos and other pages seem to be on the same > machine (ie on http://www.ipol.im/) even if they are hosted on > different servers, in different places: one in a datacenter in > Paris, one in the ENS server room > * The proxy on demo.ipol.im connects the demo program to the external > network environment. It handles all the network load (and possible > abuses) while the demo programs run quietly. > > Error 504 is a standard status code[1], sent by a proxy then it did > not receive an answer from the backend server. In our case, the first > proxy on www.ipol.im sends this page when it received no answer from > demo.ipol.im. It is supposed to only happen when there is something > gone wrong on the demo server (server off, rebooting, network > disturbances, ...), and that's why the message says "temporarily > unavailable". > > [1]http://tools.ietf.org/html/rfc2616#section-10.5.5 > > Of course, we don't want to see this message when the demo are running > but slow. Easy! The "Error 504" appears when the demo server didn't > answer within 90 seconds (the proxy timeout), so we must ensure the > demos reply before, and this is possible with the current code. > > Most of the processing time comes from running the algorithm programs > as subprocesses, so we control the execution time with the timeout > option parameter of the wait_proc() function. If the process takes > more than the timeout delay, it will be interrupted and a TimeoutError > exception is raised: > > timeout = 60 > p = self.run_proc([foo, bar]) > try: > self.wait_proc(p, timeout) > except TimeoutError: > return self.error(errcode='timeout', > errmsg="The program took too much time.") > > A better way to do it is (see app/my_affine_sift/app.py): > * use the self.timeout attribute defined for each app class > * catch the timeout error from the self.run() function > * pass the timeout parameter to the self.run_algo() function > > > def run(self): > try: > self.run_algo(timeout=self.timeout) > except TimeoutError: > return self.error(errcode='timeout', > errmsg="The program took too much time.") > except RuntimeError: > return self.error(errcode='runtime', > errmsg="The program ended in an execution error") > return self.tmpl_out("run.html") > > def run_algo(self, timeout=False) > p = self.run_proc([foo, bar]) > self.wait_proc(p, timeout) > return > > So, to avoid the infamous "Error 504" page, demos should always > specify a non-null timeout when waiting for a process. And be careful > if you run 3 processes sequentially, you should divide the timeout to > ensure a global timeout, and the demo editor expertise is required to > know which process is expected to need more time. > > p1 = self.run_proc([foo, bar]) > self.wait_proc(p1, timeout/2) > p2 = self.run_proc([foo, bar]) > self.wait_proc(p2, timeout/4) > p3 = self.run_proc([foo, bar]) > self.wait_proc(p3, timeout/4) > > Finally, to avoid this process timeout for most of the images, you > should ensure the processed data size is within a reasonable limit, > either via the input restrictions (max_size attributes) or via a > custom control if you manipulate the input (crop, ...) > > Another timeout is configurable at the Cherrypy level, but I thought > it would be overkill. > > And as usual, this is just the way I spontaneously implemented it; it > can be modified, your contributions are welcome. > > -o-0-o- > > In brief: > * there is a hard external timeout of 90 seconds on all the demo pages, > always active : Error 504 > * we avoid the hard timeout with a soft internal timeout on the > process executions; activated on demand in wait_proc(), the > suggested timeout configuration is 60 seconds > * we avoid the soft timeout by controling and reducing the input size > > Todolist: > * notify by email the demo authors of any timeout triggered > * gather statistics about these timeouts with other operation > infos[2] > > [2]http://tools.ipol.im/munin/ipol/fuchsia.html#Ipol > > > > ------------------------------------------------------------------------ > > _______________________________________________ > discuss mailing list > discuss at list.ipol.im > http://tools.ipol.im/mailman/listinfo/discuss From Miguel.Colom at cmla.ens-cachan.fr Mon Feb 7 13:27:08 2011 From: Miguel.Colom at cmla.ens-cachan.fr (Miguel.Colom at cmla.ens-cachan.fr) Date: Mon, 7 Feb 2011 13:27:08 +0100 Subject: [IPOL discuss] Time out In-Reply-To: <20110207103102.GK3972@nashi.hw.39mm.net> References: <20110207091016.GJ3972@nashi.hw.39mm.net> <20110207103102.GK3972@nashi.hw.39mm.net> Message-ID: <01f5b386357a90c6d2eee121e4ecf8d0.squirrel@webmail.cmla.ens-cachan.fr> >> And the window that appears in case of time out with "Error 504: Gateway >> Timeout. This part of IPOL Is Temporary unavailable ... " is >> inaccurate since this is generally interrupted by time out and not a >> server error. > > This page should never appear. The shortest answer is: ?demos should > properly use the timeout system?. The detailed answer starts with a > little explanation about the demo system network and timeout. See the > end of this message for an answer in 3 sentences. I think it'd be nice if the final web users could see a percentage of the progression of the computations of the algorithm. Most of them consist on repeated operations inside one or more loops and the program can overwrite a text file with that percentage. It's very simple, and of course it doesn't have to be mandatory for all the publications. The page could poll this value every 10 seconds for example and update a progress bar. It is very easy to implement and I think that this is needed to make the user feel that the algorithm is really being computed and when is it going to finish. From nicolas.limare at cmla.ens-cachan.fr Mon Feb 7 14:08:52 2011 From: nicolas.limare at cmla.ens-cachan.fr (Nicolas Limare) Date: Mon, 7 Feb 2011 22:08:52 +0900 Subject: [IPOL discuss] Time out In-Reply-To: <4D4FCC2C.3000906@cmla.ens-cachan.fr> References: <20110207091016.GJ3972@nashi.hw.39mm.net> <20110207103102.GK3972@nashi.hw.39mm.net> <4D4FCC2C.3000906@cmla.ens-cachan.fr> Message-ID: <20110207130852.GM3972@nashi.hw.39mm.net> On Mon, Feb 07, 2011 at 11:40:44AM +0100, Jean-Michel Morel wrote: > This makes it, thanks! I suggest that this instruction to authors > about time out be added in the IPOL "instructions to authors". Actually, it is an "instruction to editors", because we acknowledged that authors will probably not write the demo code themself. I think the best place for this doc is with the demo code (this info is only relevant for demo programmers), so I'll start with copying the previous message into a doc subfolder of the code archive, and add new documentations when they are written. Let's think about a smart demo handbook later. -- Nicolas LIMARE http://nicolas.limare.net/ pgp:0xFA423F4F -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From nicolas.limare at cmla.ens-cachan.fr Tue Feb 8 10:34:38 2011 From: nicolas.limare at cmla.ens-cachan.fr (Nicolas Limare) Date: Tue, 8 Feb 2011 18:34:38 +0900 Subject: [IPOL discuss] Time out In-Reply-To: <01f5b386357a90c6d2eee121e4ecf8d0.squirrel@webmail.cmla.ens-cachan.fr> References: <20110207091016.GJ3972@nashi.hw.39mm.net> <20110207103102.GK3972@nashi.hw.39mm.net> <01f5b386357a90c6d2eee121e4ecf8d0.squirrel@webmail.cmla.ens-cachan.fr> Message-ID: <20110208093438.GS3972@nashi.hw.39mm.net> > I think it'd be nice if the final web users could see a percentage of the > progression of the computations of the algorithm. Yes, this would improve the user experience. > Most of them consist on repeated operations inside one or more loops and > the program can overwrite a text file with that percentage. It's very > simple, and of course it doesn't have to be mandatory for all the > publications. > > The page could poll this value every 10 seconds for example and update a > progress bar. This design implies that the code is specifically written for the demo, because such feature (updating a file) is useless out of the web demo context. I think the main use case for programs provided in IPOL should be the general command line, and we should design the demos to adapt to the programs. A possibility is to have the program continuously write some progress information to its standard output, then this standard output can be captured into a file, and the file periodically read and displayed in the web page. > It is very easy to implement and I think that this is needed to make the > user feel that the algorithm is really being computed and when is it going > to finish. I think it is not straightforward to implement. Currently, we launch the algorithm processing with `p = run_proc(...)` and we wait for its completed execution with `wait_proc(p)`. If we want to display something before the end of the algorithm execution, we must return the page content after `run_proc()` and before `wait_proc()`. This can be a page with a 10s refresh time. When the page refresh is called, it can include the key id to read and display the current standard output content, or a progress bar. But we can no more use `wait_proc(p)`, because the process object has been lost between the two pages. Thus need to find a way to store the process descriptor object on the server and retrieve it if we want to be able to wait for its completion and controle its timeout. Another solution is to keep the current design and include in the "wait" page some Ajax code to request and refresh the progress information with Javascript. Demo contributions with this kind of improvements are of course welcome. -- Nicolas LIMARE http://nicolas.limare.net/ pgp:0xFA423F4F -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From nicolas.limare at cmla.ens-cachan.fr Tue Feb 8 10:55:04 2011 From: nicolas.limare at cmla.ens-cachan.fr (Nicolas Limare) Date: Tue, 8 Feb 2011 18:55:04 +0900 Subject: [IPOL discuss] input image format in demos In-Reply-To: <201102071037.30362.monasse@imagine.enpc.fr> References: <201102071037.30362.monasse@imagine.enpc.fr> Message-ID: <20110208095504.GV3972@nashi.hw.39mm.net> Hi Pascal, > I have a question about input image format in IPOL demos' python code. It > seems you can select the format by setting the string app.input_ext (for > example '.ppm' in graph cuts demo) but that first the images are saved in PNG > format, and then additional files with required format (here PPM) are > generated. Is this assumption correct? Yes. In the file lib/base_app.py, lines 152 and following: def process_input(self): # [...] for i in range(self.input_nb): # [...] # open the file as an image try: im = image(self.work_dir + 'input_%i' % i) except IOError: raise cherrypy.HTTPError(400, # Bad Request "Bad input file") # save the original file as png im.save(self.work_dir + 'input_%i.orig.png' % i) # convert to the expected input format im.convert(self.input_dtype) # check max size if self.input_max_pixels \ and prod(im.size) > (self.input_max_pixels): im.resize(self.input_max_pixels) # [...] # save a working copy im.save(self.work_dir + 'input_%i' % i + self.input_ext) # save a web viewable copy im.save(self.work_dir + 'input_%i.png' % i) # delete the original os.unlink(self.work_dir + 'input_%i' % i) The uploaded files, already received and saved as `input_X` in the folder `self.work_dir`, are read as an image (via the PIL library), and if successfully read, are * saved in PNG, original size, as `input_X.orig.png` * converted (in memory) to the requested data type (color, gray, ...) * downsized if necessary * saved in the requested format (app.input_ext) for further processing by the program * saved in PNG for inclusion in the web pages -- Nicolas LIMARE http://nicolas.limare.net/ pgp:0xFA423F4F -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From nicolas.limare at cmla.ens-cachan.fr Tue Feb 8 13:09:37 2011 From: nicolas.limare at cmla.ens-cachan.fr (Nicolas Limare) Date: Tue, 8 Feb 2011 21:09:37 +0900 Subject: [IPOL discuss] slider inputs for IPOL demos In-Reply-To: References: Message-ID: <20110208120936.GX3972@nashi.hw.39mm.net> > For some IPOL demos, it would be convenient to use slider inputs for > real-valued parameters. > [...] > > Although this should be simple, most implementations on the web are > pretty complicated. [...] Some sliders are implemented as one part > of a larger UI framework (mountains of code). This is the reason why I haven't been working on JavaScript features for IPOL yet. I don't know if it is better to write our own minimal code and maintain it, or use a large library widely tested and written and maintained by pros. I don't know much about the vast choice of JS libraries, and didn't reserve enough time to investigate this question. Do you think a JS library is too much for our needs? What about the slider in jQueryUI, a major player in this field? -> http://docs.jquery.com/UI/Slider -> http://jqueryui.com/demos/slider/ > I have developed a 200-line implementation that, to the best of my > abilities, satisfies these goals: > > http://www.math.ucla.edu/~getreuer/slider.html Very nice, compact and elegant! A few remarks: * You could use the "label" element, I think it's more semantic: * Why did you choose to use a
, not a simple for the thumb? (just curiosity) * I tried to modify it a little, and put the "sliderline" and "sliderthumb" elements into a common "slider" div element in order to freely position the slider and get rid of the table because I'm not a big fan of tables used for the page layout. But I couldn't reach a working solution, so if anyone has more CSS know-how... * I also tried to have the min and max values appear on both ends of the slider, here again without success. > I am aware that IPOL generally avoids JavaScript, IPOL avoids useless or unmaintained JavaScript. Any well written and tested JavaScript bringing usability improvements without good fallback behaviour is welcome. > What are your thoughts about using this slider in IPOL demos? I like it. Once we are sure we want to follow this path (and not use a JS library), it can be included and available for all the demos. Soufiane, I think you have some experience with JavaScript in the PLATO project. What is your opinion? -- Nicolas LIMARE http://nicolas.limare.net/ pgp:0xFA423F4F -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From nicolas.limare at cmla.ens-cachan.fr Thu Feb 10 09:32:21 2011 From: nicolas.limare at cmla.ens-cachan.fr (Nicolas Limare) Date: Thu, 10 Feb 2011 17:32:21 +0900 Subject: [IPOL discuss] screen size/resolution vs. text and image size Message-ID: <20110210083221.GI3179@nashi.hw.39mm.net> A follow-up on the screen resolution problems, already shrortly discussed on the list[1]. To overcome the problem of high-resolution screens, I tried an alternative configuration. Now the font size for all IPOL and the size of the thumbnails for the archive indexes are specified in "physical measures", ie cm instead of pixels. This means that (for any correctly configured screen) the size of these elements should be the same and provide the same confort to everyone. This can not be used for images other than thumbnails because the images will be resized by the browser on high-resolution screens to be displayed with the same size as on a low-res screen, and we want pixel-wise exactitude on the (non-thumbnail) images. Now I would like to know more about your IPOL user experience: * What is your screen size (width and height, in cm please) and definition (width and height in pixels) * How large usually is your browser window? full screen, half, ... * What do you think of the text size in the algo pages? -> http://www.ipol.im/pub/algo/my_affine_sift/ * And on the archive index pages? -> http://www.ipol.im/pub/demo/my_affine_sift/archive/ * What about the thumbnail sizes in the archive index? Are these sizes good, too large, too small? If you'd like them to be larger or smaller, please give an approximative enlarging or shrinking ratio. If you only answer these 5 questions, please send me your message privately (nicolas.limare at cmla.ens-cachan.fr) to avoid noise on the list; I will compile and post the statistics. Of course, if you have remarks and comments, the mailing-list is the best place. [1]http://tools.ipol.im/mailman/archive/discuss/2010-October/000031.html -- Nicolas LIMARE http://nicolas.limare.net/ pgp:0xFA423F4F -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From Miguel.Colom at cmla.ens-cachan.fr Sat Feb 12 13:13:55 2011 From: Miguel.Colom at cmla.ens-cachan.fr (Miguel Colom) Date: Sat, 12 Feb 2011 13:13:55 +0100 Subject: [IPOL discuss] Email addresses visibility Message-ID: <0f3b90631b5bf307fbc3a43dfcab6ed0.squirrel@webmail.cmla.ens-cachan.fr> Hello everybody, the email addresses of the authors of the articles as well the editor's ones are completely visible in the web page and also in the HTML source code of the page. Without any protection, any robot can find these addresses and start sending lots of spam emails to them. We should avoid that by using some simple tricks, like showing the emails in a format like 'user at server dot com" and generating the 'mailto:' field by javascript code. Regards, Miguel From getreuer at gmail.com Sat Feb 12 13:50:06 2011 From: getreuer at gmail.com (Pascal Getreuer) Date: Sat, 12 Feb 2011 13:50:06 +0100 Subject: [IPOL discuss] Email addresses visibility In-Reply-To: <0f3b90631b5bf307fbc3a43dfcab6ed0.squirrel@webmail.cmla.ens-cachan.fr> References: <0f3b90631b5bf307fbc3a43dfcab6ed0.squirrel@webmail.cmla.ens-cachan.fr> Message-ID: I suggest as a basic solution that IPOL encodes email addresses using character entities, for example, test at yahoo.com becomes test@yahoo.com The advantage of this approach is that the user still sees a working clickable mail link, so for the user this is much more convenient than retyping emails from images or dechipering captcha puzzles like "testNOatSPAMyahoodotcom." Also, it is more portable since no JavaScript is required. While a sophisticated robot could still decode an address written in character entities, it goes a long way to reduce exposure. There is a good discussion and links to tools for email hiding techniques on http://www.ohlone.edu/org/webcenter/emailencoding.html Best, Pascal On Sat, Feb 12, 2011 at 13:13, Miguel Colom wrote: > Hello everybody, > the email addresses of the authors of the articles as well the editor's > ones are completely visible in the web page and also in the HTML source > code of the page. > > Without any protection, any robot can find these addresses and start > sending lots of spam emails to them. > > We should avoid that by using some simple tricks, like showing the emails > in a format like 'user at server dot com" and generating the 'mailto:' > field by javascript code. > > Regards, > Miguel > > _______________________________________________ > discuss mailing list > discuss at list.ipol.im > http://tools.ipol.im/mailman/listinfo/discuss > From nicolas.limare at cmla.ens-cachan.fr Mon Feb 14 13:49:10 2011 From: nicolas.limare at cmla.ens-cachan.fr (Nicolas Limare) Date: Mon, 14 Feb 2011 21:49:10 +0900 Subject: [IPOL discuss] Email addresses visibility In-Reply-To: References: <0f3b90631b5bf307fbc3a43dfcab6ed0.squirrel@webmail.cmla.ens-cachan.fr> Message-ID: <20110214124909.GB30350@nashi.hw.39mm.net> > I suggest as a basic solution that IPOL encodes email addresses using > character entities, for example, > becomes > > test@ yahoo.com > I use a similar option: only encoding the "@" as "@". The adress keeps readable, and it seems enough to defeat the common page scanners. test@yahoo.com Anyway, my opinion is that I prefer to publish real working email addresses and that spam protection has to be performed on mail servers. -- Nicolas LIMARE http://nicolas.limare.net/ pgp:0xFA423F4F -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From nicolas.limare at cmla.ens-cachan.fr Tue Feb 22 11:37:41 2011 From: nicolas.limare at cmla.ens-cachan.fr (Nicolas Limare) Date: Tue, 22 Feb 2011 19:37:41 +0900 Subject: [IPOL discuss] tech@ipol.im for the technical questions Message-ID: <20110222103741.GW16543@nashi.hw.39mm.net> Dear IPOL people, We are trying to move to a collective administration of the IPOL systems. I'm referring here to the technical administration: servers and systems management, configurations, troubleshooting, etc., not to the editorial management. We are now 3 in the "tech group": Jose-Luis Lisani, Pascal Getreuer and myself. So, when you have a technical question or remark about IPOL (something doesn't work, or doesn't work as expected, or a wiki page must be (un)locked, etc.), please send your mails to tech at ipol.im. This will maximize your chances of a quick answer. Even if you are talking about a technical problem with one of us, it is better to write to tech at ipol.im to keep the others informed. In short: * questions about the edition process of a specific algorithm are dealt with the authors, editors and referees for this article, plus the IPOL editor in chief * techical requests and alerts go to tech at ipol.im * everything else goes to this list discuss at list.ipol.im I hope we can gradually switch from a people-driven project to a community-driven one. Best, -- Nicolas LIMARE - CMLA - ENS Cachan http://www.cmla.ens-cachan.fr/~limare/ IPOL - image processing on line http://www.ipol.im/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From nicolas.limare at cmla.ens-cachan.fr Thu Feb 24 08:14:06 2011 From: nicolas.limare at cmla.ens-cachan.fr (Nicolas Limare) Date: Thu, 24 Feb 2011 16:14:06 +0900 Subject: [IPOL discuss] screen size/resolution vs. text and image size In-Reply-To: <20110210083221.GI3179@nashi.hw.39mm.net> References: <20110210083221.GI3179@nashi.hw.39mm.net> Message-ID: <20110224071406.GG6507@nashi.hw.39mm.net> > To overcome the problem of high-resolution screens, I tried an > alternative configuration. Now the font size for all IPOL and the size > of the thumbnails for the archive indexes are specified in "physical > measures", ie cm instead of pixels. > > [...] > > Now I would like to know more about your IPOL user experience: > * What is your screen size (width and height, in cm please) > and definition (width and height in pixels) > * How large usually is your browser window? full screen, half, ... > * What do you think of the [text and image] size in the [algo and > demo] pages? From the few answers I received, our screen resolutions are between 30 and 50 pixels per cm. The new sizes were correct but teh text size could be reduced in the archive indexes. I did a last correction: * the general font size is 0.375cm * in the archive indexes, the font size is 0.32cm * the archive thumbnails are 3x3cm, expanded to 5x5cm when the pointer is over them, and use a 256x256px image (previously 128x128), resized by the browser -- Nicolas LIMARE http://nicolas.limare.net/ pgp:0xFA423F4F -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From monasse at imagine.enpc.fr Thu Feb 24 16:19:32 2011 From: monasse at imagine.enpc.fr (Pascal Monasse) Date: Thu, 24 Feb 2011 16:19:32 +0100 Subject: [IPOL discuss] published articles Message-ID: <201102241619.33049.monasse@imagine.enpc.fr> Hello all, I seem to remember that it was planned that on the web page of published articles the reviewer's names and their reports would appear, possibly as first posts in a public forum associated to the algorithm. This is not the case in the two published articles so far. Is this feature still planned? I understand that setting up a forum requires some work, but in the mean time, couldn't there just be links to the reports? Best, Pascal From morel at cmla.ens-cachan.fr Thu Feb 24 16:37:02 2011 From: morel at cmla.ens-cachan.fr (Jean-Michel Morel) Date: Thu, 24 Feb 2011 16:37:02 +0100 Subject: [IPOL discuss] published articles In-Reply-To: <201102241619.33049.monasse@imagine.enpc.fr> References: <201102241619.33049.monasse@imagine.enpc.fr> Message-ID: <4D667B1E.3010601@cmla.ens-cachan.fr> Dear all, Rather than formal referee reports there is an interaction between referees and authors ending up in the publication. The referee reports I have observed so far are rather informal. But this interaction could indeed be the starting point of a forum. There was and is the plan to start a forum on each publication. Actually that would be the best way to organize information sharing between the (many) users who downloaded a code and actually relieve the authors of the burden of answering repeatedly the same question. Technically speaking who is ready to organize these forums for the first published papers? JM Pascal Monasse a ?crit : > Hello all, > > I seem to remember that it was planned that on the web page of published > articles the reviewer's names and their reports would appear, possibly as first > posts in a public forum associated to the algorithm. This is not the case in > the two published articles so far. Is this feature still planned? I understand > that setting up a forum requires some work, but in the mean time, couldn't > there just be links to the reports? > > Best, > Pascal > _______________________________________________ > discuss mailing list > discuss at list.ipol.im > http://tools.ipol.im/mailman/listinfo/discuss > From daniel.kondermann at iwr.uni-heidelberg.de Fri Feb 25 13:50:21 2011 From: daniel.kondermann at iwr.uni-heidelberg.de (Daniel Kondermann) Date: Fri, 25 Feb 2011 13:50:21 +0100 Subject: [IPOL discuss] published articles In-Reply-To: <4D667B1E.3010601@cmla.ens-cachan.fr> References: <201102241619.33049.monasse@imagine.enpc.fr> <4D667B1E.3010601@cmla.ens-cachan.fr> Message-ID: <4D67A58D.1050609@iwr.uni-heidelberg.de> Hi, > Technically speaking who is ready to organize these forums for the > first published papers? I think this raises the question of the web framework. I have looked a bit deeper into that topic, but I have the feeling, that the choice is rather arbitrary/difficult. Basically, I think there are three questions: -Should it be a web framework like Django or Rails or should it instead be a content management system (CMS) like typo3 or zope? I think if we want user interaction a CMS can be very limiting, but I am not into the details. I definitely think we should have something we can modify and extend easily, so I would opt for a web framework. -The second question will be on which language the system should run. I think there are at least Ruby, Python, (server side)JavaScript, Perl, PHP and Java. For each language there is at least one system which offers all functionality we need. -So I guess the third question is who is going to do the job, because he/she has to invest quite some time to make interactive stuff like forums possible (define styles, install modules/plugins, extend plugins for review-specific workflows, ...). This is something a "scientifical assistant" (wissenschaftliche Hilskraft) can do, but this guy needs to be paid with around 400-600?/month, at least here in Germany. In case there is money which can be spent, I have one or two candidates for the middle-term administration of the web-frontend (excluding demo system and system administration, etc. for about two years). This person would most likely use something like Django or Rails. An open problem would then be to make sure the system is available long-term and new developers/administrators can be found timely once the assistant graduates. Best, Daniel Am 24.02.2011 16:37, schrieb Jean-Michel Morel: > Dear all, > > Rather than formal referee reports there is an interaction between > referees and authors ending up in the publication. The referee > reports I have observed so far are rather informal. > > But this interaction could indeed be the starting point of a forum. > > There was and is the plan to start a forum on each publication. > Actually that would be the best way to organize information sharing > between the (many) users who downloaded a code and actually relieve > the authors of the burden of answering repeatedly the same question. > > Technically speaking who is ready to organize these forums for the > first published papers? JM > > > > > > Pascal Monasse a ?crit : >> Hello all, >> >> I seem to remember that it was planned that on the web page of >> published articles the reviewer's names and their reports would >> appear, possibly as first posts in a public forum associated to >> the algorithm. This is not the case in the two published articles >> so far. Is this feature still planned? I understand that setting up >> a forum requires some work, but in the mean time, couldn't there >> just be links to the reports? >> >> Best, Pascal _______________________________________________ >> discuss mailing list discuss at list.ipol.im >> http://tools.ipol.im/mailman/listinfo/discuss >> > _______________________________________________ discuss mailing list > discuss at list.ipol.im http://tools.ipol.im/mailman/listinfo/discuss -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From nicolas.limare at cmla.ens-cachan.fr Mon Feb 28 12:29:14 2011 From: nicolas.limare at cmla.ens-cachan.fr (Nicolas Limare) Date: Mon, 28 Feb 2011 20:29:14 +0900 Subject: [IPOL discuss] web development In-Reply-To: <4D67A58D.1050609@iwr.uni-heidelberg.de> References: <201102241619.33049.monasse@imagine.enpc.fr> <4D667B1E.3010601@cmla.ens-cachan.fr> <4D67A58D.1050609@iwr.uni-heidelberg.de> Message-ID: <20110228112914.GE733@nashi.hw.39mm.net> Hi, > I think this raises the question of the web framework. [...] > Basically, I think there are three questions: > > -Should it be a web framework like Django or Rails or should it instead > be a content management system (CMS) like typo3 or zope? I think a CMS is the quick solution, limited to handle the web pages. It comes with its more or less rigid publishing workflow. A web framework implied more development work, but will be more flexible and extendable. So, the real question is not CMS vs Framework, it is more short term vs long term, and it is a matter of available workforce. For the moment, I chose a CMS (ikiwiki) to have a quickly working IPOL prototype. I think from now the correct correct way is the framework. Same for the demos. The first version, still used on mw.cmla.ens-cachan.fr, was a plain CGI script. The current version integrates with a (light) web application framework. > -The second question will be on which language the system should run. I > think there are at least Ruby, Python, (server side) JavaScript, Perl, > PHP and Java. For each language there is at least one system which > offers all functionality we need. Like everyone, I have some language preferences, but I will resist the temptation to start the debate as languages wars are the most common and heated (thus often enjoyable yet sterile) discussions among programmers... > -So I guess the third question is who is going to do the job, because > he/she has to invest quite some time to make interactive stuff like > forums possible (define styles, install modules/plugins, extend plugins > for review-specific workflows, ...). First, I think IPOL is still too tied to me, and I think it would be healtier if future developments are not done by me, even if I can (and intend to) be part of such developments. Then, I want to stress a few points, even if some may seem obvious: * Some real work is needed, IPOL can't run just from its content authors and reviewers. * Web development is more than web editing, it is designing and implementing the published document model (what is an article in IPOL?) and workflow (what are the steps from a draft to a published article, and beyond?). * An image processing researcher is not a web developer. Some researchers may be fluent in web publishing, and maybe in web development, but these skills are usually not in the resume of just any computer-savvy researcher. So, the best person for IPOL development is probably not one of the potential IPOL authors or editors. As proposed by Daniel, a "research assistant" may be a possible way. I don't know what's possible on the Cachan side. Or other sides (other French labs, Palma, Montevideo, ...). Jean-Michel, what's your opinion on these questions and the idea and possibility of remunerating someone for such works? Meanwhile, maybe something can be done to answer Pascal's original message, only asking to have the reviews available. Jean-Michel answered by asking for forums, then Daniel headed towards general web development, but let's be careful not to fail and do nothing because of too much ambitions. For the moment, with the existing tools and ressources, forums are not possible[1], but it is possible to publish the reviewers' comments in a web page accessible from the article page. Best, [1] I thought we could also have forums with the ikiwiki "comment" feature, but this proved incompatible with an early IPOL design decision: hide and protect all the "active" part of the site behind user authentification. -- Nicolas LIMARE http://nicolas.limare.net/ pgp:0xFA423F4F -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From nicolas.limare at cmla.ens-cachan.fr Tue Feb 1 13:46:22 2011 From: nicolas.limare at cmla.ens-cachan.fr (Nicolas Limare) Date: Tue, 1 Feb 2011 21:46:22 +0900 Subject: [IPOL discuss] citations in IPOL articles In-Reply-To: <4D42E655.2050303@iwr.uni-heidelberg.de> References: <4D42E655.2050303@iwr.uni-heidelberg.de> Message-ID: <20110201124622.GA29812@nashi.hw.39mm.net> 1. First, a short answer to Pascal >> I have found a method for doing this, but it is rather ugly. Here is >> an example: >> >> "# References >> 1. Historic paper >> 2. Another paper >> ... >> The proof of this result can be found in [1]." >> >> >> Is there a better way to do this? You can manually insert anchors into the reference list, and then use these anchors for internal links. 8<----------8<----------8<----------8<----------8<----------8<---------- # References 1. Natsume Foo, Historic Paper, Journal of Blah 2. John Bar, Another Paper, Journal of Articles ... The proof of this result can be found in Foo's article. 8<----------8<----------8<----------8<----------8<----------8<---------- This way, you have one stable identifier per reference. And I think it is better to use real text in the reference hyperlinks. Numbered references like "[1]" were useful in the paper era when we needed to search a reference in the reference list, but is not required anymore with hyperlinks. You can even do better with more HTML: use the "ref_xxx" names to identify the references in the list instead of empty anchor tags. 8<----------8<----------8<----------8<----------8<----------8<---------- # References
  1. Natsume Foo, Historic Paper, Journal of Blah
  2. John Bar, Another Paper, Journal of Articles
... The proof of this result can be found in Foo's article. 8<----------8<----------8<----------8<----------8<----------8<---------- I'm afraid this is the best we can do for the moment, with the current tools. 2. Now, answering to Daniel > From my point of view it would most certainly be the best way to simply > use bibtex-style references and a cite-tag in the markup. I completely agree, BibTeX is the de-facto standard and should be supported. One little problem with BibTeX is it lacks standardization for electronic reference attributes such as URLs or DOIs. > Things brings us back to the question about the requirements and choice > of a content managament system. > > I am currently trying to find a sustainable way to develop the > web-interface. As I understood up to now, there are basically three > "systems" > > Demo Frontend (HTML+Ajax, Java, ...?) > Demo Backend (Python-based code) > Article CMS (IkiWiki) For the moment the Demo frontent is only HTML. It could include Javascript/Ajax/... if someone is willing to support it. I don't think we should use Java, because a java applet is only inserted into a web page and doesn't integrate with the surrounding environment (HTML/CSS/JS), because the future of Java is quite unclear since Oracle bought Sun, and because most of the things we need for the frontend can probably be done with JavaScript+HTML5. > I suggest to leave the Demo part as it is right now and would like to > discuss the choice for content management. > Therefore, I would ask you to comment on the requirements first in order > to try to make a "bias-free" decision in terms of prior knowledge how to > use the system. Next step would be to "bias" these results by looking at > who knows how much about each system and would dare to take some > responsibility there. > > Can somebody reiterate the list of possible system choices and the one > containing the long-term requirements? I have three lists of requirements, from three points of view: author, editor and administrator. A. The core requirements for the author are: * the ability to edit an article page with rich text, media (image, video, ...), formulas, references, ... * the ability to upload some files for inclusion in the page * an easy to use syntax Authors would also like to recycle the the texts they already wrote in LaTeX for IPOL without too much work. B. The core requirements for the editor are: * user management, ie the possibility to identify people, for... * access management, ie the possibility to define and modify who can read and/or edit any content (page or uploaded file) of the system, in a flexible way (for authors, editors, reviewers, ...) * retain the history of the modifications C. The core requirements for the admin are: * supported, reliable software solution * with few dependencies * manageable with console system tools These are only the core features. I can think of tons of interesting things to be done with this system, such as * structured content of the articles, ie not putting everything as a long text but having special fields to fill for the references, for the source code, etc. * triggering actions on update, for example recomputing all the embedded images when the source code is updated (this would be real reproducible research articles) or updating the doxygen documentation when needed * mail notification on edition * support for rich metadata (Dublin Core) * user forum and review * ... The possible choices proposed were Mediawiki, Django, Drupal, Plone, Joomla. There are lots of other options, as seen on http://en.wikipedia.org/wiki/List_of_content_management_systems http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks -- Nicolas LIMARE http://nicolas.limare.net/ pgp:0xFA423F4F -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From getreuer at gmail.com Sun Feb 6 19:40:47 2011 From: getreuer at gmail.com (Pascal Getreuer) Date: Sun, 6 Feb 2011 19:40:47 +0100 Subject: [IPOL discuss] slider inputs for IPOL demos Message-ID: For some IPOL demos, it would be convenient to use slider inputs for real-valued parameters. By a slider input, I mean the kind of widget like a volume meter or a scroll bar. For example, a denoising demo might ask for the amount of noise to add using a slider input. I propose here a simple implementation of sliders using JavaScript. Please try the demo on my webpage: http://www.math.ucla.edu/~getreuer/slider.html == Problems == A disadvantage about sliders is that they are imprecise---it is hard for a user to select the value 4.00 exactly and not 3.98 or 4.07. This problem is solved by linking the slider to an editable text box. Then the user benefits from the convenience of the slider bar and has the text box in case precise entry is needed. On the web, sliders also have a technological problem. While most standard widgets are supported by HTML4, sliders are not. HTML5 will add support for sliders, but until then, sliders require JavaScript. I have looked at several implementations, and the essence of it is 1. Create a DIV or an IMG that will function as the draggable slider thumb, set its CSS position property to "relative," and set onmousedown to a JavaScript function that will initiate dragging. 2. In the onmousedown function, set document.onmousemove and document.onmouseup to functions that will handle the dragging. 3. In these handler functions, get the mouse coordinates from (event.screenX,event.screenY) and change the CSS left property of the slider thumb to move it around. Although this should be simple, most implementations on the web are pretty complicated. Some sliders implementations have significant amounts of interface code for stylizing the sliders. Some sliders are implemented as one part of a larger UI framework (mountains of code). Many good sliders have restrictive licenses. There are also free sliders, but naturally these are not as thoroughly tested for browser compatibility. == A Solution == Ideally a slider for IPOL demos should satisfy (in order of highest to lowest priority) 1. work in as many browsers as possible, and degrade gracefully where not supported 2. have a free license 3. have a simple implementation 4. enable the slider to link with an edit text box 5. be attractive and efficient I have developed a 200-line implementation that, to the best of my abilities, satisfies these goals: http://www.math.ucla.edu/~getreuer/slider.html It works successfully in the browsers that I have available: IE8, Firefox 3.6, Chrome 8 and 9, Safari 5 (Windows version), and Opera 11. It degrades gracefully if JavaScript is disabled. In that case only the text box is shown (for example, this works correctly in Firefox with the NoScript plugin and in the Lynx browser, which has no JavaScript support). Visually it is not especially attractive but reasonable. A limitation is that, unlike a standard slider, you cannot move the slider by clicking in the open areas of bar. Only the slider's thumb is interactive. Another limitation is that the slider does not respond to the mouse scroll wheel or to the keyboard. These features are possible (there exist sliders like this on the web), but they come at the cost of more JavaScript code, which it seems would increase the chances of browser compatibility issues. I am not a web expert, I know little about which JavaScript features have browser compatibility issues. I welcome any feedback or suggestions. I am aware that IPOL generally avoids JavaScript, but I see some small amounts of JavaScript are in already use. For example, the IkiWiki "!toggle" link for expanding a section of hidden text uses JavaScript. I think the key requirement is that the site is still usable without JavaScript. What are your thoughts about using this slider in IPOL demos? Pascal Getreuer From nicolas.limare at cmla.ens-cachan.fr Mon Feb 7 10:10:16 2011 From: nicolas.limare at cmla.ens-cachan.fr (Nicolas Limare) Date: Mon, 7 Feb 2011 18:10:16 +0900 Subject: [IPOL discuss] Fwd: "Time out" Message-ID: <20110207091016.GJ3972@nashi.hw.39mm.net> Dear IPOL-ers, I translate hereafter a message from Jean-Michel; I think the answers can be useful to everyone. We frequently habe "time out" on our demos. I suppose that many will be fixed with the more powerful server, but however, I think that users are not properly informed. Once a demo is launched, in addition to the small spinning top, there should de a message such as: "In case this execution takes more than 60 seconds, it will be interrupted" And the window that appears in case of time out with "Error 504: Gateway Timeout. This part of IPOL Is Temporary unavailable ... " is inaccurate since this is generally interrupted by time out and not a server error. So in this case could we send a better message like: "Sorry, the execution of the algorithm on your data was taking more than 60 seconds, and has therefore be automatically interrupted. Please, try again with smaller or less complex data." ----- Forwarded message from Jean-Michel Morel ----- Date: Sat, 05 Feb 2011 16:50:10 +0100 From: Jean-Michel Morel To: Nicolas Limare , Jose Luis Lisani Subject: "Time out" Chers Jos? Luis et Nicolas, Il se produit fr?quemment des "time out" sur nos d?mos. En principe je suppose que beaucoup se r?glerons avec le serveur plus puissant mais, n?anmoins, je pense que les utilisateurs ne sont pas proprement inform?s. D?s qu'une d?mo est lanc?e, outre la petite toupie qui tourne, il faudrait ? cot? un message du type: "In case this execution takes more than 60 seconds, it will be interrupted". Et la fen?tre qui appara?t en cas de time out avec le "Error 504: Gateway Timeout This part of IPOL is temporary unavailable, ... " est inexacte puisque s'agit en g?n?ral d'une interruption par Time out et non pas d'un d?faut du serveur. Donc dans ce cas pourrait-on envoyer un message plus conciliant du type: "Sorry, the execution of the algorithm on your data was taking more than 60 seconds, and has therefore be automatically interrupted. Please, try again with smaller or less complex data". Amiti?s, JM ----- End forwarded message ----- -- Nicolas LIMARE http://nicolas.limare.net/ pgp:0xFA423F4F -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From monasse at imagine.enpc.fr Mon Feb 7 10:37:30 2011 From: monasse at imagine.enpc.fr (Pascal Monasse) Date: Mon, 7 Feb 2011 10:37:30 +0100 Subject: [IPOL discuss] input image format in demos Message-ID: <201102071037.30362.monasse@imagine.enpc.fr> Hello all, I have a question about input image format in IPOL demos' python code. It seems you can select the format by setting the string app.input_ext (for example '.ppm' in graph cuts demo) but that first the images are saved in PNG format, and then additional files with required format (here PPM) are generated. Is this assumption correct? Best, Pascal From nicolas.limare at cmla.ens-cachan.fr Mon Feb 7 11:31:02 2011 From: nicolas.limare at cmla.ens-cachan.fr (Nicolas Limare) Date: Mon, 7 Feb 2011 19:31:02 +0900 Subject: [IPOL discuss] Time out In-Reply-To: <20110207091016.GJ3972@nashi.hw.39mm.net> References: <20110207091016.GJ3972@nashi.hw.39mm.net> Message-ID: <20110207103102.GK3972@nashi.hw.39mm.net> > We frequently habe "time out" on our demos. I suppose that many will > be fixed with the more powerful server, but however, I think that > users are not properly informed. No, the new server will only improve the performance of parallel algorithms. There will be more CPUs, but each CPU won't be faster than a CPU on the current server, so a program using only 1 CPU won't have better performances on the new server. And the situation won't improve. The processors on the next generations of machines won't go faster, there will only be more processors. This has been true for a few years now, and will probably last for a while. For the record, only ASIFT really does real (OpenMP) parallel processing for the moment. Some demos use "quick and dirty" parallel processing by splitting the image, but I'd like to see these hacks gradually disappear. > Once a demo is launched, in addition to the small spinning top, there > should de a message such as: "In case this execution takes more than > 60 seconds, it will be interrupted" I just added this sentence. > And the window that appears in case of time out with "Error 504: Gateway > Timeout. This part of IPOL Is Temporary unavailable ... " is > inaccurate since this is generally interrupted by time out and not a > server error. This page should never appear. The shortest answer is: ?demos should properly use the timeout system?. The detailed answer starts with a little explanation about the demo system network and timeout. See the end of this message for an answer in 3 sentences. There are 2 layers between the network users and the demo: users --- www.ipol.im --- demo.ipol.im --- demo proxy proxy These proxy are some transparent service redirections: * The proxy on www.ipol.im redirects all the requests to http://www.ipol.im/pub/demo to the demo.ipol.im server. With this redirection, the demos and other pages seem to be on the same machine (ie on http://www.ipol.im/) even if they are hosted on different servers, in different places: one in a datacenter in Paris, one in the ENS server room * The proxy on demo.ipol.im connects the demo program to the external network environment. It handles all the network load (and possible abuses) while the demo programs run quietly. Error 504 is a standard status code[1], sent by a proxy then it did not receive an answer from the backend server. In our case, the first proxy on www.ipol.im sends this page when it received no answer from demo.ipol.im. It is supposed to only happen when there is something gone wrong on the demo server (server off, rebooting, network disturbances, ...), and that's why the message says "temporarily unavailable". [1]http://tools.ietf.org/html/rfc2616#section-10.5.5 Of course, we don't want to see this message when the demo are running but slow. Easy! The "Error 504" appears when the demo server didn't answer within 90 seconds (the proxy timeout), so we must ensure the demos reply before, and this is possible with the current code. Most of the processing time comes from running the algorithm programs as subprocesses, so we control the execution time with the timeout option parameter of the wait_proc() function. If the process takes more than the timeout delay, it will be interrupted and a TimeoutError exception is raised: timeout = 60 p = self.run_proc([foo, bar]) try: self.wait_proc(p, timeout) except TimeoutError: return self.error(errcode='timeout', errmsg="The program took too much time.") A better way to do it is (see app/my_affine_sift/app.py): * use the self.timeout attribute defined for each app class * catch the timeout error from the self.run() function * pass the timeout parameter to the self.run_algo() function def run(self): try: self.run_algo(timeout=self.timeout) except TimeoutError: return self.error(errcode='timeout', errmsg="The program took too much time.") except RuntimeError: return self.error(errcode='runtime', errmsg="The program ended in an execution error") return self.tmpl_out("run.html") def run_algo(self, timeout=False) p = self.run_proc([foo, bar]) self.wait_proc(p, timeout) return So, to avoid the infamous "Error 504" page, demos should always specify a non-null timeout when waiting for a process. And be careful if you run 3 processes sequentially, you should divide the timeout to ensure a global timeout, and the demo editor expertise is required to know which process is expected to need more time. p1 = self.run_proc([foo, bar]) self.wait_proc(p1, timeout/2) p2 = self.run_proc([foo, bar]) self.wait_proc(p2, timeout/4) p3 = self.run_proc([foo, bar]) self.wait_proc(p3, timeout/4) Finally, to avoid this process timeout for most of the images, you should ensure the processed data size is within a reasonable limit, either via the input restrictions (max_size attributes) or via a custom control if you manipulate the input (crop, ...) Another timeout is configurable at the Cherrypy level, but I thought it would be overkill. And as usual, this is just the way I spontaneously implemented it; it can be modified, your contributions are welcome. -o-0-o- In brief: * there is a hard external timeout of 90 seconds on all the demo pages, always active : Error 504 * we avoid the hard timeout with a soft internal timeout on the process executions; activated on demand in wait_proc(), the suggested timeout configuration is 60 seconds * we avoid the soft timeout by controling and reducing the input size Todolist: * notify by email the demo authors of any timeout triggered * gather statistics about these timeouts with other operation infos[2] [2]http://tools.ipol.im/munin/ipol/fuchsia.html#Ipol -- Nicolas LIMARE http://nicolas.limare.net/ pgp:0xFA423F4F -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From morel at cmla.ens-cachan.fr Mon Feb 7 11:40:44 2011 From: morel at cmla.ens-cachan.fr (Jean-Michel Morel) Date: Mon, 07 Feb 2011 11:40:44 +0100 Subject: [IPOL discuss] Time out In-Reply-To: <20110207103102.GK3972@nashi.hw.39mm.net> References: <20110207091016.GJ3972@nashi.hw.39mm.net> <20110207103102.GK3972@nashi.hw.39mm.net> Message-ID: <4D4FCC2C.3000906@cmla.ens-cachan.fr> This makes it, thanks! I suggest that this instruction to authors about time out be added in the IPOL "instructions to authors". All the best, Jean-Michel Nicolas Limare a ?crit : >> We frequently habe "time out" on our demos. I suppose that many will >> be fixed with the more powerful server, but however, I think that >> users are not properly informed. > > No, the new server will only improve the performance of parallel > algorithms. There will be more CPUs, but each CPU won't be faster > than a CPU on the current server, so a program using only 1 CPU won't > have better performances on the new server. > > And the situation won't improve. The processors on the next > generations of machines won't go faster, there will only be more > processors. This has been true for a few years now, and will probably > last for a while. > > For the record, only ASIFT really does real (OpenMP) parallel > processing for the moment. Some demos use "quick and dirty" parallel > processing by splitting the image, but I'd like to see these hacks > gradually disappear. > >> Once a demo is launched, in addition to the small spinning top, there >> should de a message such as: "In case this execution takes more than >> 60 seconds, it will be interrupted" > > I just added this sentence. > >> And the window that appears in case of time out with "Error 504: Gateway >> Timeout. This part of IPOL Is Temporary unavailable ... " is >> inaccurate since this is generally interrupted by time out and not a >> server error. > > This page should never appear. The shortest answer is: ?demos should > properly use the timeout system?. The detailed answer starts with a > little explanation about the demo system network and timeout. See the > end of this message for an answer in 3 sentences. > > There are 2 layers between the network users and the demo: > > users --- www.ipol.im --- demo.ipol.im --- demo > proxy proxy > > These proxy are some transparent service redirections: > * The proxy on www.ipol.im redirects all the requests to > http://www.ipol.im/pub/demo to the demo.ipol.im server. With this > redirection, the demos and other pages seem to be on the same > machine (ie on http://www.ipol.im/) even if they are hosted on > different servers, in different places: one in a datacenter in > Paris, one in the ENS server room > * The proxy on demo.ipol.im connects the demo program to the external > network environment. It handles all the network load (and possible > abuses) while the demo programs run quietly. > > Error 504 is a standard status code[1], sent by a proxy then it did > not receive an answer from the backend server. In our case, the first > proxy on www.ipol.im sends this page when it received no answer from > demo.ipol.im. It is supposed to only happen when there is something > gone wrong on the demo server (server off, rebooting, network > disturbances, ...), and that's why the message says "temporarily > unavailable". > > [1]http://tools.ietf.org/html/rfc2616#section-10.5.5 > > Of course, we don't want to see this message when the demo are running > but slow. Easy! The "Error 504" appears when the demo server didn't > answer within 90 seconds (the proxy timeout), so we must ensure the > demos reply before, and this is possible with the current code. > > Most of the processing time comes from running the algorithm programs > as subprocesses, so we control the execution time with the timeout > option parameter of the wait_proc() function. If the process takes > more than the timeout delay, it will be interrupted and a TimeoutError > exception is raised: > > timeout = 60 > p = self.run_proc([foo, bar]) > try: > self.wait_proc(p, timeout) > except TimeoutError: > return self.error(errcode='timeout', > errmsg="The program took too much time.") > > A better way to do it is (see app/my_affine_sift/app.py): > * use the self.timeout attribute defined for each app class > * catch the timeout error from the self.run() function > * pass the timeout parameter to the self.run_algo() function > > > def run(self): > try: > self.run_algo(timeout=self.timeout) > except TimeoutError: > return self.error(errcode='timeout', > errmsg="The program took too much time.") > except RuntimeError: > return self.error(errcode='runtime', > errmsg="The program ended in an execution error") > return self.tmpl_out("run.html") > > def run_algo(self, timeout=False) > p = self.run_proc([foo, bar]) > self.wait_proc(p, timeout) > return > > So, to avoid the infamous "Error 504" page, demos should always > specify a non-null timeout when waiting for a process. And be careful > if you run 3 processes sequentially, you should divide the timeout to > ensure a global timeout, and the demo editor expertise is required to > know which process is expected to need more time. > > p1 = self.run_proc([foo, bar]) > self.wait_proc(p1, timeout/2) > p2 = self.run_proc([foo, bar]) > self.wait_proc(p2, timeout/4) > p3 = self.run_proc([foo, bar]) > self.wait_proc(p3, timeout/4) > > Finally, to avoid this process timeout for most of the images, you > should ensure the processed data size is within a reasonable limit, > either via the input restrictions (max_size attributes) or via a > custom control if you manipulate the input (crop, ...) > > Another timeout is configurable at the Cherrypy level, but I thought > it would be overkill. > > And as usual, this is just the way I spontaneously implemented it; it > can be modified, your contributions are welcome. > > -o-0-o- > > In brief: > * there is a hard external timeout of 90 seconds on all the demo pages, > always active : Error 504 > * we avoid the hard timeout with a soft internal timeout on the > process executions; activated on demand in wait_proc(), the > suggested timeout configuration is 60 seconds > * we avoid the soft timeout by controling and reducing the input size > > Todolist: > * notify by email the demo authors of any timeout triggered > * gather statistics about these timeouts with other operation > infos[2] > > [2]http://tools.ipol.im/munin/ipol/fuchsia.html#Ipol > > > > ------------------------------------------------------------------------ > > _______________________________________________ > discuss mailing list > discuss at list.ipol.im > http://tools.ipol.im/mailman/listinfo/discuss From Miguel.Colom at cmla.ens-cachan.fr Mon Feb 7 13:27:08 2011 From: Miguel.Colom at cmla.ens-cachan.fr (Miguel.Colom at cmla.ens-cachan.fr) Date: Mon, 7 Feb 2011 13:27:08 +0100 Subject: [IPOL discuss] Time out In-Reply-To: <20110207103102.GK3972@nashi.hw.39mm.net> References: <20110207091016.GJ3972@nashi.hw.39mm.net> <20110207103102.GK3972@nashi.hw.39mm.net> Message-ID: <01f5b386357a90c6d2eee121e4ecf8d0.squirrel@webmail.cmla.ens-cachan.fr> >> And the window that appears in case of time out with "Error 504: Gateway >> Timeout. This part of IPOL Is Temporary unavailable ... " is >> inaccurate since this is generally interrupted by time out and not a >> server error. > > This page should never appear. The shortest answer is: ?demos should > properly use the timeout system?. The detailed answer starts with a > little explanation about the demo system network and timeout. See the > end of this message for an answer in 3 sentences. I think it'd be nice if the final web users could see a percentage of the progression of the computations of the algorithm. Most of them consist on repeated operations inside one or more loops and the program can overwrite a text file with that percentage. It's very simple, and of course it doesn't have to be mandatory for all the publications. The page could poll this value every 10 seconds for example and update a progress bar. It is very easy to implement and I think that this is needed to make the user feel that the algorithm is really being computed and when is it going to finish. From nicolas.limare at cmla.ens-cachan.fr Mon Feb 7 14:08:52 2011 From: nicolas.limare at cmla.ens-cachan.fr (Nicolas Limare) Date: Mon, 7 Feb 2011 22:08:52 +0900 Subject: [IPOL discuss] Time out In-Reply-To: <4D4FCC2C.3000906@cmla.ens-cachan.fr> References: <20110207091016.GJ3972@nashi.hw.39mm.net> <20110207103102.GK3972@nashi.hw.39mm.net> <4D4FCC2C.3000906@cmla.ens-cachan.fr> Message-ID: <20110207130852.GM3972@nashi.hw.39mm.net> On Mon, Feb 07, 2011 at 11:40:44AM +0100, Jean-Michel Morel wrote: > This makes it, thanks! I suggest that this instruction to authors > about time out be added in the IPOL "instructions to authors". Actually, it is an "instruction to editors", because we acknowledged that authors will probably not write the demo code themself. I think the best place for this doc is with the demo code (this info is only relevant for demo programmers), so I'll start with copying the previous message into a doc subfolder of the code archive, and add new documentations when they are written. Let's think about a smart demo handbook later. -- Nicolas LIMARE http://nicolas.limare.net/ pgp:0xFA423F4F -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From nicolas.limare at cmla.ens-cachan.fr Tue Feb 8 10:34:38 2011 From: nicolas.limare at cmla.ens-cachan.fr (Nicolas Limare) Date: Tue, 8 Feb 2011 18:34:38 +0900 Subject: [IPOL discuss] Time out In-Reply-To: <01f5b386357a90c6d2eee121e4ecf8d0.squirrel@webmail.cmla.ens-cachan.fr> References: <20110207091016.GJ3972@nashi.hw.39mm.net> <20110207103102.GK3972@nashi.hw.39mm.net> <01f5b386357a90c6d2eee121e4ecf8d0.squirrel@webmail.cmla.ens-cachan.fr> Message-ID: <20110208093438.GS3972@nashi.hw.39mm.net> > I think it'd be nice if the final web users could see a percentage of the > progression of the computations of the algorithm. Yes, this would improve the user experience. > Most of them consist on repeated operations inside one or more loops and > the program can overwrite a text file with that percentage. It's very > simple, and of course it doesn't have to be mandatory for all the > publications. > > The page could poll this value every 10 seconds for example and update a > progress bar. This design implies that the code is specifically written for the demo, because such feature (updating a file) is useless out of the web demo context. I think the main use case for programs provided in IPOL should be the general command line, and we should design the demos to adapt to the programs. A possibility is to have the program continuously write some progress information to its standard output, then this standard output can be captured into a file, and the file periodically read and displayed in the web page. > It is very easy to implement and I think that this is needed to make the > user feel that the algorithm is really being computed and when is it going > to finish. I think it is not straightforward to implement. Currently, we launch the algorithm processing with `p = run_proc(...)` and we wait for its completed execution with `wait_proc(p)`. If we want to display something before the end of the algorithm execution, we must return the page content after `run_proc()` and before `wait_proc()`. This can be a page with a 10s refresh time. When the page refresh is called, it can include the key id to read and display the current standard output content, or a progress bar. But we can no more use `wait_proc(p)`, because the process object has been lost between the two pages. Thus need to find a way to store the process descriptor object on the server and retrieve it if we want to be able to wait for its completion and controle its timeout. Another solution is to keep the current design and include in the "wait" page some Ajax code to request and refresh the progress information with Javascript. Demo contributions with this kind of improvements are of course welcome. -- Nicolas LIMARE http://nicolas.limare.net/ pgp:0xFA423F4F -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From nicolas.limare at cmla.ens-cachan.fr Tue Feb 8 10:55:04 2011 From: nicolas.limare at cmla.ens-cachan.fr (Nicolas Limare) Date: Tue, 8 Feb 2011 18:55:04 +0900 Subject: [IPOL discuss] input image format in demos In-Reply-To: <201102071037.30362.monasse@imagine.enpc.fr> References: <201102071037.30362.monasse@imagine.enpc.fr> Message-ID: <20110208095504.GV3972@nashi.hw.39mm.net> Hi Pascal, > I have a question about input image format in IPOL demos' python code. It > seems you can select the format by setting the string app.input_ext (for > example '.ppm' in graph cuts demo) but that first the images are saved in PNG > format, and then additional files with required format (here PPM) are > generated. Is this assumption correct? Yes. In the file lib/base_app.py, lines 152 and following: def process_input(self): # [...] for i in range(self.input_nb): # [...] # open the file as an image try: im = image(self.work_dir + 'input_%i' % i) except IOError: raise cherrypy.HTTPError(400, # Bad Request "Bad input file") # save the original file as png im.save(self.work_dir + 'input_%i.orig.png' % i) # convert to the expected input format im.convert(self.input_dtype) # check max size if self.input_max_pixels \ and prod(im.size) > (self.input_max_pixels): im.resize(self.input_max_pixels) # [...] # save a working copy im.save(self.work_dir + 'input_%i' % i + self.input_ext) # save a web viewable copy im.save(self.work_dir + 'input_%i.png' % i) # delete the original os.unlink(self.work_dir + 'input_%i' % i) The uploaded files, already received and saved as `input_X` in the folder `self.work_dir`, are read as an image (via the PIL library), and if successfully read, are * saved in PNG, original size, as `input_X.orig.png` * converted (in memory) to the requested data type (color, gray, ...) * downsized if necessary * saved in the requested format (app.input_ext) for further processing by the program * saved in PNG for inclusion in the web pages -- Nicolas LIMARE http://nicolas.limare.net/ pgp:0xFA423F4F -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From nicolas.limare at cmla.ens-cachan.fr Tue Feb 8 13:09:37 2011 From: nicolas.limare at cmla.ens-cachan.fr (Nicolas Limare) Date: Tue, 8 Feb 2011 21:09:37 +0900 Subject: [IPOL discuss] slider inputs for IPOL demos In-Reply-To: References: Message-ID: <20110208120936.GX3972@nashi.hw.39mm.net> > For some IPOL demos, it would be convenient to use slider inputs for > real-valued parameters. > [...] > > Although this should be simple, most implementations on the web are > pretty complicated. [...] Some sliders are implemented as one part > of a larger UI framework (mountains of code). This is the reason why I haven't been working on JavaScript features for IPOL yet. I don't know if it is better to write our own minimal code and maintain it, or use a large library widely tested and written and maintained by pros. I don't know much about the vast choice of JS libraries, and didn't reserve enough time to investigate this question. Do you think a JS library is too much for our needs? What about the slider in jQueryUI, a major player in this field? -> http://docs.jquery.com/UI/Slider -> http://jqueryui.com/demos/slider/ > I have developed a 200-line implementation that, to the best of my > abilities, satisfies these goals: > > http://www.math.ucla.edu/~getreuer/slider.html Very nice, compact and elegant! A few remarks: * You could use the "label" element, I think it's more semantic: * Why did you choose to use a
, not a simple for the thumb? (just curiosity) * I tried to modify it a little, and put the "sliderline" and "sliderthumb" elements into a common "slider" div element in order to freely position the slider and get rid of the table because I'm not a big fan of tables used for the page layout. But I couldn't reach a working solution, so if anyone has more CSS know-how... * I also tried to have the min and max values appear on both ends of the slider, here again without success. > I am aware that IPOL generally avoids JavaScript, IPOL avoids useless or unmaintained JavaScript. Any well written and tested JavaScript bringing usability improvements without good fallback behaviour is welcome. > What are your thoughts about using this slider in IPOL demos? I like it. Once we are sure we want to follow this path (and not use a JS library), it can be included and available for all the demos. Soufiane, I think you have some experience with JavaScript in the PLATO project. What is your opinion? -- Nicolas LIMARE http://nicolas.limare.net/ pgp:0xFA423F4F -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From nicolas.limare at cmla.ens-cachan.fr Thu Feb 10 09:32:21 2011 From: nicolas.limare at cmla.ens-cachan.fr (Nicolas Limare) Date: Thu, 10 Feb 2011 17:32:21 +0900 Subject: [IPOL discuss] screen size/resolution vs. text and image size Message-ID: <20110210083221.GI3179@nashi.hw.39mm.net> A follow-up on the screen resolution problems, already shrortly discussed on the list[1]. To overcome the problem of high-resolution screens, I tried an alternative configuration. Now the font size for all IPOL and the size of the thumbnails for the archive indexes are specified in "physical measures", ie cm instead of pixels. This means that (for any correctly configured screen) the size of these elements should be the same and provide the same confort to everyone. This can not be used for images other than thumbnails because the images will be resized by the browser on high-resolution screens to be displayed with the same size as on a low-res screen, and we want pixel-wise exactitude on the (non-thumbnail) images. Now I would like to know more about your IPOL user experience: * What is your screen size (width and height, in cm please) and definition (width and height in pixels) * How large usually is your browser window? full screen, half, ... * What do you think of the text size in the algo pages? -> http://www.ipol.im/pub/algo/my_affine_sift/ * And on the archive index pages? -> http://www.ipol.im/pub/demo/my_affine_sift/archive/ * What about the thumbnail sizes in the archive index? Are these sizes good, too large, too small? If you'd like them to be larger or smaller, please give an approximative enlarging or shrinking ratio. If you only answer these 5 questions, please send me your message privately (nicolas.limare at cmla.ens-cachan.fr) to avoid noise on the list; I will compile and post the statistics. Of course, if you have remarks and comments, the mailing-list is the best place. [1]http://tools.ipol.im/mailman/archive/discuss/2010-October/000031.html -- Nicolas LIMARE http://nicolas.limare.net/ pgp:0xFA423F4F -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From Miguel.Colom at cmla.ens-cachan.fr Sat Feb 12 13:13:55 2011 From: Miguel.Colom at cmla.ens-cachan.fr (Miguel Colom) Date: Sat, 12 Feb 2011 13:13:55 +0100 Subject: [IPOL discuss] Email addresses visibility Message-ID: <0f3b90631b5bf307fbc3a43dfcab6ed0.squirrel@webmail.cmla.ens-cachan.fr> Hello everybody, the email addresses of the authors of the articles as well the editor's ones are completely visible in the web page and also in the HTML source code of the page. Without any protection, any robot can find these addresses and start sending lots of spam emails to them. We should avoid that by using some simple tricks, like showing the emails in a format like 'user at server dot com" and generating the 'mailto:' field by javascript code. Regards, Miguel From getreuer at gmail.com Sat Feb 12 13:50:06 2011 From: getreuer at gmail.com (Pascal Getreuer) Date: Sat, 12 Feb 2011 13:50:06 +0100 Subject: [IPOL discuss] Email addresses visibility In-Reply-To: <0f3b90631b5bf307fbc3a43dfcab6ed0.squirrel@webmail.cmla.ens-cachan.fr> References: <0f3b90631b5bf307fbc3a43dfcab6ed0.squirrel@webmail.cmla.ens-cachan.fr> Message-ID: I suggest as a basic solution that IPOL encodes email addresses using character entities, for example, test at yahoo.com becomes test@yahoo.com The advantage of this approach is that the user still sees a working clickable mail link, so for the user this is much more convenient than retyping emails from images or dechipering captcha puzzles like "testNOatSPAMyahoodotcom." Also, it is more portable since no JavaScript is required. While a sophisticated robot could still decode an address written in character entities, it goes a long way to reduce exposure. There is a good discussion and links to tools for email hiding techniques on http://www.ohlone.edu/org/webcenter/emailencoding.html Best, Pascal On Sat, Feb 12, 2011 at 13:13, Miguel Colom wrote: > Hello everybody, > the email addresses of the authors of the articles as well the editor's > ones are completely visible in the web page and also in the HTML source > code of the page. > > Without any protection, any robot can find these addresses and start > sending lots of spam emails to them. > > We should avoid that by using some simple tricks, like showing the emails > in a format like 'user at server dot com" and generating the 'mailto:' > field by javascript code. > > Regards, > Miguel > > _______________________________________________ > discuss mailing list > discuss at list.ipol.im > http://tools.ipol.im/mailman/listinfo/discuss > From nicolas.limare at cmla.ens-cachan.fr Mon Feb 14 13:49:10 2011 From: nicolas.limare at cmla.ens-cachan.fr (Nicolas Limare) Date: Mon, 14 Feb 2011 21:49:10 +0900 Subject: [IPOL discuss] Email addresses visibility In-Reply-To: References: <0f3b90631b5bf307fbc3a43dfcab6ed0.squirrel@webmail.cmla.ens-cachan.fr> Message-ID: <20110214124909.GB30350@nashi.hw.39mm.net> > I suggest as a basic solution that IPOL encodes email addresses using > character entities, for example, > becomes > > test@ yahoo.com > I use a similar option: only encoding the "@" as "@". The adress keeps readable, and it seems enough to defeat the common page scanners. test@yahoo.com Anyway, my opinion is that I prefer to publish real working email addresses and that spam protection has to be performed on mail servers. -- Nicolas LIMARE http://nicolas.limare.net/ pgp:0xFA423F4F -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From nicolas.limare at cmla.ens-cachan.fr Tue Feb 22 11:37:41 2011 From: nicolas.limare at cmla.ens-cachan.fr (Nicolas Limare) Date: Tue, 22 Feb 2011 19:37:41 +0900 Subject: [IPOL discuss] tech@ipol.im for the technical questions Message-ID: <20110222103741.GW16543@nashi.hw.39mm.net> Dear IPOL people, We are trying to move to a collective administration of the IPOL systems. I'm referring here to the technical administration: servers and systems management, configurations, troubleshooting, etc., not to the editorial management. We are now 3 in the "tech group": Jose-Luis Lisani, Pascal Getreuer and myself. So, when you have a technical question or remark about IPOL (something doesn't work, or doesn't work as expected, or a wiki page must be (un)locked, etc.), please send your mails to tech at ipol.im. This will maximize your chances of a quick answer. Even if you are talking about a technical problem with one of us, it is better to write to tech at ipol.im to keep the others informed. In short: * questions about the edition process of a specific algorithm are dealt with the authors, editors and referees for this article, plus the IPOL editor in chief * techical requests and alerts go to tech at ipol.im * everything else goes to this list discuss at list.ipol.im I hope we can gradually switch from a people-driven project to a community-driven one. Best, -- Nicolas LIMARE - CMLA - ENS Cachan http://www.cmla.ens-cachan.fr/~limare/ IPOL - image processing on line http://www.ipol.im/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From nicolas.limare at cmla.ens-cachan.fr Thu Feb 24 08:14:06 2011 From: nicolas.limare at cmla.ens-cachan.fr (Nicolas Limare) Date: Thu, 24 Feb 2011 16:14:06 +0900 Subject: [IPOL discuss] screen size/resolution vs. text and image size In-Reply-To: <20110210083221.GI3179@nashi.hw.39mm.net> References: <20110210083221.GI3179@nashi.hw.39mm.net> Message-ID: <20110224071406.GG6507@nashi.hw.39mm.net> > To overcome the problem of high-resolution screens, I tried an > alternative configuration. Now the font size for all IPOL and the size > of the thumbnails for the archive indexes are specified in "physical > measures", ie cm instead of pixels. > > [...] > > Now I would like to know more about your IPOL user experience: > * What is your screen size (width and height, in cm please) > and definition (width and height in pixels) > * How large usually is your browser window? full screen, half, ... > * What do you think of the [text and image] size in the [algo and > demo] pages? From the few answers I received, our screen resolutions are between 30 and 50 pixels per cm. The new sizes were correct but teh text size could be reduced in the archive indexes. I did a last correction: * the general font size is 0.375cm * in the archive indexes, the font size is 0.32cm * the archive thumbnails are 3x3cm, expanded to 5x5cm when the pointer is over them, and use a 256x256px image (previously 128x128), resized by the browser -- Nicolas LIMARE http://nicolas.limare.net/ pgp:0xFA423F4F -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From monasse at imagine.enpc.fr Thu Feb 24 16:19:32 2011 From: monasse at imagine.enpc.fr (Pascal Monasse) Date: Thu, 24 Feb 2011 16:19:32 +0100 Subject: [IPOL discuss] published articles Message-ID: <201102241619.33049.monasse@imagine.enpc.fr> Hello all, I seem to remember that it was planned that on the web page of published articles the reviewer's names and their reports would appear, possibly as first posts in a public forum associated to the algorithm. This is not the case in the two published articles so far. Is this feature still planned? I understand that setting up a forum requires some work, but in the mean time, couldn't there just be links to the reports? Best, Pascal From morel at cmla.ens-cachan.fr Thu Feb 24 16:37:02 2011 From: morel at cmla.ens-cachan.fr (Jean-Michel Morel) Date: Thu, 24 Feb 2011 16:37:02 +0100 Subject: [IPOL discuss] published articles In-Reply-To: <201102241619.33049.monasse@imagine.enpc.fr> References: <201102241619.33049.monasse@imagine.enpc.fr> Message-ID: <4D667B1E.3010601@cmla.ens-cachan.fr> Dear all, Rather than formal referee reports there is an interaction between referees and authors ending up in the publication. The referee reports I have observed so far are rather informal. But this interaction could indeed be the starting point of a forum. There was and is the plan to start a forum on each publication. Actually that would be the best way to organize information sharing between the (many) users who downloaded a code and actually relieve the authors of the burden of answering repeatedly the same question. Technically speaking who is ready to organize these forums for the first published papers? JM Pascal Monasse a ?crit : > Hello all, > > I seem to remember that it was planned that on the web page of published > articles the reviewer's names and their reports would appear, possibly as first > posts in a public forum associated to the algorithm. This is not the case in > the two published articles so far. Is this feature still planned? I understand > that setting up a forum requires some work, but in the mean time, couldn't > there just be links to the reports? > > Best, > Pascal > _______________________________________________ > discuss mailing list > discuss at list.ipol.im > http://tools.ipol.im/mailman/listinfo/discuss > From daniel.kondermann at iwr.uni-heidelberg.de Fri Feb 25 13:50:21 2011 From: daniel.kondermann at iwr.uni-heidelberg.de (Daniel Kondermann) Date: Fri, 25 Feb 2011 13:50:21 +0100 Subject: [IPOL discuss] published articles In-Reply-To: <4D667B1E.3010601@cmla.ens-cachan.fr> References: <201102241619.33049.monasse@imagine.enpc.fr> <4D667B1E.3010601@cmla.ens-cachan.fr> Message-ID: <4D67A58D.1050609@iwr.uni-heidelberg.de> Hi, > Technically speaking who is ready to organize these forums for the > first published papers? I think this raises the question of the web framework. I have looked a bit deeper into that topic, but I have the feeling, that the choice is rather arbitrary/difficult. Basically, I think there are three questions: -Should it be a web framework like Django or Rails or should it instead be a content management system (CMS) like typo3 or zope? I think if we want user interaction a CMS can be very limiting, but I am not into the details. I definitely think we should have something we can modify and extend easily, so I would opt for a web framework. -The second question will be on which language the system should run. I think there are at least Ruby, Python, (server side)JavaScript, Perl, PHP and Java. For each language there is at least one system which offers all functionality we need. -So I guess the third question is who is going to do the job, because he/she has to invest quite some time to make interactive stuff like forums possible (define styles, install modules/plugins, extend plugins for review-specific workflows, ...). This is something a "scientifical assistant" (wissenschaftliche Hilskraft) can do, but this guy needs to be paid with around 400-600?/month, at least here in Germany. In case there is money which can be spent, I have one or two candidates for the middle-term administration of the web-frontend (excluding demo system and system administration, etc. for about two years). This person would most likely use something like Django or Rails. An open problem would then be to make sure the system is available long-term and new developers/administrators can be found timely once the assistant graduates. Best, Daniel Am 24.02.2011 16:37, schrieb Jean-Michel Morel: > Dear all, > > Rather than formal referee reports there is an interaction between > referees and authors ending up in the publication. The referee > reports I have observed so far are rather informal. > > But this interaction could indeed be the starting point of a forum. > > There was and is the plan to start a forum on each publication. > Actually that would be the best way to organize information sharing > between the (many) users who downloaded a code and actually relieve > the authors of the burden of answering repeatedly the same question. > > Technically speaking who is ready to organize these forums for the > first published papers? JM > > > > > > Pascal Monasse a ?crit : >> Hello all, >> >> I seem to remember that it was planned that on the web page of >> published articles the reviewer's names and their reports would >> appear, possibly as first posts in a public forum associated to >> the algorithm. This is not the case in the two published articles >> so far. Is this feature still planned? I understand that setting up >> a forum requires some work, but in the mean time, couldn't there >> just be links to the reports? >> >> Best, Pascal _______________________________________________ >> discuss mailing list discuss at list.ipol.im >> http://tools.ipol.im/mailman/listinfo/discuss >> > _______________________________________________ discuss mailing list > discuss at list.ipol.im http://tools.ipol.im/mailman/listinfo/discuss -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From nicolas.limare at cmla.ens-cachan.fr Mon Feb 28 12:29:14 2011 From: nicolas.limare at cmla.ens-cachan.fr (Nicolas Limare) Date: Mon, 28 Feb 2011 20:29:14 +0900 Subject: [IPOL discuss] web development In-Reply-To: <4D67A58D.1050609@iwr.uni-heidelberg.de> References: <201102241619.33049.monasse@imagine.enpc.fr> <4D667B1E.3010601@cmla.ens-cachan.fr> <4D67A58D.1050609@iwr.uni-heidelberg.de> Message-ID: <20110228112914.GE733@nashi.hw.39mm.net> Hi, > I think this raises the question of the web framework. [...] > Basically, I think there are three questions: > > -Should it be a web framework like Django or Rails or should it instead > be a content management system (CMS) like typo3 or zope? I think a CMS is the quick solution, limited to handle the web pages. It comes with its more or less rigid publishing workflow. A web framework implied more development work, but will be more flexible and extendable. So, the real question is not CMS vs Framework, it is more short term vs long term, and it is a matter of available workforce. For the moment, I chose a CMS (ikiwiki) to have a quickly working IPOL prototype. I think from now the correct correct way is the framework. Same for the demos. The first version, still used on mw.cmla.ens-cachan.fr, was a plain CGI script. The current version integrates with a (light) web application framework. > -The second question will be on which language the system should run. I > think there are at least Ruby, Python, (server side) JavaScript, Perl, > PHP and Java. For each language there is at least one system which > offers all functionality we need. Like everyone, I have some language preferences, but I will resist the temptation to start the debate as languages wars are the most common and heated (thus often enjoyable yet sterile) discussions among programmers... > -So I guess the third question is who is going to do the job, because > he/she has to invest quite some time to make interactive stuff like > forums possible (define styles, install modules/plugins, extend plugins > for review-specific workflows, ...). First, I think IPOL is still too tied to me, and I think it would be healtier if future developments are not done by me, even if I can (and intend to) be part of such developments. Then, I want to stress a few points, even if some may seem obvious: * Some real work is needed, IPOL can't run just from its content authors and reviewers. * Web development is more than web editing, it is designing and implementing the published document model (what is an article in IPOL?) and workflow (what are the steps from a draft to a published article, and beyond?). * An image processing researcher is not a web developer. Some researchers may be fluent in web publishing, and maybe in web development, but these skills are usually not in the resume of just any computer-savvy researcher. So, the best person for IPOL development is probably not one of the potential IPOL authors or editors. As proposed by Daniel, a "research assistant" may be a possible way. I don't know what's possible on the Cachan side. Or other sides (other French labs, Palma, Montevideo, ...). Jean-Michel, what's your opinion on these questions and the idea and possibility of remunerating someone for such works? Meanwhile, maybe something can be done to answer Pascal's original message, only asking to have the reviews available. Jean-Michel answered by asking for forums, then Daniel headed towards general web development, but let's be careful not to fail and do nothing because of too much ambitions. For the moment, with the existing tools and ressources, forums are not possible[1], but it is possible to publish the reviewers' comments in a web page accessible from the article page. Best, [1] I thought we could also have forums with the ikiwiki "comment" feature, but this proved incompatible with an early IPOL design decision: hide and protect all the "active" part of the site behind user authentification. -- Nicolas LIMARE http://nicolas.limare.net/ pgp:0xFA423F4F -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From bogus@does.not.exist.com Mon Feb 21 09:05:15 2011 From: bogus@does.not.exist.com () Date: Mon, 21 Feb 2011 08:05:15 -0000 Subject: No subject Message-ID: Regards, Pierre M --0016e64698180fe96e04a432dd9d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Following the recent post about 3D po= int cloud data.

Does it have sense to open a &quo= t;Dataset section" in IPOL rather than put it in the algo section ?=A0=


Other dataset could be added like the one from Guoshen and Morel tha= t they have done for the ASIFT/ SIFT affine invariance.
Aka : Dataset: An image dataset for systematic evaluation of robustnes= s to absolute and transition tilt of the image matching algorithms is avail= able : zip tar/gz.

Regards,
Pierre M

--0016e64698180fe96e04a432dd9d--