Commons:Graphics village pump/May 2010

Improving math image quality question

My question is about the updating policy in the following case: Suppose I want to recalculate some images (e.g. File:Burning_Ship_Fractal_Zoom.png) with greater resolution, higher super-sampling, more iterations and higher precision. Should I upload it as a new file or as a new version of the same file? In some cases I've no choice but uploading as a new file (e.g. different license, lossy vs lossless), how should I mark that a better version is available?

P.S. I've lost in the Community portal, so redirect me if it's the wrong place for the question or it'd already been answered somewhere. Thank you.

Ybungalobill (talk) 21:03, 14 May 2010 (UTC)

Probably upload it as a new version of the same file, unless there's a significant change in the appearance of the image, or the total pixel count of the image is greater than 12,500,000 (in which case, PNGs won't be resized). AnonMoos (talk) 00:07, 15 May 2010 (UTC)

Thanks for your response! But what should I do if the description is no longer 100% correct? Add some sort of "Updated: ..." paragraph? Ybungalobill (talk) 09:18, 15 May 2010 (UTC)

Please replace old file with improved version

Atxscale.svg should be overwritten with the improved Atxscale-improved.svg that I uploaded. -- 21:48, 15 May 2010 User:The Assimilator

It's not obvious that it's "improved" when the purple area doesn't seem to define a rectangle in the version you uploaded. Was that intentional? -- AnonMoos (talk) 21:25, 16 May 2010 (UTC)

Another SVG thumbnail problem

I'm seeing File:Caroline of Brunswick Arms.svg render as a red box (English Wikipedia) or yellowish stripes (Commons) at nominal 600×600. I suspect it's a similar problem or otherwise related to a resource limit. Is there a tag template to mark these images as having a known rendering issue on Wikimedia projects and/or that someone with high access might want to do a special render for the cache? (For what it's worth, Firefox 3.6.3 in Windows also has trouble: it doesn't render the left half of the shield, leaving it all red with a black border. But we know Firefox's SVG rendering is still pretty basic.) --Closeapple (talk) 22:40, 29 April 2010 (UTC)

A 3MB svg for a coat of arms! That is rather poor coding. /Pieter Kuiper (talk) 22:43, 29 April 2010 (UTC)

Perhaps. For what it's worth, she has a lot of families represented — the coat of arms has more shout-outs than a Oscars speech. It appears the creator used the elements from the ancestor's shields, which seems reasonable. On a slow render in Firefox, it sometimes appears something is being wasted though: the first time Firefox rendered it natively, I saw the whole thing red then yellow then red again (maybe with a lighting effect), for example; but that may just be Firefox dealing with clipping areas strangely. --Closeapple (talk) 23:00, 29 April 2010 (UTC)

Original is 3,389,915 bytes. Loading into Inkscape 0.47 and doing "vacuum defs" only shaved 25 bytes off it. Saving it out as "Optimized SVG" in Inkscape 0.47 (which runs it through Scour 0.22) makes it 1,532,364 bytes, but Scour makes source code changes that may make it harder for people who edit SVG. Alas, it appears that the duplicate elements have their full definitions repeated each time in the file, even after Scour (though I could be wrong). For example, the same lion passant guardant appears 6 times at exactly the same size and 4 in addition to that; and, from looking at the XML tree in Inkscape, it appears each one is separately described rather than being cloned/linked. I wonder if there's a tool to find duplicate objects and make them clones/links. (Not that this solves the basic issue, which is that sometimes Wikimedia projects are going to encounter SVG files that are exceeding resource quota yet are legitimate to contribute the project.) --Closeapple (talk) 00:01, 30 April 2010 (UTC)

More of this sort of thing: I deleted 9 of the same 10 lions passant then made 9 clones, then deleted 1 of the 2 yellow lions rampant on the right and cloned it from the other lion rampant as well. Doing just these and nothing else dropped the size from 3,389,890 to 1,660,911 bytes. After Optimized SVG/Scour it was 1,408,425. (I didn't upload the result because it was a rough edit just for proof-of-concept, not a good version; I didn't make much attempt at preserving exact positions getting the right objects in front again.) --Closeapple (talk) 02:11, 30 April 2010 (UTC)

---

I started a new section, because I'm pretty sure this problem is different from the one reported by ZooFari above. In any case, I think you should first concentrate on fixing File:Duke of Brunswick-Lüneburg.svg, because the problem with File:Caroline of Brunswick Arms.svg has pretty clearly spread from there... AnonMoos (talk) 02:17, 30 April 2010 (UTC)

GIF thumbnails in fact greatly increase file size!!!

Beginning of this topic - (Note: link has been fixed.)
I have studied this problem and now I know answer. Thumbnail algorithm is buggy, and don't work properly with animated GIFs. It decompress/unoptimize optimized animation (size is greatly increase), and then consider (full_framesize*frames) as image size. If it exceed 12.5Mpx, only first frame is used, if not — frames resized, and then saved unoptimized!!! In fact, after this "thumbnail" greatly exceed size of original file. Examples from previous post:
(700px-65.9 KB), (120px-129 KB!)
(82px-2.09 КБ), (60px-4.29 KB!).
So if you want to use animated image of ANY size, you have only two ways: do not use thumbnails (this will greatly decrease load time and server loads) or you can resize your image, save it optimized and then upload as different file.
Please, send this bug to developers, thumbnail algorithm must optimize animation before saving, or it will only increase server load! --Vladislav Pogorelov (talk) 19:04, 3 May 2010 (UTC)

On Technical pump I heard funny answers like "This is not 100% correct" (from developers), but when feature, intended to save space and time, terribly increase both (imagine thousands of blowed GIF's * millions of requests) — and this all due to stupid implementation, and completely ruine established Wikimedia functionality, used on thousands of pages, this is a CRITICAL BUG and should be immediately fixed. (For first-time fix, I suggest change [[Image:]] behavior. Let it return <img src="...commons/thumb/... > for static GIF's and <img height=thumbh width=thumbw src="...commons/... > for animations.) Vladislav Pogorelov (talk) 17:24, 4 May 2010 (UTC)

Don't want to dismiss the seriousness of the problem you have pointed out, but there are plenty of others of us who are simply overjoyed that NON-ANIMATED GIFs are finally being resized again, and give that a much higher priority than optimizing resized animated GIFs (which I'm not sure was ever done in the past, anyway). AnonMoos (talk) 17:31, 4 May 2010 (UTC)

I suggest possible solution, it will satisfy all: resize static and don't blow animated files. --Vladislav Pogorelov (talk) 17:43, 4 May 2010 (UTC)

How about thousands of page creators, who suddenly found his featured articles broken, and nobody want to help him with this problem? They was overjoyed? --Vladislav Pogorelov (talk) 17:51, 4 May 2010 (UTC)

You wrote: "resize static and don't blow animated files." Animated GIFs have never been resized in an optimized way by MediaWiki as far as I know. There is work being done on it here: Bugzilla #11822.

In the past few years until recently the full-size animated GIFs were sent to browsers for resizing by the browser. This was unsatisfactory, especially for dialup users. It also forced static GIFs to be sent full-size to browsers.

This page may be useful: Commons:Animated image resources. --Timeshifter (talk) 05:28, 5 May 2010 (UTC)

If anyone is interested in this, please help me work on this by commenting in this English Wikipedia thread. TheDJ (talk) 21:02, 5 May 2010 (UTC)

SVG text rendering

Hi,

shows some odd SVG rendering problems. My local librsvg renders the file just fine, as do all my browsers. I tried scour, too.

I do believe it is a rendering bug, since the text is not only sized incorrectly, but also spaced incorrectly. It might be using the correct spacing for the true font size, just the glyphs being drawn at an incorrect size? I've tried various things to simplify the file, I'm already using the font "Times", i have removed all group elements and there is no transformation matrix on the text elements that render incorrectly. In fact, there is next to no difference to the text elements that do render correctly... Anyone knows how to work around this bug? --Chire (talk) 10:08, 14 May 2010 (UTC)

FWIW: by moving the non-working text elements to the beginning of the file (aka: into the background) I got them to render properly. That basically confirmes that this is a librSVG bug. Which already seems to be fixed in my librsvg version, 2.26.3. See earlier revisions of the file for the bug. --Chire (talk) 10:23, 14 May 2010 (UTC)

But it's still not yet completely okay, the graphic doesn't really scale as to be expected. Maybe I should try a more explicit font than the generic "times". --Chire (talk) 10:26, 14 May 2010 (UTC)

I don't think I can help you with your specific problem, but in general there do seem to be problems with the Wikimedia rendering of fonts. It seems that about two years ago, there were a lot of idiosyncracies and particularities with font rendering, but if you were willing to experiment a little, and knew a few relevant tips and tricks, you could probably come up with a SVG file that rendered in a satisfactory way. Since then, the treatment of fonts has become a lot more standard and uniform, and there are now many fewer exceptions and irregularities -- but if there's any general-purpose Latin font which is rendered in a satisfactory way across a broad range of point sizes, then people sure don't seem to know about it. I don't know why I should have had to replace text with paths in the ultra-simple SVG file File:Simple inverse relationship chart.svg, but I did... AnonMoos (talk) 10:03, 17 May 2010 (UTC)

I need help for a SVG image

Hi all, I made this image with Inkscape, (derivated from this one) but it doesn't seem to work properly. Can you help me? I also uploaded another version (which doesn't work as well) with an incorrect name that should be deleted. Thanks in advance.--Carnby (talk) 20:57, 15 May 2010 (UTC)

Really don't know what's wrong with the files with Italian captions. I tried to eliminate non-essential code, and the resulting files seem to display in FireFox, Inkscape, and Adobe SVG plugin, so I'm not sure why RSVG has problems. AnonMoos (talk) 09:52, 17 May 2010 (UTC)

It's the arrows. Known bug i think--DieBuche (talk) 20:14, 17 May 2010 (UTC)

Thank you very much. Now the duplicate file can be deleted.--Carnby (talk) 14:55, 18 May 2010 (UTC)

radialGradient

The SVG rendering engine seems not to always work well with radialGradient attribute. Is this a known problem? --百楽兎 (talk) 23:15, 17 May 2010 (UTC)

Do u have an example? --DieBuche (talk) 23:29, 17 May 2010 (UTC)

An example: File:CHUBU Electric Power.svg. Compare to http://upload.wikimedia.org/wikipedia/zh/e/e3/CHUBU_Electric_Power.svg --百楽兎 (talk) 09:35, 19 May 2010 (UTC)

this file was just messed up in general. I cut it down from 130kb to 6kb--DieBuche (talk) 13:05, 19 May 2010 (UTC):

I always get a black box in my svgs

I'm fairly new to inkscape, and I'm only doing the basics - but whenever I try to upload something there's always this weird black thing. See this picture, for instance.

Can anybody help? -- 02:26, 20 May 2010 User:Inoljt

I'll take a look at it, but it's usually because of stupid Inkscape "flowtext" elements... AnonMoos (talk) 05:47, 20 May 2010 (UTC)

There was a useless blank "flowtext" at the end... AnonMoos (talk) 05:57, 20 May 2010 (UTC)

Yet another SVG Inkscape problem

I tried to edit translated SVG (File:Supranational European Bodies-en cs.svg) using Inkscape, but i am getting "File extension does not match MIME type". File is here. Where is problem ? --Jklamo (talk) 19:47, 23 May 2010 (UTC)

I really can't use that "Mediafire" site to view any files with my current browser security settings; maybe if you could just cut-and-paste the first few lines of the file (down to the end of the <svg tag) the problem might become apparent... AnonMoos (talk) 21:49, 23 May 2010 (UTC)

Sorry to use mediafire, but i did not find any hosting without bloody ads (and accepting svg). First lines:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:cc="http://creativecommons.org/ns#"
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:svg="http://www.w3.org/2000/svg"
  xmlns="http://www.w3.org/2000/svg"
  xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
  xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
  version="1.1"
  id="katman_1"
  sodipodi:docname="Supranational_European_Bodies-cs.svg"
  inkscape:version="0.46"
  x="0px"
  y="0px"
  width="849.606px"
  height="617.199px"

... last lines

y="215.21841" /></flowRegion><flowPara id="flowPara5834"></flowPara></flowRoot></svg>

--Jklamo (talk) 22:11, 23 May 2010 (UTC)

Sorry, I can't really diagnose the filetype problem based on that alone (it seems like you didn't even include to the end of the <svg tag). But I can tell you from the last few lines that your file includes Inkscape "flowtext" tags, which will probably result in stupid black rectangles when uploaded here... AnonMoos (talk) 20:04, 25 May 2010 (UTC)

Finally i found imagehoster allowing svg. So here is file, without stupid ads: http://imgh.us/Supranational_European_Bodies-cs.svg. It redners ok even in my web browser, but still getting same error while trying upload it to commons. --Jklamo (talk) 17:27, 27 May 2010 (UTC)

Got it. I made several changes, but adding an xmlns:xlink="http://www.w3.org/1999/xlink" declaration may have been the most important. It was evident that the file had been edited in both Inkscape and Adobe Illustrator, which can sometimes create problems, especially in large and complex files... AnonMoos (talk) 05:51, 28 May 2010 (UTC)

Thanks. I edited file only in Inkscape, but source was apparently created with Adobe Illustrator. How can I avoid problem like this in future? Can this problem be considered as bug of Commons or Inkscape? --Jklamo (talk) 01:55, 29 May 2010 (UTC)

I'm not familiar enough with the technical SGML rules to know who's right here. If a file includes "xlink:href", then it should definitely also include an xlink declaration, but I'm not sure if it just includes "url(#...)". -- AnonMoos (talk) 06:52, 29 May 2010 (UTC)

DO-TALK-READ-WRITE.svg

The following file made in Inkscape does not render properly. I tried various fixes by converting text and squares to paths but failed.

--Nevit Dilmen (talk) 15:50, 27 May 2010 (UTC)

Most often such unexpected black rectangular areas mean Inkscape "flowtext" tags. I eliminated two blank and completely useless Inkscape "flowtext" tags at the end of the file, and it worked like a charm... AnonMoos (talk) 16:59, 27 May 2010 (UTC)

Thank you AnonMoos for fixing this. And I appreciate the fixings you did on some of my SVG files before. I am aware of your contributions. --Nevit Dilmen (talk) 16:14, 3 June 2010 (UTC)

SVG image thumbnail not displaying

Languages of Europe

Does anyone know why the thumbnail for this image is not displaying? It is interesting to note (as pointed out by User:Saibo, here) that anything below 694px width does not work (or only partially works): 694px works but not 693px. Thanks, Hayden120 (talk) 03:32, 28 May 2010 (UTC)

Maybe because of sodipodi stuff in the file? Try saving as plain SVG. Btw, there is an artifact in iceland --Georg-Johann (talk) 17:35, 11 August 2010 (UTC)

What did I do to this SVG file?

I recently uploaded a new version of File:Usenet traffic per day (en).svg, which was generated by Gnuplot and edited in Inkscape. I converted the text to paths, but the text is horribly mangled as rendered by MediaWiki; Safari has no problem displaying the text correctly. Purging the page's cache had no effect. Am I doing something wrong or is this a bug in MediaWiki? Cheers, bdesham ★ 15:44, 25 May 2010 (UTC)

Okay, I fixed the problem by having Gnuplot generate the SVG directly (instead of converting Gnuplot's PDF to SVG with Inkscape). My issue still applies to older versions of the file. --bdesham ★ 15:51, 25 May 2010 (UTC)

You declare Helvetica as a font, but the svg backend only knows these fonts meta:SVG fonts

AnonMoos, I opened a new bug, concerning the declaration of SVG fonts here [1]--DieBuche (talk) 20:10, 25 May 2010 (UTC)