Confusion about the Combine RGB Tool

I'm not sure if this problem ever got diagnosed but I just wanted to say I have experienced it myself recently. I am using version 2.0.0-beta 29 under a 30-day trial.

I created separate narrowband integrations of NGC 6960 images for Ha, Oiii, and Sii and then registered and normalised these to each other as suggested elsewhere in this forum. When I added each one in the combine RGB tool, it prompted me 3 times to add a different file. For example, I was adding the file NGC6960Ha-27_28_29-lpc-reg-norm.fits (27, 28 and 29 are my sessions numbers). After clicking Add and selecting my file, APP prompted me for NGC6960Ha-27_28_29-lpc-reg-norm.fits-1, NGC6960Ha-27_28_29-lpc-reg-norm.fits-2 and NGC6960Ha-27_28_29-lpc-reg-norm.fits-3. I noticed however, that if I just added my file once, and then clicked Cancel after the other two prompts, it worked OK. So it seems I just have to do 2 Cancels every time I add a stack, which is a bit laborious but everything works beautifully once my files are added.

What I also discovered is that if I add a stack that has not gone through a post-integration registration/normalisation (e.g. I have a NGC6960Ha-27_28_29-lpc.fits file), then the issue does not occur, so there is something about post-integration registrations that causes this glitch.

Hope this is helpful to somebody!

@marc Okay?

if i understand you stacked each filter?

after that did you load the intergrated files in the light box, that you do in tab 1?

Go to register and than normalization, after that is done did you click on the button down below save normalize frames?

after that you see the new 7 normalized frames , go to tool and open Combine RGB.

Load the 7 color in there, make sure you select the right filter for each frame.

select LRGB and Re-calculate.

i never have problems if i load HaRGB, or SHO

@brookesc 

About that you have to cancel twice time when you do Combine rgb.

It's important that before you did save normalize frames.  Make sure your files end with like NGC 6960_HA.

I never get that if the file name is correct.

Thanks for your reply Stefan.

I first created 5 integrations separately in APP using steps 0 to 6. These were a wideband colour (OSC) stack, then Ha, Oiii, Sii, and finally an artificial luminance stack. Each one used the corresponding debayer algorithm in Step 0. After integrating each individually, I performed light pollution correction and APP then saved the file with the filename format: target name-session numbers-lpc.fits. When APP previously asked me for target name, I included the channel in the name. So for example one stack was called NGC6960Ha-27_28_29-lpc.fits.

I then registered the stacks together using the following workflow.

• In Step 1 (Load), disable “auto-detect Masters & Integrations”
• Load all 5 integrated stacks as Lights
• 3, Analyse Stars
• 4, Register
• 5, Normalise
• Save each to a 32-bit fits file

This added 'reg' and 'norm' tags to each file as per the filenames in my post above.

I then cleared all files in APP and went into the combine RGB tool. I clicked Add channel and actually selected all 5 fits files produced above, but it does not matter how many I select and I can even recreate the problem by just selecting one file. For example I select say HSO 1 as a start (I will manually produce my own channel mix later), click add and select my Ha file. APP asks me to optionally describe the file, but adds a '-1' to the end of the filename. the dialog is already populated with formula: HSO 1, filter: Red, channel description 6960.fits. So I change the filter to Hydrogen alpha and click OK. It then comes back and asks me for the fits-2 file and then fits-3. I thought it could be because HSO needs 3 channels, but the same happens if I choose a 5-channel palette. 

I should stress the filenames are produced by APP, not me, but I have tried your suggestion of putting NGC6960_Ha at the end of the filename (and also NGC 6960_Ha and just _Ha) prior to using the tool but it makes no difference other than changing what is in the description box. Looking in the metadata of the Ha file (assuming APP is showing me all of the metadata) there is no filter information, even though I selected "Ha-Oiii extract Ha" as the debayer algorithm in step 0 when creating the integration originally, so APP did know it was Ha data and could have added it to the metadata. The metadata for my original Light subframes contained details of the filter (Ha-Oiii in this case) so as it is a dual-band filter that would not have helped, but anyway APP does not appear to copy this metadata across to the output fits file.

As I mentioned before, if I do not register these stacks together (so the filenames do not have the "-reg-norm" bit at the end) then the combine RGB tool works exactly as expected, but of course the stacks do not align. As soon as I register and normalise the stacks, I have the issue of having to press Cancel twice per file, which is no big deal, just strange!

@brookesc 

Hmm,  I can create a video what I select in all the steps when I extract HA from the HA-OIII filter.

And how I do the combine RGB.

I am not sure if I can post a video here or do I need to upload it to YouTube first?

But I try it for you 😉

@brookesc Here is how i do it with my NGC 6888.

You see the 6 tabs what i got selected and what not when i do extraction of the HA and OIII. After intergration i clear the load tab and load the intergrated HA and OIII and you see what i do until combine RGB.

I'm sorry for the late reply.  In fact, the issue has been solved and was entirely my fault. The images are made in a remote observatory and before transferring them, the FITS-header is changed.  Unfortunately, "RGB" is wrongly put in the bayer array field.  That caused the problem.

@marc I hope you can continue  with APP

Posted by: @stefanastro

↑

@marc I hope you can continue  with APP

Yes, everything is fine now 🙂

Thanks for going to the trouble of creating a video Stefan. It's a great way to compare.

I'm pretty happy with the individual integrations I have created so far for the purposes of evaluating APP. Obviously I have some different parameters as my needs will be different to yours. The only obvious differences in some of the tabs were as follows:

2. You are scaling your MasterDark and MasterDarkFlat files and I am not. You are also doing Cosmetic Correction and I am not.

3. You have a bigger #stars target. Mine is the default 500, but it works fine.

4. In my case I don't need to flip X and Y descriptors.

6. I have a very small number of quite long exposure narrowband subs (30 minutes each) so I am forcing the use of Median integration method rather than Automatic. I believe Automatic would actually use Median anyway in this case.

   I am using SNR for weighting, as I will be removing stars from the narrowband stacks in Photoshop, and am not so interested in Star shape etc. in this case.

   My MBB is set at 5%, yours is 10%.

Tools. I then performed Light Pollution Correction on my individual stacks. This cannot be a problem however, as Combine RGB still works fine with these files if I load them at this point before proceeding to the next step.

In the next part of your video you show registering the above stacks together in the same way that I have done. The only differences here are:

As per my workflow in my previous post, I am unchecking “auto-detect Masters & Integrations” in Step 1. This is only because I read this elsewhere on this forum in an answer regarding how to register separate integrations. I am still loading all the stack files in the same way as you.

Finally, I see you have your two separate analysed/registered/normalized stack files (Ha and Oiii) still loaded in APP before going into the Combine RGB tool, even though you then load them into the tool via the add channel button. In my case I came back to APP at a later session to use the tool and so had no files already loaded. To rule out this difference being important, I just replicated your method, and loaded the files first, then used the tool. This made no difference.

If I choose my stack file currently called NGC6960_Ha-27_28_29-lpc-reg-norm.fits, then the dialogue box that appears looks very similar to yours but with two key differences:

(a) Mine has not picked up a meaningful channel description from anywhere. This only appears to be text for information and not anything that drives processing behaviour.

(b) The problem I originally described has occurred, whereby the filename (in blue) has a '-1' after it, and if I press OK after changing Red to Hydrogen alpha, I get a similar dialogue for -2 and then -3 which both have to be cancelled.

I must say this is really not a problem for me personally. The main reason I posted was in response to Marc, but I notice his was a year ago and so he is probably no longer concerned by this. I am currently evaluating APP and trying to check out it does everything I need before purchasing and only have another 10 days so will continue to test the other functionality. So far I am pretty impressed with the flexibility and options. The only minor thing that bugs me a bit is the adding of a "Nost" tag to filenames of tiff files saved with the stretched box unticked. My logic would be you need a new tag for a significant change or warning, so a "stretched" tag if it were checked would be more useful. To me, unstretched should be the default requirement so no tag needed. That's all I can come up with. Everything else seems brilliant so far!

Just saw your reply Marc. It's very interesting what you say. I had tried to look at the fits header as that was my first thought. As far as I can see though, APP is constructing a new header for each integration stack file and not copying over any information from the original subs files. I suppose this makes sense as they could all be wildly different. My original subs had quite a bit of information on the camera and imaging settings etc. put in there by N.I.N.A. Anyway, in the APP stack fits header I cannot see anything about colour or channel information. Not sure if there should be?

@brookesc about that masters I keep that on because at every new stacking it need to calibrating.  Also when I load intergrated files I need to calibration to see if it got calibration. And otherwise if I shut that down I perhaps forget it next time to activate it.

The flipping is needed if your images are flipped, like mine are flipped because of meridian flip is happening sometimes. 

And a question what do you have selected in tab 1? 

And maybe try to place the color name at the end of the file name,  reason is your file name end with another word not Ha.

I am still going to find out how APP recognizes the filters of each file so you don't get red or blue etc.

I had a moment las time APP  choice the right color like HA.

I understand all your points Stefan

I normally have the masters detection on. Only turned it off to register my 5 integrations because, as I said, it was suggested here somewhere. It makes no real difference so I will keep it on in future to avoid forgetting as you say.

I didn't have any flipped images but might keep this checkbox on too next time.

Tab 1 settings were identical to yours. I only listed the settings that were different.

As I said, I tried putting either NGC6960_Ha or just _Ha at the end.

I don't think the Combine RGB tool does recognise the colours to start with, as your dialogue asked initially for a Red file, just like mine. Also it says "Metadata Filter tag not found" in both yours and mine too.

@brookesc

@marc

I found it. Check the video

Excellent news Stefan!

So I see that using the “Multi-Channel/Filter processing” option in 1. (Load) when registering/normalizing the stacks allows us to add a filter tag in the metadata. That is indeed very useful, well spotted! I have now tried registering stacks that had previously just been integrated and saved, the same as you, and the combine RGB tool works great, detecting each channel correctly.

However, it's not all good news for me. If I register/normalize my stacks that had been through the lpc (light pollution correction) tool after integration, the combine RGB tool still wants a fits-1, fits-2, and fits-3 file for each, even though it now knows from the metadata that it is looking for a specific channel (e,g, Ha). Instead of using the lpc tool at this stage, I tried using it at the end of the process on the registered /normalized stacks instead, but the combine RGB tool still doesn't like it. Looking at the metadata, I see that using the lpc tool changes the dimensionality of the data (HDV1 - NAXIS tag) from 2 to 3. I think this is the core of the problem, because the combine RGB tool is now looking for a Red, Green, and Blue version of each when trying to add a channel.

I am now left wondering when it is best to use the lpc tool. It will most probably have to be right at the end, after doing any experiments in the combine RGB tool. This is a pity, as I found using lpc on the monochrome stacks produced using narrowband algorithms such as "Ha-Oiii extract Ha" very effective at dealing with the background and so then made the results look better when using combine RGB. Of course I could still continue to use my previous technique at the expense of having to cancel the additional file requests from the tool and manually selecting my channel each time as before.

I will continue to learn by experiment!

@brookesc do the remove light pollution after combine RGB