Using Pixinsight or Siril Photometric Color Corrections in SC Live Stack

[meies]

I have been using SC for about 6 months for Live Stacking (planetary and DSO). I only recently started post processing the live stack using Pixinsight and Siril. Both of these have tools for color calibration (SPCC in PI and PCC in Siril) that consult databases of star colors and then generate a correction for the image at hand.

In SC Live Stack, I usually use the two "auto color balance" buttons below the histogram. The "from histogram peaks" button leaves the background looking greenish to my eyes, and the "from star colors" leaves a blue background. Of course, I can adjust the sliders until the live-stacked image "looks right," but I wonder whether it is possible to dial in the numbers from either PI or Siril.

In PI, for example, the SPCC produced a consistent correction (averaged over 4 galaxy images) of R/G 0.64, B/G 0.52, G/G 1.0. Is it possible to translate these into numbers appropriate to the histogram color sliders?

In Siril, I am less sure what numbers would be used for correction. It reports K0, K1, and K2, but it also reports "normalized" values. Over the same 4 galaxy images, it reports 0.86, 0.60, and 1.02. Is it possible to translate these into numbers appropriate to the histogram color sliders?

Ideally, the colors in my saved-exactly-as-seen images would have colors at least similar to those resulting from post processing the raw stack. I use 50/50 for white balance in the image control panel.

[admin]

Hi,

this is quite a tricky topic, because lots of things are going on...

Thinking about the data going into the image, there are two sources of colour offsets that need to be corrected in different ways

1) Different sensitivities of the colour channels of a colour camera (often green is most sensitive). This could result in the green brightness being maybe 1.5x as big as it should be, so multiplying the green values by 0.66 would fix that. You can do this sort of adjustment with the colour balance sliders in live stacking, or on some cameras with the camera colour balance adjustment

2) A colour cast to the background caused by a combination of local light pollution (which might be slightly orange perhaps) and the sensitivity of the camera which might make the orange look green. You cannot cleanly fix this sort of issue with the colour balance sliders either on the camera or on live stacking, since it is an *additive* colour component rather than a multiplicative one. Using SharpCap's background subtraction option (blended offset) is good here as it will remove the colour cast in the background by subtracting from each channel.

Now, added to that is the non-linear stretch that goes on when the live stack image is displayed (or saved - depending on the save choice made). The bulk of colour adjustments should be made *before* the stretch is applied - which is the way the adjustments in SharpCap's live stacking and background subtraction work. Making small tweaks after the stretch to get a nicer looking image is fine, but the colour adjustment values used after the stretch cannot be used before the stretch - the non-lienar nature of the stretch means they will not have the same effect. I'm concerned that this sounds very much where you are going with the discussion of values from PI/Siril being brought back to SC - if you are taking stretched images into Siril/PI...

To answer the question from a different point of view - you can hover the mouse over the colour adjustment sliders in SharpCap live stacking to read of f the adjustment effect that they are currently applying - so '1.74x' means that pixel values in that channel are being multiplied by 1.74. In theory you could combine the existing values in SharpCap with the numbers derived from PI/Siril to work out new values to set in SharpCap.

cheers,

Robin

[meies]

Thanks, Robin,

I'm taking the 32-bit raw stack into Pixinsight and Siril, usually the day after my EAA
Live Stack session. I save the "save-as-actually-seen" image as a record of what I saw at the time, and then use Pixinsight or Siril to post-process the raw stack to produce a cleaned-up version. The colors are calibrated there using SPCC or PCC. I'm just wondering whether the calibration data generated there from previous images could be used to set the color balance in the Live Stack histogram for the next image. The goal would be to have the Live Stack "saved-as-actually-seen" image have colors similar to what will later be produced when the 32-bit raw stack is processed in PI or Siril.

As it is now, I use one or the other of the auto color balance buttons in the Live Stack histogram, and then adjust until it "looks right." I'm just wondering whether the color balance from previous images could replace my subjective judgement.

[admin]

Hi,

OK, so you are taking an unstretched image out of SharpCap into PI/Siril, which is good, and means that you may be able to use the values suggested by PI/Siril in SharpCap with some thought.

What I'm not clear about is whether the R/G = 0.64 from PI means that PI found that you needed to adjust the red channel by a factor of 0.64 (making red smaller) or if PI found the red channel was 0.64x the value of the green, meaning that you need to boost red by a factor of 1/0.64 (~1.56). I am going to guess at the latter, but not 100% sure.

If we assume the latter then you would want to adjust the R/G/B sliders in SharpCap to 1.56x on red, 1x on green and 1.92x on blue to have the same effect, but I still think that may not give the background a neutral colour without a subtractive component to the colour correction too (like background subtraction)

cheers,

Robin

[meies]

Thanks, I'll give that a try. Since you are continually adding new features (thanks for that), allow me to suggest that you look at the Photometric Color Calibration routine in Siril. I can imagine a third auto color balance button in Live Stack Histogram that would apply a routine like this. The routine does a plate solve, downloads some data from an online database, and computes the corrections to produce stars with the correct colors. In practice, it takes about 5 seconds for my ASI2600MC on an image with a dense star field.
https://siril.readthedocs.io/en/stable/ ... olors.html

I'm not sure how similar this would be to the existing "auto colour balance based on star colours" button. I have assumed that it makes stars white on average rather than considering the actual colors of individual stars.

[admin]

Hi,

it would certainly be an interesting feature to have

You are right about the white balance from stars - it picks unsaturated stars in the image and tries to make them white (on average). I suspect it should really try to make them slightly yellow/orange on average, since the dimmer, unsaturated, stars are likely to be less intrinsicly luminous and therefore less blue to some extent.

cheers,

Robin