Commons:Graphics village pump

↓ Skip to table of contents ↓

Shortcut: [[:]]

Welcome to the Graphics village pump !

Hello and Welcome to this "Common graphics portal and Graphics village pump", hosted by Commons. This Graphics village pump aims to provide help and information about the several Graphic Labs spread in the Wikipedias, and to be the technical support forum for all the local Labs, graphists (graphic artists), and users interesting in Graphic works, and is a page where graphists and users from all the Labs can talk about graphics, tutorials, graphic software, help to build new Graphic Labs, etc.

The Graphic Lab and the Graphics village pump aim to transform Commons from an Uploaders community to a true working graphist community, based on the four graphic skills and interests teams.

The project is just starting - please talk everywhere about it. Please request image improvements as well. Active contributors are also really need to lead the project too. We need this to start!

Current effort is needed to help the new Commons:Graphic Lab.

Commons | Deutsch | English | Español | Français

Talking, Acting

Above, you can see the list of the open Graphics Labs, a list which we continue to expand. The spread policy of the Graphics Labs is close to be such :

In each Wikipedia of more than 200.000 articles, we should have a working local Graphic Lab (several graphists).

In each Wikipedia of more than 100.000 articles, we should at least start a local Graphic Lab (~3 graphists).

We hope to start and build several wikigraphist communities on the level of the Wikipedias, contributing in their mother language, with their friends, etc. Each team will help its Graphic Lab evolve.
All of the teams should stay connected by this Commons portal, exchanging opinions, ideas, protocols, and ways of improvement.

• 
  Whitening or cleaning the background
• 
  Removal of objects and colour improvement
• 
  Image restoration
• 
  Convert to Vector graphics

Some examples of typical work done previously.

To requests an Image creation or improvement, please see in your local Graphic Lab, in your Wikipedia or images to improve on Commons. If the requested work is possible, a Wikigraphist will sign up for the work, perform the requested actions, and after approval replace the original image with the improved one.

Happy Sharing !

See also : Graphics abilities page Graphic Tool Project Insignia | Stroke Order Project

COMMONS DISCUSSION PAGES (index)

• Commons Help desk
• Village pump (general discussion)
  • Copyright
  • Proposals
  • Technical
• Graphics and photography discussion
  • Photography critiques
  • Image improvement
    • Illustration workshop
    • Map workshop
    • Photography workshop
    • Video and sound workshop
• Categories for discussion
• Undeletion requests
• Deletion requests
• Volunteer Response Team/Noticeboard
• Translators' noticeboard
• Work requests for bots

---

• Contact administrators
  • Vandalism
  • User problems (Dispute resolution)
  • Blocks and protections
• Bureaucrats' noticeboard
• CheckUser requests
• Oversight requests

---

• Telegram
• IRC ^webchat
• Commons mailing list (archive)
• Commons' bugs on Phabricator

Graphics village pump archives:

• April 2007
• May 2007
• June 2007
• July 2007
• August 2007
• September 2007
• October 2007
• November 2007
• December 2007
• January 2008
• February 2008
• March 2008
• April 2008
• May 2008
• June 2008
• July 2008
• August 2008
• September 2008
• October 2008
• November 2008
• December 2008
• January 2009
• February 2009
• March 2009
• April 2009
• May 2009
• June 2009
• July 2009
• August 2009
• September 2009
• September 2009
• October 2009
• November 2009

July_2024

Add Topic Edit Discussion

Converting images to two colors black and white

Sorry, for beginner question, but my graphics skills doesn't go too far from cropping :-)

I made photocopy of public domain book (example), 631 pages. I need to convert gray scale image to two color black and white PNGs. My goal is to preserve sharpness of the text, but also make embedded images as good as possible.

Original images are in RAW format.

Please give me step-by-step instructions. I have Adobe Photoshop Elements which may be useful.

EugeneZelenko (talk) 15:29, 29 September 2009 (UTC)

Image extraction from book scan data

[I hope this is the right forum, move the post if it is not]

I often need to extract details from scanned books, but I uncertain of the optimum method for doing so. Restoration is not the problem, in fact that is not appropriate for the intended purpose. I understand that PNG is considered to be desirable, so I have previously converted files to that format. I have had moderate success with cropping details from jp2 files, found at sites like archive.org, but these are not always available. The widely used djvu format is not appropriate for this purpose, the strength of that format is in handling and compressing the text of book scans. The current example is File:Blake by Linnell (as Story's frontispiece).png (from a TIFF) and File:Blake by Linnell (as Story's frontispiece) 2.png (PDF). I would like to document the 'best practice' and a simple workflow, for the benefit of other contributors, so any help would be greatly appreciated. cygnis insignis 10:34, 12 October 2009 (UTC)

Animated GIF resizing. Last.fm resizes them. Why not MediaWiki?

Has there been any progress with this? Why can't MediaWiki correctly resize animated gif images?

Here is a last.fm animated gif linked below. I found it today. Note that correctly resized animated images are showing up on last.fm pages:

• http://userserve-ak.last.fm/serve/126/36538753.gif
• http://www.last.fm/user/Inci90 - largest size. 55 kilobytes.
• http://www.last.fm/user/Inci90/library - smallest size. 8 kilobytes.
• http://www.last.fm/music/Cluster/+shoutbox - medium size. 20 kilobytes. The Inci90 avatar is currently next to the third comment.

There are many animated GIF images on the Commons. For example;

• Category:Animations of geometry

Note that the full kilobytes used for the full-size image is downloaded for the thumbs. It causes some categories to take a long time to load due to all the full-size GIF animations having to load. I have broadband, and so they usually eventually finish loading. It can take a long time even on broadband. It must be an extra load on the servers.

A full category of animated thumbnail images will not finish loading for most dialup users unless they wait a very long time. It deprives them of looking at the thumbnails to decide if they want to use any of the animated images. It deprives them of static images too if they happen to be in a category page with many animated images. --Timeshifter (talk) 02:58, 20 October 2009 (UTC)

It just hasn't been a priority for developers, since a workaround exists (offline resizing). Dcoetzee (talk) 06:01, 20 October 2009 (UTC)

Offline resizing does not solve the thumbnail problem. Look at Category:Animations of geometry. All the images in that category are animated images. All the animated-GIF thumbnails are created by downloading the full-size animated-GIF images, and then resizing them in the browser. This is a huge download, and a huge waste of server time and bandwidth. It wastes money too. It also makes the animated images inaccessible to many dialup users. It also makes some static images inaccessible too if there are static images mixed up with a lot of animated images in a category. --Timeshifter (talk) 15:53, 20 October 2009 (UTC)

Bugzilla's bug #16451 GIF scaling limit should be applied to animated GIFs only is marked as fixed as of 2009-08-14. --Jarekt (talk) 21:03, 22 October 2009 (UTC)

Thanks for the link. This is great news. Maybe it will go live in the next version of MediaWiki that is installed here. --Timeshifter (talk) 02:18, 23 October 2009 (UTC)

Latest reply on the bug thread says this: "Yes, for ordinary GIFs to render properly somebody needs to activate it on Wikimedia."

--Timeshifter (talk) 10:19, 5 November 2009 (UTC)

I left a request for implementation at COM:AN here:

Commons:Administrators' noticeboard/Archive 18#Animated GIF resizing bug. Fix awaits implementation by admin

--Timeshifter (talk) 16:45, 12 November 2009 (UTC)

GIF scaling (animated and non-animated) still not working

Resizing of non-animated GIFs is still not resolved... AnonMoos (talk) 04:33, 14 December 2009 (UTC)

It seems that all GIFs (animated and non-animated) are not being scaled by MediaWiki. I thought the problem was resolved according to the Bugzilla bug thread: #16451 GIF scaling limit should be applied to animated GIFs only. A 2009-08-14 comment by Andrew Garrett in that thread says it is fixed. His user page is en:User:Werdna.

New people reading this topic need to look above at the previous talk section also in order to understand the history more fully.

See also the later Bugzilla thread comment by Robert Rohde (en:User:Dragons flight):

https://bugzilla.wikimedia.org/show_bug.cgi?id=16451#c33

He says the fix can be implemented by removing this from CommonSettings.php:

// Disable server-side GIF scaling 

$wgMediaHandlers['image/gif'] = 'BitmapHandler_ClientOnly';

See:

http://noc.wikimedia.org/conf/highlight.php?file=CommonSettings.php

It is linked from http://noc.wikimedia.org/conf --Timeshifter (talk) 16:16, 14 December 2009 (UTC)

Yes, it would appear to be just a matter of getting one of the 15 or so people with Wikimedia shell access to change it. Dragons flight (talk) 03:00, 15 December 2009 (UTC)

I left a message for Andrew Garrett at en:User talk:Werdna. m:System_administrators lists him as having shell access.

It looks like he hasn't been active since December 2, 2009 according to his Wikipedia user contributions. Any others you recommend contacting? --Timeshifter (talk) 16:38, 15 December 2009 (UTC)

This whole episode has been ultra-lame from beginning to end

This whole thing has been stupidly handled from the beginning -- when problems with a small minority of animated GIFs was allowed to indefinitely suspend the usefulness of ALL GIFs, despite the fact that there has been no effort made over the last five years to fix the well-known grave inefficiencies of Wikimedia PNG resizing (inefficiencies which were what drove many people to upload GIFs instead of PNGs in the first place) -- down to the present, when over FOUR MONTHS after a fix was offered, it still hasn't been put in place, apparently because no one with proper authority is willing to take responsibility, or even wants to be bothered at all. With proper management and active followup, this whole thing could have been a two-weeks' episode, instead of which it has dragged on TWO YEARS, partly because nobody in the developers cabal seems to take problems of image resizing very seriously -- even though such problems can have a strong effect on the user experience of people browsing Wikipedia, and the amount of bandwidth served by the Wikimedia Foundation servers... AnonMoos (talk) 18:51, 20 December 2009 (UTC)

I agree. I also think overwork has something to do with it. The Wikimedia Foundation needs to prioritize more money to pay developers to fix the over 4000 bugs listed in the Bugzilla Weekly Reports. Instead of spending as much money for lesser-needed things the Wikimedia Foundation is trying to do. --Timeshifter (talk) 21:13, 20 December 2009 (UTC)

Well, it seems like fixing it is being given "after dog-wash" priority (as such a situation is referred to in the Jargon File [1]) even though leaving it unfixed has a variety of negative consequences, such as rendering categories like Category:Octave Uzanne basically useless in their intended function of displaying the images that belong to the category... AnonMoos (talk) 03:45, 27 December 2009 (UTC)

Even artists use animated GIFs

The Animated GIF: Not Just for LOL's Anymore. By Cliff KuangMon. Dec 21, 2009. Fast Company (magazine). --Timeshifter (talk) 22:13, 26 December 2009 (UTC)

File:Suez Canal Volumes.png

Apparently, my production/uploading of this diagram ( File:Suez Canal Volumes.png ) was not successful (made on OpenOffice-draw). In any event, it is not shown on Suez Canal. And if I put the name in [[]], the diagram is opened immediately. Could anybody tell me what went wrong (or that a beginner should rather leave this to the experts)? --AHert (talk) 20:43, 6 December 2009 (UTC)

Image displayed in this manner

It seems OK, except for excessive margins (which I fixed). AnonMoos (talk) 04:46, 10 December 2009 (UTC)

Thanks a lot, but why is it not shown on Suez Canal? --AHert (talk) 16:06, 13 December 2009 (UTC)

Because no one added it to the gallery page. Click on the Edit link to do so. By the way, Category: Suez Canal and Suez Canal are two separate things... AnonMoos (talk) 19:30, 13 December 2009 (UTC)

GSM world coverage maps

Hi there, I am struggling to convert some of the GSM world coverage maps to SVG in order to extract the actual coverage from them and make a free image. Inkscape both on Windows XP and Ubuntu encounters an error when importing the maps. OpenOffice.org Draw can not import the PDF either. Is someone able to do this for me? Or any hints for another software?--Kozuch (talk) 17:11, 9 December 2009 (UTC)

Pichilemu maps

Hi, thanks Justass by recreating the Modern Talking signature in SVG. Someone can recreate these maps:

• Spanish version
  Spanish version
• English version and correct
  English version and correct
• Coat of arms
  Coat of arms
• 
  My poor coat of arms :(

The english one is the correct one, because the beach have to be at the left, not like the spanish version. Before there's just to replace names to Spanish again.

Thanks you all... --MisterWiki (talk) 20:49, 27 November 2009 (UTC)

Please, I need with urgency that coat of arms. I've made one (well, not completely) but is very bad. Please help me!!!!. --MisterWiki (talk) 00:35, 11 December 2009 (UTC)

Problems with SVG-embedded raster images

Hi. I am having issues with this file. It is an SVG map of a cathedral with embedded JPGs for the windows. In the version displayed by MediaWiki, the ratio changes that I have applied to some of the images are not taken into account. If I download the file and look at it with inkscape, it looks ok though. For an example, you can look closely at the two top-right images, both annotated "Grisaille". They should be of equal height and cover the drawing underneath, but it is not the case. Is it only an unavoidable bug of the SVG engine used by MediaWiki, or is there something I could do better, in order to make the visualization correct? Thanks in advance. --Eusebius (talk) 13:21, 13 December 2009 (UTC)

Don't want to discourage you, but the general "philosophy" of SVG use on Wikimedia projects, is that SVG files are expected to contain predominantly vector data, with smallish embedded bitmaps occasionally supplementing the vector data where necessary. The reverse (having large embedded raster bitmaps annotated with a few vector annotations) is not really what SVGs are intended to do here, and problems which arise from this may not be given a high priority to be fixed... AnonMoos (talk) 15:57, 13 December 2009 (UTC)

I'm conscious of that. I'll probably export a PNG (?) when the map is finished, but for now an SVG is the most practical way for me to keep everything and for others to contribute as well. I don't think having the SVG on Commons is totally useless as it will be the source (in some way) of the raster file. Anyway, I'm still interested in the technical question, even if just out of curiosity. --Eusebius (talk) 16:09, 13 December 2009 (UTC)

Opera 10.10, Chrome 3.0.195.33 and Firefox 3.5.5 also show the raw SVG (download and then open from local PC) with the unequal scaling, so it may not be a MediaWiki bug. -84user (talk) 08:24, 14 December 2009 (UTC)

Yes, I should have seen that, thank you. So maybe I'm doing something wrong or invalid within the SVG? --Eusebius (talk) 08:39, 14 December 2009 (UTC)

Inkscape is not standards conformant in applying the preserveAspectRatio attribute. So, if you see a distorted image in Inkscape, it may well preserve its ratio everywhere else. A way to avoid this issue would be to surround the image tag with a group element prior to applying any transformation. --Hk kng (talk) 12:07, 16 December 2009 (UTC)

Thanks for the info, will try that. --Eusebius (talk) 12:11, 16 December 2009 (UTC)

Recent modifications of basic upload form

In recent weeks I have decided to cease using the Commonist and upload the pictures with basic upload form. It was quite good and I was quite happy. Everything worked perfectly, I uploaded pictures quite fast, there were no crashes, login errors or some other "commonist stuff". But what happened in few last days?

Well lets start. First thing... When I input some data in simple upload form to {{Information}} like description, author, date, parameters... and then I upload the picture... then i press BACK to have all my previous data saved here so it can be used again in uploading a new picture. But BAM! when I do this now, all data are automatically erased and plain {{Information}} without anything appears. I do not understand why and I would like to know where in preferences this feature can be turned off.

The second problem I have encountered today. When I choose a pic from some folder, the name of the file does not appear correctly. Czech diacritics is messed up → some characters are transformed to another ones, some dissapear and therefore the filename is corrupted. Until now I have never seen any problem like this one with language-specific characters. Fixing the name in every single case in the upload form is the only solution I've found now. However, such a work slows down. As I can see, there was no need for this few days ago, why now? I think there might be something with Firefogg, that is a new thing here, but as we know, lot of people upload images here so they might be confused as well. And they might be uploading pictures with corrupted filenames. Thank for your help. --Aktron (talk) 21:38, 27 December 2009 (UTC)

This is actually a scripting problem, not an image problem as such. You may get better answers if you ask on the general Commons:Village pump, or on a Commonist-specific discussion page... AnonMoos (talk) 22:20, 27 December 2009 (UTC)

Yep. I wanted to post this on Village pump (I know here it looks a bit odd), but in the main table there was something like technical support that lead here. --Aktron (talk) 22:40, 27 December 2009 (UTC)

File:Niels Klims underjordiske reise.djvu

Pages 22-23 are duplicates of pages 24-25. Being technically challenged, I do not have the ability to change this: My DjVu Solo can't handle the DjVu-files with OCR texts, while my DjView cannot remove images from the middle of a file, it can only crop away pages at the start and end of a file. What do I do? This is important, as I recently uploaded a new version of the file, with OCR text layer, after having started writing off the text on no:s:Indeks:Niels Klims underjordiske reise.djvu, so the deouble page, in addition to being unnecessary are spoiling the page alignment of the text. Thanks. V85 (talk) 23:42, 28 December 2009 (UTC)

New SVG upload doesn't change file

I'm trying to upload a newer version of File:USMinimumWage. Nothing happened, and so I tried to upload the file again. The second revision suddenly appeared correctly, however the file I just uploaded remained identical to the older version. I tried reverting back to the second version, and now both revisions I just uploaded appeared correctly, however the newest version was identical to the oldest one! What on the world is going on? Guy0307 (talk) 05:26, 1 January 2010 (UTC)