Commons:Featured picture candidates/File:141227 Berliner Dom.jpg

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

File:141227 Berliner Dom.jpg, featured[edit]

Voting period is over. Please don't add any new votes.Voting period ends on 17 Jul 2015 at 21:29:33 (UTC)
Visit the nomination page to add or modify image notes.

The west front of the Berlin Cathedral in the early morning.
A Lightroom 6 and Mediawiki metadata viewer discussion
  • Several reasons. I tried to avoid the Mediawiki-LR6-metadata-bug (what didn't work that way, I have to assume). Then I'm often doing HDRs and if you tell LR6 to include the metadata it simply uses the metadata of one of the LDR shots for the HDR version, which is quite confusing. In the end I don't think that the camera settings are that important. If someone wants to know them - feel free to ask. It's not a secret. --Code (talk) 16:37, 9 July 2015 (UTC)[reply]
BTW: I am using Metadata Wrangler in combination with Lightroom. With this little addon you can make very fine adjustments which metadata are included into the exported image. --Tuxyso (talk) 05:47, 11 July 2015 (UTC)[reply]
I also recently started using the metadata wrangler. It has another positive side effect: It encodes the EXIF in a manner which the mediawiki metadata viewer understands how to decode, thus mitigating the LR 6.1 EXIF export issue. -- Slaunger (talk) 18:33, 12 July 2015 (UTC)[reply]
What is the LR 6.1 EXIF bug anyway? I've only just upgraded from 6 to 6.1 and haven't uploaded anything new yet... what should I be aware of? Diliff (talk) 19:53, 12 July 2015 (UTC)[reply]
Diliff, see Commons:Village_pump/Archive/2015/04#Error_in_metadata_viewer?, though the exiftool work-around on that page is not advised as it removes some essential information such as colour profiles. I think Slaunger has an updated version somewhere. I don't think it's a flaw with LR 6.1, just an incompatibility due to MediaWiki making some assumptions. If you use Metadata Wrangler it goes away, plus you get to choose what profile information is embedded. I don't know if there are also issues with Photoshop exports too. -- Colin (talk) 06:56, 13 July 2015 (UTC)[reply]
I still don't really understand the problem. The Link you provided dates back to April before LR6.1 was released so if it does in some way relate to both LR6.0 and LR6.1, I should have had the same problem in the past too, but I haven't noticed anything wrong. Also, since the examples that Slaunger provides have now been fixed, I'm still no closer to really understanding what has gone wrong with the EXIF for him. He says the metadata fields are 'wrong' but in what way? Corrupted? Missing? It's hard to understand the problem if I can't see an example of it still happening... In any case, I haven't noticed any problems with any of the images I've uploaded. Diliff (talk) 08:00, 13 July 2015 (UTC)[reply]
Here is an example (until someone fixes it): The problem is that the fields are mixed up, i.e. the value for one field was attributed to the title of a different one. — Julian H.✈ 08:16, 13 July 2015 (UTC)[reply]
Ahh thanks Julian. Now I see it. And now I can see that it's also affected my images too, although I hadn't actually realised. In my image, The 'author' and 'copyright holder' should have the same information as each other, but somehow it's done the same thing as as in the example you've provided. So do we have any concrete information about whether it only affects LR6.1 or LR6.x? Slaunger's post on the Village Pump received the reply that it is "triggered in files where the values for the exif tags come before the list of tags contained in the file". I assume therefore that Lightroom is responsible for mixing the tags up, and that the EXIF wrangler puts them back in the right order regardless of whether you strip any EXIF data out of it? Diliff (talk) 08:29, 13 July 2015 (UTC)[reply]
Diliff It was a mistake that I wrote LR 6.1. The first time I experienced this problem was in late April 2015, which correlates well with the release of Lightroom 6.0. I know it is an issue when using both version 6.0 and 6.1. It is not an actual Lightroom bug, but in these versions Lightroom organises by default the exif data in a (valid) manner, which is however not taken into account by the Mediawiki metadate viewer. Since it does not appear that a fix for the Mediawiki bug is close to being deployed, the best mitigation is to rncode the Exif data in a manner, which the Mediawiki metadata viewer is capable of decoding. For th time being I am aware of two possible mitigations. One is to use an exiftools script, which re-encodes Exif in the problematic jpg file, such that it can correctly decoded by the mediawiki metadata viewer. I recently used such a script to correct about 50 uploads I had made since late April 2015. The other solution is to install the metadata wrangler plugin by Jeffrey Friedl for Lightroom (donateware), which uses (I think) exiftools under the hood. This also has the advantage of giving you much more detailed control over your exif data, like suppress the Lightroom Development settings, or suppress personal information or serial numbers of lens and camera. Since this issue is popping up recurrently, I think I will write down a few instructions. -- Slaunger (talk) 17:24, 13 July 2015 (UTC)[reply]
Diliff: I tried to summarize the situation and describe two mitigation methods here: User:Slaunger/Mitigating Mediawiki Metadata Viewer Bug. -- Slaunger (talk) 18:33, 13 July 2015 (UTC)[reply]
  •  Support --XRay talk 17:00, 9 July 2015 (UTC) (BTW: There is a workaround for the EXIF data using the tool exiftool. Please ask if you need the parameters.)[reply]
  •  Support. Very nicely captured. Although why such a tight crop at the bottom? Did you remove some distracting elements from the foreground? Otherwise it feels a little unbalanced but not a big problem. Diliff (talk) 18:48, 9 July 2015 (UTC)[reply]
  • Thank you, Diliff. No, I did not remove anything. The crop comes from the perspective correction. I will try to give a little more space at the bottom when I'm back at my computer tomorrow. I'm saving up for the Canon TS-E 24mm f/3.5L II to avoid these problems in the future but I think this will still take some time. --Code (talk) 19:21, 9 July 2015 (UTC)[reply]
  • I don't really understand why perspective correction would have resulted in a tight crop at the bottom though. Perspective correction usually has no significant effect on the crop at the top and bottom. It usually only affects the sides because they need to be distorted outwards to straighten the inward leaning verticals. I personally think stitching is a much better option than a tilt-shift lens, but if you think it's a better option for you, great and I look forward to seeing what you do it with. :-) Diliff (talk) 19:30, 9 July 2015 (UTC)[reply]
  • Hm. If you want to preserve the aspect ratio then perspective correction affects also the bottom, or am I wrong? But as I said - I will give it a try tomorrow. Concerning the TS-lens: Shifting is not the only thing you can do with it ;-) I think it's a very interesting photographic toy in many respects. We will see. --Code (talk) 19:49, 9 July 2015 (UTC)[reply]
  • Well, you can't correct the perspective without affecting the aspect ratio. Correcting the verticals increases the height of the image because it increases the distortion. If you have to perserve the aspect ratio then yes I guess you have to crop something, but that's not a requirement of perspective correction, that's a choice. As for the TS lens, yes I suppose there is also the ability to shift the plane of focus which stitching cannot do, but I don't think the advantage of this is worth the cost of the lens, but that's just my opinion. :-) Also, I just noticed that there's a star shaped white patch just above the doorway. It doesn't look like it's part of the scene. Do you know what it is? Diliff (talk) 20:50, 9 July 2015 (UTC)[reply]
  • OK, but I'm still confused by two things about it. I see a darker shadow on either side of the star, which means that it is being lit up by the two flood lights. But it is completely white without any texture, and yet everything else around it like the white signs below it are much darker, but they should be lit up similarly to the star, I would expect. The star seems to be 'cut out' and replaced with a white shape. It seems strange. Maybe I'm making a big deal out of nothing though. Diliff (talk) 10:12, 10 July 2015 (UTC)[reply]
  • I'm not sure it's illuminated from the inside though (although I could be wrong), because it doesn't have any lens stars or light bleeding like every other source of light in the scene does - it's razor sharp. When you say "isn't it always a balance between losing more on the side or losing more on the bottom?", I'm not sure what you mean. Do you mean specifically during perspective correction? No, (proper) perspective correction follows a mathematically precise formula. However, to do it properly, the software would need to know the focal length/angle of view to know how to apply the distortion (because a 17mm focal length image needs different perspective correction to a 50mm image). If you do perspective correction manually, you can approximate these calculations but it's largely guesswork. This is an example of mine to prove/explain what I mean. Here is a hand-held panorama before and after perspective correction. I've left it uncropped so you can see how the boundaries of the image are shifted. And now here is the cropped before and after photo so you can see where the crop has removed part of the image. You can see that it is only the left and right sides, not the top and bottom that have been affected by the perspective correction. It isn't a choice between cropping the sides or the bottom. There isn't an 'alternative' way to correct the perspective. Diliff (talk) 12:45, 10 July 2015 (UTC)[reply]
  • What I meant is that the result of the mathematical operation of correcting the perspective is (roughly) a trapezoid, and cropping the trapezoid to a rectangle necessarily means cutting something off. Whether that's the bottom or the side is up to the author. — Julian H.✈ 13:04, 10 July 2015 (UTC)[reply]
  • Well ok, yes technically that's true but in practice, because of the shape of the trapezoid, you have to crop 3 or 4 pixels from the top or bottom for every pixel you save on the sides so it's rarely practical. It's much better to leave enough space around the sides so that you don't have to compromise anything during perspective correction. In this case, I can't see why the crop at the bottom should be so tight, there's plenty of space on the sides. Diliff (talk) 13:09, 10 July 2015 (UTC)[reply]
  • Wow, impressing. Are you going to upload it as a derivative? I would like not to replace this one because the TV tower is somehow part of the arrangement (as Livio said). --Code (talk) 19:49, 9 July 2015 (UTC)[reply]
Confirmed results:
Result: 17 support, 0 oppose, 0 neutral → featured. /Laitche (talk) 05:41, 14 July 2015 (UTC)[reply]
This image will be added to the FP gallery: Places/Architecture/Religious_buildings
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Featured_picture_candidates/File:141227_Berliner_Dom.jpg&oldid=296807591"