

Diffusion Curves: A Vector Representation for Smooth-Shaded Images - currywurst
http://maverick.inria.fr/Publications/2008/OBWBTS08/index.php

======
k2xl
Vectorizing bitmaps has been done for a long time. Even Flash even had a built
in feature for this (see "trace bitmap") (I think even Flash 5 had this
feature).

The significance of this is that it introduces a new algorithm for doing it.
The core of the algorithm is diffusion filters.

What would be VERY interesting is to see the vector size difference for
photorealistic pictures using Diffusion curves vs a typical linear or gradient
picture.

------
gjm11
Very impressive!

But ... Is it just me or is it just _really inappropriate_ for a video
demonstration accompanying an academic paper like this to begin with an
unrelated 20-second commercial advertisement? Can INRIA really not host the
demonstration somewhere that doesn't attach advertisements to their videos?

------
terhechte
The link to the source code doesn't work. Did anyone figure out what the
correct URL is? I'd love to play around with this.

Edit: Nevermind, I found it out myself:
<http://www.henrykorol.net/DiffusionCurves.rar>

------
crazygringo
This seems very cool, but I'd really love to see a better comparison with
gradient meshes.

Because gradient meshes seem far more "intuitive" and exact, exactly matching
the artist's "intentions".

Whereas diffusion curves look very cool, but produce great complexity of
gradients based on very simple curves -- almost too complex/unpredictable, I'd
be worried, if I were an artist.

Of course, this seems easier to deal with than gradient meshes, at least how
they exist today. I'd love to hear from artists who have tried both. I also
wonder what other languages/concepts might be developed in the future towards
this same end!

~~~
unconed
The problem with gradient meshes is that they are 2D grids that run all the
way through the shape. Thus you can't add control points on one side of your
mesh without adding a bunch of useless ones across the whole length or width.
Each mesh segment has to be a 4-sided bezier patch. If you try to gradient
mesh a curved shape, the mesh lines run at very awkward angles, it's often
better to start straight and bend it only after subdivision. Diffusion curves
solve all of these problems, and seem to have no obvious downsides.

I don't see how they would match the artist's intention any less, quite the
opposite. You can alter any small part of the image without compromising the
overall structure, and you can control spline tension through the blur radius.
The only thing I would say is missing is the ability to skew the blur to be
more intense on one side of the diffusion curve, thus creating asymmetrical
gradients.

In tools like Illustrator gradient meshes are flattened to images anyway when
exported to PDF. So if a technique like this was implemented, it wouldn't
change the workflow at all. In fact, I expect to see this in Illustrator in
the next two versions.

~~~
andybak
I can't find a source but I think gradient meshes are only flattened to images
to handle old or buggy postscript implementations. Postscript 3 can handle
them natively.

------
cs702
This is significant: it allows one programmatically to convert any raster
image into a full-color vector drawing. (Think converting JPEGs into similar-
looking but much smaller SVG-like files with one click.)

Designers would LOVE to have this functionality built into applications like
Inkscape and Adobe Illustrator.

\--

Edit: changed "SVGs" to "SVG-like files" per vlasta2's comment (thanks
vlasta2!). Also changed "equal-looking" to "similar-looking," because the
automatically-generated color gradients may not precisely match the original.

~~~
colanderman
I'm not sure that the resulting vector files will necessarily be "smaller".
JPEG uses a decent compression algorithm, so its size is already pretty close
to its actual information content (I'd wager within a factor of 2).

A while back I did some experimenting with compressing line graphics
(handwritten music notation specifically) as both CCITTv4 (a bi-level raster
compression algorithm) and SVG/PS via potrace (a tracer program), and the file
sizes were similar (if anything favoring CCITTv4).

~~~
cs702
colanderman: I'm almost certain that the resulting vector files will be much
smaller, because the algorithm substitutes subtle and complex color variations
with _much simpler color gradients that are only approximately similar_ and
therefore have much less actual information content.

PS. Note that the resulting vector files are not just smaller, but the drawing
elements contained in them are by definition resolution-independent, so all
curves, diagonal lines, and gradients will render beautifully and without
artifacts at all image sizes.

PPS. Also, note that music notation has no color gradients.

~~~
colanderman
Re: PS: Yes, I understand that, and I'm purposefully ignoring it because that
information would only help my argument. Vector drawing elements are richer
than raster drawing elements and hence tend to contain more information (e.g.
"exactly _how_ sharp is that edge?).

And you _will_ get artifacts going from raster->vector->zoom, because the
raster->vector algorithm necessarily infers information that is simply not
present (i.e. beyond the Nyquist boundary). While typically not apparent at
100% zoom, inaccuracies in this inference will become apparent once you zoom
in (e.g. "that pixel was meant to represent a perfect square, not a circle!").

Re: PPS: I never claimed it did? Music notation is bi-level and smooth edges
that makes it well-suited for vector tracing with a bi-level tracer e.g.
potrace (and therefore -- again -- aiding your argument). Comparing a CCITTv4
bitmap -- a bi-level format -- to vector output from potrace -- a bi-level
tracer -- would make no sense with color gradients.

In case it's not clear, I'm making the analogy CCITTv4 : potrace :: JPEG : the
diffusion curve algorithm.

~~~
cs702
colanderman: Yes, I understand the analogy you're making.

Your example of a pixel "meant to represent a perfect square, not a circle" is
accurate: that is one type of information that gets discarded with this
approach. Another type of information that gets discarded is complex/subtle
color gradients/variations.

Taken to the extreme, yes, this approach can make photos look like stylized
comic-book drawings; but with sensible defaults, it produces resolution-
independent images that look great (such as the example with the dolphin) even
if those images actually contain LESS information than a JPEG at the same file
size.

We'll have to wait and see...

------
currywurst
Found this in a discussion on SVG 2. The automatic generation of the curves
from images is the killer feature !

------
mistercow
Damn, something exactly like this is one of the problems I've been playing
with in my head for years, but never got very far on. Turns out it's been
solved for four years. Very, very cool work.

------
sebmarkbage
Here's an implementation in WebGL

<http://blog.calyptus.eu/seb/2010/11/webgl-not-just-for-3d/>

------
Mordor
Could this be used in image/video compression?

~~~
agumonkey
I'm not sure if it can be compressed in the time domain though.

~~~
yk
Usually vector based formats compress very well in the time domain, since you
only need to store the transformations. But without testing the code, I would
be surprised if it is fast enough for something like 50 frames.

~~~
corysama
Convert the (x,y) curves to surfaces in the (x,y,time) domain and you should
get a representation that is very fast to evaluate. With fast forward
differencing, animating the curves would only need 6 adds per control point.
If you are fine with "A Scanner Darkly"-style video it would work great!

BTW: Vector videos have been used to squeeze full-screen cinematics into a
Super Nintendo: <http://fabiensanglard.net/anotherWorld_code_review/index.php>

------
domlebo70
This seems amazingly simple (on face value). Anyone else want to have a go at
doing up a prototype as a weekend project?

------
egypturnash
The moment the video was over, I was hitting up Adobe's bug/feature request
form. Hell yeah.

------
tdrd
This paper is from 2008. Where is this being used?

