Narrowband Combination Script

[Silvercup]

As I said in the Selective Color tool thread, I'm developing a script to make the combinations of narrowband channels . The script allows you to select the weight of Halpha, OIII and SII channels and mix each one with a percentage of others.

I enclose a picture of the interface and how script is acting on an image of the Rosetta:



Here, a comparison between my previous processed with a combination of channels made by several trial and error (left) and another with a fast processing of the result of the combination script (right).



I need help with window position and a better control for STF (sliders aren't very precise).

What do you think? Any sugestion will be appreciated.

[Juan Conejero]

Very very nice. What an excellent work, and what a useful tool.

I need help with window position and a better control for STF (sliders aren't very precise)

Sure, let me see the code that is giving you problems, and we'll polish it until it shines.

I'd like to include this script in the upcoming version 1.6 --if you agree to do so, of course. In such case, do you think it will be ready in about one week?

[mmirot]

Well done Silvercup,

Hi Juan,

I see you are out of your fortress of solitude.  Glad to hear 1.6 is coming along

I suggested the this just last week.
Now I feel like a software a muse. 

Max

[mmirot]

Btw, Can it assign to colors other than R, G, B?

Max

[Niall Saunders]

I don't follow your question Max. At the end of the day, R, G and B are the ONLY colour channels

Are you thinking that it might be possible to do something like:
Hue = Ha
Saturation = Sii
Value = Oiii

because I cannot see how that would provide anything useful at all.

Can you explain what you were looking for in more detail (simply because I think that this 'pallette mixer' concept is going to be a very useful tool in a future release of PI, perhaps moving out of the PJSR side, and into 'core' PI itself.

Cheers,

[Harry page]

Hi

Could we use adapt this so we can mix say Ha with standard RGB channels 



Harry

[Niall Saunders]

Hi Harry,

Exactly - I think that the script, or module, should be totally flexible. At the end of the day we actually only have a single 'blank canvas', and this has five phyical attributes. Its X and Y pixel counts are fixed (by the source data, all of which MUST jave been aligned to each other, and trimmed to be exactly 'the same' size). and the final image will have three colour channels, which we will refer to as R, G and B, and that these channels are DIRECTLY mapped to the equivalent colour of your display device.

So, into each of the three possible channels (R, G and B) of the blank canvas, the user then has the option of 'mixing' data from other (identically sized) images. At its very simplest (and trivial) level, the user would take Rd, Gn and Bu image data, and mix these - 100% each - into each of the three R, G and B channels. Nothing particualrly clever, or advantageous there!

But, let's say the user only has bi-colour data - Rd and Gn, for example. These two images can still go into their appropriate channels, at 100%. But a 'synthetic' B channel could now be made by taking (100% Rd) and (-100% Gn) and 'summing', to give a [Rd-Gn] result for use in the B channel.

[This concept, now that I have just had to consider it more closely, suggests that the 'mixer' interface may actually need a set of 'radio buttons' to allow the user to define the 'operator' that should be applied (+, -, x, /, etc.) - and this - unfortunately is where PixMath still gives you FAR greater power]

Now, for each of the R, G or B 'channels', the user needs to be able to define which images are going to be included as 'source' data. Each channel could include as many images as needed, or just one, or even 'none'. As I suggested earlier, the R channel could be a simple Rd '+' Ha 'blend', with - say - 70%Rd 'plus' 30%Ha. The user may even then choose to 'swap' then Gn and Bu source images, putting 'Gn' into B, and vice versa.

And, because the 'recombination' call would be to the LRGB Recombine process, this actually DOES give a 'fourth' channel into which data could be 'blended', prior to this extra 'L' channel being recombined with the 'standard' R, G and B channels. The user would not even then have to be aware that LRGB combination is actually a multi-stage process in itself - where, initially, it is just the R, G and B channels that are used to form the new 'blank canvas' image, which is then immediately split into the three CIE L*a.b channels, and where the extracted L* channel is then replaced with the data specified for the Lu image in the LRGB process, before the new trio are recombined (again, as CIE L*a.b data) to regenerate a three-channel RGB image (our 'blank canvas', if you will). And the LRGB Combination process also has a whole load of extra 'features' to control how this recombination progresses.

In reality, all the script is doing is allowing more than 'just three, or four' images to be included in the LRGB Combine process - and it is providing a more convenient GUI than PixelMath alone - simply by virtue of the 'blending sliders'.

If you truly want to be able to mix up your source data any way that you want, you will end up using multiple Pixelmath processes - one for each 'channel' (up to four such processes, one each for the R, G B and L channels as needed by LRGB Combine). And each of those PixMath processes will allow you TOTAL control of how you blend your individual channel 'pigments'. (For example, instead of 'multiplying' Rd and Ha, you might choose to 'average' the two channels, or even 'maximum' the two channels - and then you might even decide to apply that Pixmath process through a mask - that meant 'small scale structures, such as stars, did NOT get affected by the Ha information, thus eliminating salmon pinks haloes that can sometimes result when blending Ha data).

I would therefore now doubt that this script would really be as capable as every user would need - maybe it will just have to be restricted to simple scaling and summing of (multiple) source data into each of the four destination channels.

Leaving the 'manual' PixelMath method as an option for the more adventurous

Cheers,

[Silvercup]

Hi all:

Niall I agree with your ideas. A new module for this type of combinations would be helpful.

I started thinking about the script after processing my Rosetta and lose a considerable amount of time to find a combination that I liked.

Clearly, LRGB combination fails when you want to combine different images into one of the four channels. The main problem I see is that to make a module or script for adding n images to each channel, would be built interactively and would have space problems, but you can always use "Tabs". Operators should be added if you want to do for example Red-Green and this is complicated given that the scripts are usually preset controls.

We can even do complex operations Avg (Half, Red) + 75% Red  +25% L, but I think it escapes the script intention, that's what PixelMath exits, but if we achieved such flexibility would be a very powerful script .

I will try to sketch how I write a module for channel combinations.


Juan, in principle, the preview is generated in a new ImageWindow you believe that when placed in the workspace where you think and often falls below the interface of the Script, I want is to open in the left corner like it js can do window.moveTo (0,0), thus placing the script interface to the right. As for the sliders of the STF are inaccurate because they jump from 10 to 10 (because of the length of the control itself), not whether there will be other more precise control.

Greetings. Silvercup

[Harry page]

Hi Niall

So yes no and maybe  , thanks for clearing that up for me 



Harry

[mmirot]

Silvercup

1.6 is here. Perhaps I can encourage you to pick up this project again.

Max

[chris.baron]

Silvercup

1.6 is here. Perhaps I can encourage you to pick up this project again.

Max

Yes please Silvercup. I was quite looking toward to seeing this in the release and was disappointed to not find it. Since I essentially work with just narrowband images this script would be of great benefit to me.

Cheers,
Chris

[Silvercup]

Hi Max, Chris:

I was waiting for Vincent's M74 explanation about new aproach of blending broadband and narowband data, but I can resume script development and modify later with the new process.

I have to finish lens distortion correction script too, but I am going to simplify it with X and Y axis coeficients only, no with independient RGB coeficients.

This weekend I do Messier Marathon and, I hope, take some photos with my new steady star AO from orion.

Best. Silvercup.

[DonW]

I am new to PI but have been astro imaging for about 15 years now (processing with PS).  One of the attractions for me to start using PI was Vicent's tutorial on combining broadband and narrow band data.  Jack Harvey referred me to this thread.  That article dates from about Dec 2007 near as I can tell.  It had the promise of a module to automate the process.  I don't know why it was not accomplished before now.

However, reading this thread, I see activity and comments leading toward the creation of a module for combining narrow band data.  As I see it, trying to make a module that works for both narrow band AND Ha+Red broadband combination is probably too complex.  I say that because I think that Vicent's concept of iterating generation and use of continuum maps is key to controlling noise and preserving stars for Ha+Red combination.  I do not image with narrow band (other than Ha) but I don't think use of continuum maps is necessary for it.

With this premise, I think Silvercup's module will be very good for narrow band imaging, but probably will not be "perfect" for Ha+Red.  His module may be extremely useful for the final "combine" with Ha+Red data, after creating synthetic Ha+Red using continuum maps.

Am I wrong?  I would like to see a module that just iterates through Vicent's continuum method to create the Ha+Red channel.  I use a CCD with filters, so I have separate LRGB & Ha images to work with.  I have no experience writing scripts, so I'm hoping some one with that talent will step in to create one.

Thanks,
Don Westergren

[Carlos Milovic]

Hi Don

We have a ***huge*** to do list in the development area, specially processing modules. Our problem is time. Juan, the main developer, also performs the 99.9999% of all the other stuff (administration, PCL and core application programming, examples, tutorials, support...). He had to prioritize, and unluckily, there have been always other tasks with higher demands. I'm one of the other main developers (orders of magnitude below Juan's level), and also time is an issue for me. First of all are my studies, and also martial arts training keep me busy.  Also there is a sort of bottleneck in my production, since I'm not as skilled as Juan, so he usually takes a final look at my codes, and fixes some things before including them to the main application. Again, due task priorities, most of the code I've wrote has been unpublished, and there are more than a dozen processes that are at one stage or another of development.
So, we are deeply sorry, but we have to ask for more patience.

Fortunately, PJSR has benefited a lot from user's contributions. They are filling the hole we had in that area, and thanks to them (and all of you for your thoughts) are giving a very exciting live to this project. I hope you'll enter the group. It's fun to write your own code, and see it work.
(BTW, I'm sorry but I'm quite useless for JS advices... I've keeped my focus on C/C++, and PCL programing, so this is a topic where I'm far behind).

[DonW]

Thanks for the update Carlos.  I have seen the tremendous development over the years from SGBNR and PixinSight LE.  I tried those versions, but didn't stay long enough to really learn them.  Now the development of the program, with image calibration and all the other tools has reached the point where I can see the benefits of the program and I can only say, I want more.  I'll be patient too.  If I figure out or learn how to write automated procedures, I will contribute them to the group.  Right now, I'm just trying to learn how to use the tools in PI to manually do these procedures.  The tutorials show what can be accomplished, and generally show the flow of the processes, but they don't give the details (step 1, step 2, etc).  So it's easy for me to get lost.  At least there is this forum where I can ask when I get lost.

Don