Commons:Featured picture candidates/File:Basel - Stadtpanorama vom Münsterturm.jpg

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

File:Basel - Stadtpanorama vom Münsterturm.jpg, not featured[edit]

Voting period is over. Please don't add any new votes.Voting period ends on 15 Apr 2015 at 15:18:46 (UTC)
Visit the nomination page to add or modify image notes.

View over Basel and the Rhine knee from Basler Münster
  •  Info all by Wladyslaw. Info: High resolution city panoramic view of Basel, Switzerland (northbound). The picture is annotated. -- Wladyslaw (talk) 15:18, 6 April 2015 (UTC)[reply]
  •  Support -- Wladyslaw (talk) 15:18, 6 April 2015 (UTC)[reply]
  •  Neutral I'm surprised it doesn't have your trademark quality. Did you have to recover shadows? I love the "bended" pattern composition but the scene is like cut in two with that right part in the shade. Unfortunately. Why couldn't you go farther on the left? And I too think you should add color space to your images. - Benh (talk) 16:23, 6 April 2015 (UTC)[reply]
    • It isn't so much "add color space" as find out what software is removing this essential component from your JPGs. Your raw software will set it. I suspect GIMP, which I'm surprised to see used considering how professional your other equipment is. GIMP doesn't even support 16-bit TIFF yet. I have checked with EXIFTOOL and the colour space is 65535, which is "uncalibrated". It should be 1 for sRGB and other EXIF tags are required if AdobeRGB. So this file is just wrong. Photoshop complains (if you have it set to warn) that the file has no colour profile. The fact that the tag is present but not 1 makes me wonder if the colours are actually correct. I don't know GIMP but perhaps you've ticked a box to "strip out unnecessary EXIF data to save space" or similar option. -- Colin (talk) 17:49, 6 April 2015 (UTC)[reply]
  • The weather situation was like you can see it on the picture. The quite shiny part on the left and the very dark clouded area on the right (maybe you dislike this two opposed parts). But in all parts the cityscape is visible very well. So why should this be an issue of the quality or GIMP? --Wladyslaw (talk) 04:21, 7 April 2015 (UTC)[reply]
The issue with quality is that we can't trust the colours. Aren't they rather important? A proper colourspace is an essential part of the JPG specification and any software that allows it to be removed is faulty (sadly not uncommon among software not aimed at professional photography). The above JPG states the colourspace is "uncalibrated", which means every browser and image viewer is left to guess what colour to display. Some will guess sRGB, others (some Macs) will simply pass the numbers straight to your monitor which may be set to AdobeRGB, sRGB or some random variation. The fact that it isn't set to sRGB makes me rather suspicious the colour profile is actually something else, which has been ignored/stripped out by software. It might not be GIMP, it might be PtGui, though Dillif doesn't seem to have any problems. -- Colin (talk) 07:33, 7 April 2015 (UTC)[reply]
I'm sorry, but I don't see a problem with the colors. Everything looks natural to me. --Wladyslaw (talk) 07:51, 7 April 2015 (UTC)[reply]
Well it would do, on your monitor. It's like you promise to pay me 100 for doing some job. Is that $100, £100 or €100? Nobody knows, and we can only guess. I don't see what the big problem with fixing this is. You've gone to all the trouble of buying the best camera and the best calibrated monitor but then fail to export your JPG with standard EXIF data needed to ensure everyone sees what you see. Just read the manual on your software and figure out what option you've chosen that removes this essential EXIF data from the image. -- Colin (talk) 09:29, 7 April 2015 (UTC)[reply]
This is not my first FP-candidate with the same workflow I do for nearly every image (RAW-image as basic, PTGui of stitching necessary, GIMP for final works) so I wonder why in this image there should be a problem and with other pictures there isn't. --Wladyslaw (talk) 11:09, 7 April 2015 (UTC)[reply]
I won't go through all ur noms, but I'm pretty sure this isn't the first time the issue is raised on one of them. I think Sting mentionned this a few years ago. Anyhow, it's an easy fix on ur side, and it would greatly improve reliability on the colours we see, even though I suspect most software revert to sRGB when no color profile is embedded. - Benh (talk) 11:15, 7 April 2015 (UTC)[reply]
Yes, I did, and several times. And I got tired trying to make understand stubborn contributors (no offense meant) about the importance of color profile (among other points).
This is not about “fixing a problem” but about not creating one, as an additional action was taken to delete the color profile. It's about preserving the integrity and thus the quality of an image. The way Internet browsers react is already difficult to manage, together with an infinity of computers/monitors configurations an you have a big mess. Posting an image without color profile is just adding one more clue.
So what's the point? It simply doesn't make sense to insist trying to give useful information imho.
There are sooo many voters here who find many images so lovely, judging them after they even didn't displayed them at full (100%) size (or, at least, their comments make us think that), so why change that perfect workflow which leaded to so many prized images (here, of course), isn't it? (generally speaking, not personally)
Sorry for the bitterness I may transmit through this comment. Just my 2 cents, as usual. Sting (talk) 19:57, 7 April 2015 (UTC)[reply]
Only 1/2 cent more: “I'm sorry, but I don't see a problem with the colors. Everything looks natural to me.” And, sure, everybody here and elsewhere on the planet looks at your pictures through your monitor, right? Typical. Sting (talk) 00:00, 8 April 2015 (UTC)[reply]
I use several different monitor to look at my image and in non of them I see a problem and no one could really explain that exactly should be the problem here because of the cut out color profile. --Wladyslaw (talk) 04:39, 8 April 2015 (UTC)[reply]
  • It's already been explained: people might not see the colours you intend to present them. The difference might be subtle. Why? because the value of your colours doesn't have any reference, so software reading it can only guess and apply one by default (to simplify if I read value "green 60%", should I display 60% on a 0 to 300 scale _180_ or on a 0 to 200 scale _120_ ? Without the profile I can't tell). I also think that you did everything in sRGB, and if I were to write software, I would revert to sRGB by default, so it's possible (won't go as far as to say likely, but I mean it) that we see the right colours. Anyhow I personaly don't say I see the problem, but that you should prevent it by making sure your workflow doesn't strip away the color profile. It's probably something which takes you only a few minutes (shorter than arguing) and it's a big gain for everyone. - Benh (talk) 07:30, 8 April 2015 (UTC)[reply]
  • I too did point you the issue a while ago. - Benh (talk) 14:48, 8 April 2015 (UTC)[reply]
  •  Oppose JPG lacks colourspace information therefore colours are arbitrary. In particular, the degree of saturation and precise hue of each colour is uncertain. What shade of blue is that sky supposed to be. Or how vivid red is the tennis court in reality? Is that bright blue van in the middle really that colour? Without a colourspace, the red 255/0/0 pixel in a JPG is just an arbitrary number. Is it the most saturated red your monitor can display (many Macs will treat it this way) -- if so, then it will be radically different on a wide-gamut monitor compared to a standard-gamut monitor. Or the most red in the sRGB colourpsace (many applications will default to that, but perhaps your image was really AdobeRGB). Or will your colour-managed application simply pop-up a warning when you open the file (as Photoshop will do) saying "I have no clue what colours to display, could you guess for me". Wladyslaw, I don't see how you can claim ignorance of the problem, since if we have failed to explain it then a quick Google will turn up plenty websites that explain how this is simply an essential component of a well-formed JPG. Rather than repeating that it isn't a problem for you, perhaps you could make an effort to find out which part of your tool-chain is screwing up. Download EXIFTOOL or upload your images at each stage to Jeffrey Friedl's Exif tool and you should see where it is going wrong. It shouldn't be hard to fix, just the wrong option chosen somewhere. Oh, and seriously consider getting Adobe's "Creative Cloud Photography" program, your monitor will thank you for it :-). -- Colin (talk) 07:28, 8 April 2015 (UTC)[reply]
Try it, there is no better one IMO if you want a distortionfree image of the main part. Wladyslaw (talk) 14:50, 7 April 2015 (UTC)[reply]
  •  Neutral It's too dark on the right. Better weather needed! --Tremonist (talk) 14:35, 7 April 2015 (UTC)[reply]
  •  Oppose Unrealistic. Sorry -- Lothar Spurzem (talk) 20:35, 7 April 2015 (UTC)[reply]
  •  Oppose I cannot say much about the colors since I am travelling and don't have a calibrated monitor with me right now. The scene is nice but I really miss a portion on the left (left bank and part of the bridge), plus the weather was not of help, either with some sunny areas and others darker, the result of weather and crop looks unbalanced to me, sorry. Poco2 18:08, 8 April 2015 (UTC)[reply]
  •  Neutral If the photo should show the beauty of this city from a idealistic perspective (and this perspective is usually desired in presentations), it's technically not good. Then, the objections to the clouds/the weather are okay. But if the photo should show this city from a more realistic perspective, as seen there most days of the year (ie not always and everywhere in bright sunshine), then this photo is excellently made. --BlackIceNRW (talk) 12:12, 9 April 2015 (UTC)[reply]
Confirmed results:
Result: 1 support, 3 oppose, 4 neutral → not featured. /Yann (talk) 21:16, 11 April 2015 (UTC)[reply]