Commons:Graphics village pump/September 2017

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Editing .png files

I'd guess this has been asked dozens of times before in the Archives, but I can't find it. I used to use MP Paint very effectively for producing and editing .png distribution maps (e.g. File:Branta bernicla map.png), but now I've got a new Mac computer and it doesn't have MS Paint of course. Photoshop is worse than useless for editing these files. What is the best (preferably free!) editing programme for a Mac that works in ± the same way as MS Paint? Recommendations, please! - MPF (talk) 16:35, 28 August 2017 (UTC)

I only use Windows and Linux, but maybe one of the following tools are right for you
  • Paint2 (a litte bit more than just MS-Paint)
  • GIMP (I would recommend it)
If you want to use MS-Paint there are several ways to run Windows-Progamms on Mac[1].
I think I didn't understand why someone needs MS-Paint, I would recommend to use GIMP instead of MS-Paint.
Because it came ready-installed on my old computer, gimp didn't. Using it would have meant finding it online and installing it, with the consequent risks to the computer (malware / viruses sneaking in with it from potentially unsecure sites), which I wasn't prepared to take. - MPF (talk) 00:25, 29 August 2017 (UTC)
Distribution maps should be created as SVG, not as PNG. In my Opinion Distribution maps should be created as SVG, not as PNG.  — Johannes Kalliauer - Talk | Contributions 20:36, 29 August 2017 (UTC)
I disagree, strongly. svg has the major disadvantage that computers don't have svg editors installed as default, therefore making svg files uneditable for the great majority of people. This is totally contrary to the ethos of Wikis, that anyone should be able to edit them. - MPF (talk) 00:25, 29 August 2017 (UTC)
 — Johannes Kalliauer - Talk | Contributions 18:28, 28 August 2017 (UTC)
SVG is simply text file; you don't even need complex image editors like binary files such as PNG does. Just open the SVG in a basic text editor as if you are writing an essay, and every single computer should have a text editor installed. --Zhuyifei1999 (talk) 17:02, 29 August 2017 (UTC)
@MPF:
risks of software
You could use virtual Windows, if you get Malware, you just install virtual Windows new, and there is no harm to your computer
I would recommend to check every downloaded Software before installing with en:Virustotal https://www.virustotal.com/
SVG <-> PNG
I know SVG has several disadvantages, which format is the best is a opinion based question, which no correct answer (Except JPG in alsmost every case won't be the correct format)
But I strongly disagree with your point (making svg files uneditable for the great majority of people. This is totally contrary to the ethos of Wikis, that anyone should be able to edit them.) The ethos of Wiki is in my opinion that it is free and can be edited by everyone, therefore you should neither use Windows/Macintosh nor MS-Paint, they are not en:Free software, not even en:Freeware. From this point of view you should use Unix and Inkscape (or GIMP).

that computers don't have svg editors installed as default

— User:MPF
Strongly disagree, as User:Zhuyifei1999 said SVG can just edited with any text editor (or even in the terminal, without graphical interface), therefore in my opinion SVG is more in the ethos of Wiki, than PNG, which needs more complex software, which is in most cases en:Proprietary software such as MS-Paint.
 — Johannes Kalliauer - Talk | Contributions 20:36, 29 August 2017 (UTC)
Exactly, even my old pre-smartphone-era mobile phone had an SVG editor. Hell, most Wifi access points, vehicles (at least on road and rail, propably also water and air) and those television-thingies have an SVG editor installed by default. --Nenntmichruhigip (talk) 19:29, 19 September 2017 (UTC)

Cropping and tilting 3 segment painting

Hi, see Commons:Deletion requests/File:Lamentation with Saint John the Baptist and Saint Catherine of Alexandria.jpg. Could anybody help creating a version that does not have a copyright problem? Jcb (talk) 14:57, 21 September 2017 (UTC)

Jcb I did a quick edit of the image and uploaded here. I'm going to probably overwrite that revision though because I think I can get a larger version from that site. - Offnfopt(talk) 15:27, 21 September 2017 (UTC)
Jcb I uploaded a larger version, not 100% happy with the edit, but best I can do with my current hardware. - Offnfopt(talk) 17:10, 21 September 2017 (UTC)
Thanks a lot! It's much better than the file we began with. Jcb (talk) 17:40, 21 September 2017 (UTC)

JFIF alternative for large files

I’ve got a grid of many files in JPEG File Interchange Format, which I want to merge to one large graphic. For large-but-not-that-large graphics, that’s no problem. But in this case, the resulting graphic's width is larger than 65535, so JFIF isn’t an option. I tried converting it to PNG, but this results in insanly huge files (several Gibibytes instead of a few hundered MiB), so this also isn’t an option. So, what is a format in which I can merge this graphic sanely? --Nenntmichruhigip (talk) 19:29, 19 September 2017 (UTC)

Nenntmichruhigip when it comes to graphic images that large, I don't think there is such thing as sanely. Here is the issue at hand lossy compression and lossless compression.
  • JPEG uses lossy compression, this means when compressing the image information and details are lost. So the negatives of this are it can result in compression artifacts on the image and the more a image is saved using lossy compression the more information is lost and the more obvious compression artifacts become. The positive note however is that the image file sizes can be reduced at the expense of some details.
  • PNG Truecolor images use lossless compression, this is why the image is so much larger, because no information is being lost so no compression artifacts but results in larger file sizes.
The Webp file format supports both lossy and lossless compression, but given the image size you'll want lossy. Google has some command line tools to convert images to webp located here, just make sure you set the parameters so it uses lossy instead of lossless compression. You may need to do some test images with different levels of compression to find the proper middle ground.
And in case you're wondering, yes webp images can be uploaded to commons. - Offnfopt(talk) 00:27, 20 September 2017 (UTC)
@Offnfopt: Which TIFF standards and decompression methods are supported by MediaWiki and Commons' backend thumbnailers?   — Jeff G. ツ 02:20, 20 September 2017 (UTC)
Jeff G. I'm unsure of this answer since I'm not familiar with which software commons backend uses to generate the thumbnails for non-SVG files. I only have a few TIFF files uploaded in my time here and one is compressed using LZW while the other two that were more recent were both uncompressed. - Offnfopt(talk) 03:17, 20 September 2017 (UTC)
I know that, my issue is that the JPEG file format doesn’t support such large images. Some of the images are smaller than 2^16, and for those JPEG works as I wish. Actually, I even think the merging operation is lossless when keeping it as JPEG because of the chunks’ sizing. WebP supports even only less than 2^14 px width. The dewiki and enwiki articles say there’s an tiling option to increase the limit to 2^14 tiles times 2^14 px, but I haven’t found anything to use this, neither in imagemagick nor in cwebp. I’ll try asking on dewiki’s information desk. --Nenntmichruhigip (talk) 18:04, 21 September 2017 (UTC)
User:Nenntmichruhigip -- According to en:Lossy_compression#JPEG, there's a "jpegjoin" program which in certain circumstances can get around some part of generation loss when joining JPEGs (I've never tried it). That won't solve the 65,535 maximum problem, of course... AnonMoos (talk) 16:29, 22 September 2017 (UTC)

You may want to try upload them in several tiles, see examples of images in Category:Gigapixel_images_from_the_Google_Art_Project. --Zhuyifei1999 (talk) 18:32, 21 September 2017 (UTC)

Seems like a good idea, thanks for letting me know about this possibility. Though the files I’m currently working on aren’t suitable for commons (not old enough), but I expect future documents of that size to be „commonsable“. For the internal use, I’ll propably go for a similiar solution to allow displaying the files on devices with fewer computational resources (thanks to a hint on dewiki). --Nenntmichruhigip (talk) 16:33, 22 September 2017 (UTC)