Raw lights and captured calibration frames are vertically flipped relative to each other

[Borodog]

I have not seen this happen before. I don't know if it was always happening somehow (hard to believe), is due to a change in SharpCap or Siril, or is somehow related to the camera I am using, which has some quirks (Touptek industrial IMX571-based camera).

What is happening is that:

1) I capture calibration frames in SharpCap using the Capture menu. I end up with a nicely stacked master dark and calibrated master flat. So far so good.

2) I live stack for a while, saving the stacked raw frames for later post-processing. The master light and dark are clearly doing their jobs correctly.

3) But when I go to calibrate the raw lights in post, they are flipped vertically relative to the calibration frames. Or at least they are in Siril. I had to go in and manually vertically flip the calibration frames and re-save them.

Is there a setting somewhere that fixes this? The only thing I can find is regarding the Bayer pattern, but this is not that. The "Flip (after dark/flat)" option is not activated in SharpCap, by the way.

Thanks,

Mike

[Chuckwagon]

Hi Mike,

I've noticed the same thing. When I view a raw frame (fits) in Siril, it's flipped. The ASI Fits Viewer shows it properly, and Sharpcap will reload it into the folder monitor camera with the same orientation, but for some reason Siril has it flipped. I have been manually flipping the images as needed and just assumed the Siril was reading the fits header in some odd way. My camera is an ASI2600 Pro.

Cheers,
Charles

[Borodog]

This camera is also an IMX571 based camera.

[admin]

Hi,

are all the files in question FITS? The vertical orientation of FITS files is a bit of a sad story for SharpCap and a number of other pieces of software

The FITS documentation says that the data in the file should start at the bottom left of the image and work upwards with the last data in the file the top right. This is the opposite to most other image formats which start at the top left. I didn't notice this quirk of FITS when I added FITS support to SharpCap and lots of other application software developers didn't notice either, since there are plenty of pieces of software out there that either write them just like SharpCap or read them assuming the first data is the top-left corner.

This is one of those things that is hard to fix once you get it wrong once - if I swap to writing FITS files the right way now then it would be likely to break processing workflows for lots of people who have become used to dealing with the ways things currently work... For the sake of being technically correct, I would upset lots of people.

Fortunately there is now a sticking plaster for this problem - a FITS header 'ROWORDER' which is gradually being supported in more software. SharpCap writes 'ROWORDER'='TOP-DOWN' in FITS files so that processing applications that understand the ROWORDER header can deal with the file correctly.

So, the things that are occurring to me that might cause this are

1) Siril is reading the ROWORDER header, but somehow either the raw frames or the calibration frames are missing it, meaning that Siril is flipping one lot of images but not the other - this can be checked with a tool to read the FITS headers.

2) Siril is not reading ROWORDER and the frames are a mixture of formats - ie FITS for RAW, PNG for calibration, meaning that Siril would interpret the FITS ones as upside down.

cheers,

Robin

[Chuckwagon]

Hi Robin,

My files are all fits. I haven't had the exact same issue as Mike, as I haven't been using the master calibration frames from Sharpcap within Siril. But I just checked and it does also flip the Master Dark (a fits file) if I open it individually. So perhaps Mike is using PNG for his cal frames? I've been using the individual frames and letting Siril build its own masters, and they have all lined up so I never had a problem with them not matching. I just noticed that it flips them. So it seems that any fits image from Sharpcap, whether a stack, an individual frame, a cal frame, etc., gets flipped.

The headers do have the ROWORDER=TOP-DOWN line in them. The header display in ASIFitsviewer and Siril's own viewer both show the ROWORDER setting. So maybe Siril isn't honoring that setting properly? Or maybe there is a setting somewhere in Siril that controls that behavior and it just needs to be changed. I didn't see anything obvious, so I'll do a little more digging.

Cheers,
Charles

P.S. - I just checked the Siril documentation, and it seems they do recognize the ROWORDER keyword in the header, but they only use that to insure the demosaic happens in the correct order. "Siril will always read and display images in the bottom-up order, however if the top-down information is specified in the keyword, then Siril will demosaic the image with the corrected pattern."

So I guess everything is working as intended, and maybe it's just a mix of file types, PNG and FITS, that is the issue. Mike would need to confirm.

[admin]

Hi Chuck,

thanks for digging up that info regarding Siril - certainly that would mean that bringing mixed formats from SharpCap into Siril would be a mess. I must say that I would consider that implementation of ROWORDER in Siril to be 'incomplete', but there you go...

cheers,

Robin

[Chuckwagon]

Hi Robin,

I agree. I would think you'd want to display the image in the manner the ROWORDER keyword indicates to avoid any confusion like what we've had. But at least they do use it to insure a correct demosaic process. So, better than it could be I guess.

Cheers,
Chuck

[Borodog]

The problem is that I had flipped by file format to PNG from FITS and forgot to switch it back. Everything that has followed on has been a nightmare. I still haven't managed to create a calibrated stack. The flat was from the day before and was still FITS, the dark was from last night and was also PNG, but you can't use a PNG as a calibration file, so I manually saved it as a FITS but that flips it so I have to reflip it . . . I used SER for the sequence conversion in SIRIL instead of FITS and that seems to throw in another random flip, which make the Bayer pattern wrong, which . . . . on and on and on.

Ugh.