KStars v3.5.0 Release Date?

[Hy Murveit]

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/bf6acf77/attachment-0001.htm>