I'd rather think there was something left in your kstars/build folder. I always build out-of-tree in a new created folder to make sure cmake doesn't use old cached info...

As for slewing: Yes, it solves (fast!), then slews (to the correct target :) ), but then runs the simulator CCD, and tries to verify - which fails. Then the 'Load & Slew' button stays disabled. So I first have to click some other location in the star map, 'goto' there, and only then I can try another image for solving....
Gets tiring after a while :ohmy:

Read More...

The stellarsolver 'issues' are only warnings about unused stuff, the error is from the fits viewer:

/home/ubuntu/Projects/kstars/kstars/kstars/fitsviewer/fitsdata.h:162:33: error: ‘const struct FITSImage::Statistic’ has no member named ‘channels’

Not sure what's wrong though - compiled w/o errors here.

Can only test it with the simulator, and it has problems solving those, maybe because of the small field? Two of my load&slew objects (Cocoon, Helix) loaded&solved fast.

Somewhat nasty: If the solver fails on the captured frame, the 'load&slew' button stays disabled until I do another slew...

Read More...

Peter Sütterlin replied to the topic 'Dithering....' in the forum. 5 days ago

Hmm, I'd say this is the 'rain' I had been talking of. You can see that the 'stripes' are in RA direction.

The pattern is made from so-called FPN, fixed pattern noise. Think of it similar as hot pixels, just that their deviation is much less. So you do not see it in a single exposure, as they are randomly distributed. But if you start displacing it in only one direction those deviating pixels will start to form the lines you see there. This is why dithering isn't really effective in RA-only guiding.

If I understand correct, for the first image dithering failed. Would really be important to know if it only claims it failed, or if the dither really did not happen. As you say it works with Stellarmate - is that indeed also with SEP and multi-star guiding?

Read More...

Peter Sütterlin replied to the topic 'Dithering....' in the forum. 5 days ago

gilesco wrote: Dithering will try to move in a random direction, I'm wondering that if your Dec axis is fixed, whether dithering is going to help you, I think it will just give you oblong stars, as the dither can only move in a single axis.


No, why would it create oblong stars? It's not moving during the exposure....
But what usually happens is that RA-only dithering will not be able to remove the 'rain', the stripy appearance coming from fixed pattern noise of the camera. At least you'd need a stronger dithering (larger max), and much more images.

Read More...

Peter Sütterlin replied to the topic 'Dark Flats' in the forum. 1 week ago

Well, Flat Darks are not different from other Darks, is it? But if you only want to easily see which type they are, just add the exposure time or a timestamp to the filename for those type of darks?

Read More...

Peter Sütterlin replied to the topic 'Dithering....' in the forum. 1 week ago

I noticed that SEP can have issues with color camera images. I'd try to use 2x2 binning and see if that improves things...

Read More...

When I try to compile the current stellarsolver my compiler (GCC 10.0) complains about missing includes in stellarsolver/sep/extract.cpp (#include <cstdio>) and stellarsolver/sep/lutz.cpp (#include <cstdlib>), else sprintf and malloc are not declared....

As for kstars, should I use 'master' or 'extractor' for testing?

Read More...

Todays version (*) is also crashing for me, on the file that last time (2 days ago) was solved, though only after very long time.
Tried a gdb backtrace - not sure if it's useful

(*) kstars-3.5.0-1537_ga8b786e88.x86_64 libstellarsolver-1.4-113_g0c587a6.x86_64

Read More...

Ah yes, now that you mention it - I had also tried binning, and that had improved results, too. I wasn't sure if binning for focus is a good idea - but given the pixel size (mine is an ASI183MC - guess that's the same chip as yours?) it's probably safe, at least for my 910mm FL...

Read More...

Quick question: What camera do you have? Is it a color one?

I recently got my first OSC, and have seen similar issues with SEP selecting weird/faint stars in AF. Switching to another algorithm for star detection did give much more reasonable selections. You can use multistar also without using SEP. Next thing I want to try is switching the camera to greyscale mode for AF.....

Read More...

xsnrg wrote: If the autofocus routine uses the offset as a starting point for the auto-focus run, that would be wonderful though.


Hmm, but it's doing that, isn't it? At least for me, the offset is applied as soon as the filter changes. Then the AF is triggered, starting from that setting.
(I have AF on filter change set for all filters, and the respective relative offsets in the table).

As for NB, it might help to use near-by BB filters. I.e., for me the focus for Hα and R is basically identical. I don't have OIII, but could imagine its focus would be very similar to G? (At least if the filters are from the same manufacturer and have the same thickness). Then do a 'fake' BB exposure to trigger AF (AF on filter change set), then switch to NB (set same offset, no AF on change).

I myself do AF on Hα, but I do have a 6nm one. That is enough to get sufficient signal in 8s exposures (ASI1600 at unity gain).

Read More...

sterne-jaeger wrote: As far as I understand it, theoretically it could happen with all mounts. With my mount for example, I've never experienced it. But from time to time I experience it during alignment, but there it does not cause any problems other that solving needs to be restarted - which happens automatically.


Ah, I think I've seen that, too, on my CEM60EC. Sometimes, in the refinement step, capture of the control frame fails, claiming the mount is slewing. So could it be that there the previous state (slew) is still reported, although the mount is already tracking again?
During flip, I think I don't have seen that so far....

Read More...

Peter Sütterlin created a new topic ' Stellarsolver' in the forum. 3 weeks ago

So I noticed stellarsolver finally made it into kstars. Great work Rob!

I've compiled latest git of both, to have a quick test. It's daylight at the moment, so no real star tests. I only fired up the simulators, and then wanted to use 'Load&Slew', using one of the images of last week as target. That was quite a disappointment. In the default setting it seemed to use 4 threads, and it chewed some 3-4 minutes on the image. I switched back to the old, local astrometry.net. That one's set up to use all 8 threads, and finished faster (2 minutes). But still, this is about the longest time I've seen it using here so far.

So I downgraded to the previous version (kstars-3.5.0-1442_gd604b2835). That one (also using the local installation of astrometry.net) solved the same image in 2 seconds. I assume this is because it found WCS info in the header and used that as starting point (?). So there's hope that things work better on real-sky plate solving, using the mount pointing and FOV of the camera as starter. Not sure though why the local version also took so long in the new setup. Is stellarsolver hiding info from astrometry.net that it did get in the old version?

Read More...