PixInsight Forum (historical)
PixInsight => Bug Reports => Topic started by: jwaters125 on 2020 January 21 14:02:44
-
Trying to help somebody on CN. See the link below. I used WBPP to process the Canon 600D images, then ImageIntegration and AutomaticBackgroundExtractor. After using AutomaticBackgroundExtractor the image is Green.
- WBPP - Full auto BIAS, Darks and Flats, DeBayer set to RGGB / VNG. Did not do Image Integration.
- ImageIntegration - Mostly Default Values. Winsorized Sigma Clipping.
- AutomaticBackgroundExtractor - Subtraction
The resultant image is GREEN, not RED.
https://www.cloudynights.com/topic/691413-process-my-data-just-over-3-hours-on-the-rosette/
------
UPDATE - So I reran the above images using BPP and got the same results. Green image. I noticed that the Debayer script was updated 1/17. Could this be causing an issue with DSLR CR2 RAW images? I will rerun some of my past data and post an update.
-
Try GBRG.
The Canon 600D is one of the cameras affected by a recent fix in LibRaw which is the library PixInsight now uses for performing the raw conversion. So it now requires GBRG instead of the previous RGGB.
A detailed explanation is here:
https://pixinsight.com/forum/index.php?topic=14219.0
Mark
-
Thanks Mark - Is a fix planned?
ADMIN - Please move this to the "General Forum'.
-
Thanks Mark - Is a fix planned?
The new LibRaw behaviour is correct, I believe.
Indeed, if you look in the "CR2 CFA Pattern" attribute in the 600D EXIF header you will see [Green, Blue][Red, Green]
Mark
-
I am missing something. If the header is correct why are the images turning out green? As far as I know all Canon EOS camera's are RGGB. I have always used RGGB and never Auto.
I will try rerunning on Auto.
-
the libRaw guys/gals started removing a row of pixels from the image at some point. that flips the bayer matrix, so it is no longer RGGB but GBRG.
in the linked thread juan says they had a good reason for doing this - i dont know what it is but i guess since most people expect libRaw to debayer the images for them, it is not something that they are going to notice (in other words, libRaw knows that it removed the row and changes how it debayers accordingly.)
the real problem comes if you have calibration masters produced with the old libRaw or DCRAW and you try to use them against lights made with the new libRaw. either that fails outright because the images are different sizes, or the calibration is outright wrong as the pixels no longer correspond to one another in the lights and calibration frames.
anyway if you prepare your masters and lights with the new libRaw then everything will work out, but you have to know that the bayer matrix is no longer what canon says it is. based on what mark has said it sounds like if you use Auto it should all work out OK.
rob
-
Thanks for the info Rob. I reran with VNG and Auto. Its the correct color low. I would like to know the details why Juan made the change.
-
well juan didnt make the change - the people who are maintaining libRaw did. libRaw is an open-source library for dealing with a variety of DSLR file formats. he uses it in PI because to implement raw support himself would be a serious reinvention of the wheel. it is a two-edged sword... if they break something they dont consider important (but that thing is important to some users of libRaw) then those users (juan) are screwed.
thus juan reverted the row-chopping change to their source code and built a libRaw library that PI users can optionally install.
rob
-
Thanks for the explanation Rob...!