From: Dominik Lenné <dominik.lenne@uumail.de>
Date: Wed, 7 Jun 2000 19:56:40 +0200
Message-ID: <000b01bfd0a9\$d850fd20\$f456e195@default>
To: <mail@christianmayer.de>, <www-svg@w3.org>
```Christian Mayer wrote:
> What I'm missing is the ability to have a per vertex colouring as you
> can do in OpenGL.

Hi,
I have been following the discussion here for quite a while quietly and have
Christians, but more generalized. I would baptize it "edge defined colour
distribution".
The idea is, to define the colour inside an area just by the colour on the
surrounding path. A logical extension of this idea would be to calculate the
colour distribution on a path by the colour of the path defining points
(vertices), linearly or in some other manner.
In the case of a tri- or quadrangle with linear colour function on the
edges, the colour inside can unambiguously and fast be calculated by a
bilinear formula (seperately for each colour component). If the surrounding
path is more complex, there is an additional condition or rule or algorithm
needed.
One crude example of that is the linear interpolation along straight lines
between the points of intersection with the border. This can be more refined
by using several directions at a time and caring somehow about the
discontinuities that occur in the case of island or concave parts of the
border.
The intuitively best approach is IMO to calculate the solution of the two
dimensional heat conduction equation with the colour on the border as
boundary condition (as above, for each colour component seperately). There
are a lot of fast algorithms available to do that. "Fast" means, that the
computation time scales with  n log n  (n = number of inside pixels). But if
it is really feasible with the computational power of average machines has
to be evaluated. In the case of tri- or quadrangles, this approach leads to
Christian's bilinear forms.

I see the following advantages of such structures:
- The output of numerical simulation software is given as "values on
vertices". With this structure, very simple SVG-backends could be coded for
those applications.
- The SVGation of photographs would be simplified. Just take a smart choice
of paths and vertices in the photograph, and you get pretty fast a fine
reproduction without any steps. The level of detail transmitted could be
managed depending on the enlargement.
- The generation of smooth images by hand would be simplified. No more
juggle with start and end values of colour vectors - just manipulate the
vertices and get smooth, steady transitions.

Two more thougths:
o For this kind of element, one has to be able to assign a colour value to
each vertex. For the modelling of steps, it would be useful to allow the
assignment of  two  colour values to each vertex, one for the "left" and one
for the "right" side.
o The introduction of "difference colours" in additon to difference
coordinates, that is the deviation from a given background colour, would
allow to use decreased colour depth for details and lead to a pretty
efficient image compression format.

I am aware, that the order of the day is to get SVG up and running as it is,
but I put out my suggestion anyway, hoping, that there is some kind of "idea
pool", in which it will float until the time is ripe.

Yours

Dominik Lenné, Berlin
```
Received on Wednesday, 7 June 2000 14:48:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:46:48 UTC