KStars v3.5.0 Release Date?

Thu Nov 12 20:48:02 GMT 2020

I found the bug related to the system always setting the users profile to
profile #0 whenever the profile editor is used.
This affected Guide, Focus & HFR, but not align (which has a different
implementation than the rest, it seems).
There was also a bug where Guide always used the index from focus, not it's
own.

It was a simple change, as you can see in the MR
https://invent.kde.org/education/kstars/-/merge_requests/131
and I tagged it as 3.5.0, but of course I'll leave it to Jasem to decide if
it should be there.

Hy

On Thu, Nov 12, 2020 at 7:43 AM Robert Lancaster <rlancaste at gmail.com>
wrote:

> Hi Eric,
>
> Yes it is mostly in KStars, the editor is in KStars, the default profiles
> are now in KStars because we wanted everyone to have more control over the
> defaults so they can be tweaked in nicely.  But the reason that
> StellarSolver affected the saving of the profile here was because the ==
> operator for comparing the profiles is defined in parameters.cpp and the
> function for conversion to and from an options map for saving or other uses
> is in parameters.cpp in StellarSolver.  I also have a convenience function
> for saving and loading profiles from a file in StellarSolver (but that was
> not affected by this issue).
>
> On Nov 12, 2020, at 9:10 AM, Eric Dejouhanet <eric.dejouhanet at gmail.com>
> wrote:
>
> Sorry if I was convinced the profile management was actually located in
> kstars and not in stellarsolver.
>
> eric.dejouhanet at gmail.com - https://astronomy.dejouha.net
> *De:* rlancaste at gmail.com
> *Envoyé:* 12 novembre 2020 13:18
> *À:* hy at murveit.com
> *Cc:* eric.dejouhanet at gmail.com; mutlaqja at ikarustech.com;
> sterne-jaeger at openfuture.de; kstars-devel at kde.org
> *Objet:* Re: KStars v3.5.0 Release Date?
>
> So the initial keep parameter not being saved was a bug in StellarSolver
> before, but I did fix it yesterday in StellarSolver before I sent those
> messages last night.  You might have missed it but I did mention that I
> fixed it with the other stuff I said.  So if you were using the older
> version yes it was not being saved, but now it should.  It was fixed in
> this commit.
>
>
> https://github.com/rlancaste/stellarsolver/commit/88135877f588c977e190977afca1c5132aacbbe2
>
> It was not being saved previously because we had added the initial keep
> parameter but then hadn’t added it to the equals method nor to the options
> map method used in the file saving.  Sorry I did not do this before, but I
> think what happened was that we were experimenting with the parameter, we
> were debating how it could be used, similarly to how we were in the emails
> yesterday, but we were still thinking about it and hadn’t yet decided
> whether to leave it alone or change it, but then we moved on to other
> things and left it unfinished.  But I did fix it yesterday after your email
> flagging this issue Eric and Hy’s response which reminded me we hadn’t
> finished it.
>
> All that remains here is to add the parameter to the options profile
> editor in KStars now, which I was waiting to do until we discussed whether
> to keep it as is or change the names.  I can add that to KStars next.
>
> Sent from my iPhone
>
> On Nov 12, 2020, at 4:05 AM, Hy Murveit <murveit at gmail.com> wrote:
>
> 
> Eric,
>
> Not sure which issue your were confirming.  The possible initialKeep bug
> would  not be minor, if it's happening it could really make processing time
> long for hfr and focus, like the 20s you're seeing. I'd vote to fix that if
> it's broken. The other one (spinbox) is an annoyance, I'd lean towards
> fixing it now, but if you twisted my arm I guess I could agree to wait.
>
> Hy
>
> On Thu, Nov 12, 2020, 12:56 AM Eric Dejouhanet <eric.dejouhanet at gmail.com>
> wrote:
>
>> I confirm, but this is probably a minor that can be addressed in 3.5.1.
>>
>> eric.dejouhanet at gmail.com - https://astronomy.dejouha.net
>> *De:* murveit at gmail.com
>> *Envoyé:* 12 novembre 2020 09:37
>> *À:* eric.dejouhanet at gmail.com
>> *Répondre à:* hy at murveit.com
>> *Cc:* mutlaqja at ikarustech.com; hy at murveit.com; rlancaste at gmail.com;
>> sterne-jaeger at openfuture.de; kstars-devel at kde.org
>> *Objet:* Re: KStars v3.5.0 Release Date?
>>
>> *Eric:* I see. So, can you check to see you don't have a file saved
>> that's messing things up (e.g. delete your ~/.local/share/kstars/
>> SavedFocusProfiles.ini <http://savedfocusprofiles.ini/> file if it
>> exists, and then make sure you're using the "1-Focus Default" profile). You
>> could play with the initialKeep and keepNum values in the
>> kstars/ekos/auxiliary/stellarsolverprofile.cpp file in the Focus method.
>> (Also see the note to Rob below).
>>
>> *Rob:* could there be a bug that if you have a saved .ini file, then the
>> initialKeep parameter no longer gets set and uses a very high default? I
>> wouldn't be surprised if that's what messing Eric up.
>>
>> Hy
>>
>> On Thu, Nov 12, 2020 at 12:24 AM Hy Murveit <murveit at gmail.com> wrote:
>>
>>> Also, for the record, I do agree that Rob should either expose the
>>> initialKeep parameter or make it a multiple of the Keep parameter.
>>> As it currently stands, it effectively limits the maximum value of the
>>> keep parameter.
>>> H
>>>
>>> On Thu, Nov 12, 2020 at 12:19 AM Hy Murveit <murveit at gmail.com> wrote:
>>>
>>>> Jasem: I can go either way I suppose, but in my experience, it's
>>>> running reasonably quickly. I won't object too strongly if you want to fix
>>>> it.
>>>>
>>>> Eric:  When I processed your images on my RPi4, they processed
>>>> reasonably quickly:
>>>>
>>>> *Looking at the 1x1 image:*
>>>> *Computing the HFR took 1-2s, but that's using my "quick HFR" which
>>>> only looks at stars in the middle 25% of the image.*
>>>> *Turning off the quick HFR option slowed it down to 4-5 seconds (again
>>>> possibly alongside guiding).*
>>>> *Are you using something slower than a RPi4? Could there be something
>>>> else slowing down the computations?*
>>>>
>>>> *Looking at the 2x2 image:*
>>>> *Seemed to take 1-2s without quickhfr, and 1s or less with quickhfr.*
>>>> *FWIW, I run my focus with 2x2 binning of a ZWO ASI 1600.*
>>>>
>>>>
>>>> We should figure out what the issue is.
>>>> Hy
>>>>
>>>>
>>>>
>>>> On Wed, Nov 11, 2020 at 11:50 PM Eric Dejouhanet <
>>>> eric.dejouhanet at gmail.com> wrote:
>>>>
>>>>> Which is my case right now. But in the particular subject of 3.5, I
>>>>> agree. I would like to know if the profiles are editable by the end-user
>>>>> when they are saved locally, I mean, are all parameters from the file
>>>>> loaded back properly?
>>>>>
>>>>> You know what I also mean here. Are there any tests validating that
>>>>> part?
>>>>>
>>>>> eric.dejouhanet at gmail.com - https://astronomy.dejouha.net
>>>>> *De:* mutlaqja at ikarustech.com
>>>>> *Envoyé:* 12 novembre 2020 08:46
>>>>> *À:* hy at murveit.com
>>>>> *Cc:* rlancaste at gmail.com; eric.dejouhanet at gmail.com;
>>>>> sterne-jaeger at openfuture.de; kstars-devel at kde.org
>>>>> *Objet:* Re: KStars v3.5.0 Release Date?
>>>>>
>>>>> That's fine with me. As long as it does end up generating too many
>>>>> stars that ends up clogging HFR calculations unnecessarily.
>>>>>
>>>>> --
>>>>> Best Regards,
>>>>> Jasem Mutlaq
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Nov 12, 2020 at 10:35 AM Hy Murveit <murveit at gmail.com> wrote:
>>>>>
>>>>>> Jasem,
>>>>>>
>>>>>> This close to the release, I'm inclined to be conservative here and
>>>>>> let it be.
>>>>>> It's just something I came up with, not some reference algorithm, and
>>>>>> it seems to be working as it was implemented.
>>>>>> I suggest that we can play with this in 3.5.1 if you want, but not
>>>>>> mess with this now.
>>>>>>
>>>>>> Hy
>>>>>>
>>>>>>
>>>>>> On Wed, Nov 11, 2020 at 11:11 PM Jasem Mutlaq <
>>>>>> mutlaqja at ikarustech.com> wrote:
>>>>>>
>>>>>>> Hello Robert,
>>>>>>>
>>>>>>> Good catch on the partition & keep stars. I think we ought to
>>>>>>> resolve this not by simply dividing by the number of chunks as this might
>>>>>>> skew the results. In some images, some regions are more star-rich than
>>>>>>> others. Maybe we should do a POST star detection but PRE star filter step
>>>>>>> where the # of stars are then trimmed to the required initial keep?
>>>>>>>
>>>>>>> --
>>>>>>> Best Regards,
>>>>>>> Jasem Mutlaq
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Nov 12, 2020 at 9:41 AM Robert Lancaster <
>>>>>>> rlancaste at gmail.com> wrote:
>>>>>>>
>>>>>>>> Oh the more significant question that I asked though, I don’t think
>>>>>>>> we addressed it yet.  Right now initial keep doesn’t work the way you meant
>>>>>>>> it to due to the partitions.  Does that need to be changed?
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> > On Nov 12, 2020, at 1:37 AM, Robert Lancaster <
>>>>>>>> rlancaste at gmail.com> wrote:
>>>>>>>> >
>>>>>>>> > Yep they are the same kind of thing when it comes to stars
>>>>>>>> certainly.  Your argument that HFR should correlate to magnitude is
>>>>>>>> probably very true for stars, but not for nebulae or galaxies.  They can be
>>>>>>>> large but dim.  It also might not be true for some stars with dust around
>>>>>>>> them
>>>>>>>> >
>>>>>>>> > Sent from my iPhone
>>>>>>>> >
>>>>>>>> >> On Nov 12, 2020, at 1:24 AM, Hy Murveit <murveit at gmail.com>
>>>>>>>> wrote:
>>>>>>>> >>
>>>>>>>>
>>>>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20201112/d7d857d6/attachment-0001.htm>