ASTAP 0.9.480, SQM (sky background) measurement using an image.
Stacking program, astrometric (plate) solver, fits file viewer
Brought to you by:
han59
Menu
▾
▴
The free ASTAP program version ß0.9.480 has a new experimental option to measure the sky background accurately in magnitudes per square arc second . This is the same value as reported by portable Unihedron SQM meters.
As soon an image is solved, the program can calculate the link between measured star flux and the star magnitude from the database. This flux/magnitude relation can also be used to measure the sky background value. The achieve the highest accuracy a pedestal values can be entered which is the same as the mean value of a dark/bias image.
Below the first result of a field test this evening. Unfortunately the Moon was shining so it doesn't go further then SQM 18.4 and I had to avoid some passing by clouds but the result is good and accurate. See the graph below. Camera used was the ASI1600MM in bin 2x2. Exposure time adapted from 0.5 second to 30 seconds. No filter.
Operation is simple. Load an image, hit the solve button, then select the fully automatic SQM measuring tool.
This is a new feature. Feedback is appreciated.
Han
Last edit: han.k 2021-01-22
Han, I downloaded latest version (Beta 0.9.550) and use ASTAP as a plate solving during image acquisition - great software!! I would really like to use this feature to measure sky SQM.
I image with DSLRs and various optical configurations, but every time I click the SQM Report based on imaged a Windows error sound is played, and nothing happens. That is after plate solving and photometry calibration of the image.
Could you write a bit more on how to do the SQM measurement, requirements, etc? Thank you very much!
Best regards,
Gabriel
Hello Gabriel,
The routine most likely fails because there is by definition not altitude or geographic location is in the DSLR image available. It could retrieve the observation time from the DSLR and as a backup position it will take the geographic location from the asteroid annotation menu.
So this routine was more intended for FITS files. Let my add a manual option to enter the sky altitude or geographic location if the time is read correctly.
For DSLR images it is also better to bin the RAW image to combine the RGGB pixels.
Normally the instruction comes after the first calculation but it fails for you.
Wait for an update.
Regards, Han
Try this version:
http://www.hnsky.org/astap_setup.exe
Enter your geographic location in the asteroid & comet annotation menu (CTRL+R). Then it will calculate the altitude. Check also the universal time in this annotation menu Then you can use the SQM menu.
If you need a Linux or Mac version tell me.
Cheers, Han
Last edit: han.k 2021-06-10
Han, that is some next level support and speed in the reply. I am very impressed! Thank you!
It appears to be working well now, thank you very much. Now I'm going to experiment with various images and learn more about how to use ASTAP!
Best regards, Gabriel
I'm working on a better menu for SQM calculation. There could have been a bug in the previous menu.
Try this version:
http://www.hnsky.org/astap_setup.exe
Han,
I've been having issues with the SQM measurement. I have input my Lat/Long as I am using DSLR files, but the calculation comes back silly, in this case it gave an SQM of 300 and an altitude of -4. The SQM numbers I get are consistent with the altitude. But sequential photos can give wildly different altitudes, so SQMs are all over. On any given photo the results are always identical, if nonsensical.
Otherwise, I greatly enjoy/appreciate this program!
Dave
Hello David,
DSLR images are less suitable since the red, green and blue pixel behave differently. Probably the best approach would be to bin 2x2 them. Secondly the question is are they exposed long enough such that the image background value has increased due to light pollution.
The pedestal value you should be estimated from a dark.
For the altitude not only the location but also date & time of the image are required. If you have set the option Libraw for conversion (tab stack method) , then most likely the correct UT time should been reported. Does the reported time match?
For testing, could you provide me some images and one dark for testing? Upload them to https://ufile.io/ or somewhere else and give me the link.
Han
Hi Han,
I've been playing with that nice SQM estimation feature lately. It's very handy to be able to quickly use frames that were captured for other purposes! The values I get are quite consistent with my local conditions
You wrote that the feature preferably uses a single capture (possibly calibrated with a masterdark - and masterflat if vignetting) and should not be fed with a stack of multiple images. Could you elaborate on that last requirement? Does stacking perturbs the measurement of the sky background flux?
Thanks!
Last edit: Clouzot 2021-11-15
Hello Clouzot,
If you have monochrome images, it could work for stacked images. But as soon you calibrate an image with a dark, ASTAP could add a pedestal so a fixed value to the pixel values. The reason is that if your image is taken at a very dark sky, the background value could be very close to the value of a dark. So the background values of an calibrated image could be very close to zero. Only the sky light pollution remains. But there is also noise in the sky and sensor, so even if the average is above zero it could fluctate around zero as a result.
At the moment, ASTAP doesn't keep a record of the pedestal is added but it the value 500 if required. I could implement that but it hasn't been done to keep it simple.
For OSC images so DSLR after applying the demosaic patter for stacking it will be even more complicated to keep track of the signal levels. There you better process only then green pixels. But an other complication is that the peak of the star signal could any up at the red or blue pixel. There you better have "fat stars.
So it makes it all more complicated. At the moment it is only good tested for monochrome sensors and single image.
Rather then measuring the sky signal as (current setup) it is possible to estimate the SQM from the noise level. Almost all noise is normally from the sky light. But you have to know the electron/adu ratio for the calculation and initial results where not so good.
Han
Hi Han.
Thanks for this new feature which is a great idea.
I have an OCS (ZWO 533) which records RAW files in fits with a bayer filter. Should I use SQM function on raw files or after debayering ?
Best regards,
Soulearth
Hello Soulearth,
Debayering should not be applied.
Use the latest ASTAP version. In older version there is a bug in the elevation calculation.
I think there two ways. One is to bin 2x2 both a light and a dark. The second way is to extract the green channel from both the light and dark.
Method Binning. Bin 2x2 both a light and dark. Measure the average dark pixel value. You can do that with the viewer popup menu "Show statistics in the reactangle". Take the first value. Use the SQM menu option under tools. Enter the average value of the dark as pedestal.
Extracting the green channel. You can do it in two ways:
or
This will give new files with end with _TG.
Measure the average pixel values of the dark (...TG.fits) . You can do that with the viewer popup menu "Show statistics in the reactangle". Take the first value
Solve the light image (TG.fits) and use the SQM menu option under tools. Enter the average value of the dark as pedestal.
I don't know which method works better. Binned or green channel. Maybe the binning is better because you use all colours. If this works, then I could automate it.
Han
Last edit: han.k 2021-11-16
Han,
Thanks for pursuing this. I think what I originally saw was the error in
altitude calculation, thanks for rectification.
Now, on SQM calculation. I took one frame from a recent night's adventure,
M33, and looked at SQM 3 ways, and the results:
Method SQM
Do nothing 21.19
Bin 2x2 21.35
Extract Green 21.50
So, no significant difference, and hard to say which is "correct". Since I
am just looking for a reasonably close, relative night to night number, the
"Do Nothing" approach is the low hanging fruit. It would be most
interesting to add to the analysis of light frames, another criteria to
pick the best frames!
Thanks,
Dave
Last edit: han.k 2021-11-17
For the first method, binning of a OSC raw, the binning of the dark is not required. Only for the light. The dark of a OSC should be reasonable smooth and all pixels will have more or less the same value. Detecting a OSC raw light is easy from the header keywords. I will test this concept with my QHY8 (OSC) lights in my archive. If the result matches with QHY measurements, then I will build an automatic binning in ASTAP.
Han
Last edit: han.k 2021-11-16
Hi.
Juste one info.
In my test "mean value of a dark" = "mean value of a dark_TG". The value is the same.
Regard,
Last edit: G Ajinn 2021-11-16
Thanks G.
I have created ASTAP development version 0.9.593 for Windows:
Download:
http://www.hnsky.org/astap_setup.exe
Binning goes now fully automatic for DSLR. Probably also a more reliable method since the Bayer pattern setting has no influence. The values I get from my OSC images look accurate. For a correct reading the pedestal value (dark mean or median) shall be set once and elevation calculated should be correct. Please test it.
I haven't added SQM measurements to the tab lights. The reason it requires some processing and you could also look to the image background values for an indication.
The SQM command line option should also work, but haven't tested it.
Han
Last edit: han.k 2021-11-16
Han,
I see you are protecting me from myself! Thanks! SQM will no longer accept
a raw DSLR file.
I was greatly happy to see the unroundness in the tools menu.
Adding the new method and using the same file on all, using the photometry
tab, extract green, solve and measure sqm, by comparison I get:
Method SQM
Do nothing 21.19
Bin 2x2 21.35
Extract Green 21.50
New Extract Green 21.97
The newest value sounds a little high. I'm in a pretty rural spot, and at
550M, so I can get pretty good skies, but not that good.
I tried to repeat, but now nothing works, I cannot extract only green
pixels. On the last try, after loading a file into photometry, analyze,
then extract, ASTAP shows busy, but is not using any CPU and won't
terminate???
Another compliment for you, your stretched version of the stacked file, it
takes me a couple of hours in Photoshop to get almost as good!
Dave
Last edit: han.k 2021-11-17
Thanks Han for your responsiveness (as usual!).
I can confirm the findings of @David and @soulearth:
Cheers!
Last edit: Clouzot 2021-11-16
Hello Dave, Hello Clouzot,
((((Bin 2x2 21.35
Yes looks good. You have good place to observe :)
I also trust technically the binning the most reliable method. Without binning the star flux detection could miss some flux due to the systematic difference between red, green and blue raw pixel values.
((( On the last try, after loading a file into photometry, analyze,
then extract, ASTAP shows busy, but is not using any CPU and won't
terminate???
If it is reproducable, tell me.
(((Another compliment for you, your stretched version of the stacked file, it
takes me a couple of hours in Photoshop to get almost as good!
Photoshop doesn't do a "colour preserving stretch" automatically. It is simple math but you to do some extra things for the colours when stretching. Futhermore to preserve the quality always export as 16 bit tiff or png.
The spectral sensistivety of a Unihedron SQM meter is comparable to visual spectrum 380 to 700 nanometers.
filter glas:
http://unihedron.com/projects/darksky/hcm500.htm
sensor:
http://unihedron.com/projects/darksky/TSL237-E32.pdf
So extracting green was not a good idea. Green is good for photometry as substitute for Johnson-V.
There will be also some difference using a V17 (Johnson-V) database and and the H17 or H18 (Gaia blue) but I assume the H17, H18 databases are the best option.
(((as an extra test, a 20-minute mono stack yields almost the same SQM value as what I got from a single calibrated light frame. So a mono stack is indeed usable for that purpose. A longer stack would probably have too many changes over time if a gradient is present.
Yes experimenting is good.
One more thing about creating a SQM trend. I could add SQM measument to the viewer batch menu. If so you could do a batch solve +SQM measurement for a series of lights. You could then load these lighs in the tab lights and add a column SQM with the popup menu option "change column keyword". Once the light list is analysed, you could copy & paste the list data into a spreadsheet. No idea if this is usefull. As said before, you could also use the light background value as an indication.
Next step will be to do some comparison tests with a Unihedron SQM meter. I have an Unihedron but will ask a friend to do one at his site.
Regards, Han
Last edit: han.k 2021-11-17
One more remark. The automatic binning for SQM measument works only if the keyword BAYERPAT is available in the header. That will be the case for DSLR images imported as raw (.cr2, cr3 ...) but it is not guaranteed for OSC cameras or DSLR imported as FITS. There will be a green remark in the SQM windows if binning is applied.
Han
Han,
This software just keeps getting better!!!
Thanks so much for your unique contribution to world wide astronomy!
Dave