KStars v3.5.0 Release Date?

Hy Murveit murveit at gmail.com
Thu Nov 12 08:24:50 GMT 2020


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


More information about the Kstars-devel mailing list