Yes, there is a number of these idiosyncracies that seem to be specific to one user and not others.
I would be very interested in finding out whether anyone else has noticed the 'Save' issue in the scheduler that I described above. Basically, what happens is that I can set up a sequence in the scheduler and save it 'Save As' just fine. But if I make any changes to it and then just 'Save' (middle button), then the saved .esl file will be truncated after about a dozen lines. It won't show the target anymore, the fields come up blank, all that shows is whether the twilight, asap and altitude boxes are checked, but no target or capture sequence specified. When you now want to reload that schedule, it comes up blank, so all the entries have been lost.
To ascertain that error, you just open the .esl file with a text editor after having executed a 'Save' command.
Intriguingly, I have not experienced all the other problems that have been described with the March 7 stable installation. So what I am wondering is whether those are caused by residual installation files from a previous install that have not been entirely purged or been overwritten. Because most of us would not have the same install history, we may all have ended up with a different complement of residual files that now introduce these seemingly random errors.
The programmers have to weigh in whether that is a plausible explanation.
Clear skies, or perhaps we should change that to 'successful Meridian flips'?
I have used the stable build since March 7 and have not had that issue. As you may recall, I had an issue with the previous nightly build where the schedule was trying to align after the flip but never took an image. At the time, nobody else had that problem either.
Now, the only issue I have found with the scheduler is that the ‘Save’ button doesn’t work. It truncates the schedule, but one can overcome this by selecting ‘Save As’ everytime changes to the .esl file are made.
I wonder whether these unique and different problems nobody else seems to have are installation related?
fenriques wrote: hi Jo,
I'm using a color cmos so I'm not really concerned about the gain issue you mentioned.
Anyway, having a different gain setting per sequence wouldn't increase time to take calibration frames too much? that could be automated of course but storage / download time would increase.
Don't tell anyone ( ) and don't post that fact on the internet, but I am a little lazy with my calibration frames. I am reusing my darks and flats for pretty extended periods of time and given that my area is light polluted, I have no problem with that. The noise is always much greater than the subtle difference from sensor shift over time. I have to use narrowband, one shot color is just not cutting it from the city, except for the very brightest objects like M42.
Anyway, given the dead time lost in downloads and dithering, exposure times of less than 30s seem to be counterproductive as they cut down substantially on total integration time achieved during the session. That was the main point I wanted to draw attention to.
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.
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?
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.
Do you have an excel file with simulations of suggested exposure times to share? I would like to compare to mine
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?
Birthdate01. 01. 1960
About meStarted astrophotography with the eclipse last year. I never knew what was possible these days. Now I'm hooked.
Unfortunately, I am living in a white zone, so the only solution to getting acceptable pictures is to collect as much light as possible above the background. That's where the Ekos scheduler can become a life-saver!
Great job, team!