Why does WBPP use ConvertToGrayscale?

[astro_nic]

I've been trying out the new Weighted Batch Preprocessing, and so far the results have been nice. However, I've noticed during the process, it uses a ConvertToGrayscale process which prevents me from gathering any colours out of my integrated image. Along with the ConvertToGrayscale process, it's also performing StarDetector, and DynamicPSF during this stage of the script, I'm assuming it might be choosing a registered image to use?

What is causing the script to run ConvertToGrayscale, and why is it being converted. Does it have to do with finding a good registered image? Could anyone shed any more details on this process, and if I can use WBPP and still have my RBG from an unbinned image (BIN set to 1).

[astro_nic]

I should mention that past that stage, I do see ICC profile embeded: 'sRGB IEC1966-2.1', 3144 bytes. However, the final light image/master is shown as: Gray 1:3 light_binning_integration | m42_master_light_60s_BINNING.xisf. But I can't convert to to colour once the WBPP has completed.


**UPDATE: I've made a few attempts, but looks like I got it in RBG form this time, although the quality is not very good. I will continue looking into the WBPP options, as I'm unsure why there is/was such a discrepancy between certain runs.

However, if anyone could explain the ConvertToGrayscale function, I would be interested in the benefits of it while batch processing.

[pfile]

is it really converting to greyscale or just not debayering your images? do you have the "CFA images" box ticked?

rob

[astro_nic]

It's converting to Grayscale, and the final image was titled Gray 1:3 rather than RBG 1:4. I did check the CFA Images box, as the diagnostic message was '** Warning: Group Light frames (filter = NoFilter, binning = 1, exposure = 60.00s, length = 226) contains CFA images, the global 'CFA Images' option should be checked.'

I am performing another WBPP script run now to see the results without CFA enabled, and will confirm the results shortly. I did want to mention however, that the quality for the Grayscale image that it produced was fantastic, however, I can't debayer it into RBG (it usually uses RGGB).

Maybe someone can shed some light on using CFA vs not using CFA, especially if the diagnostic warning mentions that it should be used. I'm not as familiar with colour filter arrays, and would be interested in learning more on how it affects the script process (or any PixInsight references/documentation that I should follow up on regarding this topic).

Thanks.

[pfile]

if the camera is an OSC, you need to use the CFA option. this means any one-shot color camera like a DSLR.

the X:Y just means the zoom factor you happen to have applied; it's not part of the image name.

you can't debayer an integrated image that was made from undebayered subs because the bayer grid is completely destroyed by the interpolation done by staralignment.

rob

[warden]

Hi -

I'd like to join this thread, since I'm facing a similar (and perhaps related) issue.

I'm using WBPP to process OSC images of M8. I've checked the CFA box in WBPP, using RGGB and VNG for Debayering. As I watch the process running, I see the Process Console show "ConvertToGrayscale: Processing view: Image01" and on the next line "In-place color space conversion: RGB -> Grayscale: done"

The final masterLight image is shown as RGB, but has almost no color. Examining the histogram shows that the red and blue histograms overlap exactly, with the green histogram slightly (but noticeably) displaced from them. The individual debayered images show similar histograms.

This does NOT happen if I Debayer the raw files manually - colors are normal.

Does this shed any light on the subject?

Regards,

Bill Arden

[pfile]

perhaps - that script is new and i have not used it... and i don't have an OSC anymore.

what is the context for that message? is there a filename given before it prints that message?

so the CFA checkbox has no effect on this at all?

rob

[warden]

It seems more subtle than simply a non-functional CFA checkbox. If I uncheck the box, the result is what you'd expect - a grayscale image ("Gray" in the title bar). If I check the box, it's "almost" grayscale The title bar shows "RGB," so there is some Debayering going on, but the resulting image looks grayscale and the histograms (as I said) show identical, overlaid red and blue with a very similar green histogram slightly displaced.

What information, in terms of screen dumps or logs, would be helpful here? Any suggestions for tests I can perform to provide insight?

Thanks for the help!
Bill Arden

[sharkmelley]

Examining the histogram shows that the red and blue histograms overlap exactly, with the green histogram slightly (but noticeably) displaced from them. The individual debayered images show similar histograms.

This is exactly what happens when the wrong Bayer Mosaic pattern is used.  That may (or may not) be the cause here.  By the way, which camera are you using?

Mark

[warden]

Here's another piece of data. I've done three tests, with the same ten light frames, bias frames and dark frames.

If I run through a manual calibration/debayering/registration/integration process, I get a proper colored image (which I then run through ABE to sort out the colors). The histogram of the final version shows three peaks (R, G, B) exactly on top of each other but of differing heights. I think that's what you'd expect, and the image looks fine.

If I run either BPP or WBPP on these same sets of files, followed by ABE, the histograms overlap exactly - same location and same height (before ABE, they're all the same height, but the red and blue histograms overlap and the green one is shifted, as we've said before). That accounts for the "gray" look of the final images. It looks as though the three histograms have been normalized in some way. Is that an artifact of the scripts, or am I missing a setting somewhere?

With regard to the original question, I've also observed that the call to "ConvertToGrayscale" in WBPP occurs during a section titled "Generation of Image Descriptors," which occurs after the debayering section. I don't see it in the Process Console when BPP is run.

Thanks and regards,

Bill Arden

[warden]

Mark -

Thanks for that point. It's an ASI 071, and I've tried all the Bayer mosaic possibilities. None of them produces "proper" colors with neutral background, but all of them are automatically and easily corrected with ABE. RGGB, which I've been using, is the least odd of the bunch. 

As I study this issue, what concerns me is not the shift of the histograms, but their identical heights. A "proper" image after ABE shows them all aligned but of different heights. The image in that case looks fine. I just posted another comment ("Here's another piece of data....") with details on this facet.

Bill Arden