- From: Dominik Lenné <dominik.lenne@uumail.de>
- Date: Wed, 7 Jun 2000 19:56:40 +0200
- 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 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 Wednesday, 7 June 2000 14:48:53 UTC