Jose Corazon replied to the topic 'Can not calibrate Images captured with EKOS (stellarmate) in Pixinsight?' in the forum. 2 hours 56 minutes ago

From your previous post I understand that the FITS header shows 2750x2200. But in the PI console upon importing the image PixInsight reads 1 px less in each dimension. That is also the dimension listed on the ATIK website.
If the ACTUAL pixel COUNT (not FITS header) shows 2750x2200 then the information on the ATIK website must either be 1) wrong, or 2) the resolution was rounded up to the next number that was divisible by 2, or 3) the driver that PI reads out states the wrong value in the console (as does the website), or 4) PI entered the value provided to it by ATIK into the database it uses for its calculations and disregards the FITS header AND the actual pixel count.
Looks like that cannot be solved without input from ATIK. You need confirmation of what the actual pixel count of the sensor really is.


Jose Corazon replied to the topic 'Can not calibrate Images captured with EKOS (stellarmate) in Pixinsight?' in the forum. 4 hours 7 minutes ago

When you take one of the FITS files and open it in Photoshop or Gimp, how many pixels does it show there when you select Canvas size and image size?
I.e. is the header right or not?


Jose Corazon replied to the topic 'Excellent tutorial on minimizing noise and optimizing exposure parameters' in the forum. 14 hours 20 minutes ago

fenriques wrote:

El Corazon wrote: Here is another informative (and at times spirited) discussion on the same topic. That one also addresses the effect of gain.

Thanks, I read the thread (well ,not all 188 posts...), argumentations are solid but the data presented are mainly empirical. There's another useful thread on CN that discuss the theory behind the calculations: (#38)

Do you have an excel file with simulations of suggested exposure times to share? I would like to compare to mine

Hi Fenriques,

Sadly, no, don't have an Excel file with simulations. That might be useful to build.

I only have the numbers I gave in my last reply, which fit the abhorrent conditions in my backyard in a white zone and which match closely what the sharpcap site says and what the formulas in the cloudynights blog also suggest. They were obtained recently with an RC-8" at f/8 using the ASI1600MM Pro at 240 gain. The ADUs come out a little higher than in the cloudnights discussion I provided the link to, I will continue tweaking times and gain some more until my results are optimized to the conditions (that doesn't say much!).

One drawback not discussed in the video presentations or the blogs is the time factor required for downloading and dithering. The shorter the exposure times, the more those come into play. By going to shorter exposure times one will progressively end up with less integration time, since progressively more time is being wasted downloading the images and dithering. That is especially critical when using a Raspberry Pi, which is much slower than a mini-PC, or when downloading the images over WiFi. Here, it becomes essential to use a mini-PC at least, preferably the more computing power one has the better. Also, USB3 becomes absolutely critical for downloading the images. For those reasons, it seems to me to make sense not to go below 30 s exposures and rather preserve dynamic range by using a lower gain for luminance, while keeping the median ADUs in the low 2000s.

That makes the scheduler more important than ever. With that, one can then program image acquisition at different gain values, i.e. perhaps 120 gain/30s for L, 180 gain/30s for RGB and 300 gain/60s for narrowband from the city at f/8.

Jasem, if you are reading this, that would be a useful addition to the capture module: Allow different gain values to be programmed for the different filter settings (rather than only one gain value for the entire sequence), without the need to set up separate entries for the same target in the scheduler.

What do y'all think?




fenriques wrote: I meant bandwidth, sorry. But the point was that for 'no filter' I would not assume 300nm bandwidth but a greater value as the SQM meter collects light on a wider range as far as i know.

That is correct, the SQM meter collects photons over a wider range, but the bandwidth at which man-made light radiates is generally more limited to the visible spectrum and falls within the 300 nm range. Anything outside that range would be deep red or glaring blue/UV. Artificial light generally minimizes those parts of the spectrum.


Here is another informative (and at times spirited) discussion on the same topic. That one also addresses the effect of gain.

Basically, the settings I have gravitated towards in my extremely light polluted backyard is a gain of 240 on the ASI1600MM Pro and an exposure time of 8 seconds for luminance, 20 s for RGB and 120 s for Ha, O3 and S2. That keeps the median ADUs in the low 2000s with my dark ADUs around 800. That puts me just a little more than 1200 ADUs above the darks. According to the cloudnights discussion, that is the optimal setting at which saturation of stars (i.e. preservation of their color) is minimized while preserving maximal dynamic range possible under the circumstances.

I had basically empirically come to very similar values before being alerted to the discussion board by a friend in our Astrophotography group. Bottomline: In the city use short exposures and high gain settings, at a dark site use long exposures and low gain settings, because only there can you really get the return on dynamic range that longer exposures and low gain can provide. It is not possible in the city.


The 300 nm in the SharpCap tool do not refer to a wavelength, but to the bandwidth of the filter used. It assumes a bandwidth of 300 nm for the luminance filter, it can be increased to a maximum of 350 nm.

I would say that’s about right, because the bandwidth of the spectrum generated by city lighting is probably around 300 nm.


Jose Corazon replied to the topic 'Re:Scheduler and calibration' in the forum. 3 days ago

I am exclusively using the internal guider. Works like a charm and recalibrates just fine.

Why not use that? I have not used PhD2 in over a year, except when I am trying to guide with my little iOptronSmartEQPro+ mount, for which there seems to be a problem with the Indi driver. The internal guider does not work with that, but PhD2 does, if run from outside Ekos.


I think this is an excellent tutorial to help anyone with their noise minimizing calculations in different settings.