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 APP-Users, Hi Mabula,
When processing my last image (M 22), I startet to rethink the integrate all function in detail. I usally use the integrate all-result as a way to achieve an artificial luminance frame. But when combining the single RGB stacks with the R+B+G-stack (as L) some strange artefacts showed up in my final M22 image. I think I know why:
In order to get an artificial luminance frame (also referred to as synthetical, but I meanwhile better call it a derived luminance frame since it is generated from real data) there are some prerequisites necessary, in such manner that data of one channel musn't outweight data of other channels:
- a derived luminance frame should consist of an equal number of R, G and B frames
- all frames must be weighted equally (so e.g. no quality-weighted option is recommended)
- using a rejection filter would perhaps erase structures that are visible in one channel only
- also setting the integrate option to "median" could erase structures in one channel
So in my opinion it is NOT sensible (although I must admit, that I do not know how APP internally calculates the results) to achieve an integrate all-result in one go with the results of each channel (exactly because you normally set weighting to quality-based and you use rejection filter or median option, which is all sensible when the frames are limited to one channel only).
So you could get the integrate all-stack in a second run, where you disable all rejection and weighting... simply averaging the frames ... but, is this really what you want?
In another post last year I described a way some of my astro mates generate their derived luminance files:
1) single derived luminance frames are achieved by combining (simple adding or average without any weighting or rejection) triples of single R, G and B frames. So let's say you have 20 frames per channel, you could generate 20 derived luminance frames.
2) These derived luminance frames can then be combined using the usual weighting mechanisms (quality based frame selection, outlier rejection, etc.). You could even load real luminance frames in the stack together with those derived and process them together.
Please let my know what you think of this.
Stephan
