Sorry if incovienent : SVG-to-png rendering on Wikimedia

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Sorry if incovienent : SVG-to-png rendering on Wikimedia

Achim Flammenkamp
Hello

May I point you to the URL

http://commons.wikimedia.org/wiki/Commons:Graphics_village_pump#default_rendering_from_SVG-to-png_looks_buggy_.28also_improper_default_flag-sizes.2C_IMHO.29

coding the literal URL

http://commons.wikimedia.org/wiki/Commons:Graphics_village_pump#default rendering from SVG-to-png looks buggy (also improper default flag-sizes, IMHO)

?

Is this the correct mailing list to get feed back and/or even contact the right developpers to change these fixed default sizes and the SVG-to-png rendering?
If not, whom or what community should I contact?

See also:
http://commons.wikimedia.org/wiki/File_talk:Flag_of_Iran.svg#general comments

Thanks, Achim

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Sorry if incovienent : SVG-to-png rendering on Wikimedia

Merlijn van Deen
On 26 June 2012 17:37, Achim Flammenkamp <[hidden email]> wrote:
> http://commons.wikimedia.org/wiki/Commons:Graphics_village_pump#default_rendering_from_SVG-to-png_looks_buggy_.28also_improper_default_flag-sizes.2C_IMHO.29
>
> Is this the correct mailing list to get feed back and/or even contact the right developpers to change these fixed default sizes and the SVG-to-png rendering?

It is completely unclear to me what the problem is. There is a note on
the image page stating 'These above (displayed) rendered images are
forced (by wikimedia politics) to an improper (even false) flag-ratio.
The correct ratio is 7:4 and to avoid some small render-bugs, the
height of the flag in pixels should be divisible by 3.'. Even though
I'm not sure what 'wikimedia politics' have to do with it, the ratio's
all look fine to me: the preview at [1], the 1000px png version [2]
and the svg version [3] all render to a 7:4 (=1.75) aspect ratio for
me (at least, that's what the Chrome dev tools tell me).

Could you try to explain your problem again? Please explain *where*
you see *which* aspect ratio, and, for instance, which browser you are
using. Please also explain how you determined the aspect ratio. The
more information you provide, the easier it is for us to understand
what's going on.

Best,
Merlijn


[1] http://commons.wikimedia.org/wiki/File:Flag_of_Iran.svg
[2] http://upload.wikimedia.org/wikipedia/commons/thumb/c/ca/Flag_of_Iran.svg/1000px-Flag_of_Iran.svg.png
[3] http://upload.wikimedia.org/wikipedia/commons/c/ca/Flag_of_Iran.svg

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Sorry if incovienent : SVG-to-png rendering on Wikimedia

Achim Flammenkamp
Hi

> It is completely unclear to me what the problem is. There is a note on
> the image page stating 'These above (displayed) rendered images are
> forced (by wikimedia politics) to an improper (even false) flag-ratio.
> The correct ratio is 7:4 and to avoid some small render-bugs, the
> height of the flag in pixels should be divisible by 3.'. Even though
> I'm not sure what 'wikimedia politics' have to do with it, the ratio's
> all look fine to me: the preview at [1], the 1000px png version [2]
> and the svg version [3] all render to a 7:4 (=1.75) aspect ratio for
> me (at least, that's what the Chrome dev tools tell me).
>
> Could you try to explain your problem again? Please explain *where*
> you see *which* aspect ratio, and, for instance, which browser you are
> using. Please also explain how you determined the aspect ratio. The
> more information you provide, the easier it is for us to understand
> what's going on.
It is explained in detail at the (yes, very lengthened section) who's URL
I pointed you at first.

But okay, I will repeat very thing relevant for you:

0) Where: on my personal/office monitor when displaying certain wikimedia pages.
1) I use different versions of Firefox 3 and 4 but the visual effect is
in always the same (running on different Linux flavors) (and not only at me).
2) If you like, take as a good example the URL http://commons.wikimedia.org/wiki/File:Flag_of_Iran.svg
3) I triggered this here because I created the valid (last) version of this SVG-file and people now come to me and complain about it's appearance on wikimedia and wikipedia.
Thus I dig done the problem and it seems to be out of my reach to correct this miss-design by wikimedia but identified it to got founded in some wikimedia politics or history which now noone seems to be responsable. :-/

Detailed explanation at example:
If there is a SVG-file on wikimedia, some fixed logic generates png-images for
the flag's description page generally. The first image, here 800 × 457, is
displayed very prominently always at the beginning of the SVG-description file,
others (320 × 183 pixels | 640 × 366 pixels | 1,024 × 585 pixels.) follows as
links. All these sizes seems to be bounding-boxes from historic used (maybe even today) resolutions of (CRT-)monitors respecting aspect about ratio as near as
they can If horicontal OR vertical is maximized to this resolution.
Then some facts to the original SVG code is stated and than further fixed png-sized images follows as links (This image rendered as PNG in other sizes: 200px, 500px, 1000px, 2000px.).

The last , in small font set explanation, I added for people to get an understanding of the reasons lying behind the scene. :-/ [Only for thios flag].

This flag should have a ratio of 7:4 which has the SVG original, but NOT the
prominantly displayed first image (800 × 457 , 800 is not divisible by 7, nor 457 by 4)!

Because in this flag, there are these two strips of "Alkmar Allah" Tekbirs,
rendering artifacts can get easily visible if improper rendering occurs!
First reason is: flag height in pixles is not divisible by 3, so the three
green, white and red strip can't be of equal height (as demanded in the original
SVG-code)! And because the Tekbirs should be exact aligned at the border of the
green/white and red/white strip rounding errors may provocate a green or a red
 one-pixel-thick line to appear between the white strip and the Tekbir as you
see in the 800x457 image! It seems the scaling and rendering is doing in the
wrong order (my guess, I also tried different work-arounds but got no satis-
factoring solution, because it is not a coding issue in SVG!).

I guess: IF one would FIRSTLY render the original SVG to its orignal size into
a fixed bitmap format and then scale this down to the wanted (png-)size,
several visibale artifacts (like the just mentioned MUST be gone!). So, this is
a rendering-design issue. Moreover to avoid further artifically introducted
problems by chosen thoughtless fixed sizes (500px), I propose NOT to use
multiples of 100 or 1000 nor historican monitor sizes as fixed image sizes
(which are out of control for the user/uploader!!), but sizes which consists
on many small primes, i.e. HCN (highly composite numbers). Thus my second
pointer in my first email to explain the background.

BTW: The same effect/statement is correct for SVG-templates like the one which
uses national flags displaying in info-boxes in articles. But here maybe I can
trigger guys responsible for these templates on XY-wikipedia (language specific).

I hope I have explained it righlty and (nearly) relevant completely now.

Thanks for your attention,
Achim


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Sorry if incovienent : SVG-to-png rendering on Wikimedia

Denny Vrandečić
2012/6/26 Achim Flammenkamp <[hidden email]>:
> This flag should have a ratio of 7:4 which has the SVG original, but NOT the
> prominantly displayed first image (800 × 457 , 800 is not divisible by 7, nor 457 by 4)!

Even though neither 800 is not divisible by 7 nor 457 is divisible by
4, 800/457 is 1.75054... which is as close as you can get using full
pixels to 7/4 which is 1.75.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Sorry if incovienent : SVG-to-png rendering on Wikimedia

Platonides
In reply to this post by Achim Flammenkamp
So, the aspect ratio is right. Your problem is that you want it to be a
perfect multiple of 7:4.

(...)
> Detailed explanation at example:
> If there is a SVG-file on wikimedia, some fixed logic generates png-images for
> the flag's description page generally. The first image, here 800 × 457, is
> displayed very prominently always at the beginning of the SVG-description file,
> others (320 × 183 pixels | 640 × 366 pixels | 1,024 × 585 pixels.) follows as
> links.


> All these sizes seems to be bounding-boxes from historic used (maybe even today)
> resolutions of (CRT-)monitors respecting aspect about ratio as near as
> they can If horicontal OR vertical is maximized to this resolution.
Those links as provided as convenience for downloading smaller versions.
They were added per bug 2581. I think those were added as arbitrary
sizes (with a large history usage, as noted).

> Then some facts to the original SVG code is stated and than further fixed
> png-sized images follows as links (This image rendered as PNG in other
>sizes: 200px, 500px, 1000px, 2000px.).
>
> The last , in small font set explanation, I added for people to get an understanding of the reasons lying behind the scene. :-/ [Only for thios flag].
>
> This flag should have a ratio of 7:4 which has the SVG original, but NOT the
> prominantly displayed first image (800 × 457 , 800 is not divisible by 7, nor 457 by 4)!

So nobody should be allowed to get a thumbnail with eg. exactly 120px
width? (As used in the galleries, meaning you would end up with
differently-sized thubmnails, which would look bad)


> Because in this flag, there are these two strips of "Alkmar Allah" Tekbirs,
> rendering artifacts can get easily visible if improper rendering occurs!
> First reason is: flag height in pixles is not divisible by 3, so the three
> green, white and red strip can't be of equal height (as demanded in the original
> SVG-code)! And because the Tekbirs should be exact aligned at the border of the
> green/white and red/white strip rounding errors may provocate a green or a red
>  one-pixel-thick line to appear between the white strip and the Tekbir as you
> see in the 800x457 image!
So your problem is not the scaling itself but that it gets wrong (I
don't see a red line above the letters or a green one below them, btw so
seems to render fine).


> It seems the scaling and rendering is doing in the
> wrong order (my guess, I also tried different work-arounds but got no satis-
> factoring solution, because it is not a coding issue in SVG!).

We are just asking rsvg to "render this svg in this size", not doing two
different passes.


> I guess: IF one would FIRSTLY render the original SVG to its orignal size into
> a fixed bitmap format and then scale this down to the wanted (png-)size,
> several visibale artifacts (like the just mentioned MUST be gone!). So, this is
> a rendering-design issue.
Well, if the given instance renders badly you should take the issue
upstream to rsvg authors (unless the problem is that wikimedia is using
an outdated version).


> Moreover to avoid further artifically introducted
> problems by chosen thoughtless fixed sizes (500px), I propose NOT to use
> multiples of 100 or 1000 nor historican monitor sizes as fixed image sizes
> (which are out of control for the user/uploader!!), but sizes which consists
> on many small primes, i.e. HCN (highly composite numbers). Thus my second
> pointer in my first email to explain the background.
I'm pretty sure this will turn out to be a bad idea, but please propose
the alternative sizes.


> BTW: The same effect/statement is correct for SVG-templates like the one which
> uses national flags displaying in info-boxes in articles. But here maybe I can
> trigger guys responsible for these templates on XY-wikipedia (language specific).

Those templates usually request a fixed size, so not related to
MediaWiki defaults.


> I hope I have explained it righlty and (nearly) relevant completely now.
>
> Thanks for your attention,
> Achim

Thanks for your explanation.


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Sorry if incovienent : SVG-to-png rendering on Wikimedia

Merlijn van Deen
In reply to this post by Achim Flammenkamp
On 26 June 2012 19:16, Achim Flammenkamp <[hidden email]> wrote:
> Thus I dig done the problem and it seems to be out of my reach to correct this miss-design by wikimedia but identified it to got founded in some wikimedia politics or history which now noone seems to be responsable. :-/
There are no politics involved, there is just misunderstanding of your
point, which is something completely different. Calling things
'miss-design' will also not get you helped to get this solved - we are
not your enemy.

> If there is a SVG-file on wikimedia, some fixed logic generates png-images for
> the flag's description page generally. The first image, here 800 × 457, is
> displayed very prominently always at the beginning of the SVG-description file,
> others (320 × 183 pixels | 640 × 366 pixels | 1,024 × 585 pixels.) follows as
> links. All these sizes seems to be bounding-boxes from historic used (maybe even today) resolutions of (CRT-)monitors respecting aspect about ratio as near as
> they can If horicontal OR vertical is maximized to this resolution.
> Then some facts to the original SVG code is stated and than further fixed png-sized images follows as links (This image rendered as PNG in other sizes: 200px, 500px, 1000px, 2000px.).
Yes. Essentially, you have to choose *a* size, and they might as well
be these. The problem you are encountering is a more generic one -
even though SVG images are scalable, you will always have rounding
issues.

> This flag should have a ratio of 7:4 which has the SVG original, but NOT the
> prominantly displayed first image (800 × 457 , 800 is not divisible by 7, nor 457 by 4)!
When speaking about the ratio of a flag, I was understanding it was
rendering at, say, 5:4 instead of 7:4. Instead, the problem is the
rounding, which makes the aspect ratio 1.7505... instead of 1.75.
That, on itself, is not a large problem.

> And because the Tekbirs should be exact aligned at the border of the
> green/white and red/white strip rounding errors may provocate a green or a red
> one-pixel-thick line to appear between the white strip and the Tekbir as you
> see in the 800x457 image!
So the problem is the SVG is rendered incorrectly when such an aspect
ratio is chosen.

>  I also tried different work-arounds but got no satis-
> factoring solution, because it is not a coding issue in SVG!.
Although any SVG renderer should be able to render any SVG file to any
resolotion in a correct way, this is of course not the case. I don't
know the specifics of the SVG renderer used, but I suspect there may
be different methods to specify the same results - some giving the
correct result at all resolutions, some not.

> Moreover to avoid further artifically introducted
> problems by chosen thoughtless fixed sizes (500px), I propose NOT to use
> multiples of 100 or 1000 nor historican monitor sizes as fixed image sizes
> (which are out of control for the user/uploader!!), but sizes which consists
> on many small primes, i.e. HCN (highly composite numbers).
I don't see how HCN's would solve this. It makes much more sense to
calculate the sizes that are close to the target value (which can be
the same as currently), but with the exact aspect ratio. So instead of
 320 x 183, one would get 322 x 184. However, it's still a workaround:
we really should have an SVG renderer that 'does the right thing'.

In bugzilla, there is a 'tracking bug' (a bug that lists other bugs)
on SVG rasterization issues [1], but I could not find a bug related to
this (also not via the search [2]), so it is probably a good idea to
open a bug for this. In the meanwhile, I think there are three
workarounds:

1) update the description page to list alternate sizes that do render
correctly (which I just did [3]).
2) upload a PNG version and link to that from the SVG version
3) fiddle with the SVG until the renderer used correctly interprets
what you want - maybe someone with a lot of SVG-fu can do that for
you.

Best,
Merlijn


[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=8901
[1] https://bugzilla.wikimedia.org/buglist.cgi?quicksearch=svg&list_id=125758

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Sorry if incovienent : SVG-to-png rendering on Wikimedia

Derric Atzrott
>[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=8901
>[1]
https://bugzilla.wikimedia.org/buglist.cgi?quicksearch=svg&list_id=125758

I think you may have missed link #3.

Thank you,
Derric Atzrott
Computer Specialist
Alizee Pathology


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Sorry if incovienent : SVG-to-png rendering on Wikimedia

Merlijn van Deen
On 26 June 2012 20:12, Derric Atzrott <[hidden email]> wrote:
>>[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=8901
>>[1]
> https://bugzilla.wikimedia.org/buglist.cgi?quicksearch=svg&list_id=125758
>
> I think you may have missed link #3.

Oops.

[3] http://commons.wikimedia.org/w/index.php?title=File%3AFlag_of_Iran.svg&diff=73320828&oldid=73181275

;-) The second [1] should have been [2], of course.


Thanks,
Merlijn

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Sorry if incovienent : SVG-to-png rendering on Wikimedia

Martijn Hoekstra
Guys, please don't forget to CC him in your messages, I don't think he
subscribes to the mailinglist. It would be a bit of a waste if you
write your arguments not to be heard for the person intended.

On Tue, Jun 26, 2012 at 8:23 PM, Merlijn van Deen <[hidden email]> wrote:

> On 26 June 2012 20:12, Derric Atzrott <[hidden email]> wrote:
>>>[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=8901
>>>[1]
>> https://bugzilla.wikimedia.org/buglist.cgi?quicksearch=svg&list_id=125758
>>
>> I think you may have missed link #3.
>
> Oops.
>
> [3] http://commons.wikimedia.org/w/index.php?title=File%3AFlag_of_Iran.svg&diff=73320828&oldid=73181275
>
> ;-) The second [1] should have been [2], of course.
>
>
> Thanks,
> Merlijn
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Sorry if incovienent : SVG-to-png rendering on Wikimedia

Achim Flammenkamp
In reply to this post by Platonides
Hi

Thanks for your very quick response and a "work-around" solution(?).
It is the first time I see someone promptly spring into action for a quick help.
I thought this was impossible here, too. I needed about 4 - 5 day only to get
the pointer form wikimedia to ask here after public question. :-/

Of cource the prominantly displayed and wrongly rendered image is still there
 (800×457 not equivalent 7x4 ). Hopefully most can understand english text.



On Tue, Jun 26, 2012 at 08:03:54PM +0200, Platonides wrote:
> So, the aspect ratio is right. Your problem is that you want it to be a
> perfect multiple of 7:4.
*LOL* You are pulling my leg. :) Integers are perfect and 7.00567... or
whatever is no integer, like 7:4 is a different ratio than 800 : 457.  :)

> Those links as provided as convenience for downloading smaller versions.
> They were added per bug 2581. I think those were added as arbitrary
> sizes (with a large history usage, as noted).
Okay -- by convenince and "arbitrary" sizes (with a large history usage) ...
well ....

> So nobody should be allowed to get a thumbnail with eg. exactly 120px
> width? (As used in the galleries, meaning you would end up with
> differently-sized thubmnails, which would look bad)
No, no .... see my proposal on http://commons.wikimedia.org/wiki/File_talk:Flag_of_Iran.svg#general comments.

> So your problem is not the scaling itself but that it gets wrong (I
> don't see a red line above the letters or a green one below them, btw so
> seems to render fine).
Depends on what you call render ....

> We are just asking rsvg to "render this svg in this size", not doing two
> different passes.
Well, This I didn't know, but I knew(guessed) if doing two passes this would
be a work-around!

> Well, if the given instance renders badly you should take the issue
> upstream to rsvg authors (unless the problem is that wikimedia is using
> an outdated version).
Well ... if this is the case, I did not know, maybe -- but I'm not an admin.
Noone told me how the original SVG size is converted to a wanted png-size.
 
> I'm pretty sure this will turn out to be a bad idea, but please propose
> the alternative sizes.
Well ... how many sizes do you want? And in which size-range?

I guess: 4 different sizes  from 200 upto 2000 ? (as now)
A quick look to http://en.wikipedia.org/wiki/Highly_composite_numbers shows:

120 2^3.3.5 16
180 2^2.3^2.5 18
240 2^4.3.5 20
360 2^3.3^2.5 24
720 2^4.3^2.5 30
840 2^3.3.5.7 32
1,260 2^2.3^2.5.7 36
1,680 2^4.3.5.7 40
2,520 2^3.3^2.5.7 48

Well, let me suggest: 180, 360, 720, 1680  (because smaller sizes probable will be used more frequently). But I'm open to a different choice (or larger set).
Alle these sizes are divisible by 3 and many even by 9, but all only by 5 no by 25! But we may bargin. ;)

> Those templates usually request a fixed size, so not related to
> MediaWiki defaults.
Yes, but an "arbitrary" size, chosen from convinience as the just discussed? ;-)


2 points  are still open:  "Allahu Akbar"  is the correct wording not
'Alkmar Allah' as you copy from my mistakenly stated/chosen words. If you or
Valhallasw who (in the version-diff look apparently) do the change) tell me how
I could change this part of a file-description page in general, I will do it.

2nd point in a different email.

Thanks
achim


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Sorry if incovienent : SVG-to-png rendering on Wikimedia

Achim Flammenkamp
In reply to this post by Merlijn van Deen
Hi

> There are no politics involved, there is just misunderstanding of your
> point, which is something completely different. Calling things
> 'miss-design' will also not get you helped to get this solved - we are
> not your enemy.
The last I know! :-)
But all looked like secret politics which defined these arbitrary sizes. :)
I got the hint "don't "bingo" with these sizes!" from an SVG-editor. :-/

> Yes. Essentially, you have to choose *a* size, and they might as well
> be these. The problem you are encountering is a more generic one -
> even though SVG images are scalable, you will always have rounding
> issues.
Yes.
BUT: It could also be that there is only the prominently displayed png-image
in the size of the given SVG-file and no other prefered/suggested png-sizes. ;)
Moreover, these other sizes are secretly protected from editing by the user
on the description page. This supported the subjective impression of "politics".


> That, on itself, is not a large problem.
Small (relative) differences could have big consequences. ;)
 
> So the problem is the SVG is rendered incorrectly when such an aspect
> ratio is chosen.
Yes, you could/might/may see it this way.
 
> I don't see how HCN's would solve this. It makes much more sense to
> calculate the sizes that are close to the target value (which can be
> the same as currently), but with the exact aspect ratio. So instead of
>  320 x 183, one would get 322 x 184. However, it's still a workaround:
> we really should have an SVG renderer that 'does the right thing'.
The last sentence I agree by heart. :)
And the important point is: "close" ! The now used sizes are TOO close. :-/
The should respect the ratio given by the original SVG perfectly (a suggestion).
 
> 1) update the description page to list alternate sizes that do render
> correctly (which I just did [3]).
> 2) upload a PNG version and link to that from the SVG version
> 3) fiddle with the SVG until the renderer used correctly interprets
> what you want - maybe someone with a lot of SVG-fu can do that for
> you.
3) I did four hours! :-( And tryed other SVG-coding but it did not work.
I had to mis design the Tekbir by more than 15% then some artifacts for some sizes vanished.
Using a none buggy png-renderer when scaling doing, would solve this issue.
(This was my suggestion).

> Best,
> Merlijn
Thanks & Regards
Achim
--
Achim Flammenkamp       Fakultät für  Mathematik           Universität Bielefeld
UniversitätsstraBe 25        33501 Bielefeld         Federal Republic of Germany
UTC+01=CET     http://wwwhomes.uni-bielefeld.de/achim/    [hidden email]


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Sorry if incovienent : SVG-to-png rendering on Wikimedia

Achim Flammenkamp
In reply to this post by Martijn Hoekstra
> Guys, please don't forget to CC him in your messages, I don't think he
> subscribes to the mailinglist. It would be a bit of a waste if you
I did subscribe to this mailing list.

> write your arguments not to be heard for the person intended.
I got these (unitl now 3 messages from others to this topic/subject).

Thanks,
achim

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: SVG-to-png rendering on Wikimedia

Mark A. Hershberger-2
In reply to this post by Achim Flammenkamp
On 06/26/2012 03:12 PM, Achim Flammenkamp wrote:
> On Tue, Jun 26, 2012 at 08:03:54PM +0200, Platonides wrote:
>> So, the aspect ratio is right. Your problem is that you want it to be a
>> perfect multiple of 7:4.

> *LOL* You are pulling my leg. :) Integers are perfect and 7.00567... or
> whatever is no integer, like 7:4 is a different ratio than 800 : 457.  :)

Is there something sacred about the ratio that means anything less than
perfection is unacceptable?

There are some *real* issues with the rendering on Commons -- especially
SVGs -- and it looks like the thumbnail on
http://commons.wikimedia.org/wiki/File:Flag_of_Iran.svg from "20:14, 21
June 2012" (http://hexm.de/jg) shows the real issue here.

The proper place for reporting this issue is probably the ImageMagick
developers.  They've been really quick about responding and fixing
problems in the past.

After the problem is fixed on the ImageMagick side, you need to get
Wikimedia Operations to deploy the fixed code.

I've reported this to the ImageMagick devs (http://hexm.de/jh).  Let's
see what their response is before we blame "Wikimedia Politics".

Mark.


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
OQ
Reply | Threaded
Open this post in threaded view
|

Re: SVG-to-png rendering on Wikimedia

OQ
On Tue, Jun 26, 2012 at 3:24 PM, Mark A. Hershberger <[hidden email]> wrote:

> On 06/26/2012 03:12 PM, Achim Flammenkamp wrote:
>>
>> On Tue, Jun 26, 2012 at 08:03:54PM +0200, Platonides wrote:
>>>
>>> So, the aspect ratio is right. Your problem is that you want it to be a
>>> perfect multiple of 7:4.
>
>
>> *LOL* You are pulling my leg. :) Integers are perfect and 7.00567... or
>> whatever is no integer, like 7:4 is a different ratio than 800 : 457.  :)
>
>
> Is there something sacred about the ratio that means anything less than
> perfection is unacceptable?
>
> There are some *real* issues with the rendering on Commons -- especially
> SVGs -- and it looks like the thumbnail on
> http://commons.wikimedia.org/wiki/File:Flag_of_Iran.svg from "20:14, 21 June
> 2012" (http://hexm.de/jg) shows the real issue here.
>
> The proper place for reporting this issue is probably the ImageMagick
> developers.  They've been really quick about responding and fixing problems
> in the past.
>
> After the problem is fixed on the ImageMagick side, you need to get
> Wikimedia Operations to deploy the fixed code.
>
> I've reported this to the ImageMagick devs (http://hexm.de/jh).  Let's see
> what their response is before we blame "Wikimedia Politics".
>
> Mark.

I thought librsvg was used and not IM?

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: SVG-to-png rendering on Wikimedia

Platonides
In reply to this post by Mark A. Hershberger-2
On 26/06/12 22:24, Mark A. Hershberger wrote:
> There are some *real* issues with the rendering on Commons -- especially
> SVGs -- and it looks like the thumbnail on
> http://commons.wikimedia.org/wiki/File:Flag_of_Iran.svg from "20:14, 21
> June 2012" (http://hexm.de/jg) shows the real issue here.

Tha shows a problem in the central image, I thought the Tekbir were the
white "letters" on the color stripes?

http://upload.wikimedia.org/wikipedia/commons/thumb/archive/c/ca/20120621203246!Flag_of_Iran.svg/800px-Flag_of_Iran.svg.png
does show a 1px green/red border (not the full one, mixed with white)
between them and the white stripe.


> The proper place for reporting this issue is probably the ImageMagick
> developers.  They've been really quick about responding and fixing
> problems in the past.
>
> After the problem is fixed on the ImageMagick side, you need to get
> Wikimedia Operations to deploy the fixed code.
>
> I've reported this to the ImageMagick devs (http://hexm.de/jh).  Let's
> see what their response is before we blame "Wikimedia Politics".
>
> Mark.

Are you sure it's rendered with imagemagick and not with rsvg?
(we use imagemagick for thumbnailing raster images)

I suspect we may be pulling the wrong developers.
OTOH, both rsvg and imagemagic seem to show a "dragonfly" in the center,
with inkscape showing instead the "trident", so it seems adequate to
drive it to the attention of both groups.
In fact, imagemagick isn't showing the 1px "border".

 rsvg-convert -w 800 -h 457 '20120621203246!Flag_of_Iran.svg' > output.png
 convert -resize 800x457 '20120621203246!Flag_of_Iran.svg' output.png



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Sorry if incovienent : SVG-to-png rendering on Wikimedia

Ilmari Karonen
In reply to this post by Achim Flammenkamp
On 06/26/2012 10:27 PM, Achim Flammenkamp wrote:
>
>> 3) fiddle with the SVG until the renderer used correctly interprets
>> what you want - maybe someone with a lot of SVG-fu can do that for
>> you.
 >
> 3) I did four hours! :-( And tryed other SVG-coding but it did not work.
 >
> I had to mis design the Tekbir by more than 15% then some artifacts for some sizes vanished.
> Using a none buggy png-renderer when scaling doing, would solve this issue.
> (This was my suggestion).

I took a look at the SVG code, and I see several things that could be
done to improve the rendering at arbitrary sizes:

* The "Allahu Akbar" strips are each supposed to contain 11 copies of
the phrase, but they actually contain 12 of them, with two of the copies
drawn on top of each other.  This can cause one of the 11 phrases to
appear bolder than the others at some sizes (such as the 120 x 69 px
size used in gallery thumbnails).  The way to fix that is simply to
remove the extra copies.

* The faint green/red line appearing between the phrases and the central
white part of the flag at some sizes occurs because the phrases and the
white area are different paths, and are thus rendered separately.  It
would be better to merge them into a single path, and to make sure that
no path segments occur in places where a visible line is not supposed to
appear.  (That is, if you set a stroke for the path, the stroked line
should appear only along the boundary of the red/green and white areas.)

* The emblem in the center is built by drawing one half of it and then
cloning and mirroring it.  At some sizes, this can cause a faint white
line to appear where the two halves join together.  It would be better
to draw the entire emblem as a single path.

All of these issues fall into the general category known as "coincident
paths".  Specifically, whenever a vector renderer is told to draw two
lines that fall exactly on top of each other, it's very likely that
there will be rendering errors under some circumstances.  Careful design
and implementation of the rendering code can minimize these issues, but
it cannot eliminate them entirely.  The only way to reliably solve the
problem is to design your drawings so that they don't contain coincident
paths.

--
Ilmari Karonen



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Sorry if inconvenient : SVG-to-png rendering on Wikimedia

Achim Flammenkamp
In reply to this post by Achim Flammenkamp
Hi

"Mark A. Hershberger" already discovered/guessed my still missing 2nd point:

There seem to be an (unknown?) rendering bug. See URL
http://commons.wikimedia.org/wiki/File:Flag_of_Iran.svg
and the flag's/file's version of 20:14, 21. Jun. 2012 .

The original sized image had no artifacts, only this thumb nail in the preview
(and maybe others of these 4+4 fixed sized png-images on the description page,
but I forgot which). I remeber that I deleted all leading digit 0 from
coordinates in a SVG path-command inside for the center emblem. Maybe this was
a reason for miss-rendering at certain sizes, but I strongly wonder that this
only hurts certain final absolute sizes of a rendered image so drastically.

Achim

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Sorry if inconvenient : SVG-to-png rendering on Wikimedia

Achim Flammenkamp
In reply to this post by Ilmari Karonen
Technical: Please email ONLY to the mailing-list, not to me personally. Thanks.


On Wed, Jun 27, 2012 at 12:03:35AM +0300, Ilmari Karonen wrote:
> done to improve the rendering at arbitrary sizes:
>
> * The "Allahu Akbar" strips are each supposed to contain 11 copies of
I 'm still waiting that somebody changes these correct words on the quickly
added comments and png-sizes on URL http://commons.wikimedia.org/wiki/File:Flag_of_Iran.svg from the false "Alkmar Allah" -- I'm not religious, but there
exists fanatics. :-/

> the phrase, but they actually contain 12 of them, with two of the copies
> drawn on top of each other.  This can cause one of the 11 phrases to
But I thought drawing one color exactly at the same position as before will
result in no change.

> appear bolder than the others at some sizes (such as the 120 x 69 px
> size used in gallery thumbnails).  The way to fix that is simply to
> remove the extra copies.
I did this only to make the drawing simpler and maybe faster.
 

> * The faint green/red line appearing between the phrases and the central
> white part of the flag at some sizes occurs because the phrases and the
> white area are different paths, and are thus rendered separately.  It
Yes, probably right.
> would be better to merge them into a single path, and to make sure that
> no path segments occur in places where a visible line is not supposed to
> appear.  (That is, if you set a stroke for the path, the stroked line
> should appear only along the boundary of the red/green and white areas.)
Good idea. But this means you must explicitly state all 22 "Alkmar Allah"
elements. This can't be the sense/usage of SVG-coding. :-(
I want to have a logical strcutred SVG code reflecting the geometric constrcution, not a meaningless heap of coordinates of 3 pathes for 3 colors ! :-((

> * The emblem in the center is built by drawing one half of it and then
> cloning and mirroring it.  At some sizes, this can cause a faint white
> line to appear where the two halves join together.  It would be better
> to draw the entire emblem as a single path.
I know this issue. :-( And the current version has exactly corrected this problem
by add atiny logical overlap. But I think mirroring complex pathes is easier
for threndere than two times draw/interparte the compl4x path coordinates, doesn't it?

Look at flags of Serbia or even Ecuador, how long in real time drawing needs
because of HUGE complex pathes. :-(

> it cannot eliminate them entirely.  The only way to reliably solve the
> problem is to design your drawings so that they don't contain coincident
> paths.
If you are right, this means to abandoned advantage from mirror symmetries
(or rotational symmetries) to repeat sub-patterns.  I hope you are wrong with
"The only way to reliably solve" . :-/

BTW: Sorry, for my many typos and grammar mistakes and wrong wording.

Thanks for your ideas,
Achim

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: SVG-to-png rendering on Wikimedia

Achim Flammenkamp
In reply to this post by Platonides
> Tha shows a problem in the central image, I thought the Tekbir were the
> white "letters" on the color stripes?
Yes, the Tekbirs are the white "letters" on the green and red strip.
 
> does show a 1px green/red border (not the full one, mixed with white)
> between them and the white stripe.
Exactly.

> I suspect we may be pulling the wrong developers.
> OTOH, both rsvg and imagemagic seem to show a "dragonfly" in the center,
> with inkscape showing instead the "trident", so it seems adequate to
> drive it to the attention of both groups.
> In fact, imagemagick isn't showing the 1px "border".
Wow -- nice example for discovering bugs in renderer I coded by chance. :-)

Achim

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Sorry if incovienent : SVG-to-png rendering on Wikimedia

Ryan Kaldari-2
In reply to this post by Achim Flammenkamp
Anti-aliasing is a feature, not a bug. As long as your SVG is going to
be displayed on a monitor that uses pixels, you have to code it with
this in mind. There is no such thing as a "correct" thumbnail size. All
thumbnails are going to have anti-aliasing unless they consist of
nothing but flat squares that are all multiples of the same dimensions,
i.e. virtually never.

I fixed the rendering issue with the Iranian flag by making the tekbirs
slightly overlap the central field. Now it will look correct no matter
what thumbnail resolution you request. The fix took a total of 10
minutes to figure out and implement, which is probably a lot less time
than has been spent on writing emails to argue about it.

Ryan Kaldari

On 6/26/12 12:27 PM, Achim Flammenkamp wrote:

> Hi
>
>> There are no politics involved, there is just misunderstanding of your
>> point, which is something completely different. Calling things
>> 'miss-design' will also not get you helped to get this solved - we are
>> not your enemy.
> The last I know! :-)
> But all looked like secret politics which defined these arbitrary sizes. :)
> I got the hint "don't "bingo" with these sizes!" from an SVG-editor. :-/
>
>> Yes. Essentially, you have to choose *a* size, and they might as well
>> be these. The problem you are encountering is a more generic one -
>> even though SVG images are scalable, you will always have rounding
>> issues.
> Yes.
> BUT: It could also be that there is only the prominently displayed png-image
> in the size of the given SVG-file and no other prefered/suggested png-sizes. ;)
> Moreover, these other sizes are secretly protected from editing by the user
> on the description page. This supported the subjective impression of "politics".
>
>
>> That, on itself, is not a large problem.
> Small (relative) differences could have big consequences. ;)
>    
>> So the problem is the SVG is rendered incorrectly when such an aspect
>> ratio is chosen.
> Yes, you could/might/may see it this way.
>    
>> I don't see how HCN's would solve this. It makes much more sense to
>> calculate the sizes that are close to the target value (which can be
>> the same as currently), but with the exact aspect ratio. So instead of
>>   320 x 183, one would get 322 x 184. However, it's still a workaround:
>> we really should have an SVG renderer that 'does the right thing'.
> The last sentence I agree by heart. :)
> And the important point is: "close" ! The now used sizes are TOO close. :-/
> The should respect the ratio given by the original SVG perfectly (a suggestion).
>    
>> 1) update the description page to list alternate sizes that do render
>> correctly (which I just did [3]).
>> 2) upload a PNG version and link to that from the SVG version
>> 3) fiddle with the SVG until the renderer used correctly interprets
>> what you want - maybe someone with a lot of SVG-fu can do that for
>> you.
> 3) I did four hours! :-( And tryed other SVG-coding but it did not work.
> I had to mis design the Tekbir by more than 15% then some artifacts for some sizes vanished.
> Using a none buggy png-renderer when scaling doing, would solve this issue.
> (This was my suggestion).
>
>> Best,
>> Merlijn
> Thanks & Regards
> Achim



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
12