"Center here" is OK in DEC; Flipped for RA

So if the problem occurs only without Hyperstar, and doesn’t show up with Hyperstar it would seem that any fix in the software would simply reverse the problem - i.e., how would SGP know what kind of optical path is present. Perhaps a UI button that would allow the user to ‘flip’ the orientation of the image? Just thinkin’ out loud here.

I was going to run some additional tests but either I was not available to setup at night or there were cloudy nights (more of the later unfortunately). I wanted to see if the issue ever occurred in DEC.

Yes… another setting would be the only way I can think of to fix this issue. I have a general aversion to adding new settings (slippery slope before SGPro looks like the cockpit of a 747). I’ll still need to consider this a vbit when time allows. It’s not forgotten.

Maybe a shot in the dark, but are you using the QHY10 camera? If so, are you rotating the image for landscape display before clicking “Center Here”? As I’m sure you know, the QHY10 camera has an odd habit of providing images in portrait mode. One of the things I noticed was that if I rotated the image for landscape display, the HFR calculations were still performed in portrait orientation and the HFR squares were displayed as though the image were still orientated as portrait even though I had rotated it to landscape. If you are rotating your images and clicking “Center Here” on the rotated image, but SGP is calculating that click position based on the portrait orientation, it could explain the incorrect motion.

If you’re not rotating your images before clicking “Center Here” then this is a rabbit hole. But if you are, you could try one of two things - don’t rotate the image before trying “Center Here”, or trying 2.5.0.16 which forces downloaded images into landscape orientation.

Tim

Tim,

Yes, a QHY10, but I don’t rotate the image, so that’s not the problem. I was going to run some imaging runs last night with the camera rotated 45 degrees to the Celestial Equator, thus seeing if the issue occurs in both RA and DEC, but I decided to spend the few hours of relatively clear skies on capturing some additional subs of the Rosette nebula. The next week doesn’t look good, but if the evenings are partly cloudy I might be able to run those tests.

Mikey

@XCalRocketMan I had a thought about this… when you are not using your hyperstar, I am wondering if you see a FITS header named FLIPPED set to TRUE (and the opposite when using it). If this holds true, we may be able to auto-detect flipped images and adjust the reported sky angle to what it would be if the image were not flipped.

In both cases the FITS metadata indicates FLIPPED=F (False). Not surprising since other than mounting the camera on the Hyperstar vs. the FR at the prime focus there is nothing different so I didn’t expect the value to change - the camera doesn’t know where it’s mounted.
In another thread on this forum Flipping Image Problems - Sequence Generator - Main Sequence Software there is a discussion about the FLIPPED data element where JulianR claims it is related to the side of pier. I looked at some images I took Fri night/Sat morning where I had SGP imaging M100 unattended during the early morning hours. In images prior to and after meridian flip the FLIPPED value was F - it didn’t change. SGP log shows the telescope moved to the east side of pier during the night. So if the FLIPPED value is supposed to be an indicator of pier side it didn’t work.

That is not relevant to the FLIPPED attribute.

Right, flipping should not change this value. It should change when when the number of mirrors changes from even to odd or possibly if your camera readout is from bottom to op instead of top to bottom. Our implementation of PlateSolve2 is pretty new and we don’t really use the FLIPPED header for anything important so I’ll need to make sure that it is reporting properly.

Yep - but without any option in the software to indicate this how else would SGP/PlateSolve know?

Not sure I follow. Your image is either flipped with respect to its relative appearance in the sky or it’s not. This has nothing to do with user defined settings.

Agreed. But here’s what I’m saying …
I point the scope to some object (let’s say the Rosette). I’m using Hyperstar so only one mirror in play. SGP works just fine. Now I remove the Hyperstar, place the camera at the rear cell of the OTA and image again. Now there are two mirrors in play - SGP’s center here won’t work. In the first case, the image is flipped. In the second case it’s not (or vice versa, doesn’t matter).

Sure. I don’t think we are saying different things. All I am saying is that one of these two should report “FLIPPED”. The one that does will have a sky angle that needs adjustment as if the image were present in a non-flipped way (so that we can get a normal east of north angle). This does not require additional user settings to convey.

This may be a bit late but would REFLECTED be a better keyword than FLIPPED? That’s what it actually means.

Chris

Possibly… we can certainly add both (keep in mind we can only use 8 characters, so there would be vowel removal or something… REFLCTED?). Initially, Elbrus used this keyword so we went with that.

So who is responsible for setting this value? The camera driver (ASCOM)?

No. The ASCOM driver would have absolutely no ideas about anything to do with image orientation… it just collects light and makes it available for reading. SGPro is responsible for setting this value and it is based off of how the image is plate solved (the solver should indicate if the image is flipped or reflected and along what axes).

So… I have confirmed that SGPro is not properly recording flipped axes when the solve is completed by PlateSolve2. Will need to do some research and determine how the PS2 solve results communicate this.

I tried this with Platesolve 2 and if both axes are mirrored. the result is the same but with the angle rotated 180 degrees. There was no other difference in the returned parameters. It will not plate solve if only one axis is mirrored.

There is only one reflection, what appears to be reflections about different axes can be achieved by a reflection and a rotation.

Two reflections cancel out leaving just a rotation.

It’s worth making little drawings of a field with a letter L in it and seeing how it changes as different reflections and rotations are applied.

Chris

Quick update on this… there are 2 things to fix here:

  • Make sure PlateSolve2 properly reports when it detects a flipped image.
  • Implement non-plate solver specific code to do location math differently when a flipped image is encountered.

The first part is done… I have Plate Solve 2 properly reporting if the image is flipped. Now all we should have to do is “flip” your X,Y click before we do the math and everything should start working.

Need to make sure Astrometry.NET is properly reporting flipped images too… Pinpoint is verified as reporting this properly.

OK… I think this is done and should work properly for flipped images. Will be out for test in 2.5.0.20.