han59

Nico Carver of NebulaPhotos.com has reviewed eight stacking programs:

The lastest CCDCiel program (free aquisition program) just released has now an internal guider. This is the new tab: Documentation: https://www.ap-i.net/ccdciel/en/documentation/internal_guider The guider is standard a multi star guider. Star selection is fully automatic. Guiding will recover automatically if a cloud temporary blocks the sky. The guider image is displayed similar as the images from the main camera. It is possible to zoom, save, swipe and solve the guide image. Han

The parallel running solver with eat up all memory. You could use the standard Astrometry.net solver or the Astap solver. An other solution would be CCdCiel program for aquisition which will use less resources. Han

The Unihedron FAQ reports this: Where mpsas is magnitudes per square arc second. ASTAP will measure the sky glow by finding the background peak in the image histogram. So detectable stars will be ignored but stars hidden in de background noise could contribute to the measured background value. This Milky Way effect will effect ASTAP less then the Unihedron but how much is unknown.

Hi Alan, Thanks for the feedback. You have set a high record with your HFD measurement. You must be located at a superb site. More reports are welcome. There is a different behavior between ASTAP and Unihedron I haven’t discussed. At very good sites the background light caused by stars stars will reduce the Unihedron SQM measured value. So if you point the Unihedron to the Milky Way it will report a lower SQM then when you point outside the Milky Way. ASTAP will be less effected because it looks in principle to the background and not to stars. An other difference is for the case there is less atmospheric transparency/more extinction. Then ASTAP will report a lower SQM because the starlight is fainter. The opposite effect will occur if your on a mountain will less air above you. The ASTAP SQM will go up because the stars are a little brighter. Since the detected star flux is the reference and of interest for the astronomer, these effects are bonus. Han

After some thought it looks like using the V17 Johnson -V magnitudes as a reference for SQM measurements is the wrong thing to do. My camera is sensitive over a wider spectral range and therefore sees more light pollution than the Unihedron SQM-L meter. Especially in the blue area the Unihedron less sensitive. With the H17 or H18 database containing the Gaia blue magnitude (BP) as reference the SQM values reported by ASTAP values match better with the Unihedron values. See new charts. I'm interested in reports of other users with an Unihedron meter. The bandpass of my Baader UV/IR blocking filter matches very nicely with the Gaia blue bandpass. Gaia and Johnson bandpass:

Below the results of a comparison test between the Unihedron L meter and ASTAP with an ASI1600 camera on April 2, 2022 . It was a clear evening/night. The SQM was measured at zenith and at 30 degrees above the horizon. Measurements were made during twilight until it was astronomically dark. At the highest SQM values, the Unihedron meter indicates approximately 0.3 to 0.4 magnitudes higher. I suspect this is because the telescope sees the entire spectrum while the Unihedron is most sensitive in the green part of the spectrum. The camera then sees more light pollution. The spectral response of the Unihedron is comparable to that of the human eye. A comparison test with a green/Johnson-V filter in front of the camera may be able to provide the answer. Han

In SharpCap beta it is also implemented.

INDIGO has implemented Astro-TIFF is their code.

There is currently an initiative to make better use of the TIFF format for astronomy. The idea is to use TIFF not only for saving an image but also to store the FITS header in a standard way into the TIFF file. So the exposure time, celestial position, date, gain, astronomical solution , sensor temperature can be stored and read similar as for a FITS file. Benefits: • The TIFF compression algorithm makes the files smaller • The files are readable by almost any image viewer. Astro-TIFF as is called is already available in several programs and more are coming: Image acquisition programs Astro-Tiff compatible: CCDCiel. version 0.9.78 read/write Nina 2.0 beta version Image processing programs: Siril version 1.0 just released ASTAP latest versions, read/write, conversion In planning: APT AstroImageJ Other program can read TIFF but not the header currently. The idea is to use this format for 16 bit raw images, so lights, darks, flats and flat-darks/bias files. These images are produced in the thousands. For these files compression is beneficial. The TIFF deflate compression is almost as good as the Rice compression as specified in the FITS standard 4.0. Any further processing results can be stored in FITS. It is possible to convert batch wise between TIFF and FITS possible without loosing header information. The Astro-TIFF specification is here: https://astro-tiff.sourceforge.io/ Note this specification is not set up as a replacement of FITS or other formats. It just proposes a better of use of the existing TIFF file format. Han

If the polar alignment is reasonable okay, maybe you should check for a cone error or just reduce the allowed error. Two slews should be sufficient. but I set the allowed error to 5 arcminutes or so.

After the shield deployment I imaged Webb yesterday with a 100 mm APO and ASI1600. It was about mag 16.5. You can find coordinates from this link: Horizons System

Yes in a previous version there was a bug in the altitude calculation. If I remember well it was for RAW files only . RAW files are now automatically binned 2x2 for the measurement . Han

The image have a lot gradient do to over-correction of the flat. The bias /flat darks where missing during stacking and probably causing this effect. I tried to correct that with an artificial flat and some other tools with limited success. The M45 tiles are difficult to correct. Anyhow I used them to test the tool "ring equalise" in ASTAP, tab pixel math 1 and made some improvements for next ASTAP edition. Below the result before I gave up. It is maybe a little better but still not good. For a good result "flat darks"are essential. ICE in general will produce better result but I don't know how good it is with gradients. Han

Have you tried in ASTAP the option crop images and maybe "Merge overlapping background=off"? Probably it also works better if you equalize the background of each image before making the mosaic. For testing/experimenting, if you could share the 4 or 6 raw images, I could try to get it better. An alternative for making a Mosaic is to use the free Microsoft program ICE which is discontinued but still can be found at some unofficial places. Han author ASTAP

You should have installed index files down to about 20% or 30% of your field of view. Which index files do you have and what is the field of view? What configuration settings for solving are set? What does the log say?

If you upload it to Youtube it is convertered anyhow.

The light pollution will not make a difference. Note it will only effect nebula. Just try it. As soon you say layers in faint part of nebula, you know you have to switch to processing in floating point. Just one more remark: The only reason why you don't see layers in the 8 bit display or 8 bit jpeg is that the image is properly stretched. Nebula in the sky will increase the ADU's in your camera with only a few ADU's. Your 16 bit astro image has a huge range. Stars will generate a lot of ADU up to saturation but you nebula will generate maybe 4 ADU's max. One you stretch the 16 bit (stacked)image, these 4 ADU's are equivalent to 2 bit or 4 levels. After stretching the 16 bit image to 0 ... 255 your nebula has maybe levels 0, 4, 8, 12 and 16 and nothing between. So the nebula will appear as having layers. If you would process in floating point values, the nebula will have any value between 0 and 16 and the nebula appear as being smooth. Han

The bit depth increases with stacking. If you combine 2 pixels of value 101 and 102 you get 101.5. How do you want to store that? In 16 bit your image will show strange pattern in grey level. Especially because faint nebula are in the low range of your 16 bit. Nebula will look like this (without the numbers)

The dimensions in pixels so width x height is too low. So in most cases the binning is too high. Keep the final image dimensions above 1280x960 pixels. So don't bin more then 2 or if you have a small sensor keep binning at 1 or better 0 (= auto) Han

Raw images are displayed grey scale. That is normal. The pixels have green, red and blue filter in front in a so called 2x2 bayer pattern. From this single colour so grey scale image is later a colour image created by a process called de-mosaic or de-bayer. The reason this is not done immediatly is that the are several methods for and some don't work good in astronomy. Second reason is that the dark has to be subtracted prior to de-mosaic processing. Han

Alain, is this one on the JTW Facebook from your setup?

Alain, For this topic a guiding graph in arcseconds will be most interesting. Furhermore slew to accuracy. So if you slew 90 degrees or so in RA, are you on the correct location? Many times in the past years performance test data was promised but never released and excuses ware made. So many readers are very curious how this mount performs in your setup. There is somehow a cloud of secrecy around this mount. If it performs well, there is no reason not to release some performance data. This was specified on march 2018 or earlier: Han

Does it work? Looking to your picture, your polar axis seems to be set for the northern part of Europe. Not for the south of France ???

There is a 30.000 object deep sky database included. The object outlines are plotted if selected. See screenshot below. Select objects or all. The exposure time doesn't do anything at the moment. Unfortunately the Ascom Sky Simulator camera reads the images produced by the program only in 8 bit. That give doesn't give much range for playing with exposure intensity without compromising the solvability of the image. So for the moment the exposure time is ignored. You could try the deep-sky-survey download option but that could be a little slow. Keep the image size in pixels small or be patient. Use here exposure times of 10 seconds or more since downloading of the images takes time an the image should be ready when the camera is read out. Han M42 view with object selected.