han59

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)

17 hours ago, symmetal said:

On the following screen click on the 'Alignment' tab, and in the 'Solver' section check that 'Downsample' is set to 0. The 'Field of view (height)' is likely set to 'auto' but you can set it to your current FOV if you wish to possibly make solving quicker, though if you are likely to change your cameras or scopes it's worth leaving it in auto.

Alan

Yes that is the most likely cause.  1391 x1039 should solve without warning.

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

ASTAP version 2024.03.07 is out. I have created a Youtube video to demonstrate the "track and stack" function.

Hi Paul,

For Track and Stack use version 2024-02-25a as indicated under the menu "about".  It was released in the evening. 

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

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

Nice. For my Phone, a Samsung S7 the access to the internal camera works.  Installed version beta 25.

Han

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.

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

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

Quote

What do you use to form the two stacks, I think maybe make two master darks in ASTAP then treat one as a light ?

Yes just make twice a master dark of 12 darks.  So you need then 24 darks.

Quote

What do you then use to do the subtraction ?

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.

Quote

I have asked myself the same three questions about my DSLR and the problems of controlling the temperature

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

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

On 24/08/2023 at 11:57, vlaiv said:

We don't use darks to reduce noise. That is common misconception.

Yes, use as many darks as possible to remove the noise and keep pixel inequality.

On 24/08/2023 at 11:57, vlaiv said:

If we don't use matching darks we will not properly remove dark current. This as a result has wrong calibration (any value that we read of from image will be skewed) and also - flat calibration will fail because of residual dark signal that was not removed.

Best way to ensure that we remove dark current is to match the temperature as dark current is temperature dependent.

Yes, we can try dark scaling - but it is not guaranteed to work with every camera (or indeed with every set of data). We need "well behaved' sensor for it to work (not much messing in firmware and trying to optimize things or remove amp glow and such).

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:

See pdf file for more details.

dark_test2.pdf

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?

I did an other test with scaling the darks. This only works for dark above 0 degrees Celsius when the dark current is significant.  The factor 4.34 comes from 17.8 e-/4.1 e- (noise 26°C/noise 11°C)

On 09/08/2023 at 11:51, Elp said:

I think the point was what does the final image look like? I use uncooled cameras more often than cooled, the difference in quality with the final image result isn't that different, granted temperatures here don't really get too warm. A lot of people use DSLRs which get quite warm perfectly fine.

I have exported four images as 16 bit PNG unstretched but first shifted the mean background to level 1000. Then combined them into one image using Gimp. Exported again in 16 bit PNG and stretched in ASTAP. See below the results.

I have attached the unstretched 16 bit PNG image in a ZIP file. You can measure yourself.

On 09/08/2023 at 14:41, wimvb said:

• How many degrees difference can there be between lights and darks? (At 26 C, 3 degrees seems ok; does that hold at -10 C as well?)
• How critical is temperature for amp glow removal (the other reason we use darks)?

How, I don't know at the moment. But I assume it becomes more critical at higher temperatures. The slope  delta noise/delta temperature becomes steeper and steeper.

I haven't tested the amp glow. The images where all taken from sensor center 250x250 pixels.

combined level 1000 v3.zip

The measured values in the spreadsheet.

Today I tested the criticality of the dark temperature compared with the light temperature. I noted that calibration with master dark of a lower temperature gives a poorer result  then calibration with a master dark of equal temperature. See noise and hot pixel values below.

Han

Thanks for the feedback. 

I noted again that the linearity test finds a great offset at zero exposure. I see the same in my test. This requires further investigation. You could argue that changing the exposure time is not ideal. The light source intensity should be adjusted.  Maybe a led should be used as light source and the voltage and current recorded assuming the efficiency is constant which it is probably not. But then the test would involve more into a lab test then a simple test.

Han

No problem. The installer is now updated.

Index of /tmp/ccdciel (ap-i.net)

Han

19 minutes ago, mgutierrez said:

I need some time to digest the info and fully understand it. But, basically, the key point is to measure the difference in magnitudes between the sky background and the chosen star, and then compare (actually add) it to the reported star magnitude, if I understood well.

 

Yes that is it. 

In practise a few hundred stars are used and some statistics are applied to get a common magnitude to flux ratio.

For photometry you compare the variable star with a reference/check star. For SQM measurement you compare a star or stars with the increased background value.

Okay, I have created a fix and uploaded the new CCDCiel executable to my own webpage:

www.hnsky.org/ccdciel.zip

You have to extract the executable and then move it to C:\Program Files\CCDciel

A version with an installer will probably come tomorrow. https://vega.ap-i.net/tmp/ccdciel/  That is done by Patrick.

Tell me if this works.

Han

Thanks. I got the flats. You could delete them to save space on this forum.

The flat show a typical unbalance between the colours. Green is about 38000 adu, blue is 30000 adu and red only 15000 adu.  Did you use an electro-luminance panel for these flats?

I'm pretty sure if the standard deviation calculation uses only the green pixels then  the measurement for gain, full well capacity and read noise will be more in line. I will work on it.

Han

For my mono version ToupTek IMX571 sensor camera, I measure a read noise of 1.086 e- at minus 10 degrees Celsius sensor temperature.

I assume you get a little higher reading due to the sensor temperature introducing some extra noise. Could you try is at a lower sensor temperature?

The full well difference is strange.

It is calculated as follows:

 FullWell_capacity[e-]:=sat_level[adu]*gain[e-/adu]

The sat_level is 65535 so it is due to the gain which in your case is 0.335 e-/adu.

This gain is calculated as follows:

σ_light[adu]:=STDEV(light1-light2)/sqrt(2)

gain[e-/adu]:=flux[adu]/sqr( σ_light[adu]) (formula 3) 

It has probably something to do with the Bayer matrix. Can you share two flats made with your camera at gain 100 and a low temperature which I could analyse?

Han