New Feature : Stellar Colour Calibration for Live Stacking

[admin]

Hi,

I'm currently working on this one (in particular for globular clusters) - thanks for sharing the data as it may well prove helpful. I have an hour of images of M13 which I was testing with and I think it points towards the background being part of the problem - the sky became clearer towards the end of the hour, and as those better frames are added to the stack and the background of the stack darkens, the blue becomes worse.

cheers,

Robin

[admin]

Just to update on this...

I spent quite a bit of time playing around with this problem to see how the input data from star colour measurements affected the results. It turns out that including the data from fainter stars pushes the result towards a more blue colour balance - my theory is that for faint stars, the star is only a few times brighter than the background, and that means any errors in the measurement of the star colour - or the background brightness/colour - become more significant.

I have tweaked the way that the background is calculated and added some filtering to exclude the faintest stars that are only just above background levels from the analysis (at least, they are excluded as long as there are sufficient brighter stars to give useful data). Both of these adjustments help, reducing the blue colour balance multiplier from about ~1.90 to ~1.95 down to about ~1.70 to ~1.75 on my sample M13 data.

I think this is an interim improvment - it gives better balance, but it's not a complete fix. The value for blue should probably be in the 1.5 to 1.6 range (based on the results from other images. I'm still trying to work out why the blue is affected here - one theory is that even on highly corrected APO or Quad refractors, the blue tends to be where you see less tight focus. Perhaps this leads to some of the blue brightness of stars being thrown further out from the center of the star (where it is hard to measure against the background) - this would then lead to the blue brightness of stars being measured as lower than it really is, leading to the colour calibration wanting to boost the blue channel more... Anyway, that's a possibility - need to try to work out a way to tell if it is the real cause or not...

cheers,

Robin

[mgCatskills]

Hi,

yes, if you have dual/tri/quad band filters then you can get 'interesting' results... The filter is cutting out more in some colours than others, and the colour calibration will naturally try to compensate for this to give the stars back their normal colours. Looking at the transmission curve for the L-Quad, it looks like it cuts out a lot in the orange end of red and also a chunk of blue around the Mercury line at ~430nm, but less in the green, so calibration will pull down the green to try to adjust. Maybe I could add a filter selection to a future update that would know this sort of thing and correct the calculations appropriately. Something to think about
SNIP

cheers,

Robin

Robin, did you ever act on this? I just had the experience with L=eNhance that color callibration failed and two of the color sliders started moving the histogram peak in opposite directions from normal. It was an image I really wanted to save, but required some serious improvisation on my part.

[admin]

Hi,

no, no real progress on that. In theory, I think you would need to know the response curve of the filter being used and then calculate the relative brightness of all the stars from their effective temperature values (black body spectrum) and then that in theory ought to reflect the 'reality' of what would be seen looking through that particular filter (correcting for camera colour bias). In practice though, who knows if that would make for a *pleasing* image.

cheers,

Robin

[carlomuccini]

Hi

In my opinion, this argument makes no sense.
If you use narrow-band interference filters, it's because you want to achieve a specific result: highlighting details, false colors, etc.
Hoping to obtain an image with realistic colors (and what are realistic colors anyway?) makes no sense at all.
Why use a narrow-band filter that cuts out green, and then want to find green in the image? Use RGB filters or color cameras.
In astronomy, you see objects colored in the most absurd ways, with balances that may be beautiful, but are absolutely unrealistic.

Carlo

[pastorgalactico]

Hi;

Do I need to use SharpCap's Plate Solvin for this to work?
I'm currently using the one from Astap.

Regards

[admin]

Hi,

the colour calibration will use SharpCap's plate solving engine even if your settings are set to use Astap or another external plate solving tool. That's because the calibration requires star colour information as well as position information, and none of the other plate solving tools provide that info.

cheers,

Robin

[pastorgalactico]

Hello;

Do we need to download those two additional catalogs for this as well?

Regards.

[admin]

Hi,

the 'default' and 'high res' catalogs contain colour data that is used for the colour calibration, while the 'ultra hi res' catalog does not.

If you get good results from colour calibration with the default catalog then no need to download any extra ones. If the procedure struggles with the default catalog and complains about not enough stars, download the 'hi res' catalog - this is more likely to be necessary with smaller fields of view (small sensors, long focal length, etc).

cheers,

Robin

[pastorgalactico]

Hello;

Okay,
Does this work using Astap for board resolution? Yes or no? I'm not entirely clear on this.
Does SharpCap use SharpSolve regardless of whether Astap or SharpSolve is used?
Should this be used after starting LiveStack, and how long after?
Is this the same as, or similar to, the star-shaped button below the color channel settings in the live stacking histogram?
Would this work the same using the Uranus c with all 3 color channels set to 0, i.e., displaying the image in green?
Images attached.

Regards.

capturada.jpg (325.59 KiB) Viewed 366 times

capturada1.jpg (272.48 KiB) Viewed 366 times

capturada2.jpg (771.15 KiB) Viewed 366 times

capturada3.jpg (705.27 KiB) Viewed 366 times

capturada4.jpg (471.35 KiB) Viewed 366 times

capturada5.jpg (258.02 KiB) Viewed 366 times