Bad Pixels: Unusual Behaviour

SkepticaLee

50

« on: 15 / October / 2013, 13:26:12 »

Advertisements

I have recently observed an unusual phenomenon concerning the behaviour of bad pixels: sets of them sporadically turn up on my raw images (DNG 1.1) only to disappear again. I am using the latest version of CHDK on a PowerShot SX120 IS.

I have documented some of the technical details (including sample images and files) at www.skeptic.de/chdk/bad pixels/index.htm - please read this before commenting.

This raises a number of questions to which I hope to find the answers to on this forum:

How does CHDK determine what pixels are bad?
Are the algorithms that CHDK uses to convert the really raw data (bits and bytes) into DNG files sufficiently accurate?
Has anyone noticed this happening on their camera as well? Can you provide further examples?
What correlations are there between the pixels determined to be bad by CHDK and those determined to be bad by the method described on my site?
What correlations exist between bad pixels determined by my method in different image pairs?

If you would like further investigation or analysis on my part, please ask; if it is easier to chat, mail me and we can contact one another on facebook or skype

Logged

lapser

1093

Re: Bad Pixels: Unusual Behaviour

« Reply #1 on: 15 / October / 2013, 14:40:34 »

reyalp can answer your questions in detail, I'm sure. But I would suggest that you try similar tests with dng 1.3 files, and load them with Adobe software. Dng 1.3 doesn't use badpixel.bin, so I'm interested in reyalp's explanation of how Dng 1.3 raw saving determines which pixels are bad. Dng 1.3 uses an opcode to specify a bad pixel, and the Adobe software replaces the specified bad pixels with interpolated values from neighboring pixels, as I understand it.

I think that only Adobe software can handle dng 1.3, but there may be updates to other software. Maybe someone knows what works today.

I suspect that the change in number of bad pixels you're noticing may be related to temperature. CHDK can display the sensor temperature, so you should see if that correlates to your results.

Logged

EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

philmoz

3450

Re: Bad Pixels: Unusual Behaviour

« Reply #2 on: 15 / October / 2013, 15:37:00 »

Quote from: SkepticaLee on 15 / October / 2013, 13:26:12

I have recently observed an unusual phenomenon concerning the behaviour of bad pixels: sets of them sporadically turn up on my raw images (DNG 1.1) only to disappear again. I am using the latest version of CHDK on a PowerShot SX120 IS.

I have documented some of the technical details (including sample images and files) at www.skeptic.de/chdk/bad pixels/index.htm - please read this before commenting.

This raises a number of questions to which I hope to find the answers to on this forum:

How does CHDK determine what pixels are bad?
Are the algorithms that CHDK uses to convert the really raw data (bits and bytes) into DNG files sufficiently accurate?
Has anyone noticed this happening on their camera as well? Can you provide further examples?
What correlations are there between the pixels determined to be bad by CHDK and those determined to be bad by the method described on my site?
What correlations exist between bad pixels determined by my method in different image pairs?

If you would like further investigation or analysis on my part, please ask; if it is easier to chat, mail me and we can contact one another on facebook or skype

CHDK only deals with dead pixels, where the value recorded on the sensor is 0.
These are also mapped out by the Canon firmware and do not usually appear in a JPG image.
The number of dead pixels found by CHDK can be affected by the ISO setting, especially on CMOS sensors. It's best to run the bad pixel generation at the highest ISO, although this may not work on some cameras, in which case use the next highest.

Stuck or hot pixels (non-zero values) can be affected by age, temperature, ISO and long shutter speeds - CHDK does not provide any method of dealing with these.

Phil.

Logged

CHDK ports:
sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
g12 (1.00c, 1.00e, 1.00f & 1.00g)
sx130is (1.01d & 1.01f)
ixus310hs (1.00a & 1.01a)
sx40hs (1.00d, 1.00g & 1.00i)
g1x (1.00e, 1.00f & 1.00g)
g5x (1.00c, 1.01a, 1.01b)
g7x2 (1.01a, 1.01b, 1.10b)

SkepticaLee

50

Re: Bad Pixels: Unusual Behaviour

« Reply #3 on: 15 / October / 2013, 15:44:14 »

lapser raises two issues: DNG 1.3 and temperature dependence.

DNG 1.3. About a year ago I was made aware of bad pixels turning up in DNG 1.3 by Paul Admiraal on the facebook CHDK User group page and discovered that shots that I had taken with DNG 1.3 were similarly speckled. Unfortunately opening them with the Adobe software had no effect on the bad pixels.

Temperature dependence. In the sunset series, the camera had been operating on its own for about 40 minutes before the first set of bad pixels turns up, and then another 7 minutes before the final set turns up (the series terminates a few minutes later). In this sequence the camera can only be cooling off as the sun sets, if there is any temperature difference at all - mild late summer evening, directly on the coast in New Zealand - I think it is unlikely that there was any change in the camera temperature at all. If temps were decreasing then at least the noise would decrease, but why would bad pixels increase?

For the Totaranui exposure bracket series taken the next day, the temperature was probably about 5° higher than at the start of the sunset sequence, yet the bad pixels seem to show a patter similar to that appearing in the middle of the sunset sequence. Sorry, doesn't make any sense in terms of being temperature dependent.

Thanks anyway.

Logged

ahull

634

Re: Bad Pixels: Unusual Behaviour

« Reply #4 on: 15 / October / 2013, 17:20:38 »

I don't have a simple answer to explain this particular scenario, but I can think of a number of possibilities.

Many other external influences can cause unwanted artifacts in the image.

Not sure which if any apply in this case.

1) Static build up.
2) Ionising radiation.
3) Electomagnetic and electrostatic fields.
4) Particular wavelengths of radio energy.
4) Dust.

These are just some of the possible sources of so called "image noise" and are in addition to so called dead and hot pixels.
In some cases noise can be non random, in the sense that some pixels may be more prone to a particular external factor than others, perhaps due to microscopic differences in circuit element size, conductor geometry (casing the element to act as a tuned circuit, prone to excitation by particular radio frequencies), variation in the distribution of ions in the semiconductor material and so forth.

Some of these factors can be eliminated or reduced of course, by for example Faraday screening the camera, and the CCD element in particular, cooling, maintaining a sterile internal environment within the camera and so forth.

Logged

lapser

1093

Re: Bad Pixels: Unusual Behaviour

« Reply #5 on: 15 / October / 2013, 19:17:55 »

Quote from: SkepticaLee on 15 / October / 2013, 15:44:14

Sorry, doesn't make any sense in terms of being temperature dependent.

The sensor temperature is what's relevant, not the ambient temperature. The sensor gets hotter the longer it's active, so long exposures and video raise the sensor temperature. CHDK shows the sensor temperature as a CHDK menu option, so you would need to activate the display option and log the temperature during your experiments. There's also a script function that gets the sensor temperature.

Logged

EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

reyalp

14117

Re: Bad Pixels: Unusual Behaviour

« Reply #6 on: 15 / October / 2013, 23:19:37 »

Quote from: philmoz on 15 / October / 2013, 15:37:00

Stuck or hot pixels (non-zero values) can be affected by age, temperature, ISO and long shutter speeds - CHDK does not provide any method of dealing with these.

To clarify, CHDK does not provide any *automatic* way of dealing with this. You can use the manual badpixel list to patch them. http://chdk.wikia.com/wiki/Badpixel_removal

Logged

Don't forget what the H stands for.

reyalp

14117

Re: Bad Pixels: Unusual Behaviour

« Reply #7 on: 15 / October / 2013, 23:25:39 »

Quote from: SkepticaLee on 15 / October / 2013, 15:44:14

lapser raises two issues: DNG 1.3 and temperature dependence.

DNG 1.3. About a year ago I was made aware of bad pixels turning up in DNG 1.3 by Paul Admiraal on the facebook CHDK User group page and discovered that shots that I had taken with DNG 1.3 were similarly speckled. Unfortunately opening them with the Adobe software had no effect on the bad pixels.

Then you are experiencing a different issue, or were using some very old adobe software, or there is some bug with the particular port or version were using.

It is a fact that current adobe software correctly implements DNG opcodes, and recent versions of CHDK output them correctly for almost every camera.

edit:
Referring to your link

Quote

There have been reports of version 1.3 producing bad pixels which cannot be removed.

Any such reports would be wrong. All you have to do is interpolate over the low valued pixels. Adobe software will do this. chdkptp can also do it. Any software that can be told to patch low valued pixels can also do this. In raw therapee, the "hot/dead pixel filter" option will do a fairly good job.

Quote

How does CHDK determine what pixels are bad?

This has been explained in numerous threads, but briefly.

For DNG 1.1 CHDK finds the pixels that the canon firmware set to zero (or some other value on a few cameras), and saves their coordinates to a file. CHDK subsequently reads the file, and interpolates over the listed pixels. The file is used only as a speed optimization, since searching the entire buffer for 0s is slow

Edit:
It has been observed that many cameras have multiple badpixel maps (pixels set to zero) in the canon firmware. These may depend on exposure time, ISO and temperature. If you generate badpixel.bin with a different a map that has less bad pixels, you will see some when the camera switches to a map with more. It's is theoretically possible that some cameras could not have a fixed map at all.

For DNG 1.3, CHDK simply generates instructions for the DNG processor which say values below a certain value are "bad".

Quote

Are the algorithms that CHDK uses to convert the really raw data (bits and bytes) into DNG files sufficiently accurate?

In DNG 1.3 it is 100% accurate, there is no conversion. In 1.2, it performs the bad pixel patching described above. Other than that, the only modification is switching the data to big endian, which does not affect the values at all.

One more edit:
The sequence on your page shows progressively more bad pixels with longer exposures. This is expected. You should generate your badpixel.bin at the longest exposure and highest ISO you intend to use. When CHDK patches the pixels, it will skip ones that aren't set to zero, so having extra pixels in your badpixel file only costs memory and a little performance, it doesn't damage your image. However, the memory required can be significant.

« Last Edit: 15 / October / 2013, 23:44:21 by reyalp »

Logged

Don't forget what the H stands for.

philmoz

3450

Re: Bad Pixels: Unusual Behaviour

« Reply #8 on: 15 / October / 2013, 23:59:19 »

Quote from: reyalp on 15 / October / 2013, 23:19:37

Quote from: philmoz on 15 / October / 2013, 15:37:00
Stuck or hot pixels (non-zero values) can be affected by age, temperature, ISO and long shutter speeds - CHDK does not provide any method of dealing with these.
To clarify, CHDK does not provide any *automatic* way of dealing with this. You can use the manual badpixel list to patch them. http://chdk.wikia.com/wiki/Badpixel_removal

In the current code, the manual bad pixel removal only works where the sensor value is 0 when the removal mode is set to 'Average' - this is probably a bug introduced in a previous code cleanup.

Phil.

Logged

CHDK ports:
sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
g12 (1.00c, 1.00e, 1.00f & 1.00g)
sx130is (1.01d & 1.01f)
ixus310hs (1.00a & 1.01a)
sx40hs (1.00d, 1.00g & 1.00i)
g1x (1.00e, 1.00f & 1.00g)
g5x (1.00c, 1.01a, 1.01b)
g7x2 (1.01a, 1.01b, 1.10b)

reyalp

14117

Re: Bad Pixels: Unusual Behaviour

« Reply #9 on: 16 / October / 2013, 00:07:00 »

Quote from: philmoz on 15 / October / 2013, 23:59:19

In the current code, the manual bad pixel removal only works where the sensor value is 0 when the removal mode is set to 'Average' - this is probably a bug introduced in a previous code cleanup.

That means it doesn't work at all. News to me...

Logged

Don't forget what the H stands for.