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

>>>>> "FP" == Fred P <fprog26@hotmail.com> writes:

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.

FP>    [ ][ ] [ ][ ][ ][ ] [ ][r][r][ ] [ ][r][r][ ] [ ][r][r][ ] VS [
FP> ][ ][ ][ ] [ ][ ] [ ][ ]

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.

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.

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.

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?

    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.

FP> Samething for polygon, for instance I tried to render a 'sheet
FP> icon', similar to Office New document button using Path.

FP> Explain me why I don't have Pixel precision with path, but an
FP> approximation, this is ridiculous.

FP> The following example shows clearly why anti-aliased looks like
FP> crapt, and shows clearly the defects of current aliased
FP> implementation at low resolution compared to a perfect bitmap
FP> image.

FP> BTW, both aliased and anti-aliased have a <path> which represent
FP> the same coordinates then the original bitmap, therefore, it
FP> should work perfectly, there is no excuse here.

    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.

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.

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.

    Instead so far you have been insulting the SVG specification and
the Adobe viewer for not intuiting the desired rendering of your
incorrect SVG content.

    You know what they say: crapt in crapt out. :)

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.

>>  If I go to different drawing/painting programs I certainly can get
>> very different results.  I tend to agree the results you got from
>> Adobe aren't very good but basically SVG engines are optimized for
>> anti-aliased graphics.  Also you need to be _very_ careful how you
>> specify the circle your example:
>> 
>> <circle style="stroke-width:1; stroke:#000000; fill:#FF0000;
>> shape-rendering: optimizeSpeed;" cx="50" cy="50" r="2"/>
>> 
>> For Adobe this is a circle who's center is at the juncture of four
>> pixels and who's stroke lies exactly on the boundry between two
>> pixels (at horizontal and vertial extents).  You have described a
>> circle that is essentially impossible to render correctly without
>> anti-aliasing.
>> 
>> However if you shift the center of the circle to lie in the middle
>> of a device pixel:
>> 
>> <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!

    Your original example was 5x5 (I was originally going to change
the radius to '1.5' but decided that you wanted the circle with that
radius so I left the size alone and shifted it so it sat on pixels).
If you want a circle where the outer edge of the stroke is a 4 pixel
circle:

<circle style="stroke-width:1; stroke:#000000; fill:#FF0000;
        shape-rendering: optimizeSpeed;" cx="50" cy="50" r="1.5"/>

    The Adobe Viewer fills in the lower 'corner' pixels so you won't
like the result (but you can fudge it by splitting the circle:)

<circle style="stroke-width:1; stroke:#000; fill:none;
        shape-rendering: optimizeSpeed;" cx="50" cy="50" r="1.5"/>
<circle style="fill:#F00;
        shape-rendering: optimizeSpeed;" cx="50" cy="50" r="1"/>

FP> My little icon which is 16x16 needs a 4x4 not a 5x5.  It might
FP> sound stupid or irrelevant but it makes a big difference, trust me
FP> on that! i.e. 25% increase in size.

    You are the one who started with a 5x5 pixel circle, not me - this
is what I mean by: you need to be _very_ careful how you specify your
circle.

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

FP> But as you can see in this "hand icon" example, SVG can be used
FP> for such task and SHOULD be used for such task.

FP> Saying SVG was not made for that is pure FUD and non-sense.

    Perhaps if I said it it might be FUD.  I was saying that your
circle was a nonsense circle for drawing without anti-aliasing
everything was split between multiple pixels - of course your not
going to get clean lines.

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.

FP> What's the point of having scalable vector graphics, if we cannot
FP> write vector graphics that doesn't look like crapt at normal size
FP> and rely of bitmap faking instead???
>>  I think you need to learn a bit more about vector graphics before
>> casting aspertions.  This is not simple stuff even though it often
>> looks like it is on the surface.

FP> I never said it was simple, but it is feasible.  Adobe and similar
FP> company are no beginner in this field, and I don't think they
FP> would appreciate having a crappy implementation that people would
FP> laugh about for aliased graphics for professional purposes.

    The implementation is not the major problem your content is!  It
is true Adobe is clearly not a beginner in this field, but you clearly
are.

>> Please have some respect!

FP> I love their product, but this is disappointing in the aliased
FP> area.

    Then learn a lot more, I think you will see that they are pretty
much as correct as they can be given the information available.

FP> Sincerely yours, Fred.

    I'm done here.

Received on Monday, 28 April 2003 10:49:05 UTC