Auto Debayering in PixInsight

[admin]

Hi,

yes, the XBAYROFF/YBAYROFF/BAYOFFX/BAYOFFY headers are the issue. I was writing them incorrectly on the assumption that they were a different way to represent the information in the BAYERPAT header, and that software would either read one source of info (the BAYERPAT header) or the other (the offset headers).

In fact, the offset headers apply as a modification to the BAYERPAT header, which effectively meant that whatever SharpCap wrote in the BAYERPAT header was being turned back into RGGB by the offsets (this always worked out due to the way that the values are linked). If you had an RGGB camera, then it worked every time. If you had a different camera then it failed no matter what settings you set in SharpCap.

This was purely my bug, not ZWO or any other camera manufacturer, and I have fixed it in the next SC4.1 update which I will release tomorrow. The simple fix is the removal of the four offset headers from SHarpCap FITs files on the grounds that they seem to only serve to break thing - they never contribute to getting the right result. Let's hope it turns out that way anyway - much better to just fix something like this than to need an option because XYZ AstroViewer or some other odd piece of software *does* use the offsets successfully...

cheers,

Robin

[rac19]

Thanks Robin, I will download and test the latest beta, when I get some clear skies.

The more information that I was able find on this subject, the more I wondered about the usefulness of Bayer Offsets. If the camera was aware of the need (possibly related to ROI) to modify BAYERPAT, why couldn't it simply provide the appropriate CFA pattern?

[rac19]

You might find the link below interesting. It mentions that certain FITS keywords are actually ignored, so it seems, by Pixinsight.

https://pixinsight.com/forum/index.php? ... ost-126181

[admin]

Hi,

in theory, the bayer offsets come in useful if you capture an image in ROI mode and the ROI offset from the left or the top is an odd number of pixels. If that happens then the effective bayer pattern of the image is different to that of the sensor itself. This would be something for imaging software like SharpCap to track.

In practice, lots of cameras only allow the ROI to be offset by an *even* number of pixels, so the problem doesn't arise. Even for those cameras that do allow an odd value for the ROI position, SharpCap itself tends to impose the limit of the position co-ordinates needing to be even to avoid the complexity of the offsets being needed. In practice, nobody will care if their ROI is 800x600 located at 60,40 rather than 59,41

cheers,

Robin

[rac19]

I finally had a clear night and did some image capturing with the latest beta. As you stated there are no Bayer (CFA) offset cards in the FITS Header. The image colour balance is now correct.

Incidentally, I can't help thinking that the FITS "cards" were originally 80 column punch cards, an indication of just long ago the FITS format was developed.

EDIT: The image was processed with Siril with auto-detect for the CFA pattern. I just stacked an auto-stretched to see how the colour balance looked. In Siril it seemed to make no difference whether the colour channels are linked or not linked when auto-stretched is used.

SIMPLE = T / C# FITS: 03/29/2023 20:02:51
BITPIX = 16
NAXIS = 2 / Dimensionality
NAXIS1 = 4656
NAXIS2 = 3520
OBSLONG = 151 /
FOCALLEN= 1380 /
RA = 84.11682948075345 / Epoch : JNOW
DEC = -5.3699832775641 / Epoch : JNOW
OBJCTRA = '05 36 28.000' / Epoch : JNOW
OBJCTDEC= '-05 22 11.000' / Epoch : JNOW
EQUINOX = 2023.2399096189897 /
GAIN = 32 /
OBSLAT = -33.75 /
OBJECT = 'Orion Nebula' /
BLKLEVEL= 10 /
OBJCTALT= 50.8679493997286 /
OBJCTAZ = 309.98323879538 /
FOCTEMP = 26.729999542236328 / CELCIUS
FOCUSPOS= 246517 /
JD_UTC = 2460032.8767941683 / Julian Date at mid exposure
DATE-OBS= '2023-03-29T09:02:27.5161205' / System Clock:Est. Frame Start
DATE-END= '2023-03-29T09:02:42.5161205' / System Clock:Est. Frame End
EXTEND = T / Extensions are permitted
BZERO = 32768 /
BSCALE = 1 /
ROWORDER= 'TOP-DOWN' /
EXPTIME = 15 / seconds
XPIXSZ = 3.8 / microns, includes binning if any
YPIXSZ = 3.8 / microns, includes binning if any
XBINNING= 1 /
YBINNING= 1 /
CCD-TEMP= 24.6 / C
COLORTYP= 'GRBG' / Try BGGR if image upside down or R/B swapped.
BAYERPAT= 'GRBG' / Try BGGR if image upside down or R/B swapped.
FRAMETYP= 'Light' /
SWCREATE= 'SharpCap v4.1.10341.0, 64 bit' /
AIRMASS = 1.287887847286356 / Pickerings formula from target elevation only.
DATE-AVG= '2023-03-29T09:02:35.0161205' / System Clock:Est. Frame Mid Point
INSTRUME= 'ZWO ASI1600MC' /
END

[admin]

Hi,

glad to hear that it is now working OK. Hopefully the change will be positive for everyone!

I suspect you are right about the headers, maybe indirectly via Fortran code standards (which were heavily influenced by punched cards and Fortran was used extensively in scientific computing - probably still is!)

cheers,

Robin

[rac19]

Yes, I remember handing in stacks of Fortran punch cards for batch processing. In fact, I learned to type on a punch card machine. Not what you would call "touch typing".