Combining mono and ...
 
Share:
Notifications
Clear all

MAY 4 2026: APP 2.0.0-beta44 has been released !

New improved internal memory controls should now work on all computers

May 1 2026: APP 2.0.0-beta43 has been released !

Improved internal memory controls (much more stable and faster on big datasets), fixed CPU image viewer, fixed Narrowband extraction demosaic algortihms.

Apr 29 2026 APP 2.0.0-beta42 has been released !

New improved Normalization engine, Fixed random crashes in integration, fixed RGB Combine & Calibrate Star Colors, fixed Narrowband extraction algorithms, new development platform with performance gains, bug fixes in the tools, etc...

Apr 14 2026: Google Pay, Apple Pay & WeChat Pay added as payment options

Update on the 2.0.0 release & the full manual

We are getting close to the 2.0.0 stable release and the full manual. The manual will soon become available on the website and also in PDF format. Both versions will be identical and once released, will start to follow the APP release cycle and thus will stay up-to-date to the latest APP version.

Once 2.0.0 is released, the price for APP will increase. Owner's license holders will not need to pay an upgrade fee to use 2.0.0, neither do Renter's license holders.

 

Combining mono and One-Shot-Color data.

12 Posts
5 Users
2 Reactions
3,217 Views
(@bcolyn)
White Dwarf
Joined: 8 years ago
Posts: 12
Topic starter  

Now, let me start by saying - I know the 'split channels' workaround. It... works but it requires quite a bit of fiddling around (more than necessary IMHO) and with high pixel count cameras (BIG subs) on fast optics like a RASA (LOTS of subs) the disk space requirements quickly balloon to the point of being unworkable (esp on an SSD where space is still a bit of a premium - even with a 1TB 970Pro).

This has irked me for some time now since nearly everything I do these days involves combining mono data with one-shot-color RBG, whether that is HaRGB of a galaxy or HOO/SHO narrowband nebulae with RGB stars. 

All data gets loaded correctly (I fix the FITS headers the capture program spits out with 'astfits' - a great tool if you run linux) without needing to force anything on tab 0, OSC is picked up as such with the correct bayer pattern (thanks to the 'BAYERPAT' keyword) and mono is also recognized as what it is. They have their own 'Filter' as well so all I'm asking as an end result is a nice stack per filter but registered together. Alas this bombs out with an ArrayIndexOutOfBoundsException in 5) Normalize. as it is looking for the second channel (index 1) in the reference frame.

 

Capture APP1
Capture APP

 

Surely this is something that can be fixed without too much hassle?



   
ReplyQuote
(@Anonymous 174)
Joined: 9 years ago
Posts: 5702
 

Not totally sure here, but you are still normalizing 3 channel RGB data with 1 channel data then? As the CFA pattern is still there. I might be misreading that. That's at least not possible right now, which is why the split channels workflow exists. But we do want to make this more clear and easier in a future version indeed.



   
ReplyQuote
(@bcolyn)
White Dwarf
Joined: 8 years ago
Posts: 12
Topic starter  

I don't see why there would be a difference (from an end-user perspective) in normalizing each channel in an RGB image on-the-fly (as happens when only RGB data is in the workflow) vs that RGB image split into 3. Esp since at that point the debayering should have already occurred.



   
ReplyQuote
(@Anonymous 174)
Joined: 9 years ago
Posts: 5702
 

That might be something that gets implemented indeed, I don't know about the background algorithms yet though and how difficult this is (or not) to implement that way.



   
ReplyQuote
(@williamshaw)
Main Sequence Star
Joined: 6 years ago
Posts: 26
 

Is there an update on this? I've just wasted a couple of hours with Java out of bounds errors combining some Ha and L from a mono cam with OSC RGB from its sister camera. All goes fine until Normalisation and when it hits the RGB data. Both the RGB and the L-Ha stuff work through to nice images when managed separately, but it would be helpful to have the whole lot processed together so they are all aligned. 

 

So now I have seen this thread! There is a split channels option at Stage 2 calibrate - is that the thing to tick. Presumably with align channels. 

Quite a few of us augment colour with mono data so I'm a bit surprised by all this. Thanks



   
ReplyQuote
(@wvreeven)
Quasar
Joined: 8 years ago
Posts: 2134
 
Posted by: @williamshaw

There is a split channels option at Stage 2 calibrate - is that the thing to tick. Presumably with align channels. 

Split channels only works when using the calibrate button in tab 2 and then using the "save calibrated lights" also in tab 2.



   
ReplyQuote
(@williamshaw)
Main Sequence Star
Joined: 6 years ago
Posts: 26
 

@wvreevenk thanks. My Mac is now producing 215 triplets of calibrated separate R, G, and B mono files along with the L and Ha. Do I just work through the remaining steps as before on those 5 channels? How do I ensure that APP now looks at the five mono channels rather than lookin g at the two mono and original RGB? Is that automatic or do I have to restart the whole process with five sets of input? Ta - sorry - new to this combo



   
ReplyQuote
(@wvreeven)
Quasar
Joined: 8 years ago
Posts: 2134
 

@williamshaw My advise would be to load the L and Ha files and calibrate them and save as well in step 2. Then clear all files and only load the calibrated R, G, B, L and Ha files and process them normally. You will end up with 5 integration results (one each for R, G, B, L and Ha) that you then can combine as you see fit.



   
ReplyQuote
(@williamshaw)
Main Sequence Star
Joined: 6 years ago
Posts: 26
 

@wvreeven so we are talking on two threads. I read the above before I deleted all those calibrated files, and decide to try it anyway. I have this problem in that the output of the split channel calibration is saved in a directory as ordered triples of files of the form

 

OLDNAME1-cal-Blue.fits

OLDNAME1-cal-Green.fits

OLDNAME1-cal-Red.fits

OLDNAME2-cal-Blue.fits

OLDNAME2-cal-Green.fits

OLDNAME2-cal-Red.fits

So the three channels are interleaved in the directory and it is a PITA to select all the reds together etc. I can drop this approach altogether but wondered if there was a cunning way to grab just each colour to reload into the relevant channel. 



   
ReplyQuote
(@wvreeven)
Quasar
Joined: 8 years ago
Posts: 2134
 

@williamshaw Yeah probably better to drop this workflow and use the one in the other thread.

Having said that, there is no cunning way in APP. If you are familiar with command line scripting then you can write a script that places the files with the same color in a directory and then load from there.



   
William Shaw reacted
ReplyQuote
(@williamshaw)
Main Sequence Star
Joined: 6 years ago
Posts: 26
 

@wvreeven thanks - agree on both points. I tend to run the OSC and mono integrations as I go in any case. I'll do the other thing. Post-processing by splitting and registering the stacked output makes more sense and uses a lot less storage!  Thanks for the feedback. I should get a nice M33 in HaLRGB form eventually. 



   
ReplyQuote
(@mark-james-ford)
Molecular Cloud
Joined: 4 years ago
Posts: 3
 

The very very very simple simple solution that would make this very workable, would be that APP adds the colour channel as a preface rather than a suffix to the saved split calibrated files:

 

Blue-cal-OLDNAME1.fits

Green-cal-OLDNAME1.fits

Red-cal-OLDNAME1.fits

Blue-cal-OLDNAME2.fits

Green-cal-OLDNAME2.fits

Red-cal-OLDNAME2.fits

 

A simple alphabetical sort in the finder will then group all the blue, green and red files together making further sorting and re-import very easy.

Please implement this ... 

 

Thanks, Mark



   
ReplyQuote
Share: