Mottling when using dark calibration

I am getting severe mottling when calibrating my QHY600C images using darks. I never had this issue before. Now on a trip to Chile, it affects all my images despite all efforts to take calibration data under the same conditions (ambient temperature, cooling power, etc.). I usually calibrate using flats, “flat darks”, and darks of the same duration (no bias). This no longer works. When I skip the darks and only use (calibrated) flats, I get a lot of rejection when stacking, but the result is much better as the attached images demonstrate. 
Either my camera has developed issues, the local power (which is quite variable) is playing with me, or something else is eluding me. 
Many thanks,
Mark

Comments

  • Thanks for posting your images..that is helpful.

    Did you notice how "faded" your image is. It isn't just mottling. You have a couple of issues.
    It appears your darks are somehow no good (not matching). 

    Here is what is happening... 

    1. When you do not use the darks the images are being aligned properly. This is because the bias level of the sensor and the sky is brighter than the hot pixels that exist in the image. So the hot pixels do not mess up the registration.
    2. When you use the darks- it subtracts off the bias level and now it is EASIER for PixInsight to see the hot pixels (that are not being subtracted due to what I think are not perfectly matching darks). These hot pixels are messing up the registration. If you go back and look at your registered images the are from the with darks used session.. you will see they are not aligned! You are looking at a half rejected stacked image. That is the "mottling"...but it is all because of an alignment issue...which is because of hot pixels... which is because of crappy darks in some way.

    CosmeticCorrection should be helping...but it shouldn't be used in this way. 

    So verify your images are not aligned...and then look closely at the calibrated images... (before registration)...they will not look quite right with hot pixels... or something.

    -the Blockhead
  • That makes sense. I just have to figure out why my darks are “crappy”.
    Many thanks.
  • My mobile laptop driver settings did not have “remove overscan” selected. I doubt this could have an effect because the same setting was used for both calibration and lights. Am I correct in assuming that?  
  • edited March 3
    Yeah..having the overscan or not having it would change the dimensions of the dark frame. If you had lights with no overscan..and darks WITH overscan...the darks would not match the lights. Dimensions of the images is always required to match.

    -the Blockhead
  • You know what.. your issue may have nothing to do with crappy darks.
    I have been reprocessing data...and I believe *I* have encountered the same issue!

    Can you please do me a favor. With your problem image... please split the channels. Look at each of the Red, Green, and Blue images. Does the weirdness show up on all channels. For me..it is only one channel. It seems like for you it is all channels. But please check. 

    -the Blockhead

  • Mark... I figured out the issue.
    This is actually important. 

    The issue is the automatic Cosmetic Correction. 
    It is possible to have it do some weird stuff. 
    You can turn *this* off and use your darks... then let me know if we are happier. 

    I have demonstrated on this end this is 100% the issue for my data. I am very strongly inclined to think this is the issue for you and likely thousands of other people as well. I would have never noticed... until I split the color image into R, G, B frames.

    -the Blockhead
  • Adam,
    I am still in Chili with limited means of communication, but I tried to split the channels and my weirdness exists in all 3 channels. I am returning home soon, and will spend more time on the problem. I did a manual integration with Image Integration and I believe it is OK. Is WBPP the issue?
    I do not know if this is related, but today, I processed a simple debayered stack in WBPP. The high and low images were reasonable, but the image itself was all 0s, all channels!!! I stacked it with image integration instead of WBPP and it was fine.
    I have undergone a significant amount of stress, testing every component of my system, in the short time I have here. I am relieved to find out that my data is good.
  • edited March 7
    The data you have is probably fine... 
    Please try to run it again, but with the normal method of CC and not AUTOCC... then see if the issue persists.
    You can also watch my video in FastTrack Training that shows the issue I was experiencing..which looks suspiciously like yours.

    -the Blockhead
  • Adam,
    I ran it as you suggested and everything is fine, phew! 
    Now I have several 10 panel mosaics, with a QHY600/644mm fl to process!! Lots and lots of stars.
    Many thanks,
    Mark
  • Mark... this is somewhat important. Can you please send me your master dark and a raw light frame?

    This is an issue that might bite many people. 
    I do not think this is entirely a one-in-a-million issue.

    -the Blockhead
  • Indeed.. your dark frame is 100% bad!
    If you look at the master dark you have zeros... and hot pixels.
    That can't be right. Did you change your offset value on the camera?
    Something is wrong here. In different way- AutoCC did make things weird..but it is because the dark frame is bad.

    This is an interesting lesson. Since AutoCC uses dark frames to do its job... it becomes a canary in the mine for detecting bad darks. This is why I always recommend look at ALL data before proceeding...even darks. 

    Let me know what is going on...

    -the Blockhead
  • edited March 10
    My bad! 
    This is a new mobile rig for me, and I am trying NINA. NINA read my camera driver gain setting of 42, but not the offset of 76, and assumed 0 offset. I think this means that my data was in effect clipped, both light and darks. I checked randomly my lights and some of them show 0-pixel values.
    I am thinking of doing the following, either:
    1) Live with it and avoid Auto CC for this data.
    2) Add a pedestal to my lights. An offset of 76 translates to about 170 count pixel values from tests, and take new darks with an offset of 76. I believe that the clipping is unrepairable, but that the unclipped data will be better calibrated.
    Does this make sense?
  • Yes... ... exactly. The point is... AutoCC found this for you in a way. But you were "bad" because you did not do the Adam Block method. Once you see a problem.. you should step through all of the WBPP output... and look at the values of the images. Looking at the stacked image rarely answers questions...because it combines everything together. 

    Regarding the clipping..the loss of information (if I understand) is just too much. I mean...I don't think it is worth it (Pyrrhic). 

    If you did not clip the raw lights...then sure you can recover from this.

    -the Blockhead
  • It worked!
    I was able to get a much better background. However, I am still getting a "negative or insignificant values" warning. I remember your Adam Block method of lighting up the zeros but cannot find it amongst the treasure trove of videos...
    Many thanks for your help.
Sign In or Register to comment.