Commons talk:Featured picture candidates

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

Set gallery works poorly on multiple rows[edit]

When you nominate a set, {{FPCnom/Set}} uses packed galleries to display the set. When all the elements of a set have the same aspect ratio (as is often the case), especially if they are of the same view, you expect them to have the same size. Unfortunately, this is not the case if the set wraps around to form multiple rows. If you have two rows, the first row will be completely packed, so the packed gallery logic will tell the images to fill the entire row, even if it means exceeding the dimensions prescribed in {{FPCnom/Setgallery}}, but images in the second row will only be as large as prescribed, causing the first image to be much larger than the second on certain monitors. Any suggestions on how to fix this issue? Pinging Adam Cuerden who created the template. -- King of ♠ 05:26, 19 September 2016 (UTC)

  • It is not good to specify both height and width in "packed" mode. See en:Help:Gallery_tag. I made an attempt; check the result. Jee 06:33, 19 September 2016 (UTC)
Additional functionality like that should probably be dealt with in phabricator, or by changing to mode=noframe and very specific heights and widths. Adam Cuerden (talk) 14:59, 19 September 2016 (UTC)
@King of Hearts, Jkadavoor: For the record - the bot doesn't really even aattempt to handle set noms well at the moment (they require a fair bit of hand tweaking on closure), so you may as well just switch them to mode=noframe heights=YYYpx widths=ZZZpx when they're all the same or similar; I'd suggest this not be the default, though, as it's only good when they're quite similar, and it's harder to set up well. Adam Cuerden (talk) 22:38, 23 September 2016 (UTC)

Color profiles[edit]

Recently, we've seen many pictures uploaded with missing color profiles, and several users jumping to point that out. It says in the image guidelines that images should be tagged but does not indicate that this is a requirement. I feel like this is not something that users can have subjective opinions about (e.g. noise; how much is too much?), but a hard line like GFDL-1.2: either it has a profile or it doesn't. So instead of this ambivalent state we're in right now, I think we should discuss whether to make this a formal requirement at FPC. -- King of ♠ 00:34, 20 September 2016 (UTC)

Now I'm using DxO Optics Pro evaluation version (which will expire soon) and found that it will not add embedded ICC profile even though I choose it while exporting to jpg. My understanding is that because sRGB is already chosen in EXIF. Today I read this and it seems there is only a problem if conflicting information is stored in different places. Jee 04:28, 20 September 2016 (UTC)
I will download DxO to see what the problem is. I am skeptical that any professional image software for photographers will fail to have the option to include a colour profile when exporting. But if that's the case, then I'll be filing a bug report to DxO. I certainly know that GIMP (as well as Lightroom and Photoshop) can embed them, but it can be confusing how to set GIMP up. It has been known for a very long time that profiles are essential to ensure images are rendered correctly, especially by browsers. In the distant past, all monitors were more-or-less sRGB and no software or operating systems could do any colour management. This has changed. See User:Colin/BrowserTest. All our current browsers (with the exception of a modified Firefox) only use the colour profile to determine the colours in an image. They all ignore the tags. There is a perception on some old web sites that EXIF tags make a difference -- they do not and never have done. Without a profile your browser will simply not colour manage the image at all. This means it takes the raw RGB values from the JPG and renders them on the monitor without any attempt to calibrate how red and how green and how blue to make each pixel. So a supposedly sRGB image, on a wide-gamut monitor, will look really really bad (weirdly saturated). And a supposedly AdobeRGB image on a standard-gamut monitor will look really really bad (dull).
There have been requests for people to include colour profiles in their images at FPC going back more than five years. For those people able to run programs on the command line of their computer, I can post some instructions later to use EXIFTOOL to embed the correct profile into a JPG. Without a profile, it is like me telling you that my living room is 4 x 5. Is that yards or metres? If we aspire for FP to determine professional-standard images fit for publication, then this sort of metadata is simple essential. -- Colin (talk) 07:49, 20 September 2016 (UTC)
Thanks Colin. BTW, I noticed that all files I processed using RawTherapee have embedded sRGB profile. But interestingly they don't have it in EXIF. So it seems both software use different technique. (I tried to save a file in Gimp; it also using EXIF; not XMP/embedding.) Jee 08:59, 20 September 2016 (UTC)
I'll try to find out what I discovered about GIMP. I seem to recall it wasn't obvious how to export with a profile included, but it is definitely possible. -- Colin (talk) 09:11, 20 September 2016 (UTC)
I would support making this a requirement. I want to see nominated images displayed properly, and I would expect that nominators want the same. A big part of why I participate here is simply to see outstanding and beautiful images. I don't want to miss out on that because of a missing color profile, and I don't want photogs/nominators to lose out on accurate reviews of their images. INeverCry 08:13, 20 September 2016 (UTC)

I should point out that Phabricator T134498, which I raised, is an attempt to mitigate this issue. It only affects thumbnails and only for images that lack an embedded profile and where it is reasonably safe to guess they are likely sRGB. Although Giles has implemented a fix, I have no idea if it will be accepted and when it might be incorporated to Commons and Wikimedia. But it doesn't affect the source JPG image. If you look at that 100% or you download it (and Commons' purpose extends beyond Wikipedia to usage elsewhere) then the colours are still undefined. And if it gets adopted on WP, it won't affect existing thumbnails unless you purge the image. Wide-gamut monitors and displays are becoming increasingly common, not just for photo professionals, but for the latest TV standards and the latest mobile phones (e.g. Apple i7 has DCI-P3 display). -- Colin (talk) 09:09, 20 September 2016 (UTC)

I would support making embedded color profiles in jpg files nominated for FPC a mandatory requirement. As we get an increasing number of properly color managed browsers, image editing programs, and an increasing occurance of wide gamut displays, now even on smart phones like the iPhone7, it is overdue we get more specific. (It would be nice to have a gadget, such that it was easier to check a nomination for a properly embedded sRGB color profile). Still, the default recommeded color profile should be sRGB although it does not span as many colors as, e.g., AdobeRGB (only relevant on wide gamut screens), as the non-color managed applications will present color way of what was intended - it is perfectly OK to also upload alternatives with other color profiles, e.g., ProPhoto RGB or Adobe RGB as they may give more optimal results on wide gamut displays or on high quality color-managed printers. Reusers can then use this version for, e.g., high quality prints. But it should be the sRGB version which is promoted as it is still the most well supported color space by many applications and displays. See this blog post to better understand better this rather technical discussion. -- Slaunger (talk) 21:28, 20 September 2016 (UTC)

What difference would knowing the color profile have on how we evaluate the images? --Frank Schulenburg (talk) 22:52, 20 September 2016 (UTC)

  • You would see the colors the way the author intended to (provided he's set up everything properly on his side). - Benh (talk) 12:31, 22 September 2016 (UTC)
  • I would support making this a requirement. - Benh (talk) 12:31, 22 September 2016 (UTC)
  • Additionally, I'd propose to automatically delist all current FPs with missing profile. - Benh (talk) 12:34, 22 September 2016 (UTC)
  • Hundreds, maybe thousands? A bit over the top... Then you could also propose to prohibit Commons from working with the Internet Explorer or other browers that, unlike Firefox or Safari, generally do not support any hardware color profiles. I have a calibrated wide gamut screen and using IE is just ugly... Perhaps someone could write a bot that is able to "repair" FPs and other files that are missing an embedded profile? --Martin Falbisoner (talk) 13:10, 22 September 2016 (UTC)
  • I think there is merit in proposing a tool (like the crop tool) that one can use to pick an image and request a colour profile be embedded. There is a public domain licence-free sRGB profile that comes with ArgyllCMS ,which is also very high quality. All the tool needs to do is call EXIFTOOL with the relevant parameter, and the profile gets embedded. Argyll CMS also comes with equivalents for AdobeRGB and others, though this issue is only really common for people who export sRGB settings and some part of their toolchain or export settings is letting them down. One thing the tool could do, is apply the same logic as the above Phabricator task, to ensure that the profile wasn't incorrectly inserted into a JPG that already had a profile, or that appeared to not be sRGB based on EXIF tags.
I don't think there is any merit in delisting, when the fix is fairly easy. Remember also the Phabricator task above, which proposes to hide the problem on Wikipedia -- but only if that task is actually adopted and released.
Where do we propose new tools? I reckon one of our tools writers could knock this up in an evening.
Btw, if there is anyone here with a Apple desktop computer and a wide gamut screen, come chat to me about User:Colin/BrowserTest, as one person has suggested the latest Safari handles images without embedded profiles correctly (i.e. assuming sRGB). I agree with Martin that IE (and Edge) are totally broken if you use a wide gamut monitor. And all mobile devices are broken too, though if anyone gets an iPhone 7 then let me know how the BrowserTest performs on that. -- Colin (talk) 13:41, 22 September 2016 (UTC)
But how do we fix those file without the missing profile, and without the exif to tell which one should be embedded? Even though it's likely it is sRGB, I'm not aware of a way to be sure of it. At least we should delist those files without any possible reliable fix. (?) - Benh (talk) 21:20, 22 September 2016 (UTC)
Benh, most JPGs out of camera do not embed a colour profile. I don't know about newest models of Nikon/Canon/etc though. It's a widespread problem but nearly always if it is sRGB then the EXIF ColorSpace tag is present and = 1. Any other colourspace is supposed to set the tag to Uncalibrated, so with those, we really have little idea other than it is not sRGB (though there may be hints elsewhere it is AdobeRGB, and other spaces like ProPhoto are very unlikely, though some people do use it mistakenly thinking it gives them more colours. The problem is if people use very crude paint programs to edit files, and lose all the EXIF. But such people probably aren't adjusting the image that accurately anyway. And for some photographs with extreme conditions (very high key, low key, sunsets, etc) the accurate colours are maybe less important. For standard conditions, and for photographing/scanning works of art, accurate colours are vital. -- Colin (talk) 14:05, 24 September 2016 (UTC)
One issue may be that there don't appear to be strong standards for greyscale. How should we handle those? Adam Cuerden (talk) 23:03, 23 September 2016 (UTC)
I'd like to find our previous discussion on greyscale before saying much more, but gamma (the function that maps from 0.255 to the brightness on your monitor) is part of the colour profile. For a b&w photograph this may well matter. For a b&w poster/ink/art then whoever photographed/scanned/restored it may well have adjusted the range of brightness very approximately to be high contrast, and therefore it doesn't matter much. -- Colin (talk) 14:05, 24 September 2016 (UTC)

Bot messed up the log page[edit]

In this edit, here, CommonsDelinker completely messed up the page. By removing the deleted file completely, instead of redlinking it, the whole Featured picture candidates page was transcluded onto the log page. How do we avoid this in future? I know it doesn't happen often, but it's a pain when it does; that big page transclusion made the log page hard to edit due to its size... Face-tongue.svg INeverCry 10:47, 27 September 2016 (UTC)

PSA: Firefox on Windows may be upsampling images[edit]

I would like to invite anyone using Firefox on Windows 7 or later to take a look at the last two paragraphs of Commons:Image guidelines#Your monitor, which I just added, and test your monitor by looking at this image at 100% magnification. Even if you are not using Firefox on Windows, it's a good idea to run this test anyways to make sure nothing funny is going on.

Here's my story if anyone's interested to hear: Recently I bought a new Windows desktop with a QHD (2560x1440) monitor. It's an amazing monitor; I can't believe I've been editing images on a puny 1600x900 laptop display for so long. Anyways, I recently noticed that somehow my images looked less sharp after being uploaded than on my local computer. Upon further investigation, full-res images on Firefox appeared more zoomed-in than the same images displayed on Chrome. And what's more, they appeared the same size on both browsers on my laptop! This was a very puzzling scenario, but I ultimately found out this was due to Windows being set to 125% scaling in Control Panel -> Display on my new desktop (but 100% on my laptop). Apparently new versions of Firefox try to mimic Windows's display scaling, which is enabled by setting devPixelsPerPx to -1.0, so setting devPixelsPerPx back to 1.0 will restore the original behavior (note that this will also make all the text and everything smaller than you were used to in Firefox). King of ♠ 04:56, 28 September 2016 (UTC)