[IPOL discuss] enabling conditional visualization in demos

[Nicolas Limare]

Hi,

Here is my late answer to your questions. First of all, I am not
taking any decisions,. I just give my point of view, decisions are to
be taken by the "IPOL community" because no decision can be enforced
if IPOL contributers don't agree,

> A) TOOLS ALLOWED FOR VISUALIZATION:

As usual, it's a balance between the immediate benefits of these tools
(better, nicer interface) and the future drawbacks (more things to
look at, more things to maintain). Every time a new software tool is
needed by a demo, it has to ba available on every machine running the
demo (current demo server, future demo server, development server,
demo developper machines).

At the beginning my intention was to keep as neutral as possible, and
try to keep usable on any OS and system where Python is available. One
year later, I think this may be too much, and maybe we can restrict
the requirement to Unix-type systems. I mean Unix, not Linux, the demo
system should also be usable on Mac OSX machines (or BSD... but there
is no use case yet). This means it may or may not be usable on
Windows, but we don't care much about it. Are there people developping
IPOL demos on Wondows now? Are there people doing Python development
on Windows now?

If Windows is dropped, then there are more software tools available on
all Unix systems. But the availability of the tools doesn't mean we
should use them, because the future work implied by a dependency is
usually underestimated. Five years later, when the current version of
a tool used by a demo changes, either in the command-line syntax, or
input format, or output characteristics, this will break the demo, and
I am sure no one will be willing to fix it unless they wrote or use
this demo.

The last thing for the demo dependencies is that almost anything can
be installed on the development machine, just ask to tech at ipol.im. But
this doesn't mean it will be available on the real "production" demo
server.

That being said (and I still want to know what yo think of focusing on
Unix as an enviroment for running demos)...

> 1) imagemagick's convert:
> *status: installed
> *what do IPOL think about it?: I don't know

What do I think about it? It's a very common tool we all love to use,
and it works quite well. The problem might be that the command-line
syntax and options sometimes change. If we want to use such a tool,
maybe graphicsmagick is better, this imagemagick fork explicitely
focuses on the API and command-line stability.

But instead of using external tools, I think we should use the
internal ones is possible. PIL is already required, so if you can use
it instead of {image,graphics}magick, I think it is better. There is
the little "image" class in the IPOL lib/image.py file, it started as
a PIL abstraction to add some functions not available in PIL. I don't
know if it was a good idea. Maybe we should revert back to plain
PIL. Or just redefine the PIL classes based on PIL, in a real
object-oriented design, something like

import PIL.Image as PIL_Image

def Image(PIL_Image):
    """
    Image class based in PIL.Image
    """

    def resize(self, size, filter=NEAREST):
        """
        resize the image, based in PIL.Image.resize()

	The filter NEAREST, BILINEAR, BICUBIC, or ANTIALIAS. NEAREST
        is redefined here because of a bug in PIL.
	http://mail.python.org/pipermail/image-sig/2011-March/006699.html
        """

	if filter == NEAREST:
            # create a new image
	    newimg = Image.new(self.mode, size)
            pxl = self.load()
	    newpxl = newimg.load()
	    # scaling ratio
	    rx = size[0] // self.size[0]
            ry = size[1] // self.size[1]
            # duplicate the pixels
            for y in range(0, size[1]):
                for x in range(0, size[0]):
                    newpxl[x, y] = pxl[x // rX, y // rY]
            return newimg
	else:
            # use resize function from PIL.Image class
            PIL_Image.resize(self, size, filter)

        return self

> *use: animating gifs for level set evolution for example
> *example: http://iie.fing.edu.uy/~juanc/files/ev.gif

GIF can only use a 256-color palette. How will you show your moving
contour in red if the background image already has 256 graylevels? I'm
not questioning the choice of GIF, just looking for a solution to
this problem. Maybe by the CSS superposition of a background PNG and
foreground transparent GIF with only the contour?

> 2)Graphviz (i.e. dot command line option)
> *status: not installed

I installed it on the dev server.

> *what do IPOL think about it?: I don't know

What do I think about it? I like and use this tool a lot. I have never
seen any significant syntax change for the graph description and basic
graph attributes. It's a good example of a reliable tool and I know no
other similar solution to render graphs. And graphviz also produces
SVG.
Is it used by the executable algorithm (ie by some script provided
with the algorithm source code) or by the demo interface (ie by a
python exec(), system() or sybprocess() call)? In the latter case,
maybe we can consider the pydot[1] interface to avoid subprocess forks
and calls.

And if the graph visualisation is not essential for the demo, if the
demo produces something else that is explained by the graph, then the
graph should be optional and the demo able to run without
graphviz/pydot.

[1] http://code.google.com/p/pydot/

> 3) makedepend: not for visualization, but my code uses it, can we
> enable it at least temporarily until I clean my code?

I installed it on the dev server. But I suggest you to use the -M
compiler option, available on gcc, icc and suncc. 

> B) HOW DO WE ENABLE VISUALIZATION
> I think we can also asume the visualization is optional and we can
> live with less availability. Thus, if we don't want our demos to crash
> due to a visualization library changing or disappearing, we should
> implement them in a way that if problem happens visualization can be
> easily disabled, and we can assure that the main part of the demo will
> keep running.

I agree. Every "fragile" operation (calling an external tool, or maybe
calling obscure python library functions) used for visialization can
be in a python "try: .. except:" block to avoid crashing when
something goes wrong in a non-essential part of the demo. You can find
an example in the LSD demo, when ghostscript is called.

> C) IMPLEMENTATION OF OPTIONAL VISUALIZATION OF GRAPHS

you can do:

    try:
        p3 = self.run_proc(['qnm','partition_to_dot_fancy',
                            'init_part.part',self.input_fname,'init_part.dot'],
                           stdout=stdout_file, stderr=stdout_file)
       self.wait_proc(p3)
       p4 = self.run_proc([self.tool_neato, '-n2','-Tpng', '-O',
                           'init_part.dot'],
                          stdout=stdout_file, stderr=stdout_file)
       self.wait_proc(p4)
    except RuntimeError:
       pass
    except EnvironmentError:
       pass

then, in result(), test if the graph file is there

    try:
        f = open("path/to/graph")
	f.close()
        with_graph = True
    except IOError:
        with_graph = False

and pass with_graph to your templates, to decide wether you must show
the graph or not, as enric explained.

-- 
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: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://tools.ipol.im/mailman/archive/discuss/attachments/20110818/98932cd4/attachment.pgp>