1630Re: corrupted symbols: analysis and solution
- Oct 3, 2005Hi Andrew,
Could you clarify what you mean by "corrupted"? In
other words, what difference in appearance do you want
with the symbols on the y=7 and y=7.4 rows? I apologize
if this has already been explained.
--- In email@example.com, Andrew Schulman <andrex@a...> wrote:
> Back in July, I reported a problem with corrupted symbols in
> this list (http://groups.yahoo.com/group/ploticus/message/1581). An
> example can be seen in, for example, the y=7 and y=7.4 rows at
> http://home.comcast.net/~andrex/bugz/ploticus.png (created by the
> http://home.comcast.net/~andrex/bugz/ploticus.plo). Those are rows
> diamonds that got corrupted in the plot.
> Steve answered my query as follows:
> > Ploticus generates vector graphics, which must be rasterized to
> > into PNG/GIF. Then when PNG/GIF are rendered by the browser
there may be
> > another round of rasterization that might not sync with the first
> OK. The remainder of the thread concerned using GD's new anti-
> facilities to mitigate the aliasing.
> I still have the corrupted symbols problem, and ploticus is so good
> other respect that I'd really like to see it get fixed. Here are my
> thoughts, please tell me what you think.
> First, this isn't a browser effect. It persists in any viewer at
> magnification. So it's a ploticus and/or libgd problem.
> Second, the problem doesn't seem to be in GD. I don't know much
> all I've done is to browse the documentation online. But AFAICT,
> only in pixels. All calls to GD functions pass arguments in pixel
> Therefore, the pixelization or aliasing is happening in ploticus.
> mind this is good news, because it means the problem must be
> Third, anti-aliasing isn't a solution. AA just amounts (as I
> it anyway; please correct me if I'm wrong in the context of GD) to
> the plot lines in order to soften jagged edges. This is, IMO,
> in most cases, since it reduces the sharpness of the plot; and it
> solve the underlying problem. Aliasing in ploticus is often bad
> make the interior color of a symbol spill outside the symbol
> can see this, for example, in every diamond in the y=7 row in the
> cited above (expand the row and look at the lower right edge of each
> diamond). AA may partly obscure this effect, but it can't solve
> may be a good idea for shapes other than vertical, horizontal, and
> lines, however, since it can reduce jaggedness.)
> Here's how I see the problem and its solution. In order to draw,
> a diamond, ploticus uses the following algorithm:
> (0) Start with coordinates (x,y) of the diamond's center, and a
> (1) Compute offsets from the center to the vertices in a standard
> diamond, e.g. (1,0), (0,1), (-1,0), and (0,-1).
> (2) Compute the vertex coordinates: e.g. for the right vertex
> (x,y) + r * (0,1) = (x, y+r).
> (3) Convert the vertex coordinates from plot units to pixel units.
> (4) Call GD to draw lines between the vertices.
> This algorithm is implemented in PLG_mark() in mark.c. But the
> to pixel units happens at a lower level-- PLG_mark calls Emov() and
> to plot the points and lines, and these eventually call PLG_xsca()
> PLG_ysca() in winscale.c, which multiply x and y by global scaling
> to convert to pixel units.
> The aliasing, or rounding error, occurs in step 3. And the problem
> this algorithm is that the vertex coordinates are all computed in
> units, and then independently rasterized, so the rounding error on
> coordinate can go in a separate direction. This is what causes the
> shape to distort in a random way.
> The solution is simple in principle: convert the center
> radius to pixel units _before_ computing the vertex coordinates.
> remove step 3 and add
> (1.5) Convert x, y, and r from plot units to pixel units.
> The distortion problem will be solved, because the rounding error
> happen just one time on r, and then be applied uniformly in finding
> the vertices. The shape will be a perfect diamond (or square or
> (This is "less accurate" for the individual vertices, since they
> independently find their closest pixels. But with plot symbols the
> accuracy of the vertices isn't the point; drawing a clean,
> shape is the point.)
> In practice this would take some work to implement, because as I
> the conversion to pixel units currently happens at a low level in
> ploticus-- just before the GD plotting routines are called. This
> simplifies the higher-level code, which doesn't have to worry about
> conversions. In order to perform the pixel conversion at a higher
> points will now have to implicitly carry units with them, and those
> will have to be passed down through all of the drawing routines.
> example in PLG_mark(), the calls to Emov() and Epath will have to
> new "already in pixel units" flag, to tell the lower-level routines
> convert them again.
> Specifying the symbol radius in pixels would have the added benefit
> providing a natural sequence of symbol sizes for users to choose
> If it would be useful, I could try to create a proof-of-concept
> not sure how long it would take, but the ploticus code seems to be
> clearly laid out, so it might not be too bad.
- << Previous post in topic Next post in topic >>