Drizzle Kernel Function Note

Playing with Drizzle again.

Saw a mention on the PixInsight forums about Drizzling with factor 1. Apparently this can help reduce the noise in your stacked image? Odd idea, I will have to try that sometime.

Tried varying the drizzle Kernel function. There are several possibilities, primarily Square (default), circular, and Gaussian. Potentially Gaussian can provide better results, but needs a larger number of subs to work well.

So, I tried doing 16 subs (Blue filter of M100, binned x2, 15 minutes each), using each of the 3 functions. I used a 0.9 drop size for each, drizzling by a factor of 2. The hardware was the STF8300M / Edge 11 combination. Measured the noise of the integrated image using the Noise script.

Kernel Noise (e-4)
No Drizzling 2.590
Square 1.511
Circle 2.015
Gaussian 2.580

Clearly in this case the default Square function performed the best. The Gaussian took significantly longer to calculate and was no better than not drizzling at all..

Advertisements

Sky Flat target ADU level

There seems to be a bit of minor quibbling over the desired target level for taking Sky flats.

  • The PixInsight forum suggested a Target ADU = 40,000 somewhere.
  • The Wodaski book uses a formula

ADU = FullWell / eGain * bin * %brightness
For 8300,
FullWell = 25,500   (spec)
eGain = 0.53  (from FITS header)
%Brightness = 0.3 – 0.5   assume 0.4  ===>    Gives Target ADU = 38000

  • The sample ACP AutoFlatConfig file has a default value of 20000 +/- 4000

I had been using 38000 +/- 50000. I noticed that sometimes exposures were “overdone”, where the vignetting effect of the flat results in an “anti-vignetted” image. Dark in the center, lighter around the outsides. I think this is particularly happening with HAlpha shots, perhaps with shorter test shots. I tried making the HAlpha flats with lower targets (20000) thinking that the values were too high, causing too much offset in the image or something. However, I still noticed occasional anti-vignetting.

So, what is the effect of using different ADU targets?

  • I created 3 different Master HAlpha flats with target levels of 20,000, 30K, and 40K target values. 25 frames of each, combined in Maxim DL6 using the SD Mask combination method.
  • I took a single 10 minute test Halpha frame from an STF8300 with HAlpha filter.
  • I calibrated the test frame with each of the 3 Halpha Flat masters. Each calibration used the same Dark and Bias frame masters; only the Flat masters were changed.

Conclusion

A big disappointment – it doesn’t seem to matter which Flat master I use! Visually the 3 calibrated frames look identical. No anti-vignetting, I can’t tell the difference between the frames. Pixel Math shows the resulting frames have the same values within +/-2 ADUs, which I assume is due to very slight variations in the Flat frames.

So, I guess I’ll go back to the 38000 range again. The odd frames must be due to some other effect. At least I don’t see the effect in regular images, just in short duration test shots. I think.

PixInsight versus Maxim: Subframe Calibration Comparison

Introduction

While trying to process some images taken with my SBig STF-8300M in PixInsight I was encountering problems; PI would not
correctly read images from my SBig STF-8300M, either the original image collected by Maxim or the calibrated image. This seems to have to do with whether the images are saved in 16-bit signed or unsigned format; there is a lot of discussion in the PI forum about how this should be done, Maxim using non-standard FITS files, etc. In the end it appears the “fix” is to manually reformat all of the calibrated light subs in Maxim into 32 bit floating point format.

During the forum discussion people made statements like

      It’s a really bad idea to let maxim touch your files at all… the less maxim does, the better.
      Stop letting maxim calibrate images and do it all in PI. the results are superior anyway.
      Avoid MaximDL like the plague once it has captured the image.

Interesting. Until now, I have been happy with Maxim calibrating the images. It is easy, happens automatically under ACP/Maxim, and the only problems encountered were caused by Some Idiot using bad flat or dark subs. Googling around, I do not find any studies showing the relative performance of Maxim versus PI in the calibration of images. I don’t know the source of these statements indicating the superior performance of PI in calibration.

On the other hand, my earlier tests on image alignment showed that PI was superior to Maxim and Registar. Maybe PI has better performance in calibration? Would this offset the extra manual work required to prepare and calibrate the images for PI
calibration (compared to almost no effort in Maxim calibration)?

So, here goes my test. Does PixInsight calibrate light subs better than Maxim?

Test data

I assembled a test data set of bias, dark, flat, and light frames. I use the same frames for calibrating under both PI and Maxim.

  • 1 light frame (an OIII light sub, 30 minute exposure). This is the image to be calibrated. The camera is trying to get to -10C, but the ambient is high enough that the actual temperature is -4C. I just grabbed a sub from last night’s imaging run. Maxim calibrates using the original file. Since PI cannot open this file correctly, it uses a copy of the same file saved as 32 bit floating point.
  • 20 Dark frames at -10C, 30 minute subs each. Collected in Maxim.
  • 25 dusk sky flats with OIII filter collected in Maxim under ACP’s control. These flats are between -5 and -10 degrees C; at dusk the ambient temperature is still around 100 Fahrenheit so the camera can’t quite cool to -10C.
  • 40 Bias frames at -10C collected in Maxim.

In PI, I set the probe to display values in 16 bit integer mode. Hopefully this allows comparison of “ADU” units with the
corresponding Maxim values.

The Maxim calibration involved using “Set Calibration” to load the various calibration individual subs into Maxim and clicking
the button that creates Masters for the groups of files (Bias, Dark, and Flat). I then opened the raw file and clicked “Calibrate”.

Maxim Calibration results showing the nebula (upper left) and the 3 master files. Click for full size.

Maxim Calibration results showing the nebula (upper left) and the 3 master files. Click for full size.

In the fight to get PI to calibrate the images, I tried several different cases as listed below. The various cases are variations on using floating point versions of the various calibration files for PI.

Note that only Case 4 adequately calibrated the images.

Case 1 – All files float

+ all files (bias, dark, flat, light) are exported in floating format from Maxim
+ FITS configured to rescale with 0-65535

FITS file config used to access floating point files.

FITS file config used to access floating point files.

Result: the PI conversion runs, but is not correct.

All individual subs (light, dark, flat, bias) exported from Maxim as 32 bit float. PI builds its own masters. Click to enlarge.

All individual subs (light, dark, flat, bias) exported from Maxim as 32 bit float. PI builds its own masters. Click for full size.

  • Calibrated image is too dark, zeros in background, no nebulosity.
  • flat is wrong; it looks a lot like the bias.
  • values in the PI created calibration master files are different from Maxim.
  • Bias ranges 40000..15000..40000 across frame.
    Maxim => 19500..1900..1950
  • Flat ranges 0..6000..0 across frame
    Maxim => 15500..18000..15500
  • Dark values around 1000 across frame
    Maxim => around 300 across frame

Case 2 – Fits configuration at 32767

This was the same as Case 1, except that the FITS configuration is set to 0..32767 instead of 65535. This was tried in an attempt to address image values being off by a factor of 2.

Result: PI Conversion fails to run.

After PI calibrates the individual flats the integration process tries to stack the flats to make the master. This process fails because one of the calibrated flats is “open in another process” and cannot be opened. On different runs, it will be a different file that is open in another process.

Case 3 – Use Maxim calibration masters

It turns out the Maxim calibration masters are already in float format. This case uses those masters directly PI, rather than converting the individual subs to float for PI to create its own masters.

FITS is configured as 65535 again (for the light frame).

  • Result: Calibration runs, but it looks like the flats are not correctly applied.
  • Dust motes are visible.
  • Darker center of image. Looks like flats are too strong?
  • Values (flat, dark, bias) of the masters when opened in PI match those reported by Maxim.

Case 4 – Use original individual 16 bit Maxim calibration files

Another weirdness – it turns out the individual calibration subs created by Maxim are readable by PI, even though they are in the same 16-bit format which doesn’t work for the light frames. For unknown reasons the calibration files can be read.

So, in this case allow PI to use the original Maxim individual subs to build it’s masters. The only thing different between PI and Maxim processing in this case is PI starts with the float version of the light sub.

+ Calibration files (bias, dark, flat) are left in “16 bit” state as created by Maxim. No conversion performed.
+ Light file is exported in 32 bit float format. Can tell this is necessary because PI does not open this 16 bit file correctly.
+ FITS configured to rescale with 0..65536

Result: As seen below, the calibration looks pretty good, very similar to the Maxim result.

PI calibration using Maxim individual calibration subs directly to create its own masters.

PI calibration using Maxim individual calibration subs directly to create its own masters. Click for full size.

  • Dark master displays around 2000 “ADU”, versus Maxim’s 300.
  • Bias master is slightly lower than Maxim: 1870..1800..1870
  • Flat master is similar to Maxim, 15800..18000..15800
  • Bias has much larger values than dark. I don’t understand this. However, the same thing is true in Maxim, so OK.

Comparison of PI versus Maxim calibrated light sub

So, how does the case 4 calibration of the light frame differ between the Maxim process and the PI process? The image below shows the two images, where the left image is the PI result and the right image is the Maxim result (converted to float).

PI and Maxim calibration results. Click to enlarge.

PI (left) and Maxim (right) calibration results. Click for full size.

Visual results:

  • The Maxim file is smaller, 2Mb versus 8Mb for Float form. The PI result is also an 8 Mb xisf file. I don’t know how Maxim got the file down to 2Mb, maybe that is a clue why PI can’t open it?
  • PI result has more hot pixels.
  • PI result has more noise (much grainier to my eye).
  • Stars look the same (roundness, brightness) even when zoomed in significantly.
  • Maxim result may have more dark pixels; a little hard to tell because of the increased noise in the PI image.

Tool Measurements

I used several PI tools to measure the noise and SNR for the converted images. Measurements for the Maxim result used the Maxim calibrated image converted to 32 bit float.

Statistics tool results:

Maxim K    PI K
count (%)   99.75290    99.95980
count (px)  2116573    2120963
mean        0.0072616    0.0075407
median      0.0071210    0.0072508
stdDev      0.0068079    0.0073814
avgDev      0.0011528    0.0013096
MAD         0.0009753    0.0009751
minimum     0.0000006    0.0000476
maximum     0.9739980    0.9766412

  • PI has more pixels?
  • PI has slightly higher background (median)
  • PI has larger deviations

Noise comparison script:

The NoiseEvaluation tool was used after performing a linear fit on the PI image to match it to the Maxim result.

PI    = 8.6e-4
Maxim = 9.34e-4

  • Maxim has slightly more noise? This does not jive with what I see visually.

SNR Calculation:

Calculated the SNR ratio as SNR ratio = MAD / Noise
PI = 1.13   Maxim = 1.044

  • Again, the PI result seems to have a slightly better SNR ratio by 0.09, although visually I wouldn’t have thought so.

ContrastBackgroundNoiseRatio tool:

Parameters: Background percentile 100th  cycle-spins 8
Maxim    PI
Median        466.48    475.15
Contrast        61.31    68.67
Background Mean    466.41    481.45
Background Noise    66.63    77.95
CBNR        0.92    0.88

  • This tool indicates the Maxim result has a better contrast (0.92 vs 0.88) and less noise (66.63 vs 77.95).

Conclusions:

Visually it seems clear the Maxim result is better. The various PI tools indicate that the two calibrations are fairly close; some tools indicate the Maxim image is better, some indicate the PI image is better. One might suspect I am not running the tools in the correct way:)

Case 5 – Case 4 plus Superbias and optimized dark frames

I turned on the optimize dark frames parameter (0.004) in the Darks frame screen. I also created 2 Superbias frames, one based on the Case 1 Bias master (from float format bias frames) and one based on the Case 4 bias master (based on master created from original Maxim bias subs).

Adding Superbias and dark frame optimization. Click to enlarge.

Adding Superbias and dark frame optimization. Click for full size.

This did not work. The background is over-reduced (lots of zero values). Somehow the superbias is not working correctly. Both superbias files had the same result.

I also tried only setting the Optimize Darks parameter = 0.004. This is the only difference between this frame and the Case4 result. It is fairly indistinguishable from the Case4 result; optimizing the darks didn’t seem to help any.

Thus, it seems that

  • the superbias makes things worse, and
  • optimizing dark frames does not help appreciably.

Final Conclusions

  1. The Maxim calibration appears to be at least as good as the PI calibration; I think it is better.
  2. There may be further fine tuning possible in PI to improve the results.
  3. Using PI for calibration requires a lot of manual operations compared to the almost automatic operation of Maxim. I see no reason to change to PI for calibration.

More Thoughts on Drizzling

Thinking about the effects of combining SubFrameSelector approved frames (versus using all the eye-balled frames), and the effect of drizzling. I was looking specifically at the integrated image noise. However, maybe there would be a separate metric indicating the Signal to Noise ratio. Perhaps the noise is greater in the “better” frames, but the overall sharpness or contrast or something of the image is better.

So, I wandered through PixInsight and pulled in some more metrics as shown in the table below.

The column N indicates the number of subframes combined to make this image. For example, in the Green subs I combined 7 subs approved by SubFrameSelector for the first image. I combined all 9 available (eye-balled OK) frames for the second image.

Script FWHMEccentricity provided the columns Median Eccentricity,

Script NoiseEvaluation provided Noise StdDev (shows up on the console).

SubFrameSelector provided FWHM, SNRWeight, Noise. When images are drizzled, I divided the resulting FWHM by 2 for comparison.

Statistics tool provided MAD.

ContrastBackgroundNoiseRatio tool provided the CBNR value, which I think is fairly analogous to SNR.

A PixInsight forum discussion indicated that the ratio of avgDev to Noise would result in a SNR analog. I used MAD instead of avgDev since I happened to have those values, and MAD seemed to follow the pattern as avgDev.

ImageIntegration Effects
N Count MAD FWHM Median Eccent CBNR Noise StdDev SNR=MAD /Noise SNR Weight Noise
Green
SubFrames 7 0.002620 1.221 0.5315 0.19 9.45E-04 2.77 34.44 61.91
All Frames 9 0.002459 1.243 0.5422 0.26 8.44E-04 2.91 36.84 55.32
SubFrames & Drizzle 7 0.002304 1.36 0.4657 4.50 5.88E-04 3.92 56.23 38.51
All Frames & Drizzle 9 0.002603 1.3945 0.4893 5.12 6.22E-04 4.18 66.71 40.85
SubFrames & Drizzle4 9 0.002300 1.326 0.4771 5.50 3.42E-04 6.72 172.7 22.44
Red
 SubFrames 9 0.004080 1.182 0.5098 0.25 9.91E-04 4.12 45.97 64.93
 All Frames 10 0.004120 1.19 0.519 0.31 9.55E-04 4.32 48.58 62.58
 SubFrames & Drizzle 9 0.003550 1.299 0.4212 6.72 5.87E-04 6.04 83.94 38.49
 All Frames & Drizzle 10 0.003150 1.302 0.4363 7.36 4.99E-04 6.31 92.05 32.72
Halpha
 SubFrames 18 0.000649 1.252 0.5035 0.24 1.52E-04 4.26 39.05 9.977
 SubFrames & Drizzle 18 0.000524 1.3945 0.4352 6.97 7.94E-05 6.60 78.98 5.206
 SubFrames & Drizzle4 18 0.000527 1.35225 0.4446 7.66 4.61E-05 11.43 237.8 3.021
OIII
 SubFrames 11 0.001290 1.765 0.4085 0.44 4.68E-04 2.76 32.69 30.68
 All Frames 16 0.001201 1.775 0.3931 0.21 4.19E-04 2.87 37.7 27.43
 SubFrames & Drizzle 11 0.001220 1.847 0.3936 6.18 3.08E-04 3.96 61.19 20.2
 All Frames & Drizzle 16 0.001060 1.8765 0.3656 6.66 2.57E-04 4.12 71.67 16.85
UHC
 SubFrames 22 0.004610 2.004 0.402 0.28 6.09E-04 7.57 115.3 39.9
 All Frames 28 0.004426 2.05 0.3505 0.41 5.84E-04 7.58 114 38.28
 SubFrames & Drizzle 22 0.003934 2.1115 0.4063 9.24 3.61E-04 10.91 211.1 23.63
 All Frames & Drizzle 28 0.003540 2.1205 0.3273 9.21 3.25E-04 10.89 212.2 21.3

Conclusions

  1. Drizzle really helps the SNR ratios. I suppose this shouldn’t be a big surprise – I imagine that is the point of the whole process.
  2. Looking at Drizzling by 4 instead of 2, the noise only changes slightly but the SNR goes up significantly.
  3. Drizzling really helps the eccentricity of the stars. PI forums indicate that ideally, stars should have about 0.44 or less for eccentricity. My raw frames tend to be about 0.5, but after drizzling the eccentricity drops to 0.42 or better! Somehow the stars are rounder.

I looked at the Eccentricity plots produced by the FWHMEccentricity tool. The eccentricity is distinctly better in the drizzled image.

 

Eccentricity map for non-drizzled image.

Eccentricity map for non-drizzled Green image.

Eccentricity map for same Green images drizzled.

Eccentricity map for same Green images drizzled.

PixInsight SubFrameSelector and Drizzle

I was reading about the PixInsight tool SubFrameSelector, and wanted to see if it would be more useful for eliminating poor images from my work process. So, I decided to try with and without bad frames to see the effect. Two issues were in my head:

  1. Historically, I have simply eyeballed the images and removed obviously bad subframes. Trailed stars, guiding errors, etc. Perhaps a more rigorous approach would yield sharper results.
  2. I read the presentation Image integration techniques : Increasing Signal/Noise Ratio and outlier rejection with PixInsight by Jordi Gallego. Most of the discussion was typical and reasonable. However, at the end he showed a shocking example where he added an obviously bad subframe with guide errors, and got a better integrated image! Hmmm, maybe I shouldn’t be eliminating the bad frames!

I had some images awaiting processing. They are from an SBig ST2000XM through a Tak Sky90, with various filters. I haven’t finished taking all the images (missing Blue, the HAlpha needs to be redone). Also, I have been experimenting with using a UHC filter for my Luminance frames. I know I am not supposed to use UHC for astrophotography, although I don’t know why.

I used the expression

(FWHMSigma < 2) && (SNRWeightSigma > -2) && (EccentricitySigma < 2.5)

to approve subframes. I should note that I had already removed obviously bad frames, so this was rejecting frames that “looked” OK.

At the same time, I wanted to play with the Drizzle tool. The criteria for using this are

  1. Lots of frames, on the order of 20. My sub counts range from 7 to 28 (15 minute) subs, depending on which selection criteria I use. So, I will test the effect of drizzling on smaller sub counts.
  2. Undersampled frames. My setup gives 3.74 arcseconds per pixel, so I think I meet this criteria. The FWHM reported by FWHMEccentricity is less than 2 pixels.

I also want to see the effect of drizzling with a scale of 2 versus 4. If 2 works, maybe 4 would be better, other than the huge file size?

The table below summarizes the results. I either integrated the subs recommended by SubFrameSelector, or used all of the frames. In the HAlpha case SubFrameSelector accepted all 18 frames, so there isn’t a smaller subset case.

I used the MAD value reported by the Statistics tool as my measure of noise. I also looked at average deviation (Statistics) and the NoiseEvaluation script; these values showed the same patterns as the MAD results, so I didn’t put them in the table.

ImageIntegration Effects
SubFrameSelector and Drizzle
n (Number Frames) MAD
Green
SubFrames 7 0.002620
All Frames 9 0.002459
SubFrames & Drizzle 7 0.002304
All Frames & Drizzle 9 0.002603
SubFrames & Drizzle4 9 0.002300
Red
SubFrames 9 0.004080
All Frames 10 0.004120
SubFrames & Drizzle 9 0.003550
All Frames & Drizzle 10 0.003150
Halpha
SubFrames 18 0.000649
SubFrames & Drizzle 18 0.000524
SubFrames & Drizzle4 18 0.000527
OIII
SubFrames 11 0.001290
All Frames 16 0.001201
SubFrames & Drizzle 11 0.001220
All Frames & Drizzle 16 0.001060
UHC
SubFrames 22 0.004610
All Frames 28 0.004426
SubFrames & Drizzle 22 0.003934
All Frames & Drizzle 28 0.003540

Conclusions

1. Rejecting subframes seems to be counterproductive.

Adding the additional subframes, rather than excluding the SubFrameSelector rejects, generally gave a somewhat lower noise result. The exception was the Red filter, where adding the one rejected frame made the noise slightly higher.

2. Drizzling works well, even with small frame counts.

Even with only 7 subs, drizzling gives lower noise. The noise is reduced, and the image is clearly better visually. Many of the dark pixels are gone, and the stars are much rounder and softer. See the zoomed previews below.

Drizzling with a scale of 4 versus 2 did not give appreciable improvement, so I don’t need to deal with the huge files:)

 

7 Green subs, no drizzling.

7 Green subs, no drizzling.

7 Green subs with drizzle.

7 Green subs with drizzle.