[IPOL discuss] computing and displaying contours

[Nicolas Limare]

> 1) actually computing the contours:
> a) I think this should be done by the author
> b) however, it won't hurt to have a handful of simple functions at
> hand, to provide the authors. Maybe we can just reuse the code done by
> the first autor interested in doing the task.

Yes, I did put some general-purpose code on
http://www.ipol.im/meta/dev/ for the same reason. this could be
expanded with other "utility code". It would be possible to turn it
into a library but I think it is not really needed, and a collection
of simple independant task-focused code is sufficient (and less work).

> c) I think about many cases in which we could be interested in
> computing/showing level lines, so maybe the definition of an interface
> (how to specify the points of the contour) could be useful.
> d) I google'd for a bit to find any clean C implementation of the
> marching squares algorithm but without luck. do you know/have any
> piece of C code to compute contours? I know implementations in ITK and
> VTK, but that's out of the question. I find sad that there is no
> reference implementation of such well-know and established
> algorithms.

I would say that to provide "reference implementation of such
well-know and established algorithms" is exactly what IPOL is made
for.

> 2) drawing the contours on the web page:
> a) the first ugly way to do this is to just ask the author for an
> image with white pixels over a black background. I think this is
> efortless but poses many problems (low resolution, no scaling, etc).
> b) Ask the user to draw in a vectorial format like eps or svg. As far
> as I know, svg support varies too much across browsers. (correct me
> please if I'm wrong)

for now, yes. Internet Explorer 9 should solve this problem, but we
need to wait for at least 1 year to see the older Internet Explorer
versions disappear.

> c) ask the author for a description of the curve as in 1c) and render
> it using javascript

Line rendering in JavaScript is not easy, because there is no native
"image" (raster or vector) object in this environment, so the
JavaScript drawing libraries resort to dirty hacks, like drawing each
pixel as a 1x1 <div> in the page. With HTML5 and the <canvas> element
we can do real drawing, but here again we don't have enough browser
support yet.

> of whatever we like. Here we need a precise
> definition of the curve, as I guess we don't want to recode that part
> for each new demo.
> d) I think in general this should be our concern, not the authors.
> 
> Personally, I would go for the svg, but sadly technology is not on our side yet.
> What do you think? Is there any hack to make an svg look the same in
> different browsers?

I'll second Pascal and suggest you to use eps + raster conversion for
the moment. Once we there is enough support, we can switch to pure
SVG. Ideally, the code (provided by the authors) should output the
lines in 3 formats:
* pure text, useful for further processing
* eps, for our current conversion to png using ghostscript (Rafael did
  some tests, the quality of svg-to-png consersion is not satisfying)
* svg, for future inclusion in the web pages

These three formats are quite simple when we only deal with
lines. Rafael wrote some code to create EPS and SVG files:
-> http://www.ipol.im/pub/algo/gjmr_line_segment_detector/#index4h1
-> in lsd_cmd.c

Maybe this could be extracted in a tiny stand-alone code and made
available on http://www.ipol.im/meta/dev/?

-- 
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: <http://tools.ipol.im/mailman/archive/discuss/attachments/20110316/96032032/attachment-0001.pgp>