›

Question on NGC3486 data

Roger Smith
in PixInsight
The NGC3486 is great data! Thanks!
I am trying to understand the (possible) brightness range.
I opened a couple of the 15Jan raw clear data images and use readout data and found no star, or the galaxy, brighter than .704 (using Max with probe size 15 for convenience). I found 11 stars which look smaller, but with readouts with maximum between .701 to .704

Is there a reason the maximum cannot reach 1.0?
Is .704 saturated?  If not, how can the smaller stars reach .701 - .704?

The FITS header says 16 BITPIX, as expected.

How long does it take to remove, open, reinstall that SBIG filter wheel and clean the filters? Seems like a good daytime job, and less time spent fixing donuts the flats don't fix. Just my opinion. Someone needs to invent a self cleaning filter wheel!

Thanks,
     Roger

Comments

  • BlockHeadBlockHead
    Typically camera manufacturers set the gain so that saturation (full well of electrons) is around 40K out of the possible 65K that is possible for 16-bits. This means the cameras are slightly less than 16-bit in dynamic range. The addition of AGB suppresses the range a bit more as well. Thus, 0.7 is a normal value for near saturation.

    Yes, cleaning the filters is a non-trivial thing to do. It would need to be practically daily to achieve what might be your expectations.

    -the Blockhead
  • Roger Smith
    Hi Adam,
    OK, perhaps .7 for saturation for this camera. But the n3486 2x2 data goes to .99; and more than 8 are .98 and above. I really doubt any of this is affecting anything in the processing, but it does not come full circle for me.

    I agree you regarding filter cleaning. I looked at the 3 sets of flats, and I can clearly see new donuts showing up on later in the 2nd and 3rd night. I was just thinking if you only have 5 or 10 dust donuts vs 100? then 1/10th the chance to have to fix something later. 

    In examining the flats provided I found that File n3486_Date_jan21_-001rff is not a flat. But looks like a bias. I doubt one bad flat is going to affect the red data much.

    You mentioned in your re-registration of the one distorted clear image that there was a 'bug' in Star Alignment that so many "views" showed up. My finding was that after running WBPP all the low and high rejection views were hiding in the view pull down in the lower left corner of the main PI window. So many views! So I do not think this is a bug. 

    I examined the Reject High Views for the different flats and found there were virtually no rejects, after a very high screen stretch. I am thinking because after WBPP organized the flats by DATE there are only a few flat files for master making. I suspect the rejection algorithm for so few flats is not really doing anything. I am going to rerun WBPP and with 100,000 console lines setting. Then I can find out what happened.

    I guess I am not really asking you questions, but any comments are welcome.
    Thks,
    Roger

  • BlockHeadBlockHead
    Yep.. you have discovered the other thing. The full well capacity for binned images *does* completely fill the larger binned pixels and the limit of the ADC to count values is 16-bits! So you will see actual 65K counts (or bigger numbers). This is all normal.

    Concerning WBPP... I am pretty sure it is a bug. Many temporary images (the rejection maps) are created and should be closed/destroyed along the way. It appears they are not at the moment. This bloats project sizes when saving them. 

    Concerning the Flats- I would not expect much rejection in general. Flats are not really noisy. You are looking at a very high S/N image. So the variation in value from image to image will be very small- and likely smaller than the thresholds of the rejection algorithms. In fact when used to create master flats with CCDStack- the method was to simply average them- no need to check for outliers. This is true for panel flats. With twilight flats the rejection of stars is important.

    -the Blockhead

    P.S. Nice catch on the bad flat. The rejection algorithm *should* have taken care of that. 
  • Roger Smith
    After further checking. 
    If I open an image and check a saturated star it reads .7 as discussed.
    If Blink the same image, the same saturated star reads .99.

    Both 1x1 and 2x2 data have this difference.

    Maybe this is some setting I have in PI is making this difference. I better ask on their forum.

    Roger

  • BlockHeadBlockHead
    No... the blink window is effectively a permanently stretched image. You can't use the values you see in the viewer for blink. 
    -the Blockhead
  • Roger Smith
    Adam,
    You are the master! 
    If you load the image to Blink and don't do anything, the readout value is .70.
    Then do the Blink's Auto Histogram Transformation (like we always do), then the .70 stars jump up to .99!

    If do Screen Transfer Function on Blink window the appearance changes, but the readout value does not change, which is correct.
    Now it is full circle for me! Thanks!
    Roger

Sign In or Register to comment.