<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Hi Hy,</div><div class=""><br class=""></div><div class="">Yes, I forgot that you added that parameter and then we didn’t add it to the interface and saving functions! </div><div class=""><br class=""></div>So I just went about rectifying this a few minutes ago. I just added the initial keep parameter to the tester and file saving functions and pushed the changes to StellarSolver. I think that will make a difference particularly if it wasn’t being saved in the saved options profiles. I can also add it to the Editor in KStars. But maybe this explains why it was taking so long on Eric’s computer. Maybe he saved it and the parameter wasn’t saved.<div class=""><br class=""></div><div class="">I am wondering though if maybe we want to reword these 2 parameters before we release. Right now they are called keepNum and initialKeep. The initialKeep is a filter based on the size of the star that is applied before HFR is done and the keepNum is a filter based on the magnitude that is applied after the star extraction is all finished. The keepNum is most useful for Solving because we want the brightest stars for solving. The initialKeep is most useful for SEP since we tend to want the biggest stars for calculating HFR. Also it is extremely important for HFR that the filtering happens before the HFR calculations are done Maybe we should call the keepNum something like keepBright and the initialKeep something like keepSize?<div class=""><div class=""><br class=""></div><div class="">On a similar note when I was adding the parameter into the tester just now and doing some testing, I found that Jasem’s changes to partition the image might make your initialKeep parameter not work like you intended it to work Hy. Now the initial keep parameter is being applied to each partition instead of being applied to the whole image. So if you set an initial Keep of 50 stars, but then partition the image into 50 chunks, while you might expect initialKeep to limit it to 50 stars, in fact you are limiting it to 50 x 50 stars. Perhaps as a simple solution, we could just divide the initial keep parameter by the number of chunks?<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 10, 2020, at 3:45 PM, Hy Murveit <<a href="mailto:murveit@gmail.com" class="">murveit@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Initial Keep is a key parameter wrt time. <div class="">I see that it isn't exposed in the profile editor. </div><div class="">Rob, how is that set when someone reduces the KEEP parameter?</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 10, 2020 at 12:15 PM Eric Dejouhanet <<a href="mailto:eric.dejouhanet@gmail.com" class="">eric.dejouhanet@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="background-color:rgb(255,255,255);background-image:initial;line-height:initial" class=""><div id="gmail-m_8739674240118973806response_container_BBPPID" style="outline:none" dir="auto" class=""> <div name="BB10" id="gmail-m_8739674240118973806BB10_response_div_BBPPID" dir="auto" style="width:100%" class=""> Robert, following your reply, I configured my SmallScaleSolving Focus configuration to return 5 stars only. I expected the HFR to be computed faster, as there would be less stars in the list (well, compared to...29?). But the duration remained the same, more than two minutes. I also observe that the cpu is at 70-80% usage on the two cores during that time. </div><div name="BB10" id="gmail-m_8739674240118973806BB10_response_div_BBPPID" dir="auto" style="width:100%" class=""><br class=""></div><div name="BB10" id="gmail-m_8739674240118973806BB10_response_div_BBPPID" dir="auto" style="width:100%" class="">What I can do is add the same log output to Focus as is done in Align and see the difference. </div> <div id="gmail-m_8739674240118973806blackberry_signature_BBPPID" name="BB10" dir="auto" class=""> <div id="gmail-m_8739674240118973806_signaturePlaceholder_BBPPID" name="BB10" dir="auto" class=""><p dir="ltr" class=""><a href="mailto:eric.dejouhanet@gmail.com" target="_blank" class="">eric.dejouhanet@gmail.com</a> - <a href="https://astronomy.dejouha.net/" target="_blank" class="">https://astronomy.dejouha.net</a></p></div> </div></div><div id="gmail-m_8739674240118973806_original_msg_header_BBPPID" dir="auto" class=""> <table width="100%" style="border-spacing:0px;display:table;outline:none" class=""><tbody class=""><tr class=""><td colspan="2" style="padding:initial;font-size:initial;text-align:initial" class=""> <div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(181,196,223);padding:3pt 0in 0in;font-family:Tahoma,"BB Alpha Sans","Slate Pro";font-size:10pt" class=""> <div id="gmail-m_8739674240118973806from" class=""><b class="">De:</b> <a href="mailto:rlancaste@gmail.com" target="_blank" class="">rlancaste@gmail.com</a></div><div id="gmail-m_8739674240118973806sent" class=""><b class="">Envoyé:</b> 10 novembre 2020 15:13</div><div id="gmail-m_8739674240118973806to" class=""><b class="">À:</b> <a href="mailto:eric.dejouhanet@gmail.com" target="_blank" class="">eric.dejouhanet@gmail.com</a></div><div id="gmail-m_8739674240118973806cc" class=""><b class="">Cc:</b> <a href="mailto:sterne-jaeger@openfuture.de" target="_blank" class="">sterne-jaeger@openfuture.de</a>; <a href="mailto:mutlaqja@ikarustech.com" target="_blank" class="">mutlaqja@ikarustech.com</a>; <a href="mailto:hy@murveit.com" target="_blank" class="">hy@murveit.com</a>; <a href="mailto:kstars-devel@kde.org" target="_blank" class="">kstars-devel@kde.org</a></div><div id="gmail-m_8739674240118973806subject" class=""><b class="">Objet:</b> Re: KStars v3.5.0 Release Date?</div></div></td></tr></tbody></table> <br class=""> </div><div name="BB10" dir="auto" style="background-image:initial;line-height:initial;outline:none" class=""><div style="overflow-wrap: break-word;" class=""></div>One simple reason, HFR calculations. They are very computation intensive. If you want the HFR, it takes much longer<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Nov 10, 2020, at 9:04 AM, Eric Dejouhanet <<a href="mailto:eric.dejouhanet@gmail.com" target="_blank" class="">eric.dejouhanet@gmail.com</a>> wrote:</div><br class=""><div class=""><div id="gmail-m_8739674240118973806response_container_BBPPID" dir="auto" style="font-family:helvetica;font-style:normal;font-weight:normal;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration:none;outline:none" class=""><div id="gmail-m_8739674240118973806BB10_response_div_BBPPID" dir="auto" style="width:1013px" class="">On my system, as an end-user, I don't understand why the star detection takes less than a second in the alignment module (SmallScaleSolving), and more than twenty in the Focus module (tweaked version of SmallSizedStars).</div><div id="gmail-m_8739674240118973806BB10_response_div_BBPPID" dir="auto" style="width:1013px" class=""><br class=""></div><div id="gmail-m_8739674240118973806BB10_response_div_BBPPID" dir="auto" style="width:1013px" class="">So I did configure Focus to use the SmallScaleSolving settings from the Align module. I used the CCD Simulator to send one of my NGC6888 frames to Focus, and ran a capture. The Focus module took FIVE minutes to detect 29 stars. I thought the whole thing was crashed. </div><div id="gmail-m_8739674240118973806BB10_response_div_BBPPID" dir="auto" style="width:1013px" class=""><span style="font-family:initial" class=""><br class=""></span></div><div id="gmail-m_8739674240118973806BB10_response_div_BBPPID" dir="auto" style="width:1013px" class=""><span style="font-family:initial" class="">The Align module took FOUR seconds with the same configuration on the same 31MB frame to detect 50+ stars. It said it wasn't parallel by itself. It did a downsample by 3.</span></div><div id="gmail-m_8739674240118973806BB10_response_div_BBPPID" dir="auto" style="width:1013px" class=""><span style="font-family:initial" class=""><br class=""></span></div><div id="gmail-m_8739674240118973806BB10_response_div_BBPPID" dir="auto" style="width:1013px" class=""><span style="font-family:initial" class="">So this is probably not a question of detection, there is another culprit somewhere. During the execution of the Focus detection, the cpu wasn't 100%. </span></div><div id="gmail-m_8739674240118973806blackberry_signature_BBPPID" dir="auto" class=""><div id="gmail-m_8739674240118973806_signaturePlaceholder_BBPPID" dir="auto" class=""><p dir="ltr" class=""><a href="mailto:eric.dejouhanet@gmail.com" target="_blank" class="">eric.dejouhanet@gmail.com</a><span class=""> </span>-<span class=""> </span><a href="https://astronomy.dejouha.net/" target="_blank" class="">https://astronomy.dejouha.net</a></p></div></div></div><div id="gmail-m_8739674240118973806_original_msg_header_BBPPID" dir="auto" style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration:none" class=""><table width="100%" style="border-spacing:0px;display:table;outline:none" class=""><tbody class=""><tr class=""><td colspan="2" class=""><div style="border-style:solid none none;border-top-width:1pt;border-top-color:rgb(181,196,223);padding:3pt 0in 0in;font-family:tahoma,"bb alpha sans","slate pro";font-size:10pt" class=""><div id="gmail-m_8739674240118973806from" class=""><b class="">De:</b><span class=""> </span><a href="mailto:sterne-jaeger@openfuture.de" target="_blank" class="">sterne-jaeger@openfuture.de</a></div><div id="gmail-m_8739674240118973806sent" class=""><b class="">Envoyé:</b><span class=""> </span>10 novembre 2020 14:03</div><div id="gmail-m_8739674240118973806to" class=""><b class="">À:</b><span class=""> </span><a href="mailto:mutlaqja@ikarustech.com" target="_blank" class="">mutlaqja@ikarustech.com</a></div><div id="gmail-m_8739674240118973806cc" class=""><b class="">Cc:</b><span class=""> </span><a href="mailto:hy@murveit.com" target="_blank" class="">hy@murveit.com</a>; <a href="mailto:rlancaste@gmail.com" target="_blank" class="">rlancaste@gmail.com</a>; <a href="mailto:kstars-devel@kde.org" target="_blank" class="">kstars-devel@kde.org</a>; <a href="mailto:eric.dejouhanet@gmail.com" target="_blank" class="">eric.dejouhanet@gmail.com</a></div><div id="gmail-m_8739674240118973806subject" class=""><b class="">Objet:</b><span class=""> </span>Re: KStars v3.5.0 Release Date?</div></div></td></tr></tbody></table><br class=""></div><div dir="auto" style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration:none;outline:none" class=""><div style="overflow-wrap: break-word;" class=""></div>OK, I did a quick check on my RPi4 with Parallel Algorithm set to „Auto“ - and it works super fast! But since it is daytime, I can only test the „Load and Slew“ option. So maybe the WCS info in the file gave hints that are not present for normal capture and slew or sync.<div class=""><br class=""></div><div class="">I need to check it under real conditions, which might be tricky due to the fog hanging around here…</div><div class=""><br class=""></div><div class="">Wolfgang<div class=""><div class=""><blockquote type="cite" class=""><div class="">Am 10.11.2020 um 11:16 schrieb Jasem Mutlaq <<a href="mailto:mutlaqja@ikarustech.com" target="_blank" class="">mutlaqja@ikarustech.com</a>>:</div><br class=""><div class=""><div dir="ltr" class="">Alright, let's look at this:<div class=""><br class=""></div><div class="">1. Parallel algorithm: This is related to SOLVER, not image partitioning. It should work fine on Rpi4 and the checks are more reliable now as Robert worked on that.</div><div class="">2. WCS Polar Align: Can this be reproduced with simulators?</div><div class=""><br clear="all" class=""><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class="">--</div><div class="">Best Regards,<br class="">Jasem Mutlaq<br class=""></div><div class=""><br class=""></div></div></div></div></div></div><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 10, 2020 at 10:48 AM Wolfgang Reissenberger <<a href="mailto:sterne-jaeger@openfuture.de" target="_blank" class="">sterne-jaeger@openfuture.de</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">It wasn’t that bad. The problem was that KStars went to 100% CPU usage and died (or I killed it, do not exactly remember). I’ll try to reproduce it...<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">Am 10.11.2020 um 08:45 schrieb Hy Murveit <<a href="mailto:murveit@gmail.com" target="_blank" class="">murveit@gmail.com</a>>:</div><br class=""><div class=""><div dir="ltr" class="">OK, well I believe it was fixed a week ago, so if you can still recreate it, you should report it. <div class="">It should be fixed before release if it is still freezing the Pi.</div><div class=""><br class=""></div><div class="">Hy</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 9, 2020 at 11:42 PM Wolfgang Reissenberger <<a href="mailto:sterne-jaeger@openfuture.de" target="_blank" class="">sterne-jaeger@openfuture.de</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">OK, I have to check it. The problem occurred only a few days ago and I think I’m always on bleeding edge...<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">Am 10.11.2020 um 08:38 schrieb Hy Murveit <<a href="mailto:murveit@gmail.com" target="_blank" class="">murveit@gmail.com</a>>:</div><br class=""><div class=""><div dir="ltr" class="">Wolfgang: I believe Rob and/or Jasem fixed the issue with parallel algorithm bringing down the RPi4 a while back.<div class="">I have the solver on auto parallelism and load all indexes in memory, and it seems to work fine (and in parallel).</div><div class="">Similarly, for star extraction, Jasem implemented a threaded extraction that also automatically determines how many threads to use and seems fine on the RPi4.</div><div class=""><br class=""></div><div class="">Eric: I believe these parallel options are the defaults. Hopefully users won't need to configure things like this.</div><div class="">For star detection, I don't believe you can turn it off.</div><div class="">For star detection Jasem split the frame before detection (into at most num-threads parts--4 for the RPi4).</div><div class="">For align, I'm not sure how Rob divided things.</div><div class=""><br class=""></div><div class="">Hy</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 9, 2020 at 11:07 PM Wolfgang Reissenberger <<a href="mailto:sterne-jaeger@openfuture.de" target="_blank" class="">sterne-jaeger@openfuture.de</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">Hi all,<div class="">I think we are close to finishing the release. I personally would opt to wait for another week and keep an eye stability.</div><div class=""><br class=""></div><div class="">Maybe we should take another look if the default settings in the StellarSolver profiles work a) for typical camera/scope combinations and b) for all platforms.</div><div class=""><br class=""></div><div class="">For example with my RPi, I needed to change the Parallel Algorithm to „None“ because parallelity brought KStars down. Is the default setting „None“ and I changed it somewhen? With all the new parameters I would prefer having a robust setup and leave it to the user to optimize speed.</div><div class=""><br class=""></div><div class="">@Jasem: please take a closer look to MR!122, since it fixed 4(!) regressions I introduced with my capture counting fix MR!114. Hopefully now we have at least a proper coverage with automated tests...</div><div class=""><br class=""></div><div class="">Wolfgang</div><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">Am<span class=""> </span><a href="tel:09112020" target="_blank" class="">09.11.2020</a><span class=""> </span>um 22:04 schrieb Jasem Mutlaq <<a href="mailto:mutlaqja@ikarustech.com" target="_blank" class="">mutlaqja@ikarustech.com</a>>:</div><br class=""><div class=""><div dir="ltr" class="">Hello Folks,<div class=""><br class=""></div><div class="">So back to this topic, any major blockers to the KStars 3.5.0 release now?</div><div class=""><br class=""></div><div class="">1. Remote Solver should be fixed now.</div><div class="">2. StellarSolver Profiles are more optimized now.</div><div class="">3. Handbook not updated yet, but we can probably work on this shortly.</div><div class="">4. Couple of pending MRs to take care of.</div><div class=""><br class=""></div><div class="">How about Friday the 13th?</div><div class=""><br class=""></div><div class=""><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class="">--</div><div class="">Best Regards,<br class="">Jasem Mutlaq<br class=""></div><div class=""><br class=""></div></div></div></div></div></div><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 5, 2020 at 3:41 AM Robert Lancaster <<a href="mailto:rlancaste@gmail.com" target="_blank" class="">rlancaste@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Eric,<br class=""><br class="">Ok so then we would be changing the way we do version numbering with this, right?<br class="">I believe now we typically add features in each new iteration 3.4.1, 3.4.2, etc etc<br class="">and when it is really big like StellarSolver, then we make it a big release like 3.5.0<br class=""><br class="">With this new paradigm, we wouldn’t put new features into the master of the main 3.5 branch<br class="">But instead we would work on a new 3.6 branch, and then bug fixes would go into the 3.5 branch<br class="">to make each new minor release, like 3.5.1, 3.5.2 etc.<br class=""><br class="">Do I have this correct?<br class=""><br class="">If this is right, then it would be longer before users see new features in the main branch, but the<span class=""> </span><br class="">tradeoff is that the main branch would have a LOT more stability. I see this as a big positive.<br class=""><br class="">Thanks,<br class=""><br class="">Rob<br class=""><br class="">> On Nov 4, 2020, at 5:54 PM, Eric Dejouhanet <<a href="mailto:eric.dejouhanet@gmail.com" target="_blank" class="">eric.dejouhanet@gmail.com</a>> wrote:<br class="">><span class=""> </span><br class="">> Hello Hy,<br class="">><span class=""> </span><br class="">> Version 3.5.0 is only the beginning of the 3.5.x series, with more<br class="">> bugfixes on each iteration (and possibly, only bugfixes).<br class="">> So I have no problem leaving unresolved issues in 3.5.0.<br class="">><span class=""> </span><br class="">> For instance, the Focus module now has a slight and unforeseeable<br class="">> delay after the capture completes.<br class="">> The UI reflects the end of the capture only, not the end of the detection.<br class="">> This makes the UI Focus test quite difficult to tweak, as running an<br class="">> average of the HFR over multiple frames now has an unknown duration.<br class="">> Right now, the test is trying to click the capture button too soon 2<br class="">> out of 10 attempts.<br class="">> But this won't block 3.5 in my opinion (and now that I understood the<br class="">> problem, I won't work on it immediately).<br class="">><span class=""> </span><br class="">> In terms of reporting problems, the official way is stil<span class=""> </span><a href="http://bugs.kde.org/" target="_blank" class="">bugs.kde.org</a>,<br class="">> but there's quite a cleanup/followup to do there.<br class="">> I'd say we can use issues in<span class=""> </span><a href="http://invent.kde.org/" target="_blank" class="">invent.kde.org</a><span class=""> </span>to discuss planned<br class="">> development around a forum/bugzilla issue or invent proposal (like<br class="">> agile stories).<br class="">> There are milestones associated with several issues (although I think<br class="">> they should be reviewed and postponed).<br class="">> And we can certainly write a punchlist: check the board at<br class="">><span class=""> </span><a href="https://invent.kde.org/education/kstars/-/milestones/3" target="_blank" class="">https://invent.kde.org/education/kstars/-/milestones/3</a><br class="">><span class=""> </span><br class="">> Le mer. 4 nov. 2020 à 22:38, Hy Murveit <<a href="mailto:murveit@gmail.com" target="_blank" class="">murveit@gmail.com</a>> a écrit :<br class="">>><span class=""> </span><br class="">>> Eric,<br class="">>><span class=""> </span><br class="">>> I would add to your list:<br class="">>><span class=""> </span><br class="">>> - KStars Handbook (review update sections to reflect 3.5.0) and finally (perhaps manually if necessary) put the latest handbook online.<br class="">>><span class=""> </span><br class="">>> - Review the extraction settings. I spent a bit of time looking at the default HFR settings, and based on some experimentation (truth be told, with a limited amount of data) adjust things a little differently than my first guess (which was basically focus' settings).<br class="">>> Rob: My intuition is that I should adjust the default StellarSolver star-extraction settings for Focus and Guide as well in<span class=""> </span><a href="http://stellarsolverprofile.cpp/" target="_blank" class="">stellarsolverprofile.cpp</a>. I don't know whether you've already verified them, and want to release them as they are, or whether they are a first shot and you'd welcome adjustment?<br class="">>><span class=""> </span><br class="">>> Also, Eric, I suppose I should be adding these things here:<span class=""> </span><a href="https://invent.kde.org/education/kstars/-/issues" target="_blank" class="">https://invent.kde.org/education/kstars/-/issues</a><br class="">>> Is that right? Sorry about that--ok, after this thread ;) But seriously, your email is a good summary, and from that link<br class="">>> it doesn't seem as easy to see which are "must do by 3.5.0" and which are "nice to have someday".<br class="">>> A 3.5.0 punchlist would be a nice thing to have.<br class="">>><span class=""> </span><br class="">>> Hy<br class="">>><span class=""> </span><br class="">>> On Wed, Nov 4, 2020 at 12:58 PM Eric Dejouhanet <<a href="mailto:eric.dejouhanet@gmail.com" target="_blank" class="">eric.dejouhanet@gmail.com</a>> wrote:<br class="">>>><span class=""> </span><br class="">>>> Hello,<br class="">>>><span class=""> </span><br class="">>>> Where do we stand now in terms of bugfixing towards 3.5.0?<br class="">>>><span class=""> </span><br class="">>>> - StellarSolver has all features in, and 1.5 is finally out at Jasem's PPA.<br class="">>>> - However Gitlab CI still complains about that lib package (see<br class="">>>><span class=""> </span><a href="https://invent.kde.org/education/kstars/-/jobs/75941" target="_blank" class="">https://invent.kde.org/education/kstars/-/jobs/75941</a>)<br class="">>>> - Unitary tests are being fixed progressively, mount tests are down to<br class="">>>> ~20 minutes (yeees!)<br class="">>>> - From my tests, the remote Astrometry INDI driver is not usable<br class="">>>> anymore from Ekos.<br class="">>>> - The issue raised with flat frames is confirmed fixed (at least by me).<br class="">>>> - Meridian flip is OK (but I had not enough time to test TWO flips in a row).<br class="">>>> - Memory leaks are still being researched in Ekos.<br class="">>>> - There is an issue when duplicating an entry in a scheduler job,<br class="">>>> where the sequence associated is copied from the next job.<br class="">>>><span class=""> </span><br class="">>>> Could we get a 3.6 branch where we will merge development of new features?<br class="">>>> And master for bugfixing 3.5.x until we merge 3.6 new features in?<br class="">>>> (we'd still have to port bugfixes from master to 3.6)<br class="">>>> I don't think the opposite, master for 3.6 and a separate living<br class="">>>> 3.5.x, is doable in the current configuration (build, ppas, MRs...).<br class="">>>><span class=""> </span><br class="">>>> --<br class="">>>> --<span class=""> </span><a href="mailto:eric.dejouhanet@gmail.com" target="_blank" class="">eric.dejouhanet@gmail.com</a><span class=""> </span>-<span class=""> </span><a href="https://astronomy.dejouha.net/" target="_blank" class="">https://astronomy.dejouha.net</a><br class="">><span class=""> </span><br class="">><span class=""> </span><br class="">><span class=""> </span><br class="">> --<span class=""> </span><br class="">> --<span class=""> </span><a href="mailto:eric.dejouhanet@gmail.com" target="_blank" class="">eric.dejouhanet@gmail.com</a><span class=""> </span>-<span class=""> </span><a href="https://astronomy.dejouha.net/" target="_blank" class="">https://astronomy.dejouha.net</a><br class=""><br class=""></blockquote></div></div></blockquote></div><br class=""></div></div></blockquote></div></div></blockquote></div><br class=""></div></blockquote></div></div></blockquote></div><br class=""></div></blockquote></div></div></blockquote></div><br class=""></div></div></div><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div>
</div></blockquote></div><br class=""></div></div></div></body></html>