51 replies to this topic

[BQ Octantis]

then you select green as a luminance, and put it all back together.  I have never done this. 

 

does it work ? 

 

what is achieved ?

 

experts please advise. 

If you do this with a planet, you can align the channels to eliminate atmospheric dispersion.

[Spaceman 56]

If you do this with a planet, you can align the channels to eliminate atmospheric dispersion.

does it add anything of value for Deep Sky BQ ?

[BQ Octantis]

does it add anything of value for Deep Sky BQ ?

Well it's made for mono, so it can align those channels, too. And it can use an arbitrary L, so even for already-aligned OSC data you can use it to compile a G-RGB file, for instance.

[EPinNC]

Cool!  It took me a few minutes to figure this out.  Just a few notes to myself (and whoever else is watching):

My 50x50px selection was slightly different, because I'm using a slightly cropped version of the stack.  Thus, my initial Statistics (under the "hamburger" menu > Image Information) are a tiny bit different.  But very close.

I see how to add the extra "Parameters" well enough, but I did not immediately see that I actually needed to modify the "R", "G", and "B" fields at the top of the Pixel Math dialog.  I misinterpreted the "-" sign there as a hyphen.  It's actually a minus sign, right?  So what goes there is, in effect, a mathematical expression.

And then finally, to see the new Statistics values (10.0, etc.), I figured out that I needed to click the "Execute" button in that dialog box.

In any case, I now seem to have a decent AutoStretch preview!

 

I think I'm ready for what's next, Professor!

 

(And yes, the difficulty of selecting a "background" in such a tightly-fitting field through my 714mm FL scope is not a new idea to me.  A conventional background extraction involved me selecting only a very small number of the darkest locations around the perimeter.)

Edited by EPinNC, 04 February 2024 - 06:43 PM.

[EPinNC]

Incidentally, a quick-and-dirty modified asinh stretch here shows no evidence of those yellow stars/artifacts that was the cause of all my consternation:

 

Edited by EPinNC, 04 February 2024 - 06:53 PM.

[PIEJr]

Because some stars just ain't so hot....

 

But in your case, I think you have some problems to sort out.

 

We're lucky our Sun is a yellow star or we'd be toast.

[imtl]

Because some stars just ain't so hot....

But in your case, I think you have some problems to sort out.

We're lucky our Sun is a yellow star or we'd be toast.

Actually our Sun is white. Not yellow.

[PIEJr]

Actually our Sun is white. Not yellow.

Aw Contrare.

About 40 billion school pictures portray it as yellow.

 

More here.

[imtl]

Aw Contrare.
About 40 billion school pictures portray it as yellow.

More here.

Maybe schools should do a better job...

[BQ Octantis]

Cool!  It took me a few minutes to figure this out.  Just a few notes to myself (and whoever else is watching):

My 50x50px selection was slightly different, because I'm using a slightly cropped version of the stack.  Thus, my initial Statistics (under the "hamburger" menu > Image Information) are a tiny bit different.  But very close.

I see how to add the extra "Parameters" well enough, but I did not immediately see that I actually needed to modify the "R", "G", and "B" fields at the top of the Pixel Math dialog.  I misinterpreted the "-" sign there as a hyphen.  It's actually a minus sign, right?  So what goes there is, in effect, a mathematical expression.

And then finally, to see the new Statistics values (10.0, etc.), I figured out that I needed to click the "Execute" button in that dialog box.

In any case, I now seem to have a decent AutoStretch preview!

 

bg-extraction.jpg

I think I'm ready for what's next, Professor!

 

(And yes, the difficulty of selecting a "background" in such a tightly-fitting field through my 714mm FL scope is not a new idea to me.  A conventional background extraction involved me selecting only a very small number of the darkest locations around the perimeter.)

Woohoo! Yes to all! These are indeed mathematical expressions. As you have already found, the image at this point is totally workable. Step 3 solves a problem fairly unique to DSLRs. The D50 multiplier for the red and blue white balance is 2.04 and 1.47, respectively. But any of those kRs and kBs over the peak green value wind up magenta because of this severe imbalance. The only way to fix it is to clip the reds and blues to the peak green level.

 

There is also noise that brings the minimum value below zero. This causes problems in several of my other workflows. But with the same expression, we can clip the minimum to 0.

 

So from your white-balanced, background-subtraced image, you want to export the channels to a new set of files, kR, kG, kB. You then reload those in Pixel math as kR, G, and kB. And then load the following channel expressions:

 

max(min(1,kR/max(G)),0)*max(G)
max(min(1,G/max(G)),0)*max(G)
max(min(1,kB/max(G)),0)*max(G)

 

These don't change the overall image, but the star cores are now clipped to white instead of magenta.

 

Lastly, we use the Histogram transformation to clip the blacks to the bare minimum for the image. Any bias results in a reduction in contrast and saturation, so we want it as low as possible. If we load the Histogram and click on the Autostretch button, we can see what the Shadows value is that puts the histogram as far to the left as possible.

 

 

Change the Midtones value back to 0.5 and click Apply.

 

So far, so good?

[PIEJr]

Maybe schools should do a better job...

And maybe you would do well to re-read your bottom line:

“Wise men speak because they have something to say; Fools because they have to say something” - Plato

 

Because you are irritatingly negative.

You obviously think you are too smart to follow a provided link.

God forbid you be shown wrong, again.

[imtl]

And maybe you would do well to re-read your bottom line:
“Wise men speak because they have something to say; Fools because they have to say something” - Plato

Because you are irritatingly negative.
You obviously think you are too smart to follow a provided link.
God forbid you be shown wrong, again.

If you think you're right then I wish you all the best.

[BQ Octantis]

I didn't think the chromaticities of the sun were the subject of this thread. But visual color is my current jam. And here's what I measured on the solar disk at 34.8°:

 

Chromaticities of the Solar Disk at 34.8°

 

So the CCT of the sun at 34.8° splits D65 white, although with a moderate lean toward the blue. Adapting to zero air masses (per my work on the lunar regolith) shows its true nature to be quite blue:

 

Chromaticities of the Solar Disk, Adapted to Zero Air Masses

 

But the poor, ignorant masses can only look at the sun with their organic eyeballs when it's down near the horizon—filtered for their fragile eyes through a dozen air masses or more—where it appears quite orange, perhaps with a tinge of yellow:

 

Chromaticities of the Solar Disk, Adapted to 5°

 

Of course, Zhai and Luo found that what constitutes "white" is in the eye of the beholder—and depends on whether the target is illuminated or self-luminous. Figure 4 in particular of their watershed study is most illuminating:

 

https://opg.optica.o...-7724&id=383537

 

I wish you both peace and good health. And may your life be filled with beautiful, well-matched colors.

 

BQ

Edited by BQ Octantis, 05 February 2024 - 04:40 PM.

[EPinNC]

Sorry for not responding earlier.  There was that "sleep" thing that I had to do.

 

...

 

So from your white-balanced, background-subtraced image, you want to export the channels to a new set of files, kR, kG, kB. You then reload those in Pixel math as kR, G, and kB. And then load the following channel expressions:

 

max(min(1,kR/max(G)),0)*max(G)
max(min(1,G/max(G)),0)*max(G)
max(min(1,kB/max(G)),0)*max(G)

 

...

 

I'm a bit lost here.

 

I want to take my latest image and export a new set of separate channels from that (Image Processing > Extract > Split Channels).  And I want to name the files

• kR
• kG
• kB

 

(clicking "Apply", and then "Close")

 

Got that.  But then I want to "reload those in Pixel math as kR, G, and kB."  I'm not sure what that means precisely.  By "reload", do you mean use the "+" button to select kR.fit, G.fit, and kB.fit?  Or is there a missing "k" in there somewhere?

 

 

And what goes in the "Parameters" box?  Anything?

[BQ Octantis]

Sorry for not responding earlier.  There was that "sleep" thing that I had to do.

 

I'm a bit lost here.

 

I want to take my latest image and export a new set of separate channels from that (Image Processing > Extract > Split Channels).  And I want to name the files

• kR
• kG
• kB

(clicking "Apply", and then "Close")

 

Got that.  But then I want to "reload those in Pixel math as kR, G, and kB."  I'm not sure what that means precisely.  By "reload", do you mean use the "+" button to select kR.fit, G.fit, and kB.fit?  Or is there a missing "k" in there somewhere?

 

And what goes in the "Parameters" box?  Anything?

Nope, you're not lost at all. But when you hit the + to add the files, you need to select kG.fit instead of G.fit because you subtracted the background before the export—so it's not the same as the original G. You then assign them the variables kR, G, and kB as you did.

 

Nothing goes in the Parameters field for this step. Indeed, for the final we're not going to use it, either.

 

Good to go?

[dx_ron]

Nice data EP, plus it's been an interesting read, following along. And, because the data were there I downloaded and popped the stack into StarTools. Color is normally a later step in ST, so I went through with background neutralization (Wipe), large-scale contrast and smaller-scale contrast (HDR - a somewhat unfortunate name because 'HDR' in ST it does not refer to combining different exposure lengths) and deconvolution.

 

Once at the color stage, I tried starting with the built-in DS5600 matrix, but the result was way purple (but I never use the dslr matrices, so maybe I just don't how to use them correctly). Then I tried using the color factors BQ arrived at in Siril, but that did not seem effective either. So I went back to my normal approach, which is to use a star mask to get the starting color balance, then adjust to tone down green to where there is no region in the image where green is the predominant signal. Had to do a bit of extra tweaking as well, due to the original star-based sample being skewed to blue (violet) a bit. In the end, I arrived at something I think is pretty close to BQ's version even though I wasn't making changes specifically to try to match those colors.

 

 

If this were my own data I'd go back and do it again, because the saturated star cores made it difficult to eliminate the ringing in deconvolution. I was also more heavy-handed with noise reduction than normal. There is a touch of inward-directed coma on your stars. Maybe a tiny tweak of backspace could eliminate that.

 

 

[EPinNC]

Nope, you're not lost at all. But when you hit the + to add the files, you need to select kG.fit instead of G.fit because you subtracted the background before the export—so it's not the same as the original G. You then assign them the variables kR, G, and kB as you did.

 

Nothing goes in the Parameters field for this step. Indeed, for the final we're not going to use it, either.

 

Good to go?

 

Hm.  Something is wrong with my expressions, it seems:

 

 

Parentheses are nested correctly.  Do I need to be using the "Variable" values as listed in the "Images" box (e.g., "mixed_R", etc.?

Edited by EPinNC, 06 February 2024 - 08:47 AM.

[EPinNC]

Nice data EP, plus it's been an interesting read, following along. And, because the data were there I downloaded and popped the stack into StarTools. Color is normally a later step in ST, so I went through with background neutralization (Wipe), large-scale contrast and smaller-scale contrast (HDR - a somewhat unfortunate name because 'HDR' in ST it does not refer to combining different exposure lengths) and deconvolution.

 

Once at the color stage, I tried starting with the built-in DS5600 matrix, but the result was way purple (but I never use the dslr matrices, so maybe I just don't how to use them correctly). Then I tried using the color factors BQ arrived at in Siril, but that did not seem effective either. So I went back to my normal approach, which is to use a star mask to get the starting color balance, then adjust to tone down green to where there is no region in the image where green is the predominant signal. Had to do a bit of extra tweaking as well, due to the original star-based sample being skewed to blue (violet) a bit. In the end, I arrived at something I think is pretty close to BQ's version even though I wasn't making changes specifically to try to match those colors.

 

Messier-42-30s-f7-iso200-714mm-361frames-round0.694-wFWHM-stacked_v2.jpg

 

If this were my own data I'd go back and do it again, because the saturated star cores made it difficult to eliminate the ringing in deconvolution. I was also more heavy-handed with noise reduction than normal. There is a touch of inward-directed coma on your stars. Maybe a tiny tweak of backspace could eliminate that.

Hi dx_ron!  Thanks for taking a stab at my image!  It looks really nice!  You brought out some of that faint dust, which is difficult to do.  (It is only 3 hours of integration, after all.)  Yes, those blasted star halos...  My early processing attempts sometimes contained those, but other times not.  Sometimes they would come out as rings around the stars along the left side of the image.

 

One thing I've noticed about what BQ has been leading me through is that noise seems to be somewhat reduced.  If that holds up through the whole process, I might not even need to do any noise reduction at all (or just a very minimal amount).  But we'll see...

 

I should say that I greatly appreciate BQ's willingness to lead me through all this!  This is totally new territory for me, with all the PixelMath stuff especially.  Hopefully, when I've arrived at a satisfactory final image, I hope to write some kind of documentation detailing what BQ, The Professor Whoopee of Color Space, has had me do.  I'll never remember it otherwise!

 

And I also appreciate your processing my data!  It's always useful to see what others come up with using the same data set.  That's one of the things that keep all this so interesting!

[EPinNC]

Ok, I think I've got it.  I did replace all those "kR" (etc.) variable names with the corresponding "mixed_R" variable names, clicked "Apply" (without anything in the "Parameters" box) and now I see this in the AutoStretch view:

 

 

Hopefully, that means I'm ready for the next step.

Edited by EPinNC, 06 February 2024 - 09:41 AM.

[BQ Octantis]

Ok, I think I've got it.  I did replace all those "kR" (etc.) variable names with the corresponding "mixed_R" variable names, clicked "Apply" (without anything in the "Parameters" box) and now I see this in the AutoStretch view:

 

mixed_RGB.jpg

 

Hopefully, that means I'm ready for the next step.

I prefer specifying the variable names but, that's another way to do it!

 

The second half of the step is to clip the blacks with the Histogram tool. Did you get that far?

[EPinNC]

My histogram doesn't look like yours from your comment #35 above.

Linear view, zoom factor 1:



Linear view, zoom factor 100:



Logarithmic view, zoom factor 100:



Not much room to clip the blacks at all.  I can manually enter some small value of "Shadows" (e.g., 0.0000900), but any further and it actually starts clipping.

 

Maybe I've missed some step?

[BQ Octantis]

If you click the autostretch button, the recommended midtones value makes the clip value more obvious:

 

 

But yes, it is only a small amount (0.0001200) before it clips. You set the midtones back to 0.5 before hitting Apply.

 

Once you've trimmed the blacks, the last step is just asinh "color boost". Ironically, asinh isn't supposed to boost color, but used improperly (without correct gamma application), it's a great way to increase saturation. One pass of 1000, followed by a pass of 200 yields this (with the display mode set to Linear):

 

 

Easy?

[EPinNC]

Indeed it is!  (for once )

 

This produced a good result, and I did some initial playing around with a generalized hyperbolic stretch.  No more artifacts, stars not too bloated (at least not any more than could be expected from a doublet and its blue halos).  I was able to pull out a good amount of faint dust, too!

 

The simple asinh stretches you suggested was a bit too saturated for my taste, so for the final version I'm going to work some more with GHS.

 

Thank you, thank you, thank you, BQ, for all your patience in walking me through this!  This image looks noticeably better than my initial efforts, even when using StarNet.  Another observation is that noise seems to be reduced (although I want to do additional testing to see if that's really true).

 

Now, I wanted to include some kind of final image here, but I think I'm going to wait.  I am trying to plow back through this entire thread and stitch together a step-by-step description of what to do, starting from the initial unprocessed stack.  Once I do that, if anyone else watching wants that, I'll make it available.

 

And once I'm happy with my own image, I'll post it here.

 

Thanks again for all the instruction from BQ and all the interest from everyone else!

Edited by EPinNC, 08 February 2024 - 10:08 AM.

[EPinNC]

Final result from using BQ's methods:

 

 

Large

 

 

Compare with the one that started this thread in the first place:

 

 

Large -- I know it's a bit brighter, but that doesn't mean better.  Note color artifacts in the core.

 

I have my own opinions about which one is "better", but I'd like to hear other people's opinions first.  (If anyone is watching, that is )

Edited by EPinNC, 08 February 2024 - 03:11 PM.

[BQ Octantis]

Bewdy!

 

This method gets the colors where we want them. But there's more that can be done for the star shapes. We can add the camera channels at their native proportions to get a grayscale result with really good SNR that we can stretch with GHT. This gives the stars a nice Gaussian shape. We can then compile an LRGB using that as the L with the RGB composition tool we already discussed.

 

Just an idea…

 

BQ