khanosu Posted January 8, 2007 Share #41 Â Posted January 8, 2007 Advertisement (gone after registration) Mark, if the reference pixels in no way effect the actual data that is written to the non reference pixels even when they are getting unexpected light that should not be there then I agree with you. Your solution should be doable in firmware at the cost of some processing time after the shutter closes (wonder if that will be an issue?). I agree that the reference pixel value should be read as soon as possible after the data is written to the non reference pixels. On the other hand I am a bit worried that light is somehow reaching the reference pixels and this light has to be bright (over 4 stops) so the reference pixels might be reaching blooming level even though there must be a baffle to protect the reference pixels; all depends on how the light is circumventing the baffle. Â Â Furrukh Link to post Share on other sites More sharing options...
Advertisement Posted January 8, 2007 Posted January 8, 2007 Hi khanosu, Take a look here Has anyone received a fully corrected M8 back from being "upgraded"?. I'm sure you'll find what you were looking for!
marknorton Posted January 8, 2007 Share #42 Â Posted January 8, 2007 Furrukh, I'd only advocate taking the second image if the data from the first has been determined as bad, not all the time. Â Doing a sanity check on the reference pixel data will take no time at all but as I explained to HC, doing the second capture will take 250mS plus the "exposure" time so you wouldn't want to do it all the time, only if the sanity check comes out bad. Â If there's something in the light angles which is somehow getting under the masking of the reference pixels and blowing them sky-high I agree this will not work, but then I would say this is a sensor design issue. Â If, on the other hand, the masking simply acts as an 8 stop ND filter instead of being completely opaque, extreme over-exposure will give bad black references for the affected rows and cause the banding. In this situation, I can't see the reference pixels reaching blooming level, though the pictures out of the airplane window into the sun might be doing this. I assume by the way, that the reference pixels have the same anti-blooming solution - the lateral overflow charge drain - as the non-reference pixels. Â In the end, we don't know, it would be interesting to see the firmware source code! Link to post Share on other sites More sharing options...
khanosu Posted January 8, 2007 Share #43 Â Posted January 8, 2007 Hey Mark, thanks for working out all the relevant numbers. Your suggestion has given us hope. This is doable in firmware without excessive processing time! The best part of this solution is that it is simple, like all good solutions. The people at Leica are already familiar with this sort of thing so they should be able to squeeze in the lines of code in some upcoming firmware. Â Furrukh Link to post Share on other sites More sharing options...
marknorton Posted January 8, 2007 Share #44 Â Posted January 8, 2007 Thanks Furrukh, I'm off to bed, it's 4:50am here! Link to post Share on other sites More sharing options...
khanosu Posted January 8, 2007 Share #45  Posted January 8, 2007 Hope you are not working tomorrow  Good night! I will head to bed also although it is only midnight here.  Furrukh Link to post Share on other sites More sharing options...
rvaubel Posted January 8, 2007 Share #46  Posted January 8, 2007 Hope you are not working tomorrow  Good night! I will head to bed also although it is only midnight here.  Furrukh  Anybody still awake? It's only 9:20 here (Berkeley) and I'm still thinking  Rex ..arf.. ARF! Link to post Share on other sites More sharing options...
scott kirkpatrick Posted January 8, 2007 Share #47  Posted January 8, 2007 Advertisement (gone after registration) Anybody still awake? It's only 9:20 here (Berkeley) and I'm still thinking  Rex ..arf.. ARF!  Yeah, I'm up now. Went to bed at 2:30 (0030 UTC) and missed all the interesting discussion.  I like Mark's idea because it lets the camera solve the problem with fresh valid data when an error condition is detected, rather than trying to patch it up locally. Also, notice that this problem produces a half-frame streak. That's a bad sign, because it means that the false levels are set very early, as the data streams off the chip through dual pathways and before it gets into a buffer where full frame corrections like WB or noise cancellation are applied. We don't know the extent to which firmware, which runs on a signal processer that is two chips away from the CCD, can affect the data at this stage. The fact that slow exposures don't seem to have the sun-at-the-edge streak (please check, someone) suggests that the bad shift can at least be turned off, allowing the dark frame gathered after the shot to be used instead to set levels.  I was thinking that there might be a problem if the camera is mounted on a tripod, so that the sun-at-the-edge condition happens repeatedly, but since the only effect is that each exposure is delayed a fraction of a second (and if you are using a tripod, what's the hurry), it won't leave you in a situation where the camera won't take the picture. Anybody see any other catches?  Well maybe -- dark frame subtraction is enabled when the shutter speed is low, and this can be decided before the shutter is pressed, based on shutter speed and TTL light meter reading. This allows an electrical signal to be sent to the A/D and signal accumulating chip (the switchyard) that is next to the CCD in time to affect image capture once the shutter is pressed, telling it to ignore the reference pixels and use a full-frame reference for the black point. It may be that invalid reference pixels can only be detected after the image has been extracted and reference set on the fly. If that is the case, then the only solution for this problem is to allow dark frame subtraction to be demanded by a menu entry in time for the next exposure. (That's clunky but not impossible. I think my E-1 has such an option.)  scott Link to post Share on other sites More sharing options...
scott kirkpatrick Posted January 8, 2007 Share #48 Â Posted January 8, 2007 Sean Reid has kindly hosted my summary of the analysis of his tests, using matlab and plotting light intensity values across the frame, of the overall and red vignetting ("cyan drift") with firmware 1.06 and the 28mm Summicron ASPH, Elmarit ASPH, and CV28/3.5 lenses, with and without firmware correction. It can be seen on his site, linked in at the very end of the article on 28mm lenses. It raises some questions which may be worth keeping an eye on as the M8 firmware evolves. Â It's way too long to run as a forum entry, but if there are questions (and if anyone is still interested) I'll take them here by PM or we can start another thread. Â cheers, Â scott Link to post Share on other sites More sharing options...
marknorton Posted January 8, 2007 Share #49 Â Posted January 8, 2007 Scott, I certainly agree they should not be applying adjustments to the data on the fly as it comes out of the ADC, but rather accumulate all the raw values in a buffer from which they can make a decision whether to go for a second image capture and then use the second image data to update the first. Â SInce they already have the processing in place to do the second image capture, the software needs to be reorganised so that the decision to do it can be influenced by that initial look at the first image as well as the exposure factors you mention and then the combining of the two images would depend on why the camera went for the second image. Â I am sure there are wrinkles such as what to do if the camera wants a second image to correct reference pixels AND to reduce noise but we're trying to poke around in a black box here and without more information, those wrinkles will have to be left to the Leica/Jenoptik engineers. As always, the combined skills here will be more than ready to help! Link to post Share on other sites More sharing options...
jaapv Posted January 8, 2007 Share #50 Â Posted January 8, 2007 I would like to thank you guys. It is really interesting to gain an insight into the workings of sensor technology. An unexpected side-effect of owning a M8 . Actually I think Leica should consider putting you on the payroll as external consultants Link to post Share on other sites More sharing options...
marknorton Posted January 8, 2007 Share #51 Â Posted January 8, 2007 I've put together an email at Sean's suggestion summarising our collective thoughts for him to forward on to Leica. I'm also having it translated into German... Link to post Share on other sites More sharing options...
marknorton Posted January 8, 2007 Share #52  Posted January 8, 2007 Actually I think Leica should consider putting you on the payroll as external consultants  LOL, I wonder what daily charge rate - in that well-known unit of currency, the Noctilux - they would wear... Link to post Share on other sites More sharing options...
marknorton Posted January 11, 2007 Share #53 Â Posted January 11, 2007 Well, I sent in my German translation to Leica explaining the thought behind the firmware solution to the banding problem. Quick as anything, back came a response from a senior person in Leica, thanking me for my effort, complimenting me on my knowledge of digital camera technology (!) and saying that he had passed the information to the M8 development team for evaluation. Â They may well dismiss it, but at least the suggestion is in the frame. Seems to me Leica are listening and welcome constructive input. Link to post Share on other sites More sharing options...
bobrudolph Posted January 11, 2007 Share #54 Â Posted January 11, 2007 What a wonderful surprise, my M-8 on the doorstep this morning. I'm so pleased. Facts: Sent via three day delivery DHL on 12-12-06 to Solms Received via DHL 01-11-07 And the Solms facility was closed for at least one week of that time. I've missed this camera as if it were the best of friends. Bob Link to post Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.