Cosmetic Correction / Bad Pixel Rejection

[admin]

Hi folks,

some good news on this one. After a bit more thinking and tinkering, I have found a way to detect a good percentage of the hot pixels using only the light frames. Based on the data @borodog sent me and using the dark frame analaysis as 'truth' for what is/is not a hot pixel, my current code detects about 60-70% of the hot pixels with very few false positives. What's more, because it is better at detecting pixels the 'hotter' they are, the detected pixels account for about 90-92% of the total hot pixel brightness detected via the dark frames.

Now I need to work out the best way to include this into SharpCap - possibly as an extra option in the dark subtraction, or possibly a control of its own.

cheers,

Robin

[Borodog]

That's fantastic, Dr. Glover. That is an order of magnitude improvement; I would guess that last 8-10% of hot pixel intensity is probably not very noticeable. Thank you again for continuing to work on this.

[Borodog]

PS. I would be very interested in hearing the details of the algorithm you've developed.

[MarMax]

Dr. Glover,

It sounds like you are close to adding this feature. And if you are going to describe it in the "What's New" area then you don't need to reply here.

Can you clarify if this feature will be an enhancement to taking darks or if it will replace taking darks. In reading through this thread I was not sure if it could replace taking darks.

Thank you.

[timh]

Hi Robin,
That's great. For my particular uses I have found very little wrong with Sharpcap - the only longstanding niggle has in fact been those few hot pixels - normally no more than half a dozen that seem to escape the current hot pixel filter and then multiply during autostacking according to the dithering pattern. I value the autostacks as a a time-efficient way of dealing with lots of short exposure data.
thanks
Tim

[admin]

Ah,

interesting... I was imagining this as an alternative to dark frame correction, so I have currently rigged up the way it is activated so that you cannot activate both dark frame correction and hot pixel removal at the same time. From the comments above, maybe there is also a call for it to be available in addition to dark frame correction.

I think it is too late to change for today's update, so to begin with it will be an *alternative* to dark frames.

cheers,

Robin

[admin]

Hi folks,

further info in this thread :

viewtopic.php?t=5492

cheers,

Robin

[Borodog]

Robin,

Thank you very much for implementing hot pixel rejection.

However, there may be a potential problem. My understanding is that you have HPR implemented as an alternative to darks. But it occurs to me that this leaves the bias in the lights, and hence flats will over correct.

So I think you need to add a step that subtracts a fixed bias level, which SharpCap should be able to measure as part of the sensor analysis.

[MarMax]

Robin,

Thank you very much for implementing hot pixel rejection.

However, there may be a potential problem. My understanding is that you have HPR implemented as an alternative to darks. But it occurs to me that this leaves the bias in the lights, and hence flats will over correct.

So I think you need to add a step that subtracts a fixed bias level, which SharpCap should be able to measure as part of the sensor analysis.

Dr. Glover may have answered this question in reply to one I asked recently.

viewtopic.php?p=30227#p30227

[Borodog]

Thanks, Max. I believe you are correct. It looks like SharpCap is already subtracting out the bias if not using darks. I should have expected Dr. Glover to be one step ahead of me. ;O)