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

> > >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 agree, but you still want the vector graphic to look 'nice'
on any of those. To the perceived 'eye' it should look like a circle,
even if it's just a round square without the corners.

A 4x4 circle in paintbrush will always look like a square without corners, 

Paintbrush as a mathematical circle definition when you draw a circle
and perform a 'best-fit highly probable match' for any radius.

> > I always drawn and specified a 4 pixels diameter
> > circle with r='2' or 2*r = diameter = 4 pixels,
> > since the beginning:
> >
> >
> > YOU specified a modified version with 5 pixels, but that doesn't > 
>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).

It covered 4 pixel badly true, he's circle covered 5 pixels true.

> > >FP> I never said this was easy and > >FP> 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 > 
> >FP> out of focus. Anti-aliased graphics/fonts > >FP> are good for "BIG" 
> > >FP> for instance a 100x100 circle > >FP> or a 48pt text font; however, 
> > >FP> you are viewing an icon which is 16x16 in 256 color, > >FP> you 
>want to have a circle, polygon which are aliased > >FP> instead of 
> > >FP> else the end result will look like crapt and fuzzy.
> > >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.

Really, poor you. I get an headache after 3 minutes looking
at anything which is not aliased TrueType fonts.
It just plainly irratating.
It likes looking through heavy fog.

I was about to make a suggestion
to have font-size under 21pt aliased and 22pt+ anti-aliased,
via something like: "font-aliased: 21pt;"

>You do often see aliased text at small sizes.

True and whenever I see anti-aliased I wonder
who was crazy enough to display such font at low resolution,
but that's just my personal opinion and taste.

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

Oh, SVG doesn't provide hinting, that might explain
why I couldn't found anything on google explaining it.

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

Yes, I do! I'm guilty, please hang me!  =)

>If your image is a bitmap, then its a collection of pixels.

Yes it is.

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

Depends if you scale it.

>If so, how did you tell the printer which
>pixels to touch or not touch?)

Best fit approach.

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

Yes and that's why I want to convert my bitmap into vectorial image,
so it scale better.

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

Yes that's what I meant. Now if you scale 200%, it should look
like a 8 pixel diameter circle isn't it?

If you scale 400% than 16 pixels
800%  -> 32 pixels
8000% -> 320 pixels

Don't you think?
Assuming the user units are pixels,
if they are 1200dpi, then best fit into 1200dpi instead of pixels.

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

I agree, but since I asked for 'aliased' you should get something like

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

Don't put me a freaking pixel at the [*], just let it curved!

or else create something called 'optimizeBitmap'
instead of 'optimizeSpeed' =P

> > 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 don't know it failled at home, I realized that, dunno why,
the picture didn't show up, but it worked at work.
It worked everywhere without the comments, weird. Another bug!?

> > I'll make your life easier, just click here:
> >
> >
> >
> > Tadam! You see the RECT hand is PERFECT.
>Actually no. I can see the tiny lines between the "pixels".

You see the tiny dots as a diagonal line,
but it looks much more better
than the vectorial version without scaling.

> > You can look at other PERFECT example here and here:
> >
> >
> >
> > 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'm currently focusing on Windows Mozilla/Netscape/IE,
probably verify with Linux later on,
if it works, it works enough for me.

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

But that's what you want a bunch of rectangle
that 'LOOKS' like a diagonal line.
You really want to fake it, so that it looks nice.
When I ask <path> to draw a diagonal line it SHOULD draw
a diagonal line WITHOUT add-on.
That would be enough for me to shut up on this issue,
even if circle doesn't work properly yet.
Since I could use path, instead of all those rect.

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

BECAUSE it will look like crapt, that's why.
Do we need to perform an election of what looks like crapt? =P

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

Yes, for a politically-correct answer of some politician
trying to save his ass, yes absolutely, but honestly
when you ask for aliasing this is not what you want at all.
Isn't it? =)

"Everything is in the look after all they are graphics!"

>Again, I think you are describing a bitmap.
>SVG isn't the best technology for that.

Nope, but it could be!

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

Yes. But it should look really nice at low resolution
with aliasing and look REALLY REALLY sharp
at high resolution with anti-aliasing.

Are you suggesting me what I was thinking?
"shape-rendering: auto; min-shape-aliasing: 50px;"

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

that someone at Microsoft or Apple from some graphic designers
or marketting folks would call REALLY IMPRESSIVELY PERFECT
shinny icons, is it better? ;)

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

But they could be! You see my hand described with <path>
if it was rendered properly at bitmap level,
would scale perfectly with zoom in, isn't it?

Instead you are telling me to have a compromize between normal size
and zoom in?

Choose between:
- Low resolution and beautiful VS High resolution and pixelized
- Low resolution and awful     VS High resolution and vectorialized

but don't complain for the lack of options!

What if I want both to look beautiful is that really too much to ask?

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

Okay fine, so what you folks are waiting for to introduce such? =P
Like I said good diagonal line for (1,1)-(3,3) would be enough
for most of us.

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

True, you have to cut off somewhere, somehow!

Best-fit would be: 9x9 checkerboard, so it looks the same.

The point is what about displaying this checkboard image on
a 1 bit-depth 10x10 checkboard on a 100x100 bitmap display
but unfortunately it doesn't look like a checkboard at all,
more like a black square screwed up in corners.
That would be close to what I'm explaining here!!!

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

It looks vaguely, but it still look better than
Adobe aliased rendering !!!

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

True but if you step back a couple feet from your screen,
it REALLY seems to be a circle, it's an illusion.

Anyway if you let me do something like:

<path style='fill:#FFFFFF; stroke:#000000; shape-rendering: optimizeSpeed;'
d='M 101 100 L 102 100 L 103 101 L 103 102 L 102 103 L 101 103 L 100 102 L 
100 101z'/>

and it renders properly at bitmap level, I'll be happy
and it will scale up reasonably quite nicely enough,
even at 800% it will look like nuts [word play]. =P

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

Nope but you could save it as such,
if your program save only vector graphics.

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

True, r=2, but it's 5 pixel drawn on the screen,
the fact is it looks better on Adobe
because it's 5 pixel wide offset! =P

> > >>>  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"?>
> > 
>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=''
> > >
> > <path style='fill:#FFFFFF; stroke:#000000; shape-rendering: 
> > 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?

Now I understood, but this is quite poor crappy quality,
saying that you can't draw properly diagonal lines in vectorial
at low resolution give me a break, my colleco programs did better.

>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 guess so. ;)

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

Sincerely yours,

Help STOP SPAM with the new MSN 8 and get 2 months FREE*

Received on Tuesday, 29 April 2003 00:22:14 UTC