Has anyone received a fully corrected M8 back from being "upgraded"?

[stunsworth]

Advertisement (gone after registration)

It works the other way too. When I was shooting with my R8 I kept forgetting to wind on the film :-)

[rvaubel]

It has been quite easy to reproduce (2 shots) and it is ugly. Here is an example :

 

Pascal

 

Looking back on your Permalink #16 black band photo, this is a classic example of the perimeter black band problem. Things to note

 

* The band is caused ENTIRELY by the part of the bulb that is in the perimeter band. It doesn't look that way, but it is.

 

* the green/black band is only the width of the most severely blown out part of the bulb. Highlights in the perimeter band must be VERY blown out to cause banding.

 

All in all, the conditions that cause this banding are pretty rare. When I FINALLY get my camera, I won't consider letting it out of my hands for a problem like this. Hopefully, it can be solved in firmware but if not, I'll wait until Solm has cleared its inventory of "fixed" cameras before adding to their "upgrade" backlog.

 

Rex

[pascal_meheut]

Yes, It did not appear in any real pictures I shot. I'm quite happy with the M8 now especially when using the lens I have a 486 filter for.

[larry]

I wonder if some sensors are more prone to this problem than others? I've tried my best to make this happen, but with no luck. (Actually, I feel lucky that it hasn't happened.)

 

Larry

[marknorton]

However you look at it, the row data coming off the sensor in this situation is invalid and the firmware's action on it leads to incorrect results. The hope of fixing it in firmware hinges on being able to recognise the invalid data and substitute valid data in its place. Tough to do IMHO, but if the alternative is a sensor replacement recall, there's incentive enough to try.

[carstenw]

Ack, my returned camera also does it easily. I have not seen it in any of my own shots, but tilting my desklamp up and shooting 4 pictures moving the centre of the bulb progressively off the picture, I got exactly what Pascal got.

[khanosu]

Advertisement (gone after registration)

Welcome to the club, Carsten. You can see a whole assortment of pictures form various camera, new versions and old versions, that exhibit this. You can make household lamps do this, or light in a fireplace or the sun outside.

 

http://www.leica-camera-user.com/digital-forum/12233-black-horizontal-band.html

 

You have plenty of company so don’t feel bad

 

Furrukh

[carstenw]

Ack ack ack. I hope this is firmware fixable. Ack.

 

It would be almost impossible to systematically avoid it when taking pictures in certain kinds of situations, such as concerts. I hope that it will be fixed. Has anyone tried this with other digital cameras?

[khanosu]

Carsten, I tried some Canons (5D, 1DM2, 1DsM2) and they did not exhibit this banding. I would really have been surprised if they had exhibited this problem given that their teething days are long over.

 

Furrukh

[ho_co]

However you look at it, the row data coming off the sensor in this situation is invalid and the firmware's action on it leads to incorrect results. The hope of fixing it in firmware hinges on being able to recognise the invalid data and substitute valid data in its place. Tough to do IMHO, but if the alternative is a sensor replacement recall, there's incentive enough to try.

Mark--

See quotation from p 7 of Kodak's MTD/PS-0962 Rev. 3.0 (KAF-10500 specs) below.

 

Last sentence says the "full dark lines" *may be used as a dark reference*. To me that implies that there are various possible approaches to the task, and one might decide to use only, say, the outside three rows.

 

In other words, it may be that the M8's sensor shows this defect because the inner rows of dark pixels are flooding the neighboring pixels. If so, perhaps those rows could be cut out of the circuit and only data from the outer rows be used as dark pixels.

 

That amounts to saying, "Hey, maybe you guys could look at fewer dark pixels, namely the ones farthest from the image, and eliminate all influence of the (not-always-so-)dark pixels directly at the image edge."

 

Someone who understands how pixels are read could possibly say whether that's even possible. Maybe overloaded pixels will contaminate adjacent pixels before any interpretation is made? If not, maybe the solution *could* be made in firmware.

Welcome, dear visitor! As registered member you'd see an image here…

Simply register for free here – We are always happy to welcome new members!

[marknorton]

However you look at it, the row data coming off the sensor in this situation is invalid and the firmware's action on it leads to incorrect results. The hope of fixing it in firmware hinges on being able to recognise the invalid data and substitute valid data in its place.

 

So, here's my solution to the problem which I think will save Leica's bacon...

 

A three stage process as I explained above to:

 

- recognise the data is bad

- obtain good data

- use it

 

1. Do a check on the reference pixels to determine if there is bad data there. This could be any or all of:

 

- different from the last shot

- spread of values, minimum to maximum

- clusters of unrepresentative values

 

Either way, they need to develop a check to say, yes it's good, no, it MAY be bad and if they're not sure, err on the side of caution and say, BAD.

 

2. Then, if the data is deemed bad, do another image capture with the shutter closed, as they do when doing the noise reduction after a long exposure. This way, they know they are getting true black reference pixel values.

 

3. Use the reference pixel values from the second image capture instead of the ones from the first image capture.

 

Job done.

[ho_co]

Mark--Looks perfect.

 

One could simplify your suggestion at least temporarily thus: Subtract a dark frame for *all* shots instead of just the longer exposures. The effect would be virtually transparent, since the only change would be on the shorter exposures.

 

That temporary fix should be easy to implement and might could be installed in next firmware. Then if Leica wants to find a better solution, they could go on working on the actual problem and install the permanent fix in a later firmware update. At which point everyone would respond, "gosh, the camera seems to be able to process a little faster than with the previous firmware!"

 

Would that be feasible?

[marknorton]

HC, with the current noise reduction, all the data is deemed valid so subtracting one from the other makes sense. In this new scenario, we've determined part of the data is bad and are replacing it instead, so there's a difference there.

 

I don't think this should be done all the time - the sensor takes a finite time to capture and readout - 250mS + exposure time - so to do it all the time would really slow things down.

[rvaubel]

So, here's my solution to the problem which I think will save Leica's bacon...

 

A three stage process as I explained above to:

 

- recognise the data is bad

- obtain good data

- use it

 

1. Do a check on the reference pixels to determine if there is bad data there. This could be any or all of:

 

- different from the last shot

- spread of values, minimum to maximum

- clusters of unrepresentative values

 

Either way, they need to develop a check to say, yes it's good, no, it MAY be bad and if they're not sure, err on the side of caution and say, BAD.

 

2. Then, if the data is deemed bad, do another image capture with the shutter closed, as they do when doing the noise reduction after a long exposure. This way, they know they are getting true black reference pixel values.

 

3. Use the reference pixel values from the second image capture instead of the ones from the first image capture.

 

Job done.

 

I agree that your fix will work. However, a very simple test of valid black reference values would be if there are an excessive amount of overflow values. The algorythm would discard the invalid results and substitute a dark frame exposure.

 

However, I have often wondered if the reference pixel area of the sensor is also used to determine white balance. That could explain some of the goofy white balance values we are getting. In other words, the perimeter pixels could be contaminating color balance information from blown pixels? Only Kodak knows the answer to this one, but I have my suspicions.

 

Rex

[marknorton]

Rex, the goal behind doing a second image capture was to avoid the need for the firmware to be ultra-smart in handling different imaging situations. You could certainly blank out bad values or interpolate across them but you could end up with so much correction that it's no longer valid. A simple check to say, "whatever it is, it's a mess" and get a new set of black references avoids the need to analyse the image in detail.

 

Don't know about the white balance - as you said in an earlier post, this only happens when there's extreme over-exposure and the white balance is off in normally exposed images.

 

My understanding is that whilte balance is determined by looking at the R G B values and effectively coming up with a colour temperature from that.

[khanosu]

Hi Rex and Mark,

 

Does the data in reference pixels in some way control (via hardware) in real time the data that is actually written into the rows that use these reference pixels? Some type of real time normalization of incoming data so it fits properly into the bins? If that is the case then the data written into the effected rows controlled by the effected reference pixels would be corrupted.

 

Furrukh

[khanosu]

... or can the excess charge in the effected reference pixels spill into the adjacent pixel rows and corrupt the data in those rows?

 

Furrukh

[khanosu]

... I guess what I am driving at is that we are assuming that the data in the non reference pixels is valid while the data in the effected reference pixels is invalid. My question is: do we know for sure that the data in the rows that use the effected reference pixels is valid and has not been by some means contaminated by the excess and unexpected charge in the reference pixels?

 

Furrukh

[marknorton]

Furrukh, as HC's post and snip from the Kodak suggests, these reference pixels are the same as the "live" ones except for not being exposed to light, so the voltage difference from live pixels is attributable to the light by taking the difference.

 

My assumption is that this can be used to anchor the sensor to a black reference as environmental factors such as supply voltage and temperature change and also to counteract any changes in the sensor which take place over time due to ageing.

 

If the black reference pixels have wild values, all the live pixels in that half row are going to be referenced to an invalid black level and the result is the sort of streaking we're seeing.

[Advertisement]

Hallo,

Look here: Interesting Leica gear

[marknorton]

... I guess what I am driving at is that we are assuming that the data in the non reference pixels is valid while the data in the effected reference pixels is invalid. My question is: do we know for sure that the data in the rows that use the effected reference pixels is valid and has not been by some means contaminated by the excess and unexpected charge in the reference pixels?

 

Furrukh

 

I don't think the charge in the reference pixels will be at the blooming level - they are in any case covered by the masking and my suggestion is that this is not completely light tight so that what light makes it through under extreme over-exposure is lifting the dark reference level which affects all the non-reference pixels in the row not because of charge overflowing into them but because of the image processing which attempts to normalise the pixels in the rows to the now incorrect black reference.

 

I may be completely wrong of course...