Flipping Image Problems

I just did an imaging run last night with and when I try to process it in Pixinsight I get an “Incompatible image geometry format” error for my flats. I looked at the Fits headers from last night and from a session last year. I have a QHY10 camera which is one of those where you are flipping the image for display.
What I am finding is that the image is flipped in the fits file. Also, in the light files there is a keyword FLIPPED with a value of F. This keyword is not in the flats even though they are flipped.

This change is going to cause big backward compatibility problems because my images form last night are flipped relative to my saved dark and bias images. Flipping the image for display should not flip the image in the fits file.

1 Like

Have you tried adding the flats as custom in BPP script. It should then use the files as it will assume you are specifying the correct flats

What I did was rotate the lights and flats to match my dark and bias files.

I hope I rotated them the correct way. Otherwise they won’t match the darks and bias files. Another reason the files should not be rotated from previous versions of SGP.

I also have a QHY10 and I think it was my suggestion that the frame be rotated to landscape when displayed. Unfortunately, I haven’t had any clear skies since upgrading to 2.5.17, but I suspect that I’ll have the same problem, since all of my darks and biases were collected with previous versions.

I wonder if there is a way to display the images in landscape (I really like that feature) but save them in the same orientation that they come off of the camera.


That is my hope also. The landscape display is nice.

@DesertSky, @spokeshave

Flipped means something different. Your images are not flipped, they are rotated.

I don’t think this is really a huge issue. The fix in PI (or whatever you use for processing) is simple… just rotate calibration images 90 degrees (to the right). I will make sure this is prominently featured in the release notes (how to fix your cal frames).

We will likely leave the changes to rotate portrait ASCOM images the way they are in

Considering that SGP has consistently stressed backward compatibility, I am disappointed in this response. I would rather see it revert to the original design rather than break all my old images. Yes, I can rotate the dark and bias calibration images but I also have to keep track of which image sets are rotated which is not an insignificant issue. Also, are you considering compatibility with other programs that might be reading these files (Prempro, GoldMask, etc)?

You are certainly correct about rotated vs flipped so I am wondering where the fits FLIPPED keyword is coming from? As I said, it was in the light files but not the flats.

1 Like

I think flipped refers to which side of the pier the scope was when the image was taken

If you add the masterflat, or flat files as a custom file and specify what it is (you may also have to do the same with the light files) then you should be able to apply the flats to your images - sorry if I made this unclear

I would prefer not to have to manually rotate all my calibration data for a visual convenience during capture. Pre processing is a PITA enough and I think the majority of us aren’t sitting around staring at SGP all night for a debate over landscape viewing.

Why did this change?

There are three users (including the original requester) asking not to have the image flipped in the fits file. So, can we either find a way to flip the image for display only or revert back to the original method? It would be ideal to get his into the next release (18).

1 Like

Flipped is more a artifact of your imaging train than anything and has no bearing on where you are pointed or the rotation of your image. Flipped indicates that your image is essentially mirrored with respect to the sky. This often happens when you have an odd number of mirrors. But it can also occur if your ccd writes bottom to top rather than top to bottom.

[quote=“mads0100, post:10, topic:3199”]Why did this change?

For almost everything it didn’t. The Qhy ASCOM driver is somewhat odd in that it stores image data in a portrait orientation where every other camera is landscape. We have been displaying and saving this data in a landscape orientation for a long while (since the inception of SGP). Something was different about the Qhy10 and it somehow missed this conversion. The recent release was addressing this to conform to the standard.

We will not be going back to portrait display. This is an error that has been corrected.

Rotating the calibration data should be a fairly trivial, one time task. Sorry for this extra processing step but at least going forward it won’t be an issue.


There is nothing in the ASCOM camera standard that indicates a preference for portrait vs landscape. I don’t know why the driver is written as it is but it meets the standard. When I print a document and choose to print it in the opposite orientation from the original, I don’t expect that the program is going to change my file format. There is nothing inherent in SGP or any other imaging processing program that prefers one orientation to the other.

This all started from two posts, one that indicated that the HFR calculation did not work on a rotated image and another that indicated a preference for viewing in landscape mode. The first one is an obvious bug in the calculation code. The second one was a display preference only and the poster later indicated not wanting the image to be rotated in the file. So should I conclude that this change is being done for the convenience of the developers? I don’t mean to be harsh but I’m not seeing anything in this decision that is based on user needs/wants. When you rotate the image file, it is no longer the “native image” from the camera and thus will likely not match any other program that uses the same ASCOM camera driver. So forever in the future all SGP users with certain cameras will have to keep track of the fact that their images are “rotated clockwise” relative to older images and other programs. You can try to document your way around the change but it is likely to remain a head scratcher. I’m not trying to provoke anyone but rather I am trying to promote a in-depth review of all the consequences and alternatives.

1 Like

I hate to revive this old topic but it seems like there is still an issue and I’m not sure I understand the previous posts.

When I display a raw sub in SGP, I treat the orientation as “correct.” When I display that same sub on the PixInsight desktop, the image appears the same – that is, same orientation. However, when the subs are processed in the Batch Preprocessing script, the resulting integration frame (“master”) is flipped vertically. A little research showed the flip is occurring during the initial calibration step in BPP.

This is new. Looking at subs -vs- masters of targets shot a year ago, do not show this flipping.

I am really confused about this since I am afraid I am applying flipped calibration frames against unflipped raw subs.


On the Pixinsight batch processing dialog, do you have “Up-bottom Fits” checked? For most consumer grade cameras you should have it checked. I believe SGP assumes a given vertical orientation so I am thinking Pixinsight might be doing the flip if you have this option set. As I recall, you need this option set to make the debayer work correctly.

The “Up-bottom Fits” option in BPP is not checked and AFAIK, I have never used that option. I am imaging with a QSI683wsg-8. Unless PI has made a change in their processing logic, this option should not be an issue.

Doing a little more research, the last target I imaged in early August does not show this flipping but the next target I imaged (late Sep) does show the flipping. I am using SGP currently and I do generally use the beta releases as they come out.

But it is clear that something is happening in the BPP script since displaying a sub directly on the PI desktop looks the same as displaying it in SGP.

I even looked at the FITS keyword “Flipped” but it is uniformly set in all the SGP frames as “F”.

Ok, 15 minutes have passed. I decided to run a BPP script to build a new set of flats and this time I specifically enabled “Up-bottom Fits”. This fixed the flip issue with the integrated flat frames. This implies PI has changed the logic of that option in a recent release. Its default value is unchecked and I believe that has always been the default.

At any rate your observation solved my problem – many thanks for your time.


I don’t think PI has changed with regard to this option.

i don’t think PI has changed anything either. the reason for opening a file being different than what BPP does is because BPP uses “format hints” to override the FITS file handler settings (in the Format Explorer tab). when you open a file to the desktop, the FITS file handler settings are used; when you use BPP the state of the “up-bottom” checkbox is used to explicitly override the behavior to “up-bottom” or “bottom-up” - the state of the FITS file handler reader direction setting is never consulted.

for what it’s worth i have been using an STT-8300M with SGP for more than a year across v2.4 and v2.5 and have never seen any difference in fits file behavior in pixinsight. i do not use BPP but my fits reader is set to “up-bottom”.

i just read the source code for the BPP script, and the default for “up-bottom” is “true”. however, BPP is designed to save whatever user settings have been changed when they differ from defaults, and restore them the next time BPP is opened. so if you had accidentally unticked “up-bottom” at some point, that gets remembered. my guess is that this is what happened.


I, too, just noticed that PI / BPP remembers the Up-bottom Fits option between invocations. It is likely that I accidentally unchecked it in one of my processing runs and that got remembered and used in subsequent runs. I think the reason I assumed I had never used it was that I associated it with OSC cameras and I don’t use an OSC camera.