Suggestion for error detection in CosmeticCorrection

[johnpane]

I suggest that CosmeticCorrection should throw an error if the CFA box is checked and it is asked to operate on an RGB image.

If CosmeticCorrection had this check, it would have saved me a lot of wasted time. Yesterday, I accidentally specified my RAW rather than calibrated subframes as input to CosmeticCorrection. It deBayered them and produced color output files. Since the next step in my workflow is to deBayer, I did not notice any issues until much later. After 3 hours of image integration (on a 16-core cpu!) I was disappointed to see vignetting was not fully corrected, but this wasn't enough to make me realize I had a serious problem. It was only after another almost 3 hours of DrizzleIntegration that a problem became evident - a nearly colorless rendition.

[wvanreeven]

Wouldn't it be better to make deBayer throw an error when trying to use it on already-deBayered images instead if possible?


Wouter

[johnpane]

Maybe. As I think about this, either one is problematic if the input is an RGB Bayer image. That is, simply checking if it is monochrome or RGB is insufficient to distinguish an already-deBayered image -- that would require looking at the data (whether individual pixels are monchromatic)

A possible alternative is for DeBayer (explicit or when done automatically on reading in images) to insert a keyword that could be detected by either or both of these processes (and possibly others when expecting CFA data).

[wvanreeven]

To my best of knowledge, raw RGB images contain a FITS keyword that indicates the Bayer pattern OR are DSLR raw images (CR2, CR3, etc). Once PI has processed them, they will be XSIF images (unless, with all due respect, the user is stubborn). The un-deBayered XSIF images contain a Bayer keyword as well which IIRC gets removed once the image has been deBayered.

This all falls apart of course if the PI user decides to do all in JPEG or another image format other than the RAW formats but in my humble opinion those users need to be educated anyway.


Wouter

[johnpane]

I think you are taking an excessively limited stance on the possible file formats and use cases. I'm confident there is a solution that does not impose unnecessary rigidity in the possible file types, workflow, metadata, etc.

[bulrichl]

To my best of knowledge, raw RGB images contain a FITS keyword that indicates the Bayer pattern OR are DSLR raw images (CR2, CR3, etc). Once PI has processed them, they will be XSIF images (unless, with all due respect, the user is stubborn). The un-deBayered XSIF images contain a Bayer keyword as well which IIRC gets removed once the image has been deBayered.

For images of digital cameras in the proprietary raw format (e.g. Canon: CR2, Nikon: NEF, Sony: ARW) your statement is correct, the bayer/mosaic pattern is handled by the RAW module and the raw image decoder LibRaw. When the image is saved in XISF format, the bayer/mosaic pattern is stored as a property of the XISF file.

However, for images in FITS format of above mentioned digital camera and astro OSC cameras (CCD cameras, or CMOS cameras) the capturing software either generates FITS keywords (BAYERPAT, XBAYROFF, YBAYROFF) that characterize the bayer/mosaic pattern or not. When these FITS keywords exist, PixInsight will evaluate them and when the image is saved in XISF format,  the bayer/mosaic pattern is stored as a property of the XISF file. However, there are capturing programs (e.g. SGP) that currently do not generate these FITS keywords. In these cases, no property corresponding to the bayer/mosaic pattern will be stored in the XISF file. In this case, the bayer/mosaic pattern for the debayering process has to be be set by the user ('Auto' will lead to the error message: "*** Error: Unable to acquire CFA pattern information: Required image metadata not available.".

Bernd