Jump to content

Banner.jpg.b89429c566825f6ab32bcafbada449c9.jpg

han59

Members
  • Posts

    408
  • Joined

  • Last visited

Reputation

284 Excellent

Profile Information

  • Gender
    Not Telling
  • Location
    Netherlands

Recent Profile Visitors

2,542 profile views
  1. Still difficult to understand whats happening. You could have a look and share the last image which failed to solve. Nina stores failed solves in this path: %localappdata%\NINA\Failed Share that image so we can have look If the folder is empty, force a fail by keeping the cap on the telescope. Then check the dimension in pixels of this image. Han (I'm traveling so it could take some time before I respond)
  2. Yes that is the most likely cause. 1391 x1039 should solve without warning.
  3. The message means that the pixel dimensions are too low. Assuming your camera has a resolution of 1391 x1039 this message should not appear. So the likely explanation is that you set the binning at 2x2 in Nina solver settings. Just go in Nina to the ASTAP solver settings and set binning at 1 or 0 (auto). Then this warning message should go away and solving should be more reliable. Han
  4. ASTAP version 2024.03.07 is out. I have created a Youtube video to demonstrate the "track and stack" function.
  5. Hi Paul, For Track and Stack use version 2024-02-25a as indicated under the menu "about". It was released in the evening.
  6. With a camera the best option is probably the much higher background value in case of clouds or loss of tracking. For rain you need clouds. Some programs like CCDCiel can take action if the tracking is lost. The problem with PHD2 is that it does not recover. So after a small problem it will loose tracking permanently even if it is not required to stop The internal guider of CCDCiel however recovers automatically. So after a minute without tracking and no recover of the internal guider you could program CCDciel to take an action. Han
  7. FYI, the free ASTAP program has two new features. The first is Track and Stack for minor planets and comets. This new feature allows to compensate for the velocity of these object and keeping them centered in the stack. This allows to improve the signal to noise ratio. The program can also extract the time and position in a MPC1992 report line to check the object in the minor planet center MPCchecker. Below a normal stack compared with Track and Stack. For the 60 x 120 seconds stack the two minor planets are vague streaks. The obsolete remarks indicates that the MPCORB database is obsolete. That is why the two minor planets are out of the center of the annotation: The manual for Track and Stack is here: http://www.hnsky.org/astap#trackandstack The second change is the possibility to add a SIP 3th order polynomial to the solution. This improves astrometric measurements and also improves the stitching of a mosaic. Feedback is most welcome. Han
  8. Nice. For my Phone, a Samsung S7 the access to the internal camera works. Installed version beta 25. Han
  9. In the last development version, I changed the scientific notation of the SQM value to an easier tp read notation. So in your table it will report something like SQM=18.63.
  10. I don't see it here. Let's check some steps to find the cause: 1) Does the viewer menu TOOLS, SQM REPORT ON AN IMAGE work? 2) If you open one of the batch processed images, does it have a keyword SQM? Once you open a file you can see the header in viewer. It should have a line like this: SQM = 1.925747011041E+001 / Sky background [magn/arcsec^2] and this line COMMENT SQM , used 900 as pedestal value Han
  11. The column requires the SQM value in the header. In the viewer, first batch solve the images with option add "Limiting magnitude and SQM" to the header activated. See screenshot Han
  12. Yes just make twice a master dark of 12 darks. So you need then 24 darks. In ASTAP, tab Pixelmath2 there is an option Apply file to image in the viewer. Select a second file and option "subtract file view + 1000". The 1000 is to keep positive values. Only for the latest Sony sensors with cooling you could consider to skip darks. But with darks the image will always be cleaner & hot pixels are removed. Only with a dark applied the flat correction will be optimal. So I still would go for full calibration with darks, flats and flat-darks. I think it good to keep a dark library of different temperatures. Old darks from year ago will still work fine. In ASTAP the correct dark with an corresponding temperature will be selected automatically. So you could keep them all in tab darks. Han
  13. In this post I tried to answer three questions around the calibration of lights: 1) Are darks required? 2) Should the dark temperature match the light temperature? 3) If not can the dark be scaled using a prediction of the dark current? The experiments where done with dark series of an ASI1600MM camera. To get a measurable result two series of stacked darks where subtracted from each other. One represents the lights, the other the darks: First some visual tests: First image, no darks gives a pretty high noise value. The second image based on ∑(12x60sec_+26°C) - ∑(12x60sec_23°C) gives the lowest noise value. So conclusion is that 1) darks help and 2) darks and lights temperature should match. Next a more extensive test presented in a table: You can see that the noise value for ∑(12x60sec_-1°C) - ∑(12x60sec_-1°C) is as good as ∑(12x60sec_-10°C). . So conclusion is that 1) darks help and 2) darks and lights temperature should match for lowest noise value. Next question 3) . Can darks be scaled? I tried to find the best X factor in subtraction of two dark series. E.g : ∑(12x60sec_+5°C) - X * ∑(100x60sec_0°C) The experiment was done in a custom adapted version of ASTAP which varied X in small steps to find the lowest noise value: Conclusions: 1) Make at least 50 or more darks to reduce the dark noise. See part 1 and 2 (pdf file). 2) It is possible to correct for a wrong dark temperature. Significant improvement above +10°C. Below +5°C the effect is limited 3) A wrong dark exposure time has only some influence above +10°C. See part 5 (pdf file) Full test report: Han dark_test2.pdf
  14. Yes, use as many darks as possible to remove the noise and keep pixel inequality. I have done an extensive automated test to find the best scaling factor . The noise of two darks was measured e.g: ∑(12x60sec_+5°C) - X * ∑(100x60sec_0°C) at the best X factor was found empirical. See attached report. Table 1 contains the best factors. Table 2 contains the noise if no scaling is applied. Table 3 contains the noise if best scaling factor is applied. Significant improvement above +10°C. Below +5°C the effect is limited The following empirical formula works well for my ASI1600: factor:=1/(exp(Δt * 0.1) corrected dark:=dark * factor - mean_dark * (1-factor) I didn't have time to test it with real lights. See pdf file for more details. dark_test2.pdf
  15. The results of the trial and error method for darks at -1C and -10C are displayed in the bottom part of the screenshot but still no improvement. A part of the noise is the read noise which will be likely stable. Which factor would you propose?
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.