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.
Hiya all
I'm combining a whole series of datasets from different setups in a collaborative effort.
There are lots of different channels, splitting out OSC data into channels and all that good stuff.
I've been given a specific reference frame to use and I'm running into an annoying 'feature' on the last of my stacks. The registration process decides it wants to use a better reference and ignores my selection. I can't argue that the stack it choses to use as reference is better but it's not the point.
I've gone through R,G,B and Ha but now I have to do a cludgy workaround to get a matching Lum frame rather than the straightforward way.
Is there any way of really forcing APP to use the reference frame you tell it to?
Thanks
Pam
PS the chosen reference isn't 2x2 or anything along those lines.
Â
There should be yes, you can select a manual reference by going to the "Register" tab and selecting the "set reference" button. First thing on that tab, did you try that? When clicked, you select the frame in the list below.
That's exactly what I did. It's the first occasion that I've seen it but occasionally with that data APP ignored that and chose its own reference.
With the diverse sources of data and quality, I was stacking each channel (each themself a stack) separately. I don't have access to the individual subs - this is what I have access to. Each time I tried this approach a single channel out of 5 went for a different reference to that I selected. I did this with two different reference frames (the second wasn't the correct one but...) and it switched the behaviour to a different channel so it wasn't anything particular to the data as such. It was always the last channel I stacked which of course it had to be....
Stacking all the channels at the same time would presumably (hopefully) get around that but I found the behaviour really weird. There must be some code to achieve this rather than throwing some sort of error during registration.
Unfortunately I won't get to experiment more for a while as I go into hospital tomorrow but will revisit when I'm able.
Best regards
So for me to understand your workflow better; you have stacks of R, G and B (all mono) and stacks of Ha and L right? You then load those stacks into their channel and then want to register those together?
Sorry to hear about the hospital visit, good luck!
That's right. It's data from the Astrobiscuit BAT project so the stacks are all I have. I did split out the OSC data into individual channels though to add to the mono data...
It's quite the challenge given the variety in data sources/quality/pixel scale and being at the mercy of other people's pre-processing! It's easier to concentrate on one individual channel at a time rather than what would be a very messy list of files.
Thanks - I'll be more annoyed if it gets cancelled though as I've been waiting a long time for it.
Yes, that's always the issue with big projects, not everyone knows how to properly calibrate data and then you can get into suboptimal results quickly. But very interesting project nonetheless! APP should be very capable of dealing with the various scales and such, it's one of its strengths.
Ok, so still to get it really clear (I didn't have my coffee yet).. it usually works for you, but not with your last attempt, which is the luminance itself right? So nothing to do with the other stacks, you just load in luminance and need a good reference for that..
That's right but one time it was the Ha that didn't behave.
For better or worse we're supposed to use the supplied reference frame for the final image. In this case it's not a very deep single sub by the looks of it and it's not difficult for APP to find a better one given that they are stacks
Interesting, because APP would be fine with any reference frame in principle. I guess they want to let everyone have the same FOV or something like that. But they then should provide a very nice one, maybe something to ask?
Anyway, maybe I should have a look. If you have time or later when you're back at it again, you can upload the luminance to our server.
