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.
Hello,
Â
please have a look. I calibrated as usual, cmos 6200mm same temp, same gain, same offset for all calibration frames and get ok for Ha, but not for red:
uncalibrated:
calibrated:
Ha looks normal, Red absolutlely not, easily seen.
any ideas?
this is how the flats look like:
the stretch on red seem very strong...
the exposure times on the flats are for red 0,2 secs, Ha ca. 3 sec (done by autoflat aid in APT)
could this cause that?Â
Â
stefan
22 hours and no ideas here, ok...
since I had 2 days lost due to this before I continue, since pixinsight worked on it with all calibrationframes without any problem!
I suppose the "again - error" in APT claimming my mono files are RGGB written in the files header could have caused this, for this was the only thing I set in the WBP scripts in PI to mono my hand. If this is so, someone should have a look into it in APP, for a hint in the header should not be able to destroy the entire stack, should it?
Â
e.
APP does look at the header to determine what the files are, if the header provides the wrong information then APP will do the wrong thing, this then should be fixed at the data acquisition stage indeed.
APP does look at the header to determine what the files are, if the header provides the wrong information then APP will do the wrong thing, this then should be fixed at the data acquisition stage indeed.
That is one option, yet not the most customer friendly. Taking a look at Pixinsight's Weighted Batch Preprocessing
tool shows that there are better options for cases where a lot of data like this happens to exist. Instead of having to convert each single frame - and with the Masters it even did not work- and wasting lots of time and nerves one just pushes a buttom and it works in WBPP. Your response does not help here at all, does it only state the plain obvious
Well the issue originates from somewhere else, so of course it doesn't help in APP itself. We can try to accommodate that, but usually we try to contact the other developer that can issue a fix. I will discuss this with Mabula though.
Well the issue originates from somewhere else, so of course it doesn't help in APP itself. We can try to accommodate that, but usually we try to contact the other developer that can issue a fix. I will discuss this with Mabula though.
That will not change anything. Note what I said above and the cause is also not clear, since an old version of APT was used for certain reasons on an old pc for other reasons. I bet there is a reason why in Pixinsight you can easily set it. For transparency. So that you see if someting is wrong, no matter why (!). You seem to be a bit selfreferential. Try to see the needs of the customer first and maybe a bit faster - and not that point of view of APP-developers...Â
