|
|
preview.png (17,029 bytes) |
|
|
The values in the FITS header are not influenced by the Preview settings. For image capture the FITS header for BAYERPAT, XBAYROFF and YBAYROFF are taken from the ASCOM or INDI driver. For ASCOM this is the properties SensorType, BayerOffsetX and BayerOffsetY. This is set with many other constant properties in T_ascomcamera.Connect in cu_ascomcamera.pas at line 302. Can you check this work for your camera? |
|
|
BayerOffset was previously not implemented because I never found a file with values different than 0 for testing. I implement it now and theoretically it must work but I am very interested if you have an example file: https://github.com/pchev/ccdciel/commit/f2d69cdf728f25014fcf83ad4ccdcddc9405ad83 |
|
|
I make some test with the simulator and fix a problem with YBAYOFF when the image from the camera is flipped vertically: https://github.com/pchev/ccdciel/commit/7af3443a2ae1a285846efbd17d357326209fb879 |
|
|
Unfortunately, I don't have an example except XBAYROFF=0 and YBAYROFF=0. On the forums there is a report that Pixelinsight is interpretating the BAYERPAT different then other programs making it even more complicated. I have a ASI1600MC file created by EKOS & INDI containing: XBAYROFF= 0 / X offset of Bayer array YBAYROFF= 0 / Y offset of Bayer array BAYERPAT= 'GRBG ' / Bayer color pattern An ASI294 file created by CCDCiel file using ASCOM contains this: XBAYROFF= 0 / X offset of Bayer array YBAYROFF= 0 / Y offset of Bayer array BAYERPAT= 'RGGB' / Bayer color pattern So Is XBAYROFF implemented or is it a dummy for some drivers?? |
|
|
I have implemented XBAYROFF, YBAYROFF according to the ASCOM specification: https://www.ascom-standards.org/Help/Developer/html/P_ASCOM_DeviceInterface_ICameraV2_SensorType.htm The offset example at the bottom of the page is quite clear. ASCOM SensorType is always RGGB for the sensors we use. I just commit a patch to not try to debayer the CMYG and other. As I use this value to put in the header, for ASCOM camera we always have BAYERPAT= 'RGGB' , with XBAYROFF, YBAYROFF set correctly for the sensor pattern. INDI on the contrary can set a BAYERPAT different than RGGB as in your example. In this case there is no reason to set XBAYROFF, YBAYROFF to a value other than 0, but we cannot exclude some driver do that. LibRaw give the same kind of pattern than INDI, so I always set XBAYROFF, YBAYROFF to 0 when converting from raw. For example my old Sony A100 as BAYERPAT= 'GRBG'. To explicit that with your example, you have this header with the ASI1600MC and INDI: XBAYROFF= 0 YBAYROFF= 0 BAYERPAT= 'GRBG ' This is exactly equivalent to: XBAYROFF= 1 YBAYROFF= 0 BAYERPAT= 'RGGB ' Another difficulty is to define where the pixel [0,0] is? top or bottom? because this can inverse the matrix. Here ASCOM and INDI also diverge. ASCOM count from the top, as with windows bitmap. INDI count from the bottom because this is the FITS standard. This can make the YBAYROFF to look different in the header but to be both right for the corresponding image data. In CCDCiel I have the option "Flip the image vertically" in the ASCOM camera driver. This is to make the image orientation compatible with INDI and this now flip the YBAYROFF value in the header. |
|
|
At https://www.cloudynights.com/topic/551901-astroliveusb-to-nebulosity-4-lose-rgb/ An ASI1600MC-C Nebulosity header contains this BAYERPAT= T XBAYROFF= 1 YBAYROFF= 0 That seems to confirm the earlier ASI1600MMC reported BAYERPAT= 'GRBG ' / Bayer color pattern. I could not find any other files, My old QHY8classic driver does not report anything. My feature request doesn't make sense for modern ASCOM drivers since they report BAYERPAT. So ignore my feature request. I will implement in my program the keyword BAYERPAT only. For the moment, I assume the reported XBAYROFF, YBAYROFF values are fixed and correct in the ASCOM driver but configurable in INDI making the less relliable. Han |
|
|
I overlooked your last post. I'm even more worried now. Looks like a manual override is always required. I will implement it now as follows in ASTAP: 5 options: auto -> Follow BAYERPAT RGGB GRBG BGGR GBRG |
|
|
Ok, I not change the way CCDciel save the FITS file. I was not really enthusiast to modify the header based on preview settings. Yes, I think it is necessary to have a way to force a specific pattern because of all the different use of this keyword. I like the use of Auto in the choice, I will replace the text for this option that is now Camera. Auto is more easy to understand. I will add BAYERPAT= T as a synonym for BAYERPAT= 'RGGB' if some software use this notation. |
|
|
Yes close this topic. Thanks for the usefull info. |
- Anonymous
