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'd be interested to hear what general workflow folks are using in APP. I am sure that I had read somewhere that one should avoid doing star alignment (or registration) more often than necessary. Because of this my processing in PI followed the following (simplified) workflow:
- Calibrate all lights
- Register all lights together (only registration required)
- Stack individual Channels
- Combine already registered stacks as required
Â
I can, of course, replicate this workflow in APP. But this does not seem to be the preferred workflow. If I understand correctly, APP lends itself to:
- Load all calibration subs (or masters if available)
- Load lights from one channel
- Calibrate, Register and Stack that channel (registration #1)
- Register the seperate stacks and then combine (registration #2)
Â
The APP method seems simpler (and quicker), but do I need to be worried about that second registration step? Â
Hi Steve,
Very good question 😉
Both methods you describe can be followed in APP as well. And yes, the second method that you describe is the easiest. But indeed, by applying another data resampling due to another registration process, it can be (for some datasets) sub optimal and lead to artefacts at the star borders.
So I would suggest to follow the first route if you encounter star artefacts with method 2. Most likely this will be the case with very sharp and/or undersampled data.
To solve this problem and to make it the easiest for the user, I intend to upgrade APP with full multi-channel (and even multi-session) processing. I will work on this soon.
So that would mean that when you load frames, you will be able to indicate to which channels (and/or sessions) the lights and calibration frames belong and then APP will calibrate the channels and register all data at once, and give you direct control to integrate the separate channels, by selecting the channel you want to integrate. To have this fully working will take some development time, but it's a big request from a lot of photographers, so I am bumbing this request up on my priorities list 😉
If you have any thoughts on how to implement this, let me know as well .
Mabula
Thanks for responding Mabula. Full multi-channel processing would be great, but I appreciate that this is a major task. I suppose the simplest thing (that we could probably do with the program as is) is to select one frame as our registration frame and keep this across the multiple registrations. My bottom window becomes awfully cluttered so I usually press the 'Clear' button between channels. I thought that one way might be to take note of which sub APP uses as the registration frame when processing the (for example) Blue channel. I could then use that same sub to register the other channels. However, if I load in that blue channel sub when all the rest are (say) greens, won't the blue frame get integrated along with the greens?
Could APP be set to 'remember' which was the best blue frame and use this for subsequent registrations, without it being incorporated into the stack?  Â
Actually, thinking about this a bit more, I think that it would almost always be useful to have a folder into which Calibrated Lights are saved (irrespective fo whether you follow method 1 or 2. I say this because there are a number of projects that you might want to add to - you might not get it finished in season 1, or you might want to add more data to a target that you were never all that happy with, or you might want to add data from a different telescope (maybe you have a dual rig). Since these combinations might require different flats, darks and biases, the best way of combining would be to have a bank of fully calibrated subs that you could just add to, then register as and when the mood takes.Â
What might be useful, therefore, is to use the APP method (method 2) but be given the option (a tick box) that allows you to save your calibrated subs into their own folder (possibly with the option of naming them as you see fit - I would use, for example, M17_June2107_Blue_900s - then the frame count).
Hi!
It would be very nice if I could simply drag an drop .fits files to the workspace and APP identifies them by their meta data (light,dark,flat,lum,red,green...). This would make things easy and fast I think:)
Uwe
Thanks for responding Mabula. Full multi-channel processing would be great, but I appreciate that this is a major task. I suppose the simplest thing (that we could probably do with the program as is) is to select one frame as our registration frame and keep this across the multiple registrations. My bottom window becomes awfully cluttered so I usually press the 'Clear' button between channels. I thought that one way might be to take note of which sub APP uses as the registration frame when processing the (for example) Blue channel. I could then use that same sub to register the other channels. However, if I load in that blue channel sub when all the rest are (say) greens, won't the blue frame get integrated along with the greens?
Could APP be set to 'remember' which was the best blue frame and use this for subsequent registrations, without it being incorporated into the stack?  Â
Hi Steve,
Yes, right now, you would need to load all frames, select the reference (or let it do automatically) and register all frames to that reference. Then in integration, only select the frames of each channel to create those integrations per channel. If you selected a green sub as a reference, it's no problem if you deselect it for integration 😉 of for instance the red channel. So the green reference frame won't get mixed up in the red data.
A true multi-channel implementation should cover all of this and make it work without having to think about all details oof course. So I'll definitely try to implement it in the most user friendly and technically correct way.
Could APP be set to 'remember' which was the best blue frame and use this for subsequent registrations, without it being incorporated into the stack? Â
Yes it could, but with the multi-channel implementation that I have in mind this should be a redundant issue.
Mabula
Actually, thinking about this a bit more, I think that it would almost always be useful to have a folder into which Calibrated Lights are saved (irrespective fo whether you follow method 1 or 2. I say this because there are a number of projects that you might want to add to - you might not get it finished in season 1, or you might want to add more data to a target that you were never all that happy with, or you might want to add data from a different telescope (maybe you have a dual rig). Since these combinations might require different flats, darks and biases, the best way of combining would be to have a bank of fully calibrated subs that you could just add to, then register as and when the mood takes.Â
What might be useful, therefore, is to use the APP method (method 2) but be given the option (a tick box) that allows you to save your calibrated subs into their own folder (possibly with the option of naming them as you see fit - I would use, for example, M17_June2107_Blue_900s - then the frame count).
Yes, exactly, and this would mean a multi-session feature then. It's probably a natural extension of multi-channel to also make it multi-session. I will start work on this soon since it should be a very attractive feature for a lot of photographers. (I have received a lot of requests for this 😉 ).
Mabula
Hi!
It would be very nice if I could simply drag an drop .fits files to the workspace and APP identifies them by their meta data (light,dark,flat,lum,red,green...). This would make things easy and fast I think:)
Uwe
Hi Uwe,
Thank you, I have put drag and drop frames to my priorites list as well:
https://www.astropixelprocessor.com/community/development-priorities/current-priorities/
Kind reagard,
Mabula
Thank you very much!! And dont forget the Metadata!
Uwe
Hi Uwe,
Yes, I almost forgot about that 😉
I think you refer to metadata that is supplied by the capture application right?
It's a bit difficult though, I would need to know how various capture applications store it in the fits files, that is, which fits header tag would the capture application use.Â
Mabula
