Re: [SVG] optimizeSpeed misbehavior pixel rendering at 100% zoom level in Adobe

On Mon, 28 Apr 2003, Fred P. wrote:

> Hi M. I know everything,

Thomas may have sounded arrogant to you, but it didn't come
across that way to me.

He took the time to carefully read your long email, copy your
examples, modify them, and then explain the concepts and errors
in a long reply. I appreciate his efforts.

> >FP> Well, it should not allow for 1 pixel mis-behavior, since this
> >FP> mean there is a 100% error tolerance for every pixel being drawn.
> >FP> In other words, for every pixel drawn a misbehaving pixel can also
> >FP> be drawn.
> >>>  In cases where a line falls exactly between two pixles which pixel
> >>> do you render (see below)?  Implementations are allowed to choose.
> >
> >FP> Okay, implementation may chose but a circle is a circle not a
> >FP> coleco E.T. monster.

I think this is the crucial point here. A <circle> is a circle in
SVG. It's always a mathematically correct circle as far as the
specification is concerned, and as far as the implementation is
concerned.  The rendering of a particular object, especially at a very
low resolution, is where your trouble is starting.

As Thomas asked, in the case where the mathematically correct
line touches two or more pixels in a non-antialiased case, which
pixel do you touch? The SVG specification should not specify
this, because we don't know what type of device we are rendering
on (monitor, pda, printer, super-high-res printer). "Pixel"s are
not little squares.

> I always drawn and specified a 4 pixels diameter
> circle with r='2' or 2*r = diameter = 4 pixels,
> since the beginning:
> http://lists.w3.org/Archives/Public/www-svg/2003Apr/0041.html
> 
> YOU specified a modified version with 5 pixels, but that doesn't matter.

Not really. Thomas specified exactly the same circle as you, it was
just slightly offset (half a user unit sideways and down). Your
complaint is that his circle appeared to cover 5 pixels, where as
yours covered 4 pixels (badly).


> >FP> I never said this was easy and I think Adobe does a great job in
> >FP> general. I mean they got themself a good reputation with
> >FP> Illustrator, Photoshop and Acrobat.  It's not like if they were
> >FP> not in the image industry since a year.
> >
> >FP> I'm programming since decades and I would have a hard time
> >FP> programming a good SVG renderer myself; however, let's not get out
> >FP> of focus. Anti-aliased graphics/fonts are good for "BIG" picture,
> >FP> for instance a 100x100 circle or a 48pt text font; however, when
> >FP> you are viewing an icon which is 16x16 in 256 color, you want to
> >FP> have a circle, polygon which are aliased instead of anti-aliased,
> >FP> else the end result will look like crapt and fuzzy.

Sure.

> >FP> Samething for text, if you render text in less than 20pt, you
> >FP> don't want anti-aliased at all. It simply won't look good at all.

I see a *lot* of text at sizes less than 20pt anti-aliased. This
message for example.

You do often see aliased text at small sizes. My impression is
that it is either a bitmap version of the font (ie. not at all the
same as a vector description) or it has hinting (which is what thomas
suggests you need below).

> >
> >FP> One thing that should be implemented is good aliased graphics at
> >FP> low resolution pixel level for small vectorial figures.
> >
> >FP> One of my biggest concern is that a lot of people even in the
> >FP> Gnome/KDE community where talking about getting vectorial icons,
> >FP> that can zoom in beautifully. I want to be able to create
> >FP> full-scale web application using SVG/JavaScript without any HTML.
> >
> >FP> SVG already proved to me to be very efficient in terms of images
> >FP> space, even for huge bitmap files encoded with <rect> tag then
> >FP> gzipped.  My second concern was to be able to translate those
> >FP> bitmap into proper vectorial image; however, due to the fact that
> >FP> the aliased doesn't work at low resolution, this seems to be an
> >FP> impossible task.  That's why I reported the 'bug', since it is
> >FP> one.  If you take a look at Paint, LView, Jasc or any other bitmap
> >FP> editing software, you will see that any of them have the same
> >FP> definition of aliased pixelized graphic.

I think you are trying to merge two separate worlds here. 
If your image is a bitmap, then its a collection of pixels. There
isn't any ambiguity as to what pixel is on or off. (In fact, that's
only true when you are displaying at the same resolution as the
image - what happens when you print a 100x100 image on a 
1200 dpi printer? Do you get a *really really* small image or
have you scaled it? If so, how did you tell the printer which
pixels to touch or not touch?)

With vector graphics you are describing the shape, not the
pixels.

> >FP> In other words, a circle of 4 pixel diameter will always look the
> >FP> same, I don't think it is too much to ask to get this in SVG
> >FP> viewer, is it?

Same as what? All other 4 pixel circles? I assume that is what
you mean.

Again, what happens when your line is touching more than one
pixel? For a circle, with no straight lines, how do you even know
what pixel you are on? Yes, for each point on the circumference
you can work out which pixel you are in, or whether you are on
the boundary of two or four pixels, but that is only a point.

> >    I strongly doubt SVG will ever guarantee pixel and code value
> >precision, if this happens then there will essentially be only one SVG
> >viewer - which would be a pitty.
> 
> Yes, it does. You know why? because you draw PERFECT RECTANGLE
> covering every pixel PERFECTLY.

There are cases where a rectangle at a particular location and
a particular stroke could give the result you want yes. What happens
when I rotate that rectangle 0.1 degrees or change the stroke?

> You didn't take a look at my hand example did you?
> Since copy-paste seems to be difficult,
> it seems Adobe doesn't display properly
> with <!--- comment tag --> anywhere in the file.

Works fine for me.

> I'll make your life easier, just click here:
> 
> http://j2k.sourceforge.net/svg/hand.svg
> 
> Tadam! You see the RECT hand is PERFECT.

Actually no. I can see the tiny lines between the "pixels".

> You can look at other PERFECT example here and here:
> http://j2k.sourceforge.net/svg/btn_all4.svgz
> http://j2k.sourceforge.net/svg/umled10.htm
> 
> See the icons are nice and perfect at PIXEL level.
> That's what I'm aiming at.

Well, I think you're going to have to use bitmaps
(since in fact that is what you are describing), or
restrict yourself to a particular implementation on
a particular device, probably on a particular operating
system.

> 
> >    I don't have time to correct all your graphics for you.  Please
> >take care to only significantly cover pixels that you want filled
> >remember that SVG uses a floating point coordinate system and I think
> >your examples will rendering much more to your liking - in particular
> >for 1 pixel wide strokes make sure your end points are in the center
> >of pixels not at the edges.
> 
> Perfect != to 1 pixel drawn wrong. BTW:
> 
> make it fit on one-line:
> 
> <path style='fill:#FFFFFF; stroke:#000000; shape-rendering: optimizeSpeed;'
> d='M 5 17 L 2 14 L 2 10 L 3 9 L 5 9 L 5 12 L 5 5 L 6 4 L 8 4 L 8 10 L 8 4 L 
> 9 3 L 10 3 L 11 4 L 11 10 L 11 4 L 13 4 L 14 5 L 14 10 L 14 6 L 16 6 L 17 7 
> L 17 15 L 16 16 L 16 17'
> />
> 
> is a perfect line in theory, it covers all pixel precisely to their
> middle point BUT because of the triangles for diagonal lines,
> the Adobe SVG renderer will make them pixels and corrupt the picture,
> there is no reason here to make have a misbehaving pixel,
> its a damn diagonal line.

A damn diagonal line is not the same as a set of pixels that
appear to be a diagonal line (or, in truth, are a set of squares
rotated 45 degrees and aligned diagonally). It may look like
a line to you. To me, it looks like a bunch of rectangles positioned
to appear like a diagonal line.

> 
> In other words:
> 
> 'M 1 1 L 3 3'
> 
> [x][ ][ ]
> [ ][x][ ]
> [ ][ ][x]
> 
> will be translated to:
> 
> [x][\][ ]
> [\][x][\]
> [ ][\][x]
> 
> where [\] SHOULD NOT be tolerated but they are currently.

Why not? The line goes directly through the corner point
of the pixels here? Why do the "\" miss out?

> and result in this ugly fat dirty line:
> 
> [x][*][ ]    [x][ ][ ]
> [*][x][*] != [ ][x][ ]
> [ ][*][x]    [ ][ ][x]
>
> where [*] has a high probability of getting filled.

I would say "results in this set of pixels, which look
less like a line than the set of pixels that I wanted to
draw would look like a line".

Again, I think you are describing a bitmap.
SVG isn't the best technology for that.
 
> and therefore it looks like crapt, see by yourself.

It looks like crap at low resolutions with aliasing.
Looks really nice at high resolution with anti-aliasing.

> Why someone should use pixeled rectangle instead
> of vectorial lines to get a PERFECT picture, this is non sense.
> in order words:

Again, the PERFECT bit is the mathematical description, not
the resulting image.

> >FP> This one looks like crapt, even though it's closer than other
> >FP> ones.  I have some bitmap icons, which render SOooo bad with path,
> >FP> it's incredible, as you can see the rendering quality with
> >FP> '<rect>' is so 'perfect' compared to '<path>' or '<circle>',
> >FP> however, it doesn't zoom like vectorial, since it's not vectorial
> >FP> at all.

I agree completely with you. Your bitmap images don't scale well.
The images you are describing are not vectors.

> >
> >FP> This is what this message thread is all about, getting 'very high
> >FP> quality' at low-resolution, in Adobe SVG viewer or any good
> >FP> competitor browser plug-in.
> >
> >    No, thus far this thread has largely been about educating you
> >about how vector graphics work.  If we were talking about 'very high
> >quality' at low-resolution - you would have already mentioned
> >font/vector-hinting or multiple representations.
> 
> font/vector-hinting ?

A hint would say something like "I want this 'line' to be aligned
with a pixel", which is what you want. SVG doesn't have vector
hinting. 

> What about 'optimizeSpeed;' not working properly?

This doesn't have anything to do with optimizeSpeed. Your 
results would be equally disappointing on devices that don't have
the power to antialias.

How about we turn the question the other way around?

What would you do if you had a 1 bit-depth 10 x 10 bitmap with a 
checkerboard image that you wanted to display in a 9 x 9
pixel square? You don't have anti-aliasing.

> >FP> When you draw a circle or polygon in Paint or similar, does it
> >FP> have a 100% pixel error? No, not at all.  Instead it draw a circle
> >FP> perfectly as it should.

Wait a minute. When do you draw a circle in Paint? You use a bitmap
program to do pixel manipulation. The result of the manipulation looks
vaguely like a circle in some cases.

[ ][x][x][ ]
[x][ ][ ][x]
[x][ ][ ][x]
[ ][x][x][ ]

You seem to think that looks like a 4 pixel circle. I see a 
4 x 4 bitmap with 8 pixels on, more like a rectangle that is
missing its corners. 

And once the pixels have been touched, it's no longer a circle is it?

> >>> <circle style="stroke-width:1; stroke:#000000; fill:#FF0000;
> >>> shape-rendering: optimizeSpeed;" cx="50.5" cy="50.5" r="2"/>
> >
> >FP> Wrong, this is a 5x5 pixel circle not a 4x4 pixel circle!!!  This
> >FP> is why it renders better!

No! It's a circle with a radius of 2 units. 

> >>>  You will find you get a much more reasonable rendering.  Adobe
> >>> still seems to have a drop out on the top of the circle, but if you
> >>> turn off optimizeSpeed this goes away and you get very little
> >>> anti-aliasing as most pixels fall nicly on one pixel as opposed to
> >>> split across pixels.
> >
> >FP> My problem is that I need aliased pixel bitmap polygon/circle to
> >FP> be drawn, in order to render icon without the anti-aliased, so it
> >FP> doesn't look like crapt.
> >
> >>>  Then you should describe graphics that don't _REQUIRE_
> >>> anti-aliasing to make sense (i.e. 1 pixel borders exactly on a
> >>> pixel boundry).
> >
> >FP> I think you wanted to say that I should not require pixel bitmap
> >FP> in aliased mode.
> >
> >    No I'm saying if you want aliased graphics to look good don't
> >describe graphics where your line has 50% coverage on adjacent pixels!
> >Put your 1 pixel stroke down the middle of a pixel not between two
> >pixels (think .5 not .0)!

I'm with Thomas here. It's going to be really hard to get a circle
to do this.

> What about this line not being drawn properly!!!
> (101,101)-(109,109)
> 
> <?xml version="1.0" encoding="iso-8859-1"?>
> <!DOCTYPE svg SYSTEM
> "http://www.w3.org/TR/2000/03/WD-SVG-20000303/DTD/svg-20000303-stylable.dtd">

Just as an aside, this is a pre CR version of the SVG DTD.
At a guess, we've released about 8 updated versions since
then, included the Recommendation of SVG 1.0 and SVG 1.1.
I doubt this has any impact on this particular problem, but 
this file is 3 years out of date.

> <svg height='500' width='500'
> xmlns:xlink='http://www.w3.org/2000/xlink/namespace/'
> >
> <path style='fill:#FFFFFF; stroke:#000000; shape-rendering: optimizeSpeed;'
> d='M 101 101 L 109 109'/>
> 
> </svg>

The same question as above. What happens at the junction of
(101,101) (101,102) (102,102) (102,101)? 

> How can you explain Paintbrush can do it nicely,
> but that Adobe can do it at all?

Because Paintbrush is touching pixels. It has no idea
what a circle is.

> I mean Paintbrush must have a hard time drawing a circle,
> it doesn't fit on every pixel, poor Paintbrush;
> weirdly this simple drawing tool, can do a perfect job,
> isn't that weird, isn't it?

What I consider weird is that you think what Paintbrush
does is perfect. Again, we'll turn the question around.

Draw your 4 pixel circle in paintbrush? You probably see
a 4x4 rectangle with missing corners.
Now, make that "circle" a 5x5 circle, without erasing it
and drawing it again.

Another way to think of this inverse question is that
you don't expect a bitmap program to handle vectors.
Similarly a vector program can't always create the
bitmaps that you like.

> 
> Oh I see, a simple bitmap drawing tool is more intelligent
> than a high-tech vector graphic renderer
> for low-resolution pixel computing,
> is that what you are suggesting!?

I probably shouldn't reply to this bait, but I think what Thomas
and I are saying is that you're confusing *very* simple 
bitmap editing with rendering vector diagrams. In fact, it is
the lack of intelligence in Paintbrush that you're trying
to replicate in a completely different situation.


> >FP> Now I'm being forced to draw tons of rectangles instead of proper
> >FP> polygon/circle, to ensure that the SVG icons doesn't look like
> >FP> crapt at normal size (100% zoom level); however, this means that
> >FP> if someone zoom in, lets say at 400% zoom level, that person will
> >FP> see the pixel sickness effects due to rectangle being drawn,
> >FP> instead of a nice polygon or circle being zoomed in.
> >
> >FP> See the <rect> hand above for further understanding of my arguing
> >FP> here!
> >
> >    In your example you are still drawing lines that span pixels if
> >you want to use a 1 pixel stroke you better put your end points in the
> >middle of pixels not at the juncture of pixels.
> 
> (101,101)-(109,109) is a perfect middle point thing that fails.

As Thomas said in his first reply, and then again here, a one pixel
stroke covers two halves of two pixels unless you have put
your end point in the middle of a pixel. And that only works for
horizontal or vertical lines anyway, since it is impossible for
anything else.

(101,101) - (109,109) is failing both those requirements.

Do you understand? I'm sorry that we may be coming over as arrogant or
dismissive, but it really appears that we are misunderstanding each
other at the most fundamental level.  I'd guess the SVG Working Group
has a combined 300 years of experience at this stuff. You'd probably
find equal amounts of experience within the Postscript, PDF,
Macromedia Flash, Microsoft GDI+ and Apple Quartz teams as well, and
as far as I can tell, you'd get pretty much the same result with
each of these technologies.

Dean

Received on Monday, 28 April 2003 22:47:33 UTC