M13 star colors

[dx_ron]

M13 is one of those objects where (I think!) there is a definitively correct color palette. For example, the image at https://science.nasa.gov/colors-and-magnitudes-m13 shows a mix of blue and reddish, along with spectral data supporting that.

In my own M13 image:

M13_g5o8_-10c_631x30s_90pct_sigma1.5_tame-HDR-NR-500k.jpg (490.48 KiB) Viewed 4782 times

I'm having trouble getting the not-blue stars to be more red. When I start the color module, everything is very green (this being OSC data), so from there I'm just mashing the sliders around - handicapped by the fact that I don't have a good intuitive sense for what change to any one slider would have on the overall colors (I can't choose good colors for a room, or even dress myself in matching colors either!).

Should anyone have some spare time, the unproccessed stack is here: https://www.dropbox.com/s/h4lp0qf6i43wo ... 5.fit?dl=0

Maybe my data just won't go there, or maybe someone with a better understanding of color space can give me a combination of "reduce bias" settings that give colors more like the 'correct' colors.

Aside: The Tame HDR preset made the "propeller" leap out. I think it's overcooked and won't use that for my final image, but I'm sure I'll show it on CN so people can say "You got the propeller!" I think a version with no use of HDR at all looks more like a proper globular cluster to me.

[admin]

Hi,

Can you tell us how you acquired (e.g. gear, filters, etc.) and stacked this?

The dataset already appears to be color balanced and does not exhibit the usual green cast associated with DSLR or OSC instruments.

In general, if all is in order with the dataset (not sure in this case), an there is still an over-representation of yellow in this dataset, then this may be the result of imaging with an OSC exhibiting an extended (e.g. beyond visual spectrum) red response, however neglecting to put a cut-off filter (aka "luminance" or UV/IR filter) in place to keep response within the visual spectrum. See also here for more on the latter.

Do let us know specifics. Thank you!

EDIT: FWIW, this is what StarTools should be able to produce from the stack at hand;

StarTools_2830.jpg (274.45 KiB) Viewed 4775 times

Do note however, that something is very wrong with your flats and the Wipe module will have to be pushed to get rid of the gradients and vignetting beforehand!

[Mike in Rancho]

Hi Ron,

Well matching NASA is never easy. I've generally failed trying to do that myself, including with globs.

Beyond their resolution (though you do have very small pixels!), they seem to be able to go quite light on the blue stars, yet heavier on the reds. Hmm not sure how that is done.

I didn't myself notice that the stack was channel or background neutralized or anything, the three colors were separated albeit fairly tight together in a pretty narrow range. I used both DSS and Gimp to check that. Oddly (to me) however, the stack does seem to be shifted towards the middle, leading to a very bright ST opening. I've only seen that rarely. At least it was all one file and so it stretches both sides in, not like those separate Hubble Pillars files with the funny shifts that Ivo had to teach us how to fix.

After crop and going to Wipe, indeed there arose some unusual (reverse?) vignetting, and hitting the color button was like nothing I've seen before. Like a Glidden paint logo or something. I'm not exactly sure what Wipe was trying to tell us with that. But, some bumps of DAF, the vignetting preset, and a raised aggressiveness (maybe 90) allowed it to go forward.

When I got to color I just took the mask that was used in SVD, used circle to create a big, well - circle, and then erased it, so that the glob wouldn't be star sampled. I hit sample on that and then reverted to full, and left the channel bias where they were. Not the same as Ivo's above, but I probably did things differently leading up to it.

Then I just played with the saturation settings to try to get as close as I could to the NASA image. Not sure I got there. I also may have gone a little too strong with the HDR (I lowered the context to 10 and put shadow on 75), but it needs to be core-revealed enough to get colors in deep. Also bright saturation to get those deep in there also.

Some stars are mutli-colored, maybe from dispersion. I could have used highlight repair but didn't want to desat the red stars. Really what I should have done was just put your stack through DSS for RGB channel (spatial) align. And who knows that might help with the other colors also.

But for now this is as close as I could get I think.

Code: Select all

--- Color
Parameter [Bias Slider Mode] set to [Sliders Reduce Color Bias]
Parameter [Style] set to [Scientific (Color Constancy)]
Parameter [LRGB Method Emulation] set to [Straight CIELab Luminance Retention]
Parameter [Matrix] set to [Identity (OFF)]
Parameter [Dark Saturation] set to [3.5]
Parameter [Bright Saturation] set to [7.5]
Parameter [Saturation Amount] set to [155 %]
Parameter [Blue Bias Reduce] set to [1.00]
Parameter [Green Bias Reduce] set to [1.89]
Parameter [Red Bias Reduce] set to [1.28]
Parameter [Mask Fuzz] set to [1.0 pixels]
Parameter [Cap Green] set to [100 %]
Parameter [Highlight Repair] set to [Off]

dxron sirilstack m13 ST8 1A.jpg (470.42 KiB) Viewed 4769 times

[dx_ron]

Thanks for the effort, guys! I only have a moment this morning, so just the basic answers.

Image was acquired with:
6" RC + AP ccdt67 reducer, at 993mm f/l
QHY183C - note this camera has a UV/IR-cut window, so no additional filter was used
pre-process in Siril, stacking with No Normalization

Flats - well, I have been struggling to get a good system. These used an LED panel, which might be problematic. You'd think sky flats would be the simple solution, but Ekos has a weird behavior when the light level is changing (near dusk, for example) where it increases exposure time just barely enough to get back into the ADU window, takes a test shot which is OK, but by the time it takes the next shot the light levels have dropped again - so it cycles and never completes the sequence. I've not been able to get the developers' attention yet about this.

I did not think to mask out the glob at the start of the color module - always thinking, Mike!

[Mike in Rancho]

Thanks for the effort, guys! I only have a moment this morning, so just the basic answers.

Image was acquired with:
6" RC + AP ccdt67 reducer, at 993mm f/l
QHY183C - note this camera has a UV/IR-cut window, so no additional filter was used
pre-process in Siril, stacking with No Normalization

Flats - well, I have been struggling to get a good system. These used an LED panel, which might be problematic. You'd think sky flats would be the simple solution, but Ekos has a weird behavior when the light level is changing (near dusk, for example) where it increases exposure time just barely enough to get back into the ADU window, takes a test shot which is OK, but by the time it takes the next shot the light levels have dropped again - so it cycles and never completes the sequence. I've not been able to get the developers' attention yet about this.

I did not think to mask out the glob at the start of the color module - always thinking, Mike!

Ah, well that might explain a few things....

I never had luck with sky flats. And one time when I "really" tried hard, setting up on a clear, low evening sky with the sun setting, after finding the exposure I wanted and setting the intervalometer, I was amazed at how quickly the brightness was changing. I stood there stunned, watching the view screen, as the histogram just marched itself to the left shot-by-shot.

I'm still learning NINA, but the flats wizard does have a "dynamic exposure" setting. I presumed that was just for finding the right ADU before beginning the sequence, and that's how I've used it, but I wonder if it will adjust in the middle of the process for a "the sun is moving, dummy" sky-flats situation.

Does an RC have any possibility of mirror flop? One very recent change I have made, that seems to be helping, was to make a box with foam cutout for my tracing pad and take flats with the Newt at the same scope orientation (mostly) as the acquisition. This seems to help solve differential shifting of the vignetting profile. Previously, I had just been taking flats normally as I would with the refractor - horizontally pointed at my tracing pad.

[dx_ron]

I don't think RCs have mirror flop. There is the potential for focuser sag (we sound like a couple of old farts at the rest home).

I did fight through using Ekos to get some sky flats a couple of nights ago. I can't use them to re-process the M13 data, unfortunately. But I do have M92 data (we've only had clear nights + bright moon lately, so I'm on a glob binge). There's only a couple of hours worth, but I have not disassembled the imaging train since taking them. The flats aren't perfect, as I have a dust mote that moved a bit, but the overall vingetting, etc should be correct. The sky was cloudy, but I think generally uniform where I pointed.

The results are - confusing.

Here's one:

21k-sky-flat_35pct-bin_sigma3_color.jpg (312.82 KiB) Viewed 4709 times

I'm guessing that's similar to the wacky color patterning you mentioned.
Then there's this:

21k-sky-flat_no-bin_sigma3_color.jpg (282.95 KiB) Viewed 4709 times

and this:

21k-sky-flat_50pct-bin_sigma3_color.jpg (300.11 KiB) Viewed 4709 times

Those are, in fact, exactly the same file at the same point in processing - except for binning.
The top one was: Bin 35% -> Autodev -> Crop -> Wipe
The middle one was: Bin 50% -> Autodev -> Crop -> Wipe
The bottom one was: Autodev -> Crop -> Wipe without any binning first

[dx_ron]

And similar with flats from the LED panel.

No binning before Wipe:

led-flat-no-bin-color.jpg (298.97 KiB) Viewed 4708 times

35% bin before Wipe:

led-flat-35pct-bin-color.jpg (318.35 KiB) Viewed 4708 times

Is this just how it looks on the screen? Of course 'how it looks on the screen' is what we have to go by when setting the Wipe parameter values.

[Mike in Rancho]

Wow, if only mine looked so clean at only 75% aggressiveness! No such luck though.

I have noticed that Wipe will act differently depending on the bin/no-bin. Of course I always like to get the extra SNR if I can. I think sometimes the anomalies can return though if bin is done later, after Wipe.

I did an M13 last night after the eclipse and I'll post up an interim version of that. I still have crazy stuff to chase down though with my flats, and perhaps lights too. And while mine did correct out, I also have some giant-sized donuts like that if I stack only lights, or stretch the master flat. I know there's a formula for figuring out the dust distance, but I figure these are at least out at the filter or maybe coma corrector (reducer for you?) instead of near the sensor?

We'll need Ivo on the Bin-Wipe relationship though. I am curious myself if/how it affects Wipe's hunt for undulation. Or lack of undulation, maybe that's it.

[dx_ron]

I ran the M13 stack through dss (as per Freddie's thread). I guess I did it correctly, not having used dss before. Interestingly, the after fits file opens in ST with the normal very dark image rather than grey. I processed it at 50% bin both binning first, then Wipe, and Wipe first, then binning. I had to be more aggressive withe the bin-first version. I didn't really notice a residual gradient / color problem after the Wipe-first, even though it was just the default 75%, but I don't think I (yet) have as highly developed sensitivity to residual gradient problems as others (certainly not as keen as Ivo's!).

I cannot figure out what Ivo saw when he opened my original file. I don't see how to get anything that is overwhelmingly blue and needs to have green bias reduce set to zero.

Anyway - colors. I'm not colorblind, more like color-agnostic. I can look at two quite different color renderings and think "looks OK to me".

M13_dss_bin1st_blue-version-500k.jpg (493.06 KiB) Viewed 4669 times

I guess the more-blue version is closer to scientific reality.

[Mike in Rancho]

Those look a lot better Ron!

I like the bluer version, and based on that NASA link that does seem correct too. More blue in some of these globs than they are sometimes credited with. Or at least for M13 and a pretty good distribution of pale blue dots.

Great that the channel align worked, and for first time in DSS too. It's really an oddball usage scenario to "fake stack" an already finished stack just to align the RGB, but, it seems to work.

I do not see anything built into Siril to do that. But it might work in a couple steps. Open your finished stack and use the extraction/split RGB channels, and then align/register those separate channels. Not sure how Siril does that, maybe RGB composition or something. But it could probably do it either by creating a single RGB file, or maintain the three separate channels but now star-aligned. Perhaps use the strongest, green, as reference?

Interesting that DSS put the data back down at the bottom of the file so that it looks black again, not gray. That would perhaps take some investigation to figure out. Possible that Siril wrote out a DATAMIN into the FITS file, which DSS picked up on and hacked the bottom off?