1.2.0 rc1 color balance issue

Something seems to have changed in Siril relative to stacked color balance. Normally, when I do an auto stretch on the stacked file it has a very strong green cast which is normal because of the RGGB bayer pattern. With the latest release 1.2.0 rc1 the starting color balance is slightly magenta, if I do a photometric color balance I end up with a nearly monochrome image. Is anyone else seeing this? I like the new features in the latest release so I’d hate to roll back. Problem is, it’s really unusable as is.

Just as a check that the data is good, I processed the same set in Deep Sky Stacker and the color was fine.

I’ve also processed data that was processed in the past and the same problem happens.

Hello, generally the magenta cast shows an issue in the demosaicing. This can come from many problem like FITS orientation for example.

But as usual, with no sample to download, we cannot guess

The orientation issue is explained here: FITS — Siril 1.2.0 documentation

And at the end you have some image samples covering all use cases, showing that Siril knows how to debayer most images.

I noticed the same thing since the latest update. After the OSC_Preprocessing script is finished, the stacked file doesn’t have that green tint. So I guess it is applying PCC behind the scenes?
When doing the calibration/registration/stacking manual then the green tint comes back again in the stacked file.

No.
The background is neutralized, that’s all. No hidden PCC

Because you need to check the option rgb equalization in the stacking tab to reproduce same behavior.

Ok, now I get it. So I can do a PCC after this rgb equalization? Because I don’t see a difference after applying PCC, or maybe I don’t see the differences.

yes you can, there can be very small difference between the two depending on the camera

I also saw the issue the original poster observed; namely a magenta cast to images when I use an OSC. This was my first imaging session for many months so I updated Siril.

Here are some steps that can reproduce the issue and also some that do not display it. I can reproduce the issue with no preprocessing apart from file conversion.
This file is one of my sub frames.

2023-09-05_22-40-45_North America Nebula_100_50_-5.00_300.00s_0013.fits (17.3 MB)

I use version v1.2.0-rc1
If I open a FIT file of one of my sub exposures and perform the statistics on the file, it reports a mean RGB of 81.5,116.9,94.0 respectively for the frame. That frame shows a green cast as expected from the higher G value.

If I create a minimal “SER sequence” using two subs using the conversion option, then inspect the statistics of the frames from the SER file, the RGB value is now 117.0,87.8,116.8. This frame now looks magenta. I would not have expected any change in RGB.

If instead of choosing SER during the conversion I choose “FIT Sequence” then the RGB of each frame matches the original, and all subsequent processing works as expected, eliminating the green cast.

Looking through the changelog, I see that version 1.2.0-beta1 says it “Fixed bug in roworder of SER sequence created from TOP-DOWN FITS images”.
The header of my file says it is “TOP-DOWN”
This might be related to the problem?

1 Like

Hello,

Thank you for this excellent bug report. If all reports were like this it would be easier to debug.
We’re currently working on it and will fix it for the next release.