Hello all,

I'm new here; I purchased my setup about a year ago and haven't got a whole lot of clear night to image on. Of those, a bunch were spent dealing with technical issues as I'm learning.

Onto the main subject:

I am imaging from my balcony, and I have a severely restricted view. Basically I can look north, about 100 degrees west of that, and about 60 degrees east. Maximum possible elevation is 66 degrees (there's a balcony above) and minimum elevation is about 26 degrees.
With this in mind I created a region which blocks the appropriate piece of the sky. It is created as a 'window' type and have about 7-8 points that define it.

Major Problem one:
The regions being overlayed on the skymap have a truly massive impact on graphical performance. Rotating the skymap is very noticeably choppy/laggy, especially on the rpi4.

Major problem two:
The scheduler fails to correctly account for a target being 'in the window' after moving out of it. What I mean specifically is this: I had set as my target the iris nebula, which rises from about 60 to over 66 degrees (and thus exits the allowable region) at around midnight. But half an hour or an hour later it dips below 66 degrees again - however, the scheduler will only schedule this target for the time before it exits the the region, and ignores the target when it returns into the region.

Probably minor but impactful improvements to the Artificial horizon would be:
Allow turning on and off display of the region without deleting it, and make it available as a toolbar-assignable action. It is both a desirable feature and a stopgap to allow having the region present given its current impact on graphical performance.
Allow the export and import of the regions via a CSV. This would be a convenient way of sharing and backing up regions.

I am using the current version of SM, 1.7.2 x64

My setup:
SV503 102mm
SV106 50mm
CEM26 with iPolar
Canon 7D unmodified
SV905C
Rpi4 with SM

Thanks for the report.
Can you please send me a screenshot of the artificial horizon region (i.e. the 7-8 points you defined).
BTW, I would assume that you'd need to create two horizons. One for below and the 2nd for the window "top" region.

Also please send me enough info (e.g. rough geographical location, times and target) so I can re-create the scheduler issue.

I assume you're talking about the graphical performance for the artificial horizon (the red overlay on the skymap) and not for a terrain image overlay.

Thanks,
Hy

Thanks for the reply!

Yes, I do mean the red overlay, I intend to use it both for being able to easily specify where to 'look' and for automation with the scheduler. You are correct about creating multiple regions, however, just the one causes a big problem.

Geographic info: 45 40 N, -75 40 E
Target: Iris Nebula (NGC 7023)
Times: Use 21/08/2022, 23:02 EST is when the target will 'rise' up to the ceiling, and it will come back into the window at 01:02 on 22/08/2022

Screenshot as requested is attached.

Somehow the screenshot didn't come through (It says you don't have permission to access this page).
You can attach the image to the post.

Also, are you using the "greedy" scheduler algorithm?
Perhaps a screenshot of the scheduler page as well.

Thanks,
Hy

Fixed the screenshot.
Here's one of the scheduler, and I tried both classic and greedy; I tried replicating the misbehavior right now by changing the time in kstars but I don't think that will fly I guess I'll have to wait another hour or so and see if I can replicate it then.

What happened to me was this: I had the artificial horizon checked in scheduler, I let the rig do its thing.

It hits the AF window, and shuts itself down. Curiously I look at it, I was expecting it to go after M51 in this case but it didn't. So I checked the Iris nebula and I saw it was scheduled for next day, right then astronomical darkness takes hold in the PM, as opposed to resuming two hours later.

PS: It seems the massive graphical performance glitch happens when I use the 'ceiling' mode.

I am unable to replicate the previous misbehavior...instead, the scheduler now schedules the run immediately, despite the target being in the red region.

George,

Before I start debugging any scheduler issues, I thought we'd first look at the artificial horizon you defined.
From looking at your screenshot, I don't believe it implements what you want.

I believe you need two horizons. One defines the area below which your telescope can't see.
This would would be a "standard" horizon--that is not marked as a "window".
In my screenshot below it is labeled GeorgeFloor.

Then you'd need a 2nd one in "ceiling" mode, that defines the area above which the telescope can't see.
In the 2nd screenshot it is called GeorgeCeiling.

You'd enable both those by clicking the checkbox and then clicking apply.
I have entered approximate values you might try in the screenshots.

I'm not sure you'd need all the points I entered, but it was pretty quick to hand-type all those value.
Please try that horizon, and let me now about any scheduler issues you have.
Please just test with the greedy scheduling algorithm.

I do see the slowdown. I'm not familiar with that rendering code, I do know that we don't have gpu acceleration.
I agree that it would be a good feature to not display the transparent-red overlay given its slowdown.

Hy

BTW, I looked into it and found a cause for the graphics slowness.
I submitted a merge request for this which will work its way into the nightly releases in the next day or two
and eventually into the next KStars release 3.6.1
See invent.kde.org/education/kstars/-/merge_requests/710

If you can compile your code and want to run it before you can access those releases, just change value sampling is assigned to from 0.1 to 1.0 (or larger to speed it up more)
invent.kde.org/education/kstars/-/blob/m...oncomponent.cpp#L454
You might get some artifacts in the graphics, but the rendering will be much quicker.

George,

I discovered that if you uncheck "Opaque Ground", then the red semi-transparent artificial horizon wont be drawn.

You can find that in Settings --> Configure KStars --> Guides --> Opaque Ground.

Hy

Thanks Hy! I've added a few more points to the horizon as you suggested. I actually caught it misbehaving as originally described - please note that this is just the scheduler scheduling, I was not attempting to do any photography (it's all cloudy).

I caught this just before midnight on the 22nd. You can see that the Iris nebula is marked as being in the red zone. The expectation is that the scheduler will reschedule the job for when this target exits the red zone at about 1am on the 23rd.
Furthermore, even the evening capture schedule on the 23rd should begin at around 22:00 ... which is when astronomical darkness will take hold.

I just got the update and the performance issue is fixed. Yes, there are weird artifacts depending on how the horizon is set up and I imagine that the feature needs a bit more love in the graphical respect.

So then what remains in the scheduler's behavior which I do not understand.

I verified that the ceiling constraint isn't honored properly by the scheduler. I'll work on a fix. Thanks for reporting that.

Hy