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.
I'm running APP on a Win7 Enterprise machine. APP crashes on large integration (600 subs) All steps up to final integration work fine. Gets about 85% of the way on integration and locks up the PC. Throws garbage up on screen. Have to force power off and restart. Two of three stacks successfully integrated. How do I recover from this?
APP doesn't seem to know where it left off leaving me to start over from calibration. This is several hours lost and not the first time this happens. I'm wondering if anyone else has had this issue or if it's a local problem. The PC crash and garbage screen only happens when using APP, no other issues.Â
I have 7 threads and 14gb allocated to APPÂ Â
- 64 bit
- Core I7
- 16Gb RAM
- 500Gb SSD
600 frames is a bit of a stretch to stack all at once, it consumes too much memory probably at certain steps. It's better to divide them into 200 sub stacks and then integrate the 3 resulting integrations.
A history feature of steps is a nice idea yes, I think it's also on the list to be supported in due time.
@vincent-mod
Can you be more specific on how this would be done? I can break down subs by filter, but how do you register and normalize between sets?
Ah it's different filters, well then you make those in separate stacks, usually I process those completely to my liking first and then you load them into APP again using the multi-filter option and then proceed to register them. Save the registered frames, go to the tools tab and use the combine RGB feature to combine them.
Also, I guess you configured APP to use more memory than set standard?
Mine is set a bit too high as I also just have 16GB total, I simply use APP only when I'm not doing much else. 🙂
Ah it's different filters, well then you make those in separate stacks, usually I process those completely to my liking first and then you load them into APP again using the multi-filter option and then proceed to register them. Save the registered frames, go to the tools tab and use the combine RGB feature to combine them.
Are you saying to completely run each filter from load to integrate and then load the three integrations again with multi-channel, register them, then combine in RGB?
Yes, if that makes the subs at a more reasonable level of 100-200 at a time. Otherwise you split up a bit more, but basically doing the same thing. Doing it all at once works as well, but if it's this much, dividing is a better approach.
@vincent-mod
Does this have an effect on normalization, or is normalization only considering the subs in each stack. I mean does normalization take subs from different filters into account or does it work only "locally" per stack.
I think you're correct there, you need to save the normalized stacks then go to RGB combine. Sorry.
Saw this thread and it interested me. I am shooting one shot color, and can easily end up with 5 or 600 frames of data over the course of many nights of imaging. When I have tried this I check Multi Session and assign the light and calibration frames to the correct session. Should I be running each night separately and then combining integrated frames with each other?
Multi session processing is handy when you have the need for different flats per night or other calibration data that differs. And in the end you can further integrate the calibrated data yes.
