Re: Colorgradient

Jon Ferraiolo wrote:
> 
> 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.

This sounds very powerfull... (but looks rather complicated in the PS
specs; but I'm no PS expert)

> 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.

Fair enough.

But I hope that the addition of such a feature will extend the current
version in a way that a simplistic shading (e.g. per-vertex colouring)
can be done by trivially modyfing a SVG file. (A more complicated one
will need a more complicated format anyway).

CU,
Christian

> 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 Friday, 9 June 2000 17:49:08 UTC