[IPOL discuss] how to specify "run_proc" in the demo generator...

asalgado at dis.ulpgc.es asalgado at dis.ulpgc.es
Tue Aug 23 12:23:30 CEST 2011


Dear all,

   the generator demo is near to be ready. However there are some  
points (doubts) I would like to discuss with you.

   Demos generator creates the html pages of the demo (input, params,  
wait, result) with the information specified in the interface. This  
already works. You can also save and load data from a demo. The file  
with the demo information is stored on the server (no on local hard  
disk).

   I've looked at all the demos available in the GIT repository. They  
can be classified into three groups:

    1) Demo with/without parameters that directly use the input  
sequence (1 image or stereo pair).

       The existence of parameters and not only changes the demo  
dictionary size but does not increase the complexity of the demo.


    2) Demo with/without parameters that can use the sequence or a subimage.

       Similar to type 1 demos but you have to include code for  
selecting the subimage.


    3) Demo with parameters that can execute different algorithms  
depending on the user.

       This kind of demos will not be included in the generator demos.


    The python code common to all the type (1) demos is about 80-90%
    The python code common to all the type (2) demos is about  75-90%
    Between demo type (1) and (2) share over 70% lines of code.


    The differences are located in three points:

    a) In "run_algo." This function makes calls to the compiled code.  
The code of this function depends on (and it is different) each demo.

    b) In the "wait". Some demos apply some operations over the input images.

    c) In the "result" or "run_algo" (depending on the demo). Some  
demos apply some operations on the output images (such as invert the  
image, resize, etc).


    When the demo generator tries to create the "app.py" file is  
facing several problems in these three points. The code generation in  
the "app.py" file is relatively easy  except in these three points  
because on each demo is different. It depends on the source code  
compiled.

    In my opinion, the demo complexity is in how the algorithm calls  
the binaries to execute. What information should specify in the  
"run_proc()" and the number of processes to call. A priori this  
information is difficult to know (and specify).

    The generator can create demos for 80% of the code automatically,  
but in (a), (b) and (c) need help (information). I've thought of  
several alternatives, but I would like to know your opinions. The  
alternatives are:

    (1*) The user must create three files to be included in the  
"app.py" file with a <%include file="file1.py" />. In these three  
files you specify with python code the operations to apply over the  
input images (1), the output images (2), and (3) the calls to the  
processes. Thus The demo creation would be reduced to these three  
files instead of modifying the "app.py" file . Less code to modify,  
reduce errors and improve maintenance. The only drawback I see is the  
fragmentation of information in the demo (divided into 4 files).

    (2 *) All the processes are called through a script created by the  
algorithm author. It still has the problem of how to specify the  
parameter list from the interface but it reduces the run_proc  
complexity to a single call. This alternative does not solve the  
problem in those demos where you have to apply some kind of operation  
on the input or output images.

    In my opinion the alternative (1*) allows the demo generation. It  
delegates to the user the specification of how processes must be  
called. I am currently doing the "app.py" template based on the  
alternative (1*). If you have another alternative please let me know.


    I wait for your comments and suggestions.

Best regards,

   Agustin



   TODO:

   *) The inclusion in the demo generator main page  
(dev.ipol.im/~asalgado/ipol/demo_generator) some sample configuration  
files with several demos running on IPOL (such as  
http://www.ipol.im/pub/demo/blm_color_dimensional_filtering/  
http://www.ipol.im/pub/demo/my_affine_sift/  
http://www.ipol.im/pub/algo/bcms_self_similarity_driven_demosaicking/  
http://www.ipol.im/pub/demo/g_image_interpolation_with_contour_stencils/  
http://www.ipol.im/pub/algo/abmh_real_time_morphological_snakes_algorithm/).  
Thus we can verify hown the generator works and how to specify the  
parameters in the interface.
   *) The demo configuration file (demo data) can be stored/loaded  
from the local hard disk.
   *) Improve the help información.
   *) Fix some bugs in the interface .

   Once I finish the template for the file "app.py" the code generator  
demo will be available in dev.ipol.im with git.


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.




More information about the discuss mailing list