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.
Read More...
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?
Read More...
fenriques wrote:
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:El Corazon wrote: Here is another informative (and at times spirited) discussion on the same topic. That one also addresses the effect of gain.
www.cloudynights.com/topic/573886-sub-ex...00-and-maybe-qhy163/
www.cloudynights.com/topic/536809-conver...o-photon-flux/page-2 (#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?
Best
Jo
Read More...
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.
Read More...
Here is another informative (and at times spirited) discussion on the same topic. That one also addresses the effect of gain.
www.cloudynights.com/topic/573886-sub-ex...00-and-maybe-qhy163/
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.
Read More...
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.
Read More...
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.
Read More...
www.youtube.com/watch?v=3RH93UvP358&feature=youtu.be
I think this is an excellent tutorial to help anyone with their noise minimizing calculations in different settings.
Read More...