Commons:Graphics village pump/February 2017

High-quality photographic workflow

Hello all. I am trying to establish a sensible workflow when uploading high-quality photographs to Wikimedia Commons. I have read most of the help related to saving, manipulating, and uploading photographic images. I use Linux solely.

Assuming I shoot in Sony SRW raw at around 24 megapixels, here is what I am considering:

• using GIMP, open SRW, crop out any barrel distortion, and export as PNG

The Exif data is not transferred because unfortunately Exif is not supported by PNG. However the Exif data can be copied programmatically to the PNG Description field. This information is no longer machine readable but at least it will be still present in the file.

• copy the Exif data to the PNG Description field using python and ExifTool
• upload the lossless PNG to the Commons

Then develop a lossy JPG version as these are more convenient and can also embed Exif metadata:

• still in GIMP, export as JPG at 100% quality, preserving the Exif data
• upload the JPG as a new version using: Upload a new version of this file

As required, continue to work the image:

• using GIMP, correct the perspective, crop, adjust, and sharpen
• export again as JPG at 100% quality
• upload the JPG as a new version

Repeat the process with more substantial reworking as necessary.

Is this a reasonable workflow? Can one upload a new version in another format (I didn't want to experiment).

I see in the Wikimedia documentation that the templates {{PNG with JPEG version}} and {{JPEG version of PNG}} should be used. Does this mean that two different uploads need to be performed? Surely that is poor database practice having two entries for the one image. Maybe Wikimedia should support forked image development (one for a PNG thread and one for a JPG thread) under the one image record. The Wikipedia page (caller) could then elect which version to display.

Continuing, it would solve much if PNG supported Exif, but it doesn't. Another reasonable workaround would be to allow the parallel uploading of a sidecar *.exf file containing the original Exif metadata. Sidecar files of course have obvious downsides. But is this possible? If so, should it be supported?

Any comments would be very welcome. Thanks in advance. RobbieIanMorrison (talk) 16:15, 3 February 2017 (UTC)

Is there a specific reason why you are not using tiff files instead of pngs? Tiff also has lossless compression (preferably zip), the compression is better suited for photos, and it supports EXIF and IPTC. — Julian H.^✈ 15:11, 4 February 2017 (UTC)

Hello Julian Herzog. Thanks for your suggestion. Yes I wondered that myself. But some Wikipedia and Wikimedia Commons pages steer the user towards PNG as the lossless format of choice for photographs. My main reference here is Commons:File types. On re-reading that page I find a problem. The main section header Images discusses photographs and non-photographic files (typically diagrams and screenshots) together and weaves between these two distinct targets in a rather confusing manner. It would be better to split the material in that section into Photographs and Non-photographic images and deal with each specifically. In any case, here is an example of the prompting towards PNG over TIFF: Overall, PNG is a preferred format; however, the ability to upload TIFF files is offered as a courtesy. (Commons:File types#TIFF).

Notwithstanding, the question of whether one can upload a TIFF and then a JPG remains unanswered. I will do a trial and then request a deletion if there is no response on this point. With best wishes. RobbieIanMorrison (talk) 09:13, 5 February 2017 (UTC)

I haven't tried it, but it would seem odd to me if it worked. After all, the file type is baked into the file names here on Commons. Not sure what would happen with a new version upload and subsequent rename of the file. — Julian H.^✈ 10:41, 5 February 2017 (UTC)

Hello again Julian Herzog. I see your point. I also note the {{JPEG version of TIF}} template, which says:

new file

This image is a JPEG version of the original TIF image at File: Example.tif. However, any edits to the image should be based on the original TIF version in order to prevent generation loss, and both versions should be updated. Do not make edits based on this version. Admins: Although this file is a scaled-down duplicate, it should not be deleted!

So whether or not this is bad database design, the fact remains that two instances of the same image (as in scene or person or object) must be uploaded. There is no reciprocal {{TIF version of JPEG}} template in this case but there is an {{Archival version}} template for the canonical TIF:

 

 

This image has a thumbnail version at File: Example.jpg. Any edits to the image should be based on this version in order to prevent generational loss, and both versions should be updated.

---

I think these two templates represent the best work plan if I decide that a high-resolution archive should be preserved. I also note, after looking at a couple of your files, that you appear to deal solely with JPGs. Finally, your UserInfoTemplate looks very useful, perhaps that could be extended and become official. Once again, many thanks for your comments and interest. With best wishes. RobbieIanMorrison (talk) 16:06, 5 February 2017 (UTC)

A footnote. Photographer Katy Blackwood only uploads in PNG. She points out that the file types page states: PNG is good for ... print-quality photographs. It seems that that advice is open to debate though. RobbieIanMorrison (talk) 10:47, 6 February 2017 (UTC)

Hi, yes, I do. My use of PNG is connected more to an over-sharpening issue that means my high resolution photographs look dreadful when uploaded as JPEG (which in turn makes me look incompetent), hence requesting they not be uploaded as such. Theoretically, if TIFF didn't have the sharpening issue, I'd have no real objection to using that format. Katy Blackwood (talk) 22:40, 6 February 2017 (UTC)

Just to note that this discussion more or less continues at Commons talk:File types#Archival format for digital photographs. Take a look. RobbieIanMorrison (talk) 11:40, 10 February 2017 (UTC)

How can I make areas of maps dotted or striped using Inkscape?

I've created a lot of maps but I've never been able to figure out how this is done. Is there a straightforward method in Inkscape? Eg the striped effect on this map. Thanks. Rob984 (talk) 13:19, 10 February 2017 (UTC)

Well, normally I'd use a GIS rather than graphics software for stuff like this, but for Inkscape I've found this. Hatching is the search term you're looking for. Cheers, --El Grafo (talk) 16:44, 10 February 2017 (UTC)

Thank you. Indeed, hatching. The "object to pattern" tool seems to ignore the existing shape of the object, though the "pattern to object" tool seems to pretty much do what I want. But after I duplicate my object and apply the hatching pattern fill, it wont allow be to easily change the colour of the hatched duplicate. I've tried every option I know of ("object to path", etc.) and none of them seem to do anything. Only way I can figure out how to change the colour is to export it as a bitmap, then import it and use the "trace bitmap" tool to covert it into a regular object. This is easy enough, but I'm guessing there is a more straightforward way to change the colour of an object with a pattern fill? Rob984 (talk) 13:40, 11 February 2017 (UTC)

Script created for assisting Fourier/FFT/descreening/half-tone removal workflows

I've assembled a bash script for assisting with workflows for removing half-toning and the resulting moire effects in scanned images. It automates a few of the tedious steps of FFT processing, automatically reprocessing an image each time an intermediary file is edited. It's primarily ripped from an ImageMagick guide, and requires ImageMagick and inotifywait.

I'm thinking of linking to this from the Commons guides to descreening: Help:Scanning and Commons:Cleaning up interference with Fourier analysis.

Any input would be appreciated. djr13 (talk) 19:10, 14 February 2017 (UTC)