[IPOL discuss] matplotlib? [Re: courve 1D ...]

rafael grompone von gioi grompone at gmail.com
Sun Oct 30 15:25:08 CET 2011


Hi!

I support the idea of depending on as few elements as possible,
and as standard as possible. The best is relying on programming
languages that posses a standard, for example C, and on standard
file formats. Yes, the key word is "standard", everything else will change.

For visualization, in my opinion, we should use standard file formats.
Something like PNG for images, simple ASCII files for raw data,
and some standard format for vector graphics.

For vector graphics I prefer the use of Postscript or SVG files.
Both formats (or languages) are complex and powerful. But
for doing simple thing, we do not need to implement the full
language; generating simple figures is very simple. It requires
the generation of some lines of ASCII files; some small
C functions are enough. We could gradually generate a small
C code for that, that anyone would be free to use or not, similar
to what we already have to load and write PNG files.

SVG seems to be the best option as browsers would eventually
be able to handle it directly. In the meantime, we can convert
SVG files to PNG images. In the LSD demo, the C code directly
generates EPS and SVG files. The demo now converts
from the EPS file to PNG. The reason for using EPS instead
of SVG is that I obtained better conversions with it, but it is
probably possible to obtain a similar result with SVG.

LSD only draw line segments. It is possible that making more
complex figures is not that simple. But I have two more examples,
with figure a little more complex but still easy to generate. In both
examples the algorithms are far from finished, please just look at
the figures generated without a critical regard : )

Line segments angle's mode detector:
In the result you can see a simple histogram,
and line segments drawn with the same colors.
http://dev.ipol.im/~jirafa/ipol_demo/gg_angle_modes/

Detector of clusters and alignments of dots:
You should click on the "Gaussian noise" example to
start; this will show you a white rectangle were you can
click to draw dots. When you have enough dots, you
can run the algorithm and see the result. In the result,
the clusters and the best alignment (according to
draft algorithms) are shown.
http://dev.ipol.im/~jirafa/ipol_demo/g_aligned_points/

best
rafa





On Sat, Oct 29, 2011 at 1:05 PM, Jean-Michel Morel
<Jean-Michel.Morel at cmla.ens-cachan.fr> wrote:
> Dear all,
>
> In answer to this proposition by Miguel:
>
> "A sensible policy would be that when someone creates a new tools or
> feature, he/she becomes the responsible for it."
>
> This is not a viable policy:  we need a consensus on any new tool used in
> the code operating the demos. The consensus implying that not just one
> redactor, but most agree that maintenance is feasible, and are committed to
> it.
>
> The reason why I'd require some sort of consensus, is that creating or using
> special visualization tools in the demo code contradicts our publication
> policy.
>
> In principle every user should be able to download the C code of each
> article, to operate it, and see the results. Thus, the visualization tools
> must be part of the C code.  Nothing opposes instead our placing C
> visualization tools to the disposal of authors.  But visualization is part
> of the scientific activity and should remain under the responsibility
> authors.
>
> See for instance Line Segment Detector, where the visualization of the
> segments  is generated by the C code itself.
>
> Best,
> Jean-Michel
>
>
>
>
>
>
> Miguel Colom a écrit :
>>>
>>> As long as there is someone to provide this maintenance service.
>>
>> A sensible policy would be that when someone creates a new tools or
>> feature, he/she becomes the responsible for it.
>>
>> For example, I created the plotting script, so I can be responsible for
>> it.
>>
>>> No, gnuplot comes with a "nox" command-line only version.
>>> -> http://packages.debian.org/squeeze/gnuplot-nox
>>
>> You're right. It's less dependencies than matplotlib:
>>
>> gnuplot-nox
>>  Depende: libc6 (>= 2.11)
>>  Depende: libcairo2 (>= 1.2.4)
>>  Depende: libedit2 (>= 2.11-20080614-1)
>>  Depende: libgd2-noxpm (>= 2.0.36~rc1~dfsg)
>>  Depende: libgd2-xpm (>= 2.0.36~rc1~dfsg)
>>  Depende: libglib2.0-0 (>= 2.12.0)
>>  Depende: libpango1.0-0 (>= 1.14.0)
>>
>>> Lots of packages are installed on the dev server, for
>>> experimentation. Only the minimum is on the demo server.
>>>
>>> Collect the point coordinates, draw lines with PIL, you have the
>>> curve. It is boring, the curve will not be pretty and have
>>> coordinates, legends, and so on but it works and doesn't require a
>>> gazillion of libraries to draw a curve.
>>
>> Well, it's a different point of view.
>> There're two:
>>
>> - Nicola's way: minimal system with minimal dependencies. "Do it
>> yourself", if you need something the server doesn't suppport. Drawback:
>> perhaps you have to re-invent the wheel many times and the results are
>> poor. Advantage: a minimal system is easier to maintain.
>>
>> - Miguel's way: install all needed dependencies, even if only a part of
>> their capabilities is used. Drawbacks: the servers takes more time to
>> update all its packages. Advantage: versatile graphics. Script easy to
>> modify and expand to new functionality.
>>
>> In short: I prefer the machines do the work, instead of humans*!
>> *(us)
>>
>>
>> _______________________________________________
>> 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
>
>


More information about the discuss mailing list