Removing hot pixels

Hi,

I'm currently working on a research project where we process images like the one below:

http://eol.jsc.nasa.gov/scripts/sseop/photo.pl?mission=ISS030&roll=E&fra...

When you download the RAW file (click on "Request the original image file") you can see that there are many hot pixels, caused by the increased radiation in space. The goal is to get rid of these, that is use the average (or median) of the surrounding pixels. The output format then should be tiff.

I think in theory it is quite easy to do that, as it is simple to detect the hot pixels in the raw Bayer data, being fully saturated red, green, or blue pixels. Does LibRaw support this at the moment? If not, what is missing?

Thanks for your time,
Maik

Forums: 

There is no special procedure

There is no special procedure, call or data format for detecting hot pixels in LibRaw.
You may scan imgdata.rawdata.raw_image array for saturated pixels

-- Alex Tutubalin

Followup.

Followup.
I've downloaded sample file, opens it in RawDigger, selects some area outside of Earth and ISS station:
https://www.dropbox.com/s/y3w8dva8q4mc1n5/Screenshot%202014-07-10%2009.2...

Histogram of selected area is here: https://www.dropbox.com/s/42poviw3pupztpw/Screenshot%202014-07-10%2009.2... (this is RAW data histogram, note the log vertical scale)

As you can see, there are not many fully saturated pixels (value 4095/3936), but many pixels with some intermediate values (and these values may be stars too, not only hot pixels).

So, detecting hot pixels by 'saturated' value looks not possible

-- Alex Tutubalin

You're right, hmm. The next

You're right, hmm. The next thing to try would be to analyse multiple images of the sequence

http://eol.jsc.nasa.gov/scripts/sseop/photo.pl?mission=ISS030&roll=E&fra...
http://eol.jsc.nasa.gov/scripts/sseop/photo.pl?mission=ISS030&roll=E&fra...
etc

Maybe it would then be possible to identify hot pixels by checking which pixels never change in their value (in the hope that this is the case). I expect that noise would have a slight effect on the other working pixels. There will probably still be false positives so one could require that only pixels are considered as hot pixels whose value is e.g. >98% of the maximum in that channel.

Suppose I come up with a way to identify hot pixels, could I then simply mess with imgdata.rawdata.raw_image and let LibRaw use this modified array to give me the final interpolated RGB image?

Yes, you can modify rawdata

Yes, you can modify rawdata.raw_image[] array before calling LibRaw::dcraw_process() and processed image will preceive your changes.

To access pixel at row r and column c relative to *visible area of image*:

LibRaw LR
#define S LR.imgdata.rawdata.sizes
 
pixel_at_r_c = LR.imgdata.rawdata.raw_image[(r+S.top_margin)*(S.raw_pitch/2) + c + S.left_margin]l
color_at_r_c = LR.COLOR(r,c);

Comments: raw_pitch is in bytes, so you need to divide to 2 to access unsigned short item;
COLOR call accepts cordinates relative to visible area top-left corner

-- Alex Tutubalin

From my point of view,

From my point of view, possible method to detect hot pixels in image sequence may be something like:

1) Median filter detects/removes hot pixels very well (and fine details too). So run 5x5 (or something like it) median filter, comparing only same color (on Bayer CFA) values.
If pixel value is 2x (for example) larger than median value, then this pixel is suspected to be hot (or star).

Remember suspect's coordinates.

2) Compare suspect's coordinates for several images from same camera. The repeated coords are sustained hot pixels/

-- Alex Tutubalin

Hey, just wanted to let you

Hey, just wanted to let you know that I finally gave this a shot and it actually works quite well. A 5x5 kernel for the median seems to work best. As threshold I use a fixed value, currently "max value of color"/150 (with a lower limit of 20). To also detect dead pixels I compare to the absolute difference between pixel and median value.

For reference, the code is here: https://github.com/neothemachine/rawpy/blob/master/rawpy/enhance.py Still potential for optimizations, mostly performance-wise.

Maik