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

[Miguel Colom]

Dear all,
my suggestion about having standard tools for visualization is only for
those kinds of figures that a broad amount of demos are likely to need.
For example: 2D plots.

I agree with Rafael on that the C code should generate its output in the
simplest form. Data and its visualization shoud be, in my opinion, two
isolated domains.

However, Jean-Michel explained in a previous message that it should be C
code that generates the figures, because otherwise it goes against IPOL's
publication policy.

As Rafael said, it isn't a trivial task to generate high quality and
versatile plots.
Perhaps a good solution to this problem would be that the C program could
use a plotting library to do it's duty, instead of doing so without any
library support.

A C program can open a pipe to communicate with the plotting library
(gnuplot has few dependencies, as Nicolas explained in a previous
message), configure it, recover the plot from the pipe and save a
raster/vector output file.

This way we wouldn't be forcing authors to write their own plotting system
and we solve the package-dependency problem in the server at the same
time.

Best,
Miguel

> 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
>>
>>
> _______________________________________________
> discuss mailing list
> discuss at list.ipol.im
> http://tools.ipol.im/mailman/listinfo/discuss
>