Getting back into imaging after a long break

[Gina]

Ultra stretched 240s dark in KStars FITS Viewer.

[Gina]

Looking at fields of view with the various lenses it strikes me that the ability to rotate the rig for better DSO framing would be a very useful feature.  I did design a rig with this facility some time ago but thought it was too complicated.  Since then I have much improved the accuracy of 3D printing and may consider it again.  KStars actually supports this feature but I'm not sure how it's implemented in INDI yet.  A stepper motor would be used to turn the rig in a turret and this would need calibrating so that the software would know the angle.  When I was looking into this before, I had in mind writing my own INDI driver with a suitable GUI display but this may be already covered.

Edited July 9, 2019 by Gina
typos

[Gina]

The PixInsight book recommends taking lots of Bias frames so I just set it going - very quick to capture.  Just grabbed 150 😄

PI book also seemed to thing Biases to subtract from Flats was a good idea so I'll do some of those - different temperature.

There's a patch of clear sky slowly approaching from the west but could be an hour or two before reaching here.  If it gets here in the next hour I might set up for some more lights or I might decide on an early night after late one last night.

Edited July 9, 2019 by Gina

[Gina]

Hmm... the 0°C Bias frames look the same as the -20°C ones.  Maybe Bias doesn't depend on temperature.

[wimvb]

33 minutes ago, Gina said:

Hmm... the 0°C Bias frames look the same as the -20°C ones.  Maybe Bias doesn't depend on temperature.

I don't think they do. Temperature affects dark current in semiconductor devices. As such it will affect amp glow. But bias frames are so short, that dark current is not an issue. In stead only artefacts caused by the read out circuits and unevenness in gain will affect bias frames. But better safe than sorry and don't vary temperature.

Flats are a different issue. They correct only optical issues. As such they must be independent of temperature.

46 minutes ago, Gina said:

The PixInsight book recommends taking lots of Bias frames so I just set it going - very quick to capture.  Just grabbed 150 😄

PI book also seemed to thing Biases to subtract from Flats was a good idea so I'll do some of those - different temperature.

I don't think Warren had cooled cmos in mind when he wrote that. Amp glow is probably not that much of a problem with short exposures. But theoretically any exposure except the very shortest ones, must have some dark current (read, possible amp glow). It just may be so little that you can't see it. But when you start stretching the image, and there is some residual dark signal left, it may show itself.

[happy-kat]

Aren't bias files about read noise rather then temp.

[Gina]

It would seem so.

[Gina]

Gradually getting everything sorted out for using KStars to control all aspects of remote astro imaging.  The only remaining problem is with plate solving and pointing the rig where I want to.  When I was using Windows software, I was controlling everything from the warm room and not using remote operation.  This meant I could see directly just what the mount was doing.  I was planning to set up a webcam to watch the mount remotely but haven't got round to it - got into real actual astro imaging sooner than I expected.  I have definitely got my astro imaging MOJO back! 😀

I have got a little further with plate solving.  Found where to set up the FOV for plate solving and the Index Files setup form made sense, showing some wider field essential files already downloaded.  However, when I tried plate solving I got "Solver started" followed a little while later by "Solver failed".  I didn't think to take a screenshot of all this though - I was clearly getting tired and gave up, closed the roof and went to bed.  I'm still wondering if having a FOV bigger that the widest index files is the problem.  I tried setting the solver FOV within the index files range but it still failed.  I think I'll change to a longer FL lens that will give a FOV within the index files range and see if that works.  If it does, I'll find another way of slewing the rig for the widest FOV.

Edited July 10, 2019 by Gina
typos

[wimvb]

If you have internet access from the computer that runs kstars, you could try the online solver.

[alacant]

13 minutes ago, Gina said:

I didn't think to take a screenshot

Hi. Quite often wrong permissions on:

/usr/share/astrometry

or the wrong entry in:

~/.local/share/kstars/astrometry/astrometry.cfg

Maybe activate the log to see exactly what's happening. This should do it:

Cheers and HTH.

 

[Gina]

/usr/share/astrometry is empty.  The permissions are set to root so maybe I should set permissions to user (me) using sudo.

[alacant]

7 minutes ago, Gina said:

/usr/share/astrometry is empty

Hi. They don't necessarily have to be there, but usually are if you installed them via the Debian packages. 

If you installed them via EKOS, they'll usually be at:

/home/gina/.local/share/kstars/astrometry

Here are the relevant lines in astrometry.cfg:

# In which directories should we search for indices?
add_path /usr/share/astrometry
add_path /home/steve/.local/share/kstars/astrometry

HTH

 

Edited July 10, 2019 by alacant

[Gina]

Here is ~/.local/share/kstars/astrometry/astrometry.cfg

# This is a config file for the Astrometry.net 'astrometry-engine'
# program - it contains information about where indices are stored,
# and "site policy" items.

# Check the indices in parallel?
#
# -if the indices you are using take less than 2 GB of space, and you have at least
#  as much physical memory as indices, then you want this enabled.
#
# -if you are using a 64-bit machine and you have enough physical memory to contain
#  the indices you are using, then you want this enabled.
# 
# -otherwise, leave it commented-out.

#inparallel

# If no scale estimate is given, use these limits on field width.
# minwidth 0.1
# maxwidth 180

# If no depths are given, use these:
#depths 10 20 30 40 50 60 70 80 90 100

# Maximum CPU time to spend on a field, in seconds:
# default is 600 (ten minutes), which is probably way overkill.
cpulimit 300

# In which directories should we search for indices?
add_path /usr/share/astrometry
add_path /home/gina/.local/share/kstars/astrometry

# Load any indices found in the directories listed above.
autoindex

## Or... explicitly list the indices to load.
#index index-219
#index index-218
#index index-217
#index index-216
#index index-215
#index index-214
#index index-213
#index index-212
#index index-211
#index index-210
#index index-209
#index index-208
#index index-207
#index index-206
#index index-205
#index index-204-00
#index index-204-01
#index index-204-02
#index index-204-03
#index index-204-04
#index index-204-05
#index index-204-06
#index index-204-07
#index index-204-08
#index index-204-09
#index index-204-10
#index index-204-11
#index index-203-00
#index index-203-01
#index index-203-02
#index index-203-03
#index index-203-04
#index index-203-05
#index index-203-06
#index index-203-07
#index index-203-08
#index index-203-09
#index index-203-10
#index index-203-11
#index index-202-00
#index index-202-01
#index index-202-02
#index index-202-03
#index index-202-04
#index index-202-05
#index index-202-06
#index index-202-07
#index index-202-08
#index index-202-09
#index index-202-10
#index index-202-11
#index index-201-00
#index index-201-01
#index index-201-02
#index index-201-03
#index index-201-04
#index index-201-05
#index index-201-06
#index index-201-07
#index index-201-08
#index index-201-09
#index index-201-10
#index index-201-11
#index index-200-00
#index index-200-01
#index index-200-02
#index index-200-03
#index index-200-04
#index index-200-05
#index index-200-06
#index index-200-07
#index index-200-08
#index index-200-09
#index index-200-10
#index index-200-11

 

[alacant]

2 minutes ago, Gina said:

# In which directories should we search for indices?

add_path /usr/share/astrometry

add_path /home/gina/.local/share/kstars/astrometry

OK, that's fine.

So if the indices are not at:

/usr/share/astrometry

 are they at :

/home/gina/.local/share/kstars/astrometry

?

 

Edited July 10, 2019 by alacant

[Gina]

3 minutes ago, alacant said:

Hi. They don't necessarily have to be there, but usually are if you installed them via the Debian packages. 

If you installed them via EKOS, they'll usually be at:

/home/gina/.local/kstars/astrometry

Here are the relevant lines in astrometry.cfg:

# In which directories should we search for indices?
add_path /usr/share/astrometry
add_path /home/steve/.local/share/kstars/astrometry

HTH

Aha!!

[Gina]

Looks like that's alright then.

[alacant]

3 minutes ago, Gina said:

Aha!!

Bingo!

Now check you have the correct files for your telescope and that you have read permission;)

Cheers

Edited July 10, 2019 by alacant

[Gina]

I've set FOV to 2000' x 1400' which seems to be the maximum that astrometry will solve.

And here are permissions for one of the index files :-

[Gina]

My FOV with the 28mm lens and ASI 1600MM-Cool camera is 2172.26' x 1642.26' as shown by :-

Is the fact that one dimensions exceeds the 2000' of the widest index file any problem?  Otherwise, everything looks fine.

[Gina]

Had a thought.  Cropped an image saved earlier and used that for Load & Slew and it worked - the mount slewed to a new position (below the horizon but it's about 10 hours earlier than the time-of-day of the original image so expected and agrees with KStars sky view).  Strangely, KStars set the FOV to 3' x 1.4' so it seems that doesn't mean the imaging FOV.

[Gina]

I can't be 100% sure that the rig is pointing exactly where it should be but at least the Solver worked on the saved image.  It can't have taken a new image and solved that as the sky is not in view (roof closed).  I guess it must be relying on the mount encoders to know where it is.  Proof of the pudding will be next time we get some clear night sky and can take an image to see where the rig is actually pointing.  From the weather forecast maybe Friday night.

Still looks like the image needs to be smaller than 2000' in both axes.

[Gina]

Edited July 10, 2019 by Gina

[alacant]

37 minutes ago, Gina said:

image needs to be smaller than 2000' in both axes.

Hi. Looking good. Best to let EKOS determine the FOV. All you have to do is enter your focal length, sensor resolution and pixel size. The defaults always work I find. Once it's working consistently, then you can start tweaking. 

Good luck with the clouds and do report back:)

 

**EDIT. Why not have a go with the simulator profile? Put in your camera and focal length in the indi panel and snap away. Good for testing your setup and no need for clear skies.

 

 

Edited July 10, 2019 by alacant

[Gina]

I shall certainly report back.  I guess few imagers use as wide (36° x  27°) FOV as me.  In fact most of my imaging is likely to be with a smaller FOV.

2000' = 33.3° which is pretty wide.  I could cut down my FOV a bit by using ROI - it's only 10% less.

Edited July 10, 2019 by Gina

[Gina]

Been busy stacking calibration files in PI.  Bias and 5 sets of Darks with various exposure times - 30s, 45s, 60s, 120s and 240s.  Now having a cuppa break!...