I'v seen that if I point my scope at the moon the rate changes to moon rate automagically
I think I found a solution for the issue with colors, take a look here: free-astro.org/index.php?title=Siril:FITS_orientation/en
It seems it have something to do with a FITS-Keyword "TOP-DOWN", I can not test if I'm correct about this because I don't have a color camera.
Not sure if Ekos really 'know' how the image is transferred from camera sensor if it is read from "TOP-DOWN" or "BOTTOM-UP" and then sets the keyword according to that, maybe Jasem could chime in and tell us.
Of course there could be a setting like there is for "Auto stretch" for which way the image is displayed if somebody wold like to have a specific orientation in the fits viewer.
Well, let's clear up the issue with upsidedown images.
I don't think there is a bug in KStars FITSviewer, it's just a matter of camera rotation and propably how the image is read from the camera, it could be different for other cameras but i use only SX cameras so I really don't know, in my case I usually rotate my camera upsidedown.
I made some screenshots to show how my SX camera displays images.
Images show the result from different resolves by name of the image so you can compare and come to a conclusion, please take a look.
Seeing Alfred's guiding makes me wonder what the problem could be, I thought it was my mount but couldn't find anything wrong..
This is from another session..
I guess this is a example of "freak aberrations" that happens sometimes..
Now I've installed indi-allsky on Ubuntu 20.04.4, installation went fine but for some reason I had to install opencv manually.
Trying to connect to localhost with Firefox it asks for User/Password.. ?? I tried using my accounts but it didn't accept my credentials, so what credentials do I suppose to use ??
Trying to run for first time using KStars version 3.5.7, Build: 2022-03-04T10:42:19Z but when trying to take a image with SXVR-H9 KStars just crash everything else seems to work, noticed that a image using the LodestarX2 within the guiderwindow in Ekos does not crash but when the fitsviewer comes up then KStars just dies.
Everything is up to date both Ubuntu, KStars and also the drivers.
Runing in gdb this is the result:
Thread 1 "kstars" received signal SIGSEGV, Segmentation fault.
0x00007ffff5210202 in QString::operator=(QString const&) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#0 0x00007ffff5210202 in QString::operator=(QString const&) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#1 0x0000555555fd43ae in SSolver::Parameters::operator= (this=0x55555d4245a8)
#2 StellarSolver::setParameters (parameters=..., this=0x55555d4244e0)
#3 FITSSEPDetector::findSourcesAndBackground (this=0x55555e625890, boundary=...)
#4 0x0000555555fd1bfa in QtConcurrent::StoredMemberFunctionPointerCall1<bool, FITSSEPDetector, QRect const&, QRect>::runFunctor (this=0x55555e5d88f0)
#5 0x000055555573d87d in QtConcurrent::RunFunctionTask<bool>::run (this=0x55555e5d88f0)
#6 0x00007ffff5191d62 in QThreadPoolPrivate::stealAndRunRunnable(QRunnable*) ()
#7 0x00007ffff5196262 in QFutureInterfaceBase::waitForFinished() () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#8 0x00005555558cb925 in QFuture<bool>::waitForFinished (this=0x7fffffffd200)
#9 FITSView::searchStars (this=0x55555de4c180) at ./kstars/fitsviewer/fitsview.cpp:1865
#10 0x0000555555a25fe5 in FITSTab::processData (this=0x55555e401270) at ./kstars/fitsviewer/fitstab.cpp:473
#11 0x0000555555a297a7 in FITSTab::loadData (this=this@entry=0x55555e401270, data=...,
mode=mode@entry=FITS_NORMAL, filter=filter@entry=FITS_NONE) at ./kstars/fitsviewer/fitstab.cpp:532
#12 0x0000555555a140b3 in FITSViewer::loadData (this=0x55555e0d21c0, data=..., imageName=...,
tab_uid=tab_uid@entry=0x7fffffffd414, mode=mode@entry=FITS_NORMAL, filter=filter@entry=FITS_NONE,
--Type <RET> for more, q to quit, c to continue without paging--
previewText=...) at ./kstars/fitsviewer/fitsviewer.cpp:462
#13 0x00005555559e92d0 in ISD::CCD::handleImage (this=0x55555d4c8970, targetChip=0x55555d4c1690, filename=...,
bp=<optimized out>, data=...) at /usr/include/c++/9/bits/atomic_base.h:413
#14 0x00005555559ed0a1 in ISD::CCD::processBLOB (this=0x55555d4c8970, bp=<optimized out>)
#15 0x00007ffff5382328 in QMetaObject::activate(QObject*, int, int, void**) ()
#16 0x0000555555936636 in ClientManager::newINDIBLOB (this=<optimized out>, _t1=<optimized out>)
#17 0x00007ffff5382c2a in QObject::event(QEvent*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#18 0x00007ffff5d70a66 in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
#19 0x00007ffff5d7a0f0 in QApplication::notify(QObject*, QEvent*) ()
#20 0x00007ffff535680a in QCoreApplication::notifyInternal2(QObject*, QEvent*) ()
#21 0x00007ffff5359488 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ()
#22 0x00007ffff53aee37 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#23 0x00007ffff442617d in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#24 0x00007ffff4426400 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#25 0x00007ffff44264a3 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#26 0x00007ffff53ae435 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
--Type <RET> for more, q to quit, c to continue without paging--
#27 0x00007ffff53553ab in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
#28 0x00007ffff535d116 in QCoreApplication::exec() () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#29 0x00005555556ccdf4 in main (argc=<optimized out>, argv=<optimized out>) at ./kstars/main.cpp:382
So what do I do now ??
For now the keyword looks like this when taking long exposures: DATE-OBS= '2021-11-05T22:02:00.034' / 2021-11-05T22:02:00.034
I guess the first time and date is when the exposure starts, so could we have the second part showing when the exposure is finished ? the above data is taken from a 120 second exposure.
I ran autofocus to to get new focus settings for a lower temperature, but the old values from previous autofocus keeps coming up even if the new values are set ??
Also the new values is filled in the wrong field, they should be in "Offset" but gets to the "Flat focus position" instead for some reason.
I moved the new values to their correct places but the old values is what the focuser uses anyway.
Take a look: www.youtube.com/watch?v=5Ty5BJUbDxg
Using KStars Version 3.5.5, Build: 2021-11-02T15:31:59Z
Ok, thank you for answering Jasem.
I'm just wondering if the offset for filters after autofocus should be filled in or are they needed at all ?
It seems that the offsets are not filled in after running autofocus, as I remember the numbers where there in previous versions but not sure about that.
Now I'm using KStars 3.3.3 Stable. I supply image from the "userdb.sqlite"
I tried using a 1,5 Barlow on my 300 scope long time ago but it was not possible to resolve the images so I gave up, have you tried to send the image to astrometry.net for resolving ??
I wish the Rapid guide was enabled and usable, i'ts a great feature.
This is a tricky one but my guess is that the wobbly line is a geostationary (TV broadcast) satellite, the stars are moving but the satellite is not, and the cause of the line is wobbly is because of the guiding.