QHY12 subs come through in portrait mode

Hi all,

Just purchased latest SGP and loving it.

I have one small issue with QHY12 subs coming through in portrait mode. In “frame and focus” it’s easy to hit the rotate and see it in landscape, but it’s totally throwing the “frame and mosaic tool” which shows it’s preview frame guides as landscape oriented. It also means I need to manually bulk rotate to match my current calibration library of masters. I can’t see anything in the driver settings to alter this behaviour. Is this a bug or am I missing something?

Dylan.

This is a known issue with some of the QHY drivers. ASCOM does not specify which way an image should be although SGP seems to prefer landscape as you have found.

Thanks DesertSky,

Is there anything I can do in SGP to alleviate the issue… I don’t mean to be “that guy” but I’ve been using Nebulosity for years with the same driver (same machine) and they always came through as landscape.

I do my images in 2 stages using 2 different cameras(mono then OSC), and this means the QHY12 OSC won’t match the mosaic targets in the sequence.

Thanks again!

d

I’m not sure what you mean by “won’t match the mosaic targets in the sequence”. Do you mean match the reference image that is saved when you create the target? As you likely know, when you create a mosaic the images are shown as landscape no matter what camera angle you have. In the end what is important is to have the actual camera angle match the angle when the mosaic was created. If you do a plate solve and have the correct angle, RA and DEC, it does not matter how the image is displayed in SGP. When you combine the images you will get the image as designed in the mosaic. The reference image created by the mosaic is just that a reference. You can look at it to see if it resembles the actual image you got but the display orientation does not matter in the end.

That’s what I would have assumed too… but I can assure you that’s not what happened.

Here is the mosaic and the frame that came out (ignore star overglow I solved that). You can see the target is 90 degrees out from where it should be. I don’t have a rotator but manually rotated 90 degrees to see if it would fix… no luck. Weird right?

Perhaps this is a 3.0 “bug” that is actually QHY’s driver fault but the last SGP corrected for?

Have you tried the manual rotator that SGP provides? Using that will get the correct orientation according to your mosaic. It is also possible that you will need to rotate the mosaic 90 degrees to get the camera orientation you want.

Thanks I’ll give that a go and see if it helps as a workaround.

Is there a bug anywhere?

The ASCOM specification has properties for the frame width and height but there is no stipulation that the width must be greater than the height.
Then the image data is specified to be a 2D array with the dimensions that were set with the default being the maximum width and height.

If the dimensions of the image array that’s sent to SGP has a height greater than the width then that’s how the image can be expected to be displayed.

“Fixing” this could be tricky, it would be easy the look at the height and width of the image and rotate it if the height was greater than the width but there are snags. First which way to rotate? Second what happens if the user has chosen to use a subframe where the height is greater than the width? How does the system prevent that being rotated? And what about the data that’s saved? Is that to be rotated as well?

One thing that may help to check what the camera is returning is to run the ASCOM Conform application with this camera. That will exercise all the functions of the camera and show very clearly what the frame dimensions are and what the image array dimensions are.

Interesting, thanks Chris. I’ll see what I can find out.

BTW, looking at your screen shot it seems to me that the orientation of the image you collected and the orientation of the reference mosaic image are the same. The stars in both match and the centre of your image seems about the same as the mosaic frame 1. What’s different are the boundaries of the two images.

Looking at SGP 2.6 in the mosaic wizard all you need to do is specify the image size in pixels in the same way as the image from the camera, with the height greater than the width. Once that’s done the frames on the mosaic wizard are portrait and the images you get should match the wizard.

Good idea… I’ve swapped width and height around and that certainly sets the field to portrait in the frame and mosaic wizard but clouds came over and I’m yet to confirm if the image result is itself now oriented correctly too as I’d also rotated and reframed … if that works it’s a workaround that will let me eventually finish the run. Thanks Chris!

Yep it matches now… not ideal having different orientations for my 2 QHY cameras as I have to run different mosaics and sequences for the same run but it gets me out of jail. Thanks!

Ya, it’s a “quark” of their ASCOM driver. As Chris mentioned it’s not technically wrong, it’s just different. Most Qhy camera are this way actually. We put a lot of effort into fixing this at first and essentially just decided to stop. On earlier models it actually was broken but we could detect it and “fix” those (it would report flipped Width and Heights compared to what the CCD actually reported). In more recent cameras they have corrected this so we no longer “fix” them. We just display as the driver says.

Thanks,
Jared

Cool, thanks for the clarification Jared. I understand where you guys are at … it’s not your mistake to fix. I wish there was some way to get it back to displaying as landscape again in the frame and mosaic tool … just like how the frame and focus tool has a rotate option, because I now have to plan my mosaic Ha/Mono runs with RGB runs at 90 degrees to each other heh… I could’ve used the same sequence for both cameras otherwise.

Thanks again for the clarity.

d

I have QHY10 and it displays captured images in portrait but actually takes the images in Landscape or as the camera is orientated. This does not affect Mosaic wizard as this uses the orientation either that you have entered or was calculated after running the target. As long as the orientation of the camera matches the figures entered in the camera setting all works fine on mine. Took me a while to get this sorted. Especially the angle the camera needs to be set up physically. Note when in polar position the camera sensor need to be set to portrait which is 0 degrees (Rotated anti clockwise from horizontal by 90 degrees) See image which I found on the internet. Sorted it for me. Hope this helps:
post-1029-0-88490900-1399841477