Commons talk:Image guidelines

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

This is the talk page for discussing improvements to Commons:Image guidelines.

Should they be required to be manifold to be quality? Arlo James Barnes 01:00, 9 January 2021 (UTC)Reply[reply]

Can we remove sRGB recommendation?[edit]

Can we remove the following sRGB recommendation?

Best color spaces are sRGB or, optionally, Adobe RGB, which is wider, as these are standard color spaces and hence easiest to support and for other editors to use. If using a non-sRGB color space – say for greater color range – consider making an sRGB version of the image for greater compatibility.

All major web browsers and operating systems support color profiles, and modern cameras capture more colors and bit depth as well. Other color spaces are also standards. We shouldn't discourage people from posting wide gamut images if they need to show some colors which are not part of the ancient sRGB standard. The only compelling argument for sRGB is that JPEG is only 8-bits (so likely posterization with very wide gamut profiles like Rec.2020) but that doesn't apply to AdobeRGB which isn't that wide and it's hopefully all going away soon with modern >8-bit codecs like JPEG XL.

--Trougnouf (talk) 14:19, 13 September 2021 (UTC)Reply[reply]

So, by not suggesting a standard, or preferable shortlist, would it be ok for people to submit images in *any* color space? I'm thinking that would cause some problems. Hohum (talk) 16:05, 13 September 2021 (UTC)Reply[reply]
I believe so. It's pretty rare that people change from the default sRGB color space, and I assume one would know why they are chosing something else, so why bother with restrictions for problems that do not materialize? --Trougnouf (talk) 16:23, 13 September 2021 (UTC)Reply[reply]
Moreover if one were to create a custom color space for their image, then it would likely just be beneficial because they could then fit the colors they need in only 8-bits. Either way, no one does that. --Trougnouf (talk) 16:28, 13 September 2021 (UTC)Reply[reply]
A few notes: Every thumbnail of an image must include the profile used for that image. When a file is thumbnailed by Thumbor, sRGB profiles are replaced by TinyRGB (see phab:T100976). This can result in a performance improvement, especially for users on limited connections. Most other profiles are larger than sRGB to start with and aren't made smaller. AdobeRGB isn't too bad, but I've seen some hilariously large color profiles. Due to phab:T219569, TIFFs with certain profiles will be converted to TinyRGB during thumbnailing anyway. While ICCv2 is well-supported among desktop browsers, ICCv4 is not. I have no idea about mobile browsers.
In summary: it's still best to use sRGB unless you have a good reason not to. AntiCompositeNumber (talk) 23:53, 13 September 2021 (UTC)Reply[reply]
ICCv2 seems to be supported on Apple mobile devices and Chrome on Android (both ICCv2 and ICCv4 here). Neither work on my phone with Firefox mobile (which is the only exception I know of). Mobile devices tend to have wider gamut than most desktops since they are small enough for AMOLEDs and such fancy tech to have been cost effective. ICCv4 is supported on desktops by Chrome, IE, and Safari, but not Firefox (v2 only) but either I haven't seen one in the wild or most software export in a backward compatible way somehow? (I am a Firefox user and I sometimes export my images in Rec. 2020 to preserve colors which don't exist in sRGB or Adobe RGB.)
I can see your argument for saving bandwidth, especially on thumbnails, but these are the image guidelines which we use in Commons:Quality Images; size is not so much of an issue when we specifically ask authors not to downsize their image. Color gamut compression is definitely a downsizing operation, which is usually worse than spatial dimensions imo, and the size difference is minimal; ***most color profiles take up less than 1 kB***, eg 732 bytes for Rec.2020, 1.1 kB for ProPhoto RGB with half of the data being a string containing copyright (CC-BY-SA-3.0) information. That is nothing compared to the megabytes we use up by providing full resolution.
I think it would be ok to use a wording that mentions Wikimedia Commons is optimized to save bandwidth on thumbnails with sRGB images, but the current wording is just misleading; sRGB (or optionally Adobe RGB) are not just "best" anymore, and software support is prevalent among viewers and editors so there is no added difficulty for the other editors. This has created pointless arguments on Commons:Quality images candidates that have repeated and will repeat so long as the guidelines mislead reviewers into prefering sRGB over color accuracy.
--Trougnouf (talk) 06:40, 14 September 2021 (UTC)Reply[reply]

Question about perspective[edit]

Hi, not sure if this is the correct place to ask that ... but I'm new to Quality Images and unsure about the perspective/distortion requirements. The page says:

Images of architecture should usually be rectilinear. Perspective distortion should either have a purpose or be insignificant.

Per my understanding, this picture would not be a QI because it is obviously not "rectilinear" and I can't see any "purpose" in the distortion - the photographer just stood in front of the church and directed his camera upward:

However, the general consensus seems to be that this picture is a QI and "there are a lot of examples of similar photographs already QI".
Am I too critical here? Main reason for my question is that I have lots of similar pictures, but I have not dared to nominate these for QI so far.
Related, while this page says that "images of architecture should usually be rectilinear", and some of my pictures were declined because they showed upward perspective, the Quality Images page even has such pictures as QI examples:

So why are my way less tilted pictures declined due to "too tilted", but these massively tilted pictures are used as QI examples? Plozessor (talk) 16:51, 11 October 2023 (UTC)Reply[reply]