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

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.

Thanks Ken - I’ll give it a try as soon as 2.5.0.20 is out and the skies co-operate :slight_smile:

I prefer the term parity instead of something like flipped. “Flipped” is especially confusing if the y-direction of the image could be up or down depending on the display convention.

Imaging with an sct and a given sensor will have one parity at the normal f/10 focus, and the opposite parity at the hyperstar focus.

You could also say “LHR” or “RHR” for left and right hand rule - but that is also affected by the convention for y-direction.

If you know the direction of north in the image and you know the image parity - you should know how directions map on the pixels.

Frank

Loaded up 2.5.0.21 beta this evening and set up my Edge11 with 0.7x FR and the QHY10. I centered the trapezium in the camera and executed a solve and sync command. I then requested a ‘center here’ on a star to the right and down from center. The resultant image displayed a position error in both RA and DEC (rotated by 180 degrees). I did not try this with Hyperstar yet, only with the standard prime focus image train. A pdf file showing screenshots of the imaging is located in my DropBox at: Dropbox - File Deleted

How do you know the error is in both RA and DEC? Are the CCD axes square with RA and DEC?

Yes. I had the camera rotated so that the longer side was N-S and the shorter side E-W.

OK… so I think I have a fix that will work for your camera. The fix applied in 2.5.0.20 I believe will work for just about all cameras except yours. I needed to find a way to do this without adding special handling “per-camera”.

I do my best to replicate your camera’s behavior when testing, but the proof, in this case, will be obtained by using the actual camera (and also confirming that it is not broken for everyone else).

Keep in mind, that if this does work as expected, the fix is currently limited to clicking on images pulled directly off the camera. It will not work if you open an image from disk (from a previous session) and attempt to click and center with this image. If we are successful, I can port the fix to images opened from disk… not worth it until verified.

This will be available in 2.5.0.22. Even if it fails, there is now additional logging that will help me trace the path we used to transform the click coordinates to RA and DEC.

2.5.0.22 has been released for testing.

Spent the better part of four hours this evening testing the 2.5.0.22beta version with my camera. What I was able to find out is that the ‘center here’ operation seems to now work with the following proviso: you must use the same binning for both the plate solves and the image you use to do the centering. The procedure that seems to work is:

  1. Set the Plate Solver to a specific binning (say 4x4)
  2. Do a Solve and Sync Blind on the target
  3. Take an image with the same binning (4x4) as the plate solver used
  4. Execute the ‘Center here’ to get the target centered
  5. Change to whatever binning you use for the actual imaging sequence (usually 1x1)

I was not aware that the binning would have an effect on the centering.

Since the clouds moved in I was not able to test this out using the HyperStar lens. If the weather cooperates tomorrow evening I will do so.

NOTE: It now appears that subframes are no longer working correctly. Selecting a subframe on the image seems to load a different region of the image frame than the selected subframe. I will need to experiment on this a bit more.

Thx for the feedback. Off hand I cannot say why one operation would have any effect on the other, but if that bug exists, considering that this is a rarely used feature, it is something we can probably live with for a bit while we tend to other things.

Why take another image? Why not just right click and center on the image you just used to blind solve?

Why do you need to do this? Each sequence event already contains its own binning setting.

Ya… I can see how this is broken.

Setup the HyperStar this evening. Center here works just fine. That leaves only the subframe issue.

The subframe issue should no longer be present… the official 2.5 release returns the QHY10 to its original portrait orientation.

Hello Ken,

For the next version SGP the QHY camera will return at Landscape Orientation?, I have session with SGP in portrait Orientation and Landscape Orientation and the best is Landscape for us to verify the picture.

Thank you,

Leandro