Question processing in compose module

Questions and answers about processing in StarTools and how to accomplish certain tasks.
Post Reply
fmeireso
Posts: 370
Joined: Mon Sep 28, 2020 8:46 pm
Location: Belgium

Question processing in compose module

Post by fmeireso »

Hi everybody

I have this question.

Suppose i have a mono cam. And 3 filters Ha,OIII, SII. I take 3 sessions wich each filter, on a object. I will then have 3 stacks, 3 masterlights. But no color.
What is the exact workflow to produce a HSO image in the compose module in color?

I don't use this approach, i always take Ha Luminance and use a color stack for the RGB channels in the compose module. But if i want this, how to do it. Bit confused about this..

CS
Freddy
Stefan B
Posts: 425
Joined: Sat Oct 31, 2020 8:59 pm

Re: Question processing in compose module

Post by Stefan B »

Hi Freddy,

that's pretty easy I guess. From the documentation (https://www.startools.org/modules/composite):
As is common practice in astronomy, StarTools assumes channels are imported in order of descending wavelength. E.g. the dataset with the longest wavelength (e.g. the light with the highest nm or Å comes first). In other words, the reddest light comes first, and the bluest light comes last.

In practice this means that;

When using visual spectrum datasets, load red into the red channel, green into the green channel, and blue into the blue channel.
When using triple channel narrowband datasets such as Hubble-like S-II + H-alpha + O-III (aka "SHO" datasets), load S-II as red, H-alpha as green and O-III as blue.
When using a duo/tri/quad band filtered dataset, load H-alpha (which is possibly combined with the neighbouring S-II line depending on the filter) as red, and load O-III (which is possibly combined with the neighbouring H-beta line depending on the filter) as green.


In any case, you should not concern yourself with the colouring until you hit the Color module in your workflow; as opposed to other software, this initial channel assignment has no bearing at all on the final colouring in your image. Please note that failing to import channels correctly in the manner and order described above, will cause the Color module to mis-label the many colouring and blend options it offers.
I used this workflow for foreign data sets which worked fine. There are plenty on the internet. Just try :-)

Regards
Stefan
fmeireso
Posts: 370
Joined: Mon Sep 28, 2020 8:46 pm
Location: Belgium

Re: Question processing in compose module

Post by fmeireso »

This means the software somehow 'invents' the color? Because using a mono cam with Ha,SII,OIII filters, records no color.....

That is weird to me...
Stefan B
Posts: 425
Joined: Sat Oct 31, 2020 8:59 pm

Re: Question processing in compose module

Post by Stefan B »

Well, a mono cam with RGB filters doesn't record color either. It collects light of all the wavelengths transmitted by the filter. You map the different filters' luminance to different color channels, no matter what the filter's spectrum.

In case of narrowband you mostly use false color mapping since S2 and Ha are both red in true color so you wouldn't get any differentiation by color if combining both in red. So you map S2 and Ha to different channels. Since S2 has the longest wavelengths, it gets red. Ha having a shorter wavelength, gets the green channel (since green complementary has a shorter wavelength than red). That has some sense to it but is arbitrary in the end. You can do different mappings. But in ST's compose this mapping is INITIALLY the way to go. Recombination etc is finally done in the color module.

But maybe I am the wrong person explaining that since I don't even have a mono cam. Mike is probably more experienced.

If you are a book person (like me) you might want to have a look at 'Coloring the Universe' (https://www.amazon.de/Coloring-Universe ... 1602232733). It's a great read covering this stuff.

Regards
Stefan
fmeireso
Posts: 370
Joined: Mon Sep 28, 2020 8:46 pm
Location: Belgium

Re: Question processing in compose module

Post by fmeireso »

Ok, thanks Stefan.

So actually , it is very simple to do then...just needs a mono cam and a couple of narrowband filters....

I assumed allready it was like that, but somehow i thought i was missing something important..;

This means also i could in that way i could go HOO. Take a Ha, en a OIII narrowband, put Ha in the red, and the OIII in the green and blue channels..;and it should provide a bi-color picture.
Correct?

Now i come to think of it i believe i did this allready with 'The Elf' data of M27,once. He had an OIII and Ha stack :think:

You know i am really not so keen on all the technical aspects of AP. I don't have any background. I just try to do the things i should and avoid the things i should not do... :D
Stefan B
Posts: 425
Joined: Sat Oct 31, 2020 8:59 pm

Re: Question processing in compose module

Post by Stefan B »

Hi Freddy,

yes, I think you got it. Bicolor works the way you described.
fmeireso wrote: Tue Jun 27, 2023 1:10 pm You know i am really not so keen on all the technical aspects of AP. I don't have any background. I just try to do the things i should and avoid the things i should not do... :D
That sounds totally reasonable :mrgreen:

Regards
Stefan
Mike in Rancho
Posts: 1153
Joined: Sun Jun 20, 2021 10:05 pm
Location: Alta Loma, CA

Re: Question processing in compose module

Post by Mike in Rancho »

fmeireso wrote: Tue Jun 27, 2023 11:03 am This means the software somehow 'invents' the color? Because using a mono cam with Ha,SII,OIII filters, records no color.....

That is weird to me...
I think Stefan covered everything, but yeah the same could be said for mono RGB or even your OSC. The underlying sensor is just a bunch of "mono" buckets for counting photons. Instead of taking 3 separate RGB filters, you capture at the same time through a grid of miniature filters. The result is a 2 dimensional "mono" array, but can then be decoded based on what filter was in front of what pixel. And then the holes have to be interpolated. The result is three mono channels, R, G, and B, but composited into one file that can now be considered more of a three dimensional array.

Setting aside the interpolation, each channel represents whatever response curve was designed into the bayer grid for that color, but is simply a grayscale map of intensities. There are plenty of debates as to the shapes of those filter response curves, gaps, overlapping, and so on, and what that means. In fact there have been several such discussions, sometimes annoyingly contentious, going on in EDSI lately.

Color for us to see isn't created until the three filters are composited and those grayscale intensities are blended. And some of that then gets into what ST provides for us with things like the style and emulation settings for how that blending is displayed.

In visual spectrum, whether by bayered OSC or individual RGB mono filters (and with the possible pros and cons of each), those differing grayscale intensities blend together to make a particular hue. You can go into your Gimp and in the color selection window check out the ways you can define a particular color numerically, or just click on a color and read those RGB numbers, which can be either percentage (0-100) or 8-bit (0-255) format.

Narrowband is the same, except, the colors (which you can map as you choose) from the blending now represent relative photon emission concentration of the gassy element you are photographing. Along with of course bright continuum sources like stars.

Is any of that helpful or did it just make things worse? :lol:

If I got any of that wrong hopefully some corrections will come along.
Stefan B wrote: Tue Jun 27, 2023 11:37 am
If you are a book person (like me) you might want to have a look at 'Coloring the Universe' (https://www.amazon.de/Coloring-Universe ... 1602232733). It's a great read covering this stuff.

Regards
Stefan
Pretty worthwhile, Stefan? $39 for the Kindle edition, but maybe there's lots of pictures? :D
fmeireso
Posts: 370
Joined: Mon Sep 28, 2020 8:46 pm
Location: Belgium

Re: Question processing in compose module

Post by fmeireso »

Mike in Rancho wrote: Tue Jun 27, 2023 6:37 pm

I think Stefan covered everything, but yeah the same could be said for mono RGB or even your OSC. The underlying sensor is just a bunch of "mono" buckets for counting photons.



Is any of that helpful or did it just make things worse? :lol:

If I got any of that wrong hopefully some corrections will come along.



Pretty worthwhile, Stefan? $39 for the Kindle edition, but maybe there's lots of pictures? :D
thanks Mike
Yes, it makes sense now, only i did not give much thought in the past

We still got the Luminance channel. If one use narrowband in the RGB channels what benefit would there be in using a L channel. Guess you have to use a Luminance filter, will it makes sense or add anything usefull?
Mike in Rancho
Posts: 1153
Joined: Sun Jun 20, 2021 10:05 pm
Location: Alta Loma, CA

Re: Question processing in compose module

Post by Mike in Rancho »

fmeireso wrote: Tue Jun 27, 2023 7:50 pm thanks Mike
Yes, it makes sense now, only i did not give much thought in the past

We still got the Luminance channel. If one use narrowband in the RGB channels what benefit would there be in using a L channel. Guess you have to use a Luminance filter, will it makes sense or add anything usefull?
I doubt it Freddy. A full luminance as in L or UV-IR cut filter will acquire full broadband, so using that as L or combined with a synth L, only colored by the limited and high contrast narrowband, would I think just create a mess.

Theoretically I suppose a duoband capture on a mono sensor, with closely matching spectral attributes to separately acquired narrowband, could act as an "L" against discrete Ha and OIII stacks. But that's still just a matter of efficiency and absent that perfect or near-perfect bandpass matching, may not be worth the trouble.
Post Reply