KStars v3.5.0 Release Date?
Hy Murveit
murveit at gmail.com
Wed Oct 21 10:40:20 BST 2020
Agree with your idea. Just a few details:
- Will need a profile for the HFR calculation too.
- I think all-stars is a bad default, probably some middle-of-the-way
setting. AllStars is way to computation intensive (could take minutes on a
RPi).
Hy
On Wed, Oct 21, 2020 at 2:23 AM Jasem Mutlaq <mutlaqja at ikarustech.com>
wrote:
> Thank Hy. Ok this brings up discussion on the profiles themselves. I think
> most are in agreement that it is confusing to to list all profiles in both
> focus/align (and soon guide) when they don't share much together.
> "BigStars" doesn't make sense in Align module and "Fast Solving" doesn't
> make sense in Align. I thought about this and I propose this solution.
>
> 1. KStars will not use ANY profiles from StellarSolver.
> 2. KStars will create "default Profiles" for each module.
> 3. We will have 3 INI files. FocusStellarSolverProfiles.ini,
> GuideStellarSolverProfiles.ini, and AlignStellarSolverProfiles.ini (we can
> also called FocusSSP.ini for short...etc)
> 4. Each module would load the profile names from the corresponding INI
> file.
> 5. in FITS detector, I added QVariantMap settings which is used to set all
> kind of settings. To tell it to use a specific profile we set two parameters
> 5.1. profileGroup: Focus, Guide, Align
> 5.2. profileName: e.g. "Medium Stars".
> 6. FITS Detector would then try to first check if these parameters if set
> and then load the appropriate profiles, and then set the solver to use them.
> 7. If it fails, it would default to all ALL_STARS profile.
>
> Please let me know what you think.
>
> --
> Best Regards,
> Jasem Mutlaq
>
>
>
> On Wed, Oct 21, 2020 at 12:13 PM Hy Murveit <murveit at gmail.com> wrote:
>
>> Wolfgang,
>>
>> Jasem and I figured out what that issue is, though not quite yet fixed in
>> the code.
>> The HFR calculation was using Rob's "AllStars" profile which literally
>> puts no constraint
>> on the number of stars detected or how many of those have their HFRs
>> calculated
>> (and it seems to be the default profile, at least for the code that calls
>> the fitsdata SEP star extraction).
>> In a dense star field that could be 10K or 20K stars. Should really be
>> set to 50 - 200 for HFR.
>>
>> Hy
>>
>> On Tue, Oct 20, 2020 at 11:44 PM Wolfgang Reissenberger <
>> sterne-jaeger at openfuture.de> wrote:
>>
>>> I had the same problem when capturing a wide field around NGC6888. After
>>> downloading the image it took very long (minutes) until the image was
>>> displayed. I did not drill down deeper, but I think it is the HFR
>>> calculation. I am running it on a RPi 4 with Raspbian 10.
>>>
>>> Cheers
>>> Wolfgang
>>>
>>> Am 21.10.2020 um 06:24 schrieb Hy Murveit <murveit at gmail.com>:
>>>
>>> BTW, FWIW, I started running again. It finished the first image and went
>>> into its 3-minute-long (this time) star detection
>>> on the sub that I described above as 'Major Problem'. I noticed that it
>>> was using 3 or 4 CPUs at near 100% to do this.
>>> I doubt that this was ever multi-threaded before. So, apparently, in
>>> addition to the SEP library running in a separate thread,
>>> the SEP library is also running multiple processes on its own. These
>>> both seem like likely suspects for these memory issues.
>>>
>>> Hy
>>>
>>> On Tue, Oct 20, 2020 at 9:01 PM Hy Murveit <murveit at gmail.com> wrote:
>>>
>>>> Started testing Jasem's change tonight, 30 minutes ago.
>>>> TL;DR It runs better than before, but unfortunately still crashes. A
>>>> few other bugs too.
>>>>
>>>> *ISSUES*
>>>>
>>>> *Most Major problem*. Worked for a little while (a few minutes?) which
>>>> is much better than before when it crashed pretty much at the start of
>>>> guiding, but then still segv'd. Started again in gdb in hopes of getting a
>>>> stack trace. Running for a while...segv'd after about 10 minutes. See
>>>> pretty unhelpful stack track below.
>>>>
>>>> In summary, I ran it twice, crashed after a couple minutes the first
>>>> time, crashed after 10 minutes the 2nd time. Always seems to crash in the
>>>> guider's request for star extraction. Can we run star extraction on the
>>>> normal thread instead of the threading we're doing?
>>>>
>>>> *Major problem*. Computing the HFR after my sub (8-minute Ha image) used
>>>> to take 1-5 seconds. It needs to detect stars, calculate individual
>>>> HFRs, etc
>>>> I did some work to optimize the time for this. It took 130+ seconds
>>>> for my first image with stellarsolver! I can try and help fix that somehow.
>>>>
>>>> *Minor problem*. I noticed is that in the guideview, even though I
>>>> checked and am 100% sure it was off, the little button called 'Detect Stars
>>>> in Image' in the guideview window got enabled and there are little red
>>>> circles over the detected stars. This is a little bug--didn't used to be
>>>> this way.
>>>>
>>>>
>>>> Wish I had better news,
>>>> Hy
>>>>
>>>> *End of GDB output including crash and backtrace.*
>>>>
>>>> [New Thread 0x9ec56090 (LWP 16299)]
>>>> [Thread 0x9ec56090 (LWP 16299) exited]
>>>> [New Thread 0x9ec56090 (LWP 16333)]
>>>> [Thread 0x9ec56090 (LWP 16333) exited]
>>>> [New Thread 0x9ec56090 (LWP 16364)]
>>>> [Thread 0x9ec56090 (LWP 16364) exited]
>>>> [New Thread 0x9ec56090 (LWP 16398)]
>>>> [Thread 0x9ec56090 (LWP 16398) exited]
>>>> [New Thread 0x9ec56090 (LWP 16432)]
>>>> [Thread 0x9ec56090 (LWP 16432) exited]
>>>> [New Thread 0x9ec56090 (LWP 16462)]
>>>> [Thread 0x9ec56090 (LWP 16462) exited]
>>>> [New Thread 0x9ec56090 (LWP 16492)]
>>>> [Thread 0x9ec56090 (LWP 16492) exited]
>>>> [New Thread 0x9ec56090 (LWP 16526)]
>>>> [Thread 0x9ec56090 (LWP 16526) exited]
>>>> [New Thread 0x9ec56090 (LWP 16531)]
>>>> [Thread 0x9ec56090 (LWP 16531) exited]
>>>> [New Thread 0x9ec56090 (LWP 16560)]
>>>> [Thread 0x9ec56090 (LWP 16560) exited]
>>>> [New Thread 0x9ec56090 (LWP 16587)]
>>>>
>>>> Thread 35 "Thread (pooled)" received signal SIGSEGV, Segmentation fault.
>>>> [Switching to Thread 0xa4239090 (LWP 5157)]
>>>> 0xb6fbc14c in memset () from
>>>> /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so
>>>> (gdb) bt
>>>> #0 0xb6fbc14c in memset () from
>>>> /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so
>>>> #1 0xb421a500 in SEP::Deblend::deblend (this=0x67985398,
>>>> objlistin=objlistin at entry=0xa423855c, l=l at entry=0,
>>>> objlistout=objlistout at entry=0xa4238454,
>>>> deblend_nthresh=deblend_nthresh at entry=32,
>>>> deblend_mincont=0.0050000000000000001, minarea=minarea at entry=5,
>>>> lutz=0x4d348778)
>>>> at /home/pi/Projects2/stellarsolver/stellarsolver/sep/deblend.cpp:77
>>>> #2 0xb421ae84 in SEP::Extract::sortit (this=this at entry=0x7fef5478,
>>>> info=info at entry=0x66ae1218,
>>>> objlist=0xa423855c, objlist at entry=0xa4238554, minarea=5,
>>>> minarea at entry=-1541175988, finalobjlist=0x66be0218,
>>>> finalobjlist at entry=0x0, deblend_nthresh=32, deblend_nthresh at entry=3,
>>>> deblend_mincont=0.0050000000000000001,
>>>> gain=1) at /usr/include/c++/8/bits/unique_ptr.h:342
>>>> #3 0xb421cbc0 in SEP::Extract::sep_extract (this=0x7fef5478, this at entry=0xa4238896,
>>>> image=0x1a5e8308,
>>>> image at entry=0xa4238948, thresh=thresh at entry=8.42488956,
>>>> thresh_type=thresh_type at entry=1, minarea=-1541175988,
>>>> minarea at entry=5, conv=conv at entry=0x66be01b8, convw=<optimized
>>>> out>, convw at entry=3, convh=convh at entry=3,
>>>> filter_type=<optimized out>, filter_type at entry=0,
>>>> deblend_nthresh=32, deblend_cont=0.0050000000000000001,
>>>> clean_flag=1, clean_param=1, catalog=0xa423889c, catalog at entry
>>>> =0xa4238894)
>>>> at
>>>> /home/pi/Projects2/stellarsolver/stellarsolver/sep/extract.cpp:643
>>>> #4 0xb41ebee8 in InternalSextractorSolver::extractPartition
>>>> (this=0x76e6468, parameters=...)
>>>> at /usr/include/c++/8/cmath:475
>>>> #5 0xb41efa6c in non-virtual thunk to
>>>> QtConcurrent::RunFunctionTask<QList<FITSImage::Star> >::run() ()
>>>> at /usr/include/c++/8/bits/exception.h:63
>>>> #6 0xb4855f30 in ?? () from
>>>> /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
>>>> #7 0xb485eb58 in ?? () from
>>>> /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
>>>> #8 0xb42c2494 in start_thread (arg=0xa4239090) at pthread_create.c:486
>>>> #9 0xb3979578 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:73
>>>> from /lib/arm-linux-gnueabihf/libc.so.6
>>>> Backtrace stopped: previous frame identical to this frame (corrupt
>>>> stack?)
>>>> (gdb)
>>>>
>>>> *Here's the end of the log. Clearly in a guide-frame's star extraction.*
>>>>
>>>> [2020-10-20T20:39:36.043 PDT DEBG ][ org.kde.kstars.indi] -
>>>> EQMod Mount : "[SCOPE] GetRAEncoder() = 10576388 "
>>>> [2020-10-20T20:39:36.060 PDT DEBG ][ org.kde.kstars.indi] -
>>>> EQMod Mount : "[SCOPE] Current encoders RA=10576388 DE=9885062 "
>>>> [2020-10-20T20:39:37.115 PDT DEBG ][ org.kde.kstars.indi] -
>>>> processBLOB() mode 2
>>>> [2020-10-20T20:39:37.122 PDT DEBG ][ org.kde.kstars.fits] -
>>>> Reading FITS file buffer ( "1.2 MiB" )
>>>> [2020-10-20T20:39:37.188 PDT DEBG ][ org.kde.kstars.ekos.guide] -
>>>> Received guide frame.
>>>> [2020-10-20T20:39:37.188 PDT DEBG ][ org.kde.kstars.ekos.guide] -
>>>> Multistar: findTopStars 25
>>>> [2020-10-20T20:39:37.192 PDT DEBG ][ org.kde.kstars.indi] -
>>>> EQMod Mount : "[SCOPE] Compute local time: lst=21.51869180 (21:31:07.29) -
>>>> julian date=2459143.65248889 "
>>>> [2020-10-20T20:39:37.209 PDT DEBG ][ org.kde.kstars.indi] -
>>>> EQMod Mount : "[SCOPE] GetRAEncoder() = 10576506 "
>>>> [2020-10-20T20:39:37.211 PDT DEBG ][ org.kde.kstars.indi] -
>>>> EQMod Mount : "[SCOPE] Current encoders RA=10576506 DE=9885062 "
>>>>
>>>>
>>>> *Odd message*: Saw this as the last log line in the first crash:
>>>> [2020-10-20T20:14:08.358 PDT WARN ][ default] -
>>>> QObject::~QObject: Timers cannot be stopped from another thread
>>>>
>>>> also saw these earlier in a log, never seen them before, dont know if
>>>> relevant:
>>>> [2020-10-20T20:15:57.329 PDT WARN ][ default] -
>>>> QObject::connect: invalid null parameter
>>>> [2020-10-20T20:15:57.329 PDT WARN ][ default] -
>>>> QObject::connect: invalid null parameter
>>>> [2020-10-20T20:15:58.014 PDT WARN ][ default] -
>>>> QObject::connect: signal not found in Ekos::Mount
>>>> [2020-10-20T20:15:58.015 PDT DEBG ][ org.kde.kstars.ekos.capture] -
>>>> Registering new Module ( "Mount" )
>>>> [2020-10-20T20:15:58.017 PDT WARN ][ default] -
>>>> QObject::connect: invalid null parameter
>>>> [2020-10-20T20:15:58.017 PDT WARN ][ default] -
>>>> QObject::connect: invalid null parameter
>>>> [2020-10-20T20:15:59.315 PDT WARN ][ default] -
>>>> QObject::disconnect: Unexpected null parameter
>>>>
>>>> On Tue, Oct 20, 2020 at 1:17 PM Robert Lancaster <rlancaste at gmail.com>
>>>> wrote:
>>>>
>>>>> Yes, please, I agree! I am working on fixing up the options profile
>>>>> now.
>>>>>
>>>>> On Oct 20, 2020, at 12:11 PM, Hy Murveit <murveit at gmail.com> wrote:
>>>>>
>>>>> I'd like to suggest that since the main KStars branch still core dumps
>>>>> while guiding (every time for me) and perhaps there are other issues with
>>>>> flats, we should push back the release date for at least two weeks. I
>>>>> believe we need a stable two weeks of user testing before any major release.
>>>>>
>>>>> I know Jasem and Robert are working very hard to fix this, and in no
>>>>> way is this a knock on their work, just a desire to make this a stable
>>>>> release.
>>>>>
>>>>> I would propose that there only be bug fix commits during those two
>>>>> weeks.
>>>>>
>>>>> Comments?
>>>>> Hy
>>>>>
>>>>> On Thu, Oct 15, 2020, 9:55 PM Hy Murveit <murveit at gmail.com> wrote:
>>>>>
>>>>>> Core dump again with the 'load all indexes' flag unchecked. Am
>>>>>> running in gdb now.
>>>>>> ...
>>>>>>
>>>>>> Also, it doesn't seem to remember that checkmark, nor the profile
>>>>>> type (top menu under ""Options Profiles")--please add that to the todo list
>>>>>> too.
>>>>>> Also, it's my impression that the solver takes longer than it used
>>>>>> to. Could it be that the binning isn't being honored?
>>>>>> Perhaps you derived your speed by threading, and I'm defeating that
>>>>>> by unchecking the box?
>>>>>> ...
>>>>>>
>>>>>> Here's the backtrace, as it crashed again--this time in GDB.
>>>>>>
>>>>>> I guess I'm done testing for the night.
>>>>>> Hy
>>>>>>
>>>>>> log-odds ratio 0.335153 (1.39815), 0 match, 0 conflict, 0
>>>>>> distractors, 39 index.
>>>>>> RA,Dec = (318.284,63.9039), pixel scale 3.84851 arcsec/pix.
>>>>>> log-odds ratio 0.335153 (1.39815), 0 match, 0 conflict, 0
>>>>>> distractors, 39 index.
>>>>>> RA,Dec = (318.284,63.9039), pixel scale 3.84851 arcsec/pix.
>>>>>> log-odds ratio 34.6274 (1.09262e+15), 18 match, 0 conflict, 120
>>>>>> distractors, 37 index.
>>>>>> RA,Dec = (325.282,58.0472), pixel scale 3.97646 arcsec/pix.
>>>>>> Hit/miss: Hit/miss:
>>>>>> ----+-----------+--+--+------+---------------+---+------+----+--+--+---------------+-----------+----
>>>>>> [Thread 0x83925090 (LWP 1384) exited]
>>>>>>
>>>>>> Thread 38 "Thread (pooled)" received signal SIGSEGV, Segmentation
>>>>>> fault.
>>>>>> [Switching to Thread 0x92c2c090 (LWP 31265)]
>>>>>> belong (corenb=corenb at entry=0, coreobjlist=coreobjlist at entry=0xb42b9afc
>>>>>> <debobjlist>, shellnb=shellnb at entry=0,
>>>>>> shellobjlist=0x47d6cbc) at
>>>>>> /home/pi/Projects/stellarsolver/stellarsolver/sep/deblend.c:378
>>>>>> 378 int xc=PLIST(cpl+cobj->firstpix,x),
>>>>>> yc=PLIST(cpl+cobj->firstpix,y);
>>>>>> (gdb) bt
>>>>>> #0 belong (corenb=corenb at entry=0, coreobjlist=coreobjlist at entry=0xb42b9afc
>>>>>> <debobjlist>,
>>>>>> shellnb=shellnb at entry=0, shellobjlist=0x47d6cbc)
>>>>>> at /home/pi/Projects/stellarsolver/stellarsolver/sep/deblend.c:378
>>>>>> #1 0xb4217178 in deblend (objlistin=0xa8cb2b00, objlistin at entry=0x92c2b1c4,
>>>>>> l=l at entry=0, objlistout=0x0,
>>>>>> objlistout at entry=0x92c2b0c4, deblend_nthresh=75328520,
>>>>>> deblend_nthresh at entry=0,
>>>>>> deblend_mincont=0.0050000000000000001, minarea=minarea at entry=5)
>>>>>> at /home/pi/Projects/stellarsolver/stellarsolver/sep/deblend.c:125
>>>>>> #2 0xb4217b4c in sortit (info=info at entry=0xa8cc52b0,
>>>>>> objlist=0x92c2b1c4, objlist at entry=0x92c2b1bc, minarea=5,
>>>>>> minarea at entry=2, finalobjlist=0xa8c296d8, finalobjlist at entry=0x0,
>>>>>> deblend_nthresh=32,
>>>>>> deblend_nthresh at entry=3, deblend_mincont=0.0050000000000000001,
>>>>>> gain=1)
>>>>>> at /home/pi/Projects/stellarsolver/stellarsolver/sep/extract.c:777
>>>>>> #3 0xb4219e80 in sep_extract (image=0x5b8d6c
>>>>>> <NewFOV::slotDetectFromINDI()+324>, image at entry=0x8ecf2008,
>>>>>> thresh=thresh at entry=54.3094788, thresh_type=thresh_type at entry=1,
>>>>>> minarea=2, minarea at entry=5,
>>>>>> conv=0xa8cc7100, convw=<optimized out>, convw at entry=3,
>>>>>> convh=convh at entry=3, filter_type=<optimized out>,
>>>>>> filter_type at entry=0, deblend_nthresh=32,
>>>>>> deblend_cont=0.0050000000000000001, clean_flag=1, clean_param=1,
>>>>>> catalog=0x92c2b514, catalog at entry=0x92c2b50c)
>>>>>> at /home/pi/Projects/stellarsolver/stellarsolver/sep/extract.c:632
>>>>>> #4 0xb41edc34 in InternalSextractorSolver::runSEPSextractor
>>>>>> (this=this at entry=0xa8cb9e70)
>>>>>> at /usr/include/c++/8/cmath:475
>>>>>> #5 0xb41eed90 in InternalSextractorSolver::sextract (this=0xa8cb9e70)
>>>>>> at
>>>>>> /home/pi/Projects/stellarsolver/stellarsolver/internalsextractorsolver.cpp:94
>>>>>> #6 InternalSextractorSolver::run (this=0xa8cb9e70)
>>>>>> at
>>>>>> /home/pi/Projects/stellarsolver/stellarsolver/internalsextractorsolver.cpp:137
>>>>>> #7 0xb420ddd4 in StellarSolver::extract (this=0x9e403bd0,
>>>>>> calculateHFR=calculateHFR at entry=true, frame=...)
>>>>>> at /usr/include/c++/8/bits/atomic_base.h:390
>>>>>> #8 0x00c4c4c8 in FITSSEPDetector::findSourcesAndBackground
>>>>>> (this=0x92c2b89c, boundary=..., bg=bg at entry=0x0)
>>>>>> at /usr/include/arm-linux-gnueabihf/qt5/QtCore/qrect.h:60
>>>>>> #9 0x00c4a32c in
>>>>>> QtConcurrent::StoredMemberFunctionPointerCall2<bool, FITSSEPDetector, QRect
>>>>>> const&, QRect, SkyBackground*, decltype(nullptr)>::runFunctor()
>>>>>> (this=0x424be80)
>>>>>> at
>>>>>> /usr/include/arm-linux-gnueabihf/qt5/QtConcurrent/qtconcurrentstoredfunctioncall.h:911
>>>>>> #10 0x004df0f0 in QtConcurrent::RunFunctionTask<bool>::run
>>>>>> (this=0x424be80)
>>>>>> at /usr/include/arm-linux-gnueabihf/qt5/QtCore/qmutex.h:240
>>>>>> #11 0xb4855f30 in ?? () from
>>>>>> /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
>>>>>> #12 0xb485eb58 in ?? () from
>>>>>> /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
>>>>>> #13 0xb42c2494 in start_thread (arg=0x92c2c090) at
>>>>>> pthread_create.c:486
>>>>>> #14 0xb397c578 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:73
>>>>>> from /lib/arm-linux-gnueabihf/libc.so.6
>>>>>> Backtrace stopped: previous frame identical to this frame (corrupt
>>>>>> stack?)
>>>>>> (gdb)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Oct 15, 2020 at 9:36 PM Hy Murveit <murveit at gmail.com> wrote:
>>>>>>
>>>>>>> OK, you knew this would happen 10 minutes after I sent that...
>>>>>>>
>>>>>>> log-odds ratio 0.69992 (2.01359), 0 match, 0 conflict, 0
>>>>>>> distractors, 17 index.
>>>>>>> RA,Dec = (309.748,70.6162), pixel scale 4.38547 arcsec/pix.
>>>>>>> log-odds ratio 0.69992 (2.01359), 0 match, 0 conflict, 0
>>>>>>> distractors, 17 index.
>>>>>>> RA,Dec = (309.748,70.6162), pixel scale 4.38547 arcsec/pix.
>>>>>>> log-odds ratio 6.76328 (865.472), 0 match, 0 conflict, 0
>>>>>>> distractors, 14 index.
>>>>>>> RA,Dec = (327.788,50.727), pixel scale 4.50653 arcsec/pix.
>>>>>>> log-odds ratio 6.76328 (865.472), 0 match, 0 conflict, 0
>>>>>>> distractors, 14 index.
>>>>>>> RA,Dec = (327.788,50.727), pixel scale 4.50653 arcsec/pix.
>>>>>>> log-odds ratio 53.7431 (2.18938e+23), 18 match, 0 conflict, 100
>>>>>>> distractors, 37 index.
>>>>>>> RA,Dec = (325.28,58.0466), pixel scale 3.97665 arcsec/pix.
>>>>>>> Hit/miss: Hit/miss:
>>>>>>> +------+----+--------++------------+-+---+-----+--------++--+-----------------++--------------+-----
>>>>>>> Segmentation fault
>>>>>>>
>>>>>>>
>>>>>>> It's hard to say what caused it, but if I had to guess, I'd say it
>>>>>>> was run out of memory.
>>>>>>> It happened during a meridian flip, and perhaps StellarSolver is too
>>>>>>> greedy with memory.
>>>>>>> I'll uncheck that load all indexes flag and continue.
>>>>>>>
>>>>>>> Hy
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Oct 15, 2020 at 9:23 PM Hy Murveit <murveit at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Some good news.
>>>>>>>>
>>>>>>>> Tonight, for the first time, I was able to start up the latest
>>>>>>>> (built from latest source as of an hour before I wrote this) KStars and
>>>>>>>> StellarSolver on my RPi4, without issues (so far).
>>>>>>>> I've polar aligned, plate solved, focused, guiding, ... and so far
>>>>>>>> all good. I have never been able to get to this point with this new
>>>>>>>> software, so there's definitely been progress.
>>>>>>>>
>>>>>>>> Still need to bang on it for several nights, I'm sure, but thanks
>>>>>>>> for the hard work!
>>>>>>>>
>>>>>>>> FWIW, I am not using any of the safeguards I was asked to put in
>>>>>>>> (e.g. I have "Use Scale" and "Load All Indexes In Memory" both checked).
>>>>>>>>
>>>>>>>> Hy
>>>>>>>>
>>>>>>>> On Wed, Oct 14, 2020 at 12:35 PM Hy Murveit <murveit at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Rob,
>>>>>>>>>
>>>>>>>>> Thanks for your hard work on this!
>>>>>>>>>
>>>>>>>>> As we discussed privately, I have been unable to get plate-solving
>>>>>>>>> to work with the internal StellarSolver on my RPi4.
>>>>>>>>> Do you think this is unique to me--that is, have others been able
>>>>>>>>> to do so? If this a general problem, then I think Oct 22 is too aggressive
>>>>>>>>> a release target, as we should give our advanced users at least a few weeks
>>>>>>>>> of using the software more-or-less successfully on their target
>>>>>>>>> environments. If this is something specific to me, but others are
>>>>>>>>> successfully plate-solving on RPi's, then perhaps I'm over-reacting.
>>>>>>>>>
>>>>>>>>> FWIW, I just tried to send the full bug report I sent you out to
>>>>>>>>> this devel list, but it got blocked (I guess one of my screenshots was too
>>>>>>>>> large).
>>>>>>>>> Hopefully the moderator will accept my thread soon, and it will be
>>>>>>>>> available to all.
>>>>>>>>>
>>>>>>>>> Until that happens, where should we post bugs related to 3.5.0?
>>>>>>>>> This thread? New threads on kstars-devel?
>>>>>>>>>
>>>>>>>>> Again, I want to emphasize that this is a huge undertaking and I
>>>>>>>>> really appreciate the effort,
>>>>>>>>> Hy
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Oct 14, 2020 at 5:47 AM Robert Lancaster <
>>>>>>>>> rlancaste at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hey guys,
>>>>>>>>>>
>>>>>>>>>> I also agree 100%, we are not ready by Oct. 15th. There are
>>>>>>>>>> still several loose ends that need to be tied up on my end, as well as
>>>>>>>>>> writing up documentation for how to use StellarSolver. Since it is a major
>>>>>>>>>> release of KStars (3.5.0 vs 4.4.4), I think major changes in the UI and the
>>>>>>>>>> functions are perfectly fine, but I agree we don’t want to change
>>>>>>>>>> everything on the user without warning, so we need time to write up
>>>>>>>>>> documentation and make sure everything is clear and simple for the user to
>>>>>>>>>> use. So please let me know what is confusing so that we can try to improve
>>>>>>>>>> that. As for your suggestion that we allow the old code to work during a
>>>>>>>>>> transition period, the issue with that is that the old code is not
>>>>>>>>>> compatible really. But that doesn’t mean that we couldn’t make the UI in
>>>>>>>>>> the Align module *LOOK* like it used to with the combo boxes in align. I
>>>>>>>>>> put the options for which source extraction method, which solving method,
>>>>>>>>>> and which profile to use inside the Options dialog because I thought people
>>>>>>>>>> would access them less often than the other settings in the align module
>>>>>>>>>> and I also want those to be available if we plate solve in other places in
>>>>>>>>>> KStars. But we could also put those same options at the bottom in the
>>>>>>>>>> align module as well, which would make it look close to what it used to
>>>>>>>>>> look like. There is no reason they couldn’t be in both places. It might
>>>>>>>>>> lead to a better transition.
>>>>>>>>>>
>>>>>>>>>> On that note I also agree that we weren’t really ready to put all
>>>>>>>>>> this in KStars master right away, especially because people rely on the
>>>>>>>>>> master branch of the repo for nightly builds, and we needed to test it
>>>>>>>>>> thoroughly before integrating it. I was hoping for more of a testing time
>>>>>>>>>> period where people could test this on my fork or maybe in a different
>>>>>>>>>> branch in the main repo and we could have a nice discussion about how to
>>>>>>>>>> improve it before putting it in the official KStars Master repo. But,
>>>>>>>>>> let's not be too hard on Jasem for that, he is a great guy and works
>>>>>>>>>> incredibly hard to support KStars and INDI and us. It has caused a little
>>>>>>>>>> more pressure on me to fix all these problems and get it all integrated,
>>>>>>>>>> and maybe that was a good thing, because I had mostly finished
>>>>>>>>>> StellarSolver back in June, and I was not integrating it into KStars very
>>>>>>>>>> fast at all. This has pretty much lit a fire under me to get it done. We
>>>>>>>>>> already did complain to him about putting it in the main repo so quickly,
>>>>>>>>>> but it really has worked to get things up and running. So instead of
>>>>>>>>>> focusing on that, now that its done, let's work really hard to polish
>>>>>>>>>> everything up and get it ready for release. I think we could be on track
>>>>>>>>>> for a Oct 22nd release. Please keep testing and I will keep trying to
>>>>>>>>>> perfect things with StellarSolver and its integration with KStars for the
>>>>>>>>>> release. And I am sorry if the integration has caused anybody any issues
>>>>>>>>>> because it wasn’t ready yet.
>>>>>>>>>>
>>>>>>>>>> Thank you very much,
>>>>>>>>>>
>>>>>>>>>> Rob
>>>>>>>>>
>>>>>>>>>
>>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20201021/218d6d7b/attachment-0001.htm>
More information about the Kstars-devel
mailing list