Wikimedia Commons

Commons:Featured picture candidates/File:Line scan photo of nine car BART C1 train in 2017.jpg/2

< Commons:Featured picture candidates‎ | File:Line scan photo of nine car BART C1 train in 2017.jpg

File:Line scan photo of nine car BART C1 train in 2017.jpg, not featured edit

Voting period is over. Please don't add any new votes.Voting period ends on 2 Apr 2018 at 10:09:44 (UTC)
Visit the nomination page to add or modify image notes.

 
 
Scrollable version of above

*  Support --Martin Falbisoner (talk) 10:17, 24 March 2018 (UTC)[reply]

for the time being... per Colin, sorry. --Martin Falbisoner (talk) 07:51, 25 March 2018 (UTC)[reply]
wrong colors -- Basile Morin (talk) 14:02, 24 March 2018 (UTC)[reply]
  •   Support --cart-Talk 10:57, 24 March 2018 (UTC)[reply]
  •   Support Great work! --Yann (talk) 11:14, 24 March 2018 (UTC)[reply]
  •   strong oppose Sorry to be the one, but well, the colours are just completely wrong. The image is somewhat darker, which might explain how you are happier with the US flag, and the white letters are fairly white, so I don't know enough about how your program figures out the coloured areas to know what went wrong. Look at the right end of the photo for the "Bay Area Rapid Transit Police" advert. The logo is yellow and blue. Look at the "BART ba" logo, which is black and blue. And of course the wheelchair disabled logo is blue. Scroll along a bit for the "Kaiser Permanente" advert. Their corporate colour is blue. The photo of a man in a wheelchair, has the man wearing a blue vest. And of course, the sky should be blue, not green, and sunlight glowing off the track should be golden, not magenta-orange. In the middle, the United Airlines advert should be blue and gold. In the previous version, the colours were much better, though the overall white balance was a little cool perhaps.
  • I suggest you try calibrating your software with some known colours (e.g. official corporate colours) or by taking a photo with your Sony camera and processing it using known good software, then comparing with your custom gear/software. Perhaps you've already done that, but then something has gone wrong here. There isn't much point in having 96MP of the wrong colours. Sorry.
  • And I should mention that to be fully correct, you really need to add the appropriate EXIF colourspace tag to the JPG and embed an sRGB colourspace profile. You can use exiftool to add this. I know you like free software, so you can get a fully free sRGB profile by downloading Argyll CMS. Their profiles are top quality too. -- Colin (talk) 12:56, 24 March 2018 (UTC)[reply]
  •   Neutral per Colin. He's right, the colors are not yet perfect. I do, however, salute your efforts in removing that sensor defect. They will definitely be of value to others in the future, even if it didn't turn the trick here. (And it is in any event a lot of fun to scroll this image to the left). Daniel Case (talk) 15:17, 24 March 2018 (UTC)[reply]
  •   Support The most impressive scroll I've taken in a while.--RaboKarbakian (talk) 02:35, 26 March 2018 (UTC)[reply]
  •   Oppose - I regret that I must agree with Colin's observations. -- Ikan Kekek (talk) 02:52, 26 March 2018 (UTC)[reply]
  •   I withdraw my nomination @Colin: Good observation! I admit I didn't look carefully at the regions you pointed out, as I was more concerned about denoising and the sharpness of the 4096 px tall image than about colour accuracy. Due to the long time needed to process the whole image, during development of the demosaicing algorithms I was mostly looking at a smaller test section which didn't include the regions you mentioned (I've since then updated my test set to include those regions). After reading your comment, I've started working on colour calibration. Here's a MATLAB script I hacked together over the weekend to perform colour calibration in linear colourspace. The strategy is to display a sequence of random colours (warning: flashing colours) using a well-calibrated sRGB monitor such as my calibrated Dell P2415Q with the camera pressed against the monitor without a lens. The line scan camera response is shown here for one of the pixels plotted against time. The reason for using a sequence of colours over time instead of a single photo of a test chart is because the calibration may vary from pixel to pixel. In this image, the top 1/9th of the image are true (ground truth) colours, the middle 4/9th of the image are raw uncalibrated colours from the line scan camera, and the bottom 4/9th of the image are the calibrated colours. From a visual inspection, the calibrated colours match the true colours quite well. Since the response of the line scan camera seems to vary across the length of the sensor, a separate calibration (3 × 4 matrix mapping raw RGGB values to linear sRGB values) is performed for each of the pixels across the sensor. Notice that pixel-to-pixel variations, which manifest as subtle horizontal stripes in the middle row, have been all but eliminated in the bottom of the image (the effect is more visible in the 300 MB full size lossless image, which is too difficult to share here). In this plot for one of the pixels, you can see that the calibrated sensor response is fairly linear -- not perfect, but OK for now. I'll work on incorporating the calibration results into my demosaicing program this week.
For future work, I may get a test chart and point the camera at each of the squares of the test chart in sequence using a known white light source, in case there are issues with my monitor's spectral emission. I also suspect that the camera's red channel gets much higher noise in the top half of the image when the camera heats up. This would explain why the shadows in the top half of the image are so reddish, a phenomenon which I've also observed in other line scan photos.
p.s. as for the BART ba logo, I have no idea why the "b" on car 349 isn't black. It's black on all the other cars. I totally agree about the blue being too green, and the yellow being far too red, though.
p.p.s. for the original upload, I manually adjusted the white balance and used a highly nonlinear tone curve to raise the shadows compared to the unprocessed version. The second version was automatically generated. dllu (t,c) 01:04, 27 March 2018 (UTC)[reply]
dllu I second Martin's comments. Be careful with your monitor -- the colours may shift as it warms up; the monitor display itself may not be consistent in brightness across the screen; pixels viewed not straight-on may be shifted in colour/contrast/brightness. Wrt calibration, perhaps you can explain more how your monitor is calibrated on your talk page, if you want to talk more there. -- Colin (talk) 07:32, 27 March 2018 (UTC)[reply]
@Colin, you won't believe what a stupid bug it was that caused the inaccurate colors. I can't believe it took months for me to realize this. The problem is that I accidentally replaced the green channel with a blue channel! It was a one letter typo! [1] No wonder all the yellows became red! here is an updated test image where you can see the yellows are correct. I will continue to tweak and improve things... dllu (t,c) 10:27, 30 May 2018 (UTC)[reply]
dllu, thanks for the update and improved image. That's quite a radical defect that I'm quite surprised it even generated an image anyone might think was normal. Perhaps some FPC regulars should get their colour vision tested :-). Actually, when testing colour profiles on my PC, I created a profile with the red and green primaries switched. If you install it on your PC as the profile of your monitor, then it shows up very visibly which software is correctly using the display profile, and which ignore it (Internet Explorer, for example). If embedded into a JPG, it shows up which software uses the embedded profile, and which ignore it (some older versions of Android or iOS). You can see such a JPG here and a simulation of what it looks like with bad software here and there is no mistaking the effect. If only you'd switched red and green, rather than blue and green. -- Colin (talk) 10:43, 30 May 2018 (UTC)[reply]
Confirmed results:
Result: 4 support, 2 oppose, 1 neutral → not featured. /--cart-Talk 16:56, 27 March 2018 (UTC)[reply]
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Featured_picture_candidates/File:Line_scan_photo_of_nine_car_BART_C1_train_in_2017.jpg/2&oldid=303776894"