|
|
bayer_test_pattern using method GBRG.png (13,820 bytes) bayer_test_pattern.png (2,734 bytes) |
|
|
I'm pretty sure is has something to do with your previous remark: >>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. |
|
|
Han, Thank you for your bayer_test image, very useful. All the pattern work correctly with the last CCDciel and Pixinsight. I just take a look at one of the M33 image, from the header the user take the images with the version 0.9.64 that has a bug with the preview because some pattern are inverted, so we cannot compare how it see the color with this version. In Pixinsight, with Auto it select the value RGGB from the header, the image is very purple and show residual matrix, this is clearly not the right choice. I need to force GBRG to show the correct color, the same with CCDciel. This is probably because of the bug with ASCOM camera Flip image option I fix a few days ago: https://github.com/pchev/ccdciel/commit/7af3443a2ae1a285846efbd17d357326209fb879 and https://www.ap-i.net/mantis/view.php?id=2240#c6119 I edit the header with fv to simulate this fix, change YBAYROFF= 1 (without changing BAYERPAT= 'RGGB'), then both Pixinsight and CCDciel show the right color in automatic mode. Can you confirm the automatic color work with your color camera when using the latest git version? try with both "Flip image" checked or not, if possible on a colorful daytime subject that make more easy to be sure the debayering is correct. Also check what the driver report for the color camera in T_ascomcamera.Connect between line 296 and 319. |
|
|
The ASI294C camera is from a club member. I will prepare for him new CCDCiel version from GIT and add a log message for containing values of V.BayerOffsetX , V.BayerOffsetY and FCType. I assume that's what your looking for. I'm still puzzled by the diffractionlimited.com definitions: XBAYROFF – X offset of Bayer array on imaging sensor. YBAYROFF – Y offset of Bayer array on imaging sensor. BAYERPAT – if present the image has a valid Bayer color pattern. The last line indicates BAYERPAT is a boolean. Note that Nebulosity writes: BAYERPAT= T I just found on my laptop an ASI1600MC (source?) image created by INDI with the following: XBAYROFF= 1 / X offset of Bayer array YBAYROFF= 0 / Y offset of Bayer array BAYERPAT= 'GRBG ' / Bayer color pattern The image is now at: https://ufile.io/jiib3ov5 Using the GRBG the de-mosaic works fine. But in CCDCiel the automatic demosaic fails! So my impression from this image is to use either BAYERPAT or X/YBAYROFF but not both combined? Unfortunately I can't test it with Pixelinsight. At the moment I'm uncertain how interpretate the above three keywords. Are all three keywords read by Pixinsight or only X/YBAYROFF? Han |
|
|
A simular discussion at SIRIL https://www.forum.siril.org/index.php?topic=227.0 gives a link to ZWO indicating the following: Yang: correspondence between pattern and offset is: RGGB: x=0,y=0 GRBG: x=1,y=0 GBRG: x=0,y=1 BGGR: x=1,y=1 This indicates that BAYERPAT and X/YBAYROFF are two ways to describes the same bayer matrix. You have to apply only one of them? |
|
|
Yes, it is important to know what the driver report for V.BayerOffsetX , V.BayerOffsetY and FCType. The definition of BAYERPAT do not imply it is a boolean. The only thing that's sure is a BW image do not include this keyword, but otherwise it can be interpreted as you want. This is a problem with this non-standard keyword that are not defined precisely. Pixinsight also debayer correctly in automatic mode if I change BAYERPAT= 'GRBG ' in the M33 file. So it interpret this value not as a simple switch. About the ASI1600 Veil image, I think this is a bug in INDI. It must not set both XBAYROFF=1 and BAYERPAT= 'GRBG ' . CCDciel and Pixinsight combine the two and produce wrong color. This is clear from the ZWO forum link, it must be: XBAYROFF= 0 YBAYROFF= 0 BAYERPAT= 'GRBG ' or the equivalent: XBAYROFF= 1 YBAYROFF= 0 BAYERPAT= 'RGGB ' but not a mix of the two. So yes, BAYERPAT and the offset must be combined to get the final pattern. From it's result this is also what Pixinsight do. In my code I adjust the bayer pattern found in the header with the two offset before to debayer. The code is here: https://github.com/pchev/ccdciel/blob/master/src/cu_fits.pas#L2105 |
|
|
I make another change to not write the BAY* keyword when the binning is set and greater than one: https://github.com/pchev/ccdciel/commit/ad90a54a200c2d5392ce1bdc98da2c5ec9cbf9aa |
|
|
On Thursday or Friday I will have the values V.BayerOffsetX , V.BayerOffsetY and FCType and a new image of the ASI294C camera. |
|
|
Did today with a club member the test with the ASI294C camera: 11:01:07 ASCOM.ASICamera2.Camera: Special: BayerOffsetX: 0 11:01:07 ASCOM.ASICamera2.Camera: Special: BayerOffsetY: 0 11:01:07 ASCOM.ASICamera2.Camera: Special: Sensortype: 2 No exceptions The header contains then XBAYROFF= 0 / X offset of Bayer array YBAYROFF= 1 / Y offset of Bayer array BAYERPAT= 'RGGB' / Bayer color pattern I was a little puzzeled by the 1 in the header till I saw this in this code: if FhasCfaInfo then begin CfaInfo(OffsetX,OffsetY,CType); if FASCOMFlipImage and (not odd(FCameraYSize)) then OffsetY:=(OffsetY+1) mod 2; In automatic mode the colours of the new images are correct. So the offsetX, offsetY are applied correctly. It is a little difficult to see but using any other pattern the colours did not match. The two FITS test images are available from here: https://ufile.io/w1sd94hy Attached the result as jpg in automatic debayer selection So this looks all good! I have to add offsetX, offsetY in ASTAP to get the colours correct in automatic. :) test1.jpg (148,817 bytes) test2.jpg (155,384 bytes) |
|
|
The blue is as usual too weak. The get better colours you have to increase blue and reduce green. I see the same in ASTAP. For astronomical images ASTAP can adjust the colours assuming the average star colour is white and background is grey. Does "balance from camera only work for DSLR cameras? test1 corrected.jpg (155,434 bytes) |
|
|
Thank you for this test Han! Yes, the YBAYROFF is set to 1 because the ASCOM image array is flipped vertically to write to the FITS file. If you not want that you can uncheck the flip option in the CCDciel ASCOM camera setup. "balance from camera" work only for DSLR because I get this information from LibRaw and there is no corresponding ASCOM properties. I will change the text to make clear this is for DSLR. Even if the option is checked the program use the cursor values if the FITS keywords are not present. This is totally non-standard keyword I invented for the occasion because I not found any reference for that. But this values are interesting only for the preview image, for real image processing you have much better color balance options. I debayer the two image in the latest Pixinsight in automatic mode and the color are right. It show in the console it use GBRG, so it take account for the YBAYROFF value. We must be careful when looking at old forum post about Pixinsight debayering because the FITS keyword BAYERPAT and X/YBAYROFF are only supported since May of this year. I try to send you the link to the code I use to alter the pattern based on the x/y offset, but it no more work because I do other change in the mean time. Here is a link to a specific version of the file that must not change: https://github.com/pchev/ccdciel/blob/81f2583d290350627e48444210b2a7806fc76e04/src/cu_fits.pas#L2064 |
|
|
Yes all clear now. Still I find this three keyword description for the Bayer pattern inefficient. It could be all described in the single keyword BAYERPAT. If the image is flipped they could simple have adapted the BAYERPAT accordingly. But that's now too late, the standard is set. Maybe you disable (=greyed) the check-mark "Balance from camera" in case no DSLR is present. |
|
|
My understanding of this keywords is BAYERPAT represent the base pattern for the sensor. Then the capture application can set the offset in specific case, like flipping the y axis as I do, or if a ROI frame start at an odd position. In CCDciel I force the ROI to be on even position to avoid this problem. Maybe this look simpler to implement with the offset? I can try to detect if the configured camera is a DSLR but this is not easy. This option really work only for INDI DSLR configured to send RAW files. Or when opening a raw file from the File menu. Maybe start by enabling it only for INDI camera? |
|
|
Or label the checkbox "Try to use color from DSLR RAW" and make it to not disable the R,G,B cursor? I want to keep the option to disable the automatic color from LibRaw in case there is an issue with a specific camera. |
|
|
>>Maybe start by enabling it only for INDI camera? Yes why not. >>Then the capture application can set the offset in specific case Correct, I didn't realise the offset could be higher then 1. I better use the odd(xbayeroff) function. |
|
|
Suggest: DSLR color balance Maybe the simplest way it to disable it after loading the image and there is no libraw info regarding the white balance correction. In most cases the user will look to this only after loading the image. |
|
|
I do a change so this option can stay checked and do not affect the use of OSC camera. The label is "Use DSLR color balance" and I move the option so it not look related with the color balance cursor. It is checked by default and the only case it need to be unchecked is if LibRaw return wrong information, for example with unfiltered DSLR. If this is OK for you I think we can close this issue. |
|
|
Yes close the issue. |
|
|
I will make a new version soon. |
- Anonymous
