Share:
Notifications
Clear all

19 June 2021: Our upload server https://upload.astropixelprocessor.com/ has been migrated successfully to our new office with higher upload and download speeds (nearly 10MByte/sec up/down ) ! We now have 1 general upload user called: upload with password: upload. The users upload1 - upload5 have been disabled.

31 May 2021: APP 1.083-beta2 has been released ! APP 1.083 stable will follow soon afterwards. It includes a completely new Star Reducer Tool, New File Saver Module, Improved Comet registration and much more, check the release notes here!

DOWNLOADS are available HERE!

 

[Sticky] Creating a Bad Pixel Map  

Page 5 / 5
  RSS

(@vincent-mod)
Universe Admin
Joined: 4 years ago
Posts: 3810
January 2, 2021 13:56  

APP indeed does take the entire sensor data, this shouldn't cause issues normally though. If you see it does, we'd definitely like to see. 🙂 Also, a BPM will not be destructive to the data, so it shouldn't add artefacts (like create black pixels because the BPM has a hot pixel and the light not). Best is to zoom into a light with pixels, hot or cold, and switch to "l-calibrated" on top of the preview window with a BPM loaded. This way you can check if the BPM is working properly.


ReplyQuote
(@gisfmp)
Hydrogen Atom Customer
Joined: 2 years ago
Posts: 2
January 15, 2021 12:22  

Hello everyone,

I am currently struggling to prepare a BPM for my ZWO ASI294MC pro camera. I tried following the instructions by Mabula in the first post, but couldn't achieve a satisfying result yet.

 

An issue seems to be the amp glow - the ASI294MC is known to suffer from it quite a bit. When I prepared the BPM using 5min darks (which nicely show the amp glow pattern), the BPM will essentially include the amp glow pattern as well, which leads to a very high density of hot pixels there (the "main beam" of the amp glow, which is about 5 - 10 pixels in width, is 50% hot pixels, it is actually interesting to see that the BPM has columns of hot pixels alternating with columns of regular pixels along the beam). Since APP will replace hot pixels by a mean value from the surronding pixels, the light image suffers severly in the amp glow region (I will attach an image later when I have the rights to do so (first post)).

 

I tried using shorter exposure darks while heating the camera to 40°C, so that dark current noise is maximized. I got subs with amazingly many hot pixels (about 10% at kappa=3) and without noticeable amp glow, which looked good to me. However, when I create the BPM using these darks, the main aim of the BPM (removing essentially all hot pixels in light images) is still not achieved, and I don't understand why.

 

For testing whether or not the BPM works correctly, it is suggested to use the "l-calibrated" image viewer mode. I would assume that if I loaded one of the darks used for creating the BPM as a light and then check it, most of the hot pixels in that image should be earased when viewed in "l-calibrated" mode. Indeed, some hot pixels are cancelled, but so many remain that I doubt this is what can be achieved. The same holds when I check using a "normal" light frame. 

 

I am wondering if I am doing something wrong in checking if the BPM works correctly. What I currently do is that I load a light frame and have the created BPM assigned to it. I deselect all the darks/flat frames and only leave the light and the BPM selected, then switch between "image" viewing mode and "l-calibrated" viewing mode (with DDP turned of) to see if the hot pixels get cancelled. Is this the correct workflow or am I missing something??

 

I will continue to try some different settings for creating the BPM, but in the meantime I would be happy for any advise you guys can give me on this topic. It would be specially interesting to hear what other users with cameras having amp glow experienced when creating the BPM and/or how they dealt with it.

 

Cheers,

Marcel


ReplyQuote
(@vincent-mod)
Universe Admin
Joined: 4 years ago
Posts: 3810
January 15, 2021 12:48  

Thanks for the detailed explanation. If I'm not mistaken, a BPM shouldn't harm the data. So if there are pixels in it that are not in the light, it shouldn't matter as far as I understand it. So just to clarify, you used standard settings in APP and you have uncalibrated darks to create the BPM right?


ReplyQuote
(@vincent-mod)
Universe Admin
Joined: 4 years ago
Posts: 3810
January 15, 2021 13:41  

Oh and one other thing, to increase the number of hot pixels detected by APP for the BPM, you can play around with the Kappa values. In tab 2 (APP version 1.082 and further) you can switch "create BPM" to "enable" and choose your own kappa values (try to lower it). Hover over the buttons to see more information on what to do there. I would use slightly higher temperatures and shorter exposures first in that case. This takes a bit of experimenting, but when you have a good one you can use this BPM for at least a year probably.


ReplyQuote
(@gisfmp)
Hydrogen Atom Customer
Joined: 2 years ago
Posts: 2
January 15, 2021 21:11  

Hello Vincent,

thank you for your replies. I played a bit more around and it seems to be actually working not bad.

 

As promised, I provide below an image showing the problem due to amp glow. Looking at the BPM in the amp glow region, I am not surprised that the calibrated image suffers, considering that the pixels which are removed based on the BPM need to be populated some way. 

BPM1 amp glow problems

 

 

Avoiding the amp glow issue:

Using shorter exposures while at the same time heating the camera to high temperatures, I obtained dark frames that do not really show an amp glow signal. The following image shows an example of a BPM created using those darks. I believe the result is actually good enough to work with (settings for creating the BPM were kappa=3, coldpix%=10, resulting in close to 6% hot pixels). As is shown in the test using a dark frame, it actually removes most of hot pixel succesfully (compare bottom left/right images). What's also interesting to note is that the BPM appears to have a "frame" of around 10px width where there is no hot pixel data (the effect of this can be seen in the calibrated dark frame (bottom right), which shows many residual hot pixels on the top and right edges).

BPM2 amp glow avoided

 

Finally, I used the BPM on a number of normal light frames and found that, while removing hot pixels, some artifacts are created in some of the light frames (see image below). I don't believe this is a problem that would actually show up in an integration of several light frames. Still, it may be worth considering what causes these artifacts and if they can be avoided by changing the algorithm that fills up the deleted pixels.

BPM3 calibration artifacts

 

I hope this information is helpful for other people having trouble in creating BPM's.

Cheers,

Marcel


ReplyQuote
(@vincent-mod)
Universe Admin
Joined: 4 years ago
Posts: 3810
January 15, 2021 22:05  

Thanks a lot for that, this is really valuable to us as well. I'll ask Mabula as to why this last effect might be as my understanding indeed is this shouldn't happen with a BPM. But I hope it does work out for you now in the integration! Thanks again.


ReplyQuote
(@neverfox)
White Dwarf Customer
Joined: 1 year ago
Posts: 17
February 4, 2021 22:04  

Sorry if this has been asked and answered but:

  • Does it matter which flats you use, as they would be potentially taken with different filters?
  • What if you have amp glow, which I've seen the BPM pick up as hot pixels to some degree? Amp glow is generally stronger with longer darks, so it would seem the longer darks you toss is would flag more pixels as hot (that aren't really) and not be great if used in an integration with exposure times that didn't have as much of it. I see this is recently discussed.
This post was modified 8 months ago by Roman Pearah

ReplyQuote
(@neverfox)
White Dwarf Customer
Joined: 1 year ago
Posts: 17
February 4, 2021 22:54  

I'm seeing something similar with my amp-glow infested BPM. The left image is uncalibrated, the middle is MD/MF/MDF only, and the last is also adding in the BPM. The smudge-like artifacts are greater in the image using the BPM.

Screen Shot 2021 02 04 at 4.47.07 PM
Screen Shot 2021 02 04 at 4.53.41 PM

ReplyQuote
(@wvreeven)
Quasar Admin
Joined: 3 years ago
Posts: 1122
February 5, 2021 01:29  
Posted by: @neverfox

Sorry if this has been asked and answered but:

  • Does it matter which flats you use, as they would be potentially taken with different filters?

Yes that matters a lot. If you take, for instance, flats with an R filter and use them on B lights then the response of the sensor will be different which will introduce all kinds of artifacts in the calibrated image. Also the properties of at least a part of the optical train may differ when using different filters, especially small band versus broad band. In short: always take flats with the same filter as the lights that you want to calibrate.


ReplyQuote
 John
(@john-j)
Brown Dwarf Customer
Joined: 2 years ago
Posts: 6
October 13, 2021 20:04  

I wonder.. If you shoot light frames with a cmos, in 2 x 2 binning mode, must darks and flats so be taken with the same binning to create a BPM?

- John


ReplyQuote
(@vincent-mod)
Universe Admin
Joined: 4 years ago
Posts: 3810
October 13, 2021 21:37  

Yes, calibration needs to be done with the same binning then as well.


John liked
ReplyQuote
Page 5 / 5
Share: