Re: Colorgradient

Dominik,
I believe that the gradient mesh feature that is in PostScript Level 3 and
PDF 1.3 would satisfy your needs. Think of this feature as a warped grid of
vertices on top of a 3D surface, and each line segment in the grid is a
cubic bezier path segment (i.e., two end points and two control points).
Each vertex can have a different color. Basically, a gradient on steroids.

The SVG working group decided to leave gradient meshes out of SVG 1.0
because only a handful of tools supported this feature at the time we
drafted our requirements document. Now that time has passed, more tools are
supporting this feature. It is unlikely that such a major feature would be
added at this late date for SVG 1.0, but it seems like a strong candidate
feature for a future version of SVG.

Jon Ferraiolo
SVG Editor
Adobe Systems Incorporated

At 07:56 PM 6/7/00 +0200, Dominik Lenné wrote:
>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
>thought a lot about this aspect, too. The result is a suggestion like
>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 Thursday, 8 June 2000 17:03:39 UTC