UPDATE FROM MABULA
I have had a very rough 2 months unfortunately health wise. I was struck 3x in a row with bacterial infections. The second infection occurred after a routine hospital checkup and I became very sick. I had to rest and take a lot of antibiotics. Once I was recovering and restarting work 1 month ago, I again became sick. The infection was not yet gone, so even more antibiotics and rest was needed. Needless to say, it took a lot of my energy and I needed a lot of rest.
Finally, the infection is really gone and my energy is coming back step-by-step now and I have started work again. I am terribly sorry to have kept you waiting for support. I will address all outstanding questions and e-mails step-by step and will be on the forum daily from today.
APP 2.0.0-beta47 will come soon as well, a lot of work was already completed before I became very ill, so the release is also nearly ready for you. Beta47 will be much faster actually. Many workflows will be more than 2x faster, mosaics can even be 10x faster than before because registration really received a major boost... all compared to beta46. Before I release it, I will make sure that everything is working properly and then I will release it.
Hi,
About 2 weeks ago I posted
Problem calibrating with demosaic narrow band data
and within about 5 hours Mabula had explained my problem and how to fix it. So I can't fault the service I get here!
Now that's great, but the more I thought about it, the more I realised that there were aspects of the problem that I didn't understand so I have a supplementary question. It may be academic but part of the fun of our hobby is understanding the technology which is in any case key to best exploiting it.
I will briefly restate the original problem, albeit with different data
My setup
Target M42 170x15sec 125gain
Capture RedCat 51. Optolong L-eNhance Dual Narrowband. ZWO ASI183MC Pro
Processing MacOS Mojave. APP 1.083 or 2.0.0-beta12
Calibration Full set BPM,MF,MD(300sec),MDF,MB
My problem is that when I debayered with the algorithm Ha-OIII color my integration looks like this (maximally overstretched to enhance the effect).
Clearly horrible amp glow even though I thought my calibration was fine.
Mabula explained that amp glow isn't linear in time, which does make sense, so dark scaling won't work; I need to make my MDs with 15sec darks.
So, I have a solution, BUT if I integrate with the Adaptive Airy Disk then I get this.
which looks like the amp glow has gone! I appreciate that comparing stretched histograms can be misleading so I saved my images un-stretched and then in photoshop carefully stretched both in exactly the same way and the result was the same.
Naively, I thought that as dark noise isn't "coloured", it has not been subjected to any optical filter, its subtraction ought be more or less the same regardless of the debayering method. Clearly I am mistaken, but I should really like to know how I appear to get away with scaling with AAD but not when I use the correct Ha-OIII color?
I'll inform Mabula on this one. 🙂
Thanks Vincent, have you had a chance to let Mabula know yet
Nick
I have, he didn't have time yet unfortunately. If he doesn't come back in a few days I'll check.
Thanks Vincent, I know you guys are very busy so I'll be patient.
Nick
Dear Nick @nickwest
Sorry for the delay in my response.
Did you try to provide matching darks for your lights frames? Was the result better?
I have no clue why AAD is not showing the amp-glow versus Ha-O3 extract O3 showing it without seeing the data myself. But as I said, any issue relating the amp-glow will be solved if you would supply 100% matching darks for the lights and disable dark-scaling.
