pixel rejection isn't rejecting pixels?

[troypiggo]

After image calibration my subs are left with some stray hot pixels.  I've been playing with the different pixel rejection routines at the image integration stage, but these hot pixels remain.  Any ideas or thoughts on how to remove them?  What do you do to remove hot pixels?  I'm using a QSI583 mono, so when the RGB is combined I get little rainbows of RGB due to the slight movement between filters (putting on and taking off the bahtinov mask etc).

[Nocturnal]

Hi,

maybe some day I'll port this to PCL so it'll be a PI module. Till then you're welcome to use my free FixFITS utility to detect and fix your hot pixels. Keep in mind it was meant for OSC cameras so you have to tell it that you have a mono camera. I don't think you'd see the difference but for correct behavior it's better.

Let me know if it works for you or if you're seeing any trouble.

http://www.tungstentech.com/Software/FixFITS/tabid/78/Default.aspx

[troypiggo]

Thanks Sander.  I had trouble downloading your application, but noticed it's for Windows anyway.  I do my processing on Mac preferably.  Still, I'll have a look at it when I get a chance.

I was wondering if there's a way of achieving it in PI, perhaps with scripting?  I had a look at the "hot pixels" aren't so "hot".  I was thinking they'd be easily detectable because they'd be saturated, but they aren't.  Perhaps a script could be run on individual subs after calibration, and can a script detect if one pixel has a higher standard deviation that the surrounding?  Or is that what the built-in feature of pixel rejection is supposed to do and I'm just not using the right settings for std dev?

[Nocturnal]

Sure it's possible to do this in scripting. Sounds like a great project to get started with javascript for PI

[troypiggo]

Haha.  I will probably get into some scripting when I know a bit more about the existing built-in features 

Just spent lunch break playing with the different image integration pixel rejection algorithms and settings, and I think I can achieve it by tweaking the clipping values a little better.  So it seems, as usual with me, it was user inexperience.

[Nocturnal]

I don't know how the reject algorithm works, sorry. You're on the right track thinking in terms of stddev, that's how my tool works. Javascript could actually implement it pretty easily except that building the GUI part is a pain. I suppose it could be a command line only javascript. Maybe I'll write that instead.

[Enzo De Bernardini]

Hi,

Try with DefectMap tool, using a dark frame to generate the defect map (grayscale image, white background, black pixels to correct, use Binarize module to generate this) When this work with a individual image, you can make a ImageContainer and correct all subs.

Regards,

Enzo.

[troypiggo]

Thankyou, I'll look into that.  Haven't used those tools yet.

BTW I think I spoke too soon about my problem being solved above.  I was doing some tests on my luminance subs (bin 1x1) and they were pixel rejecting well.

Last night I tried it with my RGB subs, binned 2x2, and I can't get a satisfactory result.  Still left with hot pixels no matter what algorithm or clipping values I use.

I had a good read of the powerpoint presentation by Jordi Gallego that I've seen recommended here a few times.  It was excellent and did help a lot in understanding the background and workflow, but think these RGB subs are being too stubborn. 

[Nocturnal]

Troy, stacking algorithms generally only recognize outliers (hot pixels) if they are, well, outliers. If your subs are well aligned then hot pixels fall on the same locations and they are no longer outliers. To get around this you can either dither your exposures or fix hot pixels in the raw subs.

[troypiggo]

Thanks Sander.  That makes sense.  I'm guessing that because my RGBs were binned, and I reduced the exposure time accordingly, I wasn't getting as much flexure as my longer L subs.  That may account for why they aren't getting detected as outliers, while the Ls were.

Learning/understanding more each and every day   

[Nocturnal]

Hi Troy,

you should always review the dx and dy values that are calculated after registering your images. Actually if you don't dither you should monitor that during capture. This is how I do it:

http://deepskystacker.wikispaces.com/Measuring+image+quality+while+capturing