KStars v3.5.0 Release Date?
Hy Murveit
murveit at gmail.com
Fri Nov 13 06:00:35 GMT 2020
The program continues to run nicely for me in testing.
I tested Jasem's speedup to the polar align on my RPi and worked great.
The meridian flip checkbox issue is fixed, as far as I can tell.
For me, the star detection, guiding and focus are all good.
The bugs I found previously are all fixed, with a slight issue in the
initialKeep thing.
The initialKeep thing:
- Rob has submitted (thanks Rob) an MR
https://invent.kde.org/education/kstars/-/merge_requests/132 to fix the
initialKeep issue--that edited profiles lose initialKeep, and it gets set
to 1000000 causing possible very long computation times.
- I briefly tested the MR, and it (mostly--see below) looks fine to me.
My only comment is to add some more flavor to the mouse-over doc, and
ultimately to the handbook.
- The one issue I found, is that folks with old saved profiles, made
before this fix -- so all existing saved profiles as of today -- will
still have the problem until the user either deletes all their
~/.local/share/kstars/Saved*.ini files, or explicitly edits all their saved
profiles and changes the initialKeep value from 1000000 to a reasonable
number. Our choice is to
- either email out telling people to delete those files, and live
with complaints from a few folks who don't delete them
- or change the names of those files (so all people who've edited
profiles lose their profile work--but have a record of their lost data)
- I prefer the 2nd option--change the file names we look for--so
effectively all files are deleted.
Other than the initialKeep discussion above, I'm pretty happy with the code.
Hy
On Thu, Nov 12, 2020 at 1:22 PM Robert Lancaster <rlancaste at gmail.com>
wrote:
> Oops. "There was also a bug where Guide always used the index from focus,
> not it's own.”
>
> Thanks for fixing that!
>
> On Nov 12, 2020, at 3:48 PM, Hy Murveit <murveit at gmail.com> wrote:
>
> 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/93149bac/attachment-0001.htm>
More information about the Kstars-devel
mailing list