Subframe Selector PCL Module

[bvalente]

new update looks really nice - it was already performing nicely but i'll take faster performance any day!

i hope someone does windows soon

thanks again

Brian

[pfile]

i can try to build it for OSX but i think i'm maybe behind a couple of revs on Xcode and don't have the latest PCL installed so it may take me a couple of days.

rob

well so i made the mistake of pulling the latest PCL from the pixinsight github, and i found that after i built the module that 01.08.05.1352 (which is the latest for OSX) complains that the API version is unknown (161) vs an expected of 160.

i guess i can rebuild PCL from your fork of the PCL tree which i assume is going to have api version 160... but something is funny here. either OSX core is a release behind the PCL release, or the PCL API version has been bumped without a corresponding release of the core application on every platform... (?)

i also have an older build of PCL that i used to build the last SFS so maybe i can just point to that instead.

rob

[pfile]

so i'm going to need some guidance here -

the release called PCL-01.04.01.0001 on your github does not seem to contain the SubframeSelector module source code.

the branch called SubframeSelector does contain the source code, however, that branch contains the API version 161, so i can't build in that tree.

if i build PCL in the PCL-01.04.01.0001 release, then build SubframeSelector from the same-named branch, PI gives a segmentation fault when attempting to load the module. not sure exactly what is wrong there.

there is one more thing i can try - i have an older build of the PCL libraries which should be api version 160. but i feel like the SubframeSelector source should have been in your PCL-01.04.01.0001 release zipfile, and it's apparently not.

rob

[cameronleger]

Sorry this is so confusing, Rob.

My SubframeSelector branch, https://github.com/cameronleger/PCL/tree/SubframeSelector, is based off the latest PCL commit and has all the SS code up-to-date. I merged the latest PCL at the end of this development cycle so that a Pull Request would be clean.

The tag for my release was automatically added when I did a 'release' in GitHub, but that appears to have automatically applied to the 'master' branch which is actually the plain PCL repository from a while back... It also appears that the automatic zip of the code has the same issue. I'll see about moving that tag to the correct location, and that's on me for not understanding what GitHub does automatically.

You are right that PCL sets an API version 161, that happened six months ago here: https://github.com/cameronleger/PCL/commit/97e83fd6747bcf5655a4caf395a6109c348c79e9.

Comments indicate it applies for 1.8.5.1357, and yet I'm running 1.8.5.1352 also and had no issues with this build or loading the module. For some reason, the Linux 1352 doesn't care about the API version change while the OS X 1352 does.

For what you want to try, it should work. Since I haven't modified any files outside of the SubframeSelector folder, you can probably checkout any PCL commit you want, copy that folder in, and try building. I can't imagine that I'm using any extremely new portions of the PCL.

Aside from fixing the 'release' on my GitHub, let me know if you'd prefer I do anything else for you. While I cannot do the OS X build myself, I can do whatever magic in the structure/code/files that makes it easier for you.

EDIT: The tag is in the correct place now, and the source zips were automatically updated with that as well. Looks like the same issue applies to previous tags as well.

[pfile]

i got it built against the older v160 PCL tree that i had hanging around, and SFS loads and runs OK in PI. juan confirms that 161 corresponds to a future release of PI, so that problem will take care of itself eventually.

at this point the only open question is if building against the 10.14 SDK is kosher for running this module against older versions of OSX. since i am running 10.13 and the latest XCode contains only the 10.14 SDK tree, it seems like the answer is probably yes. hopefully someone who is running 10.12 can try my build.

one other question - when opening the module in PI, besides the main interface window, a 2nd (blank) window opens behind it. any idea what that is about?

thanks,

rob

https://drive.google.com/file/d/1xWKzGr4YKXbNaaeui5nH8RZR7olD1bIj/view?usp=sharing

[cameronleger]

I've seen the blank window too. It used to appear and disappear, and sometimes it would stick, but lately it's been sticking around. This inconsistency happened without code/build changes also! I fear that it has something to do with the QTWebKit views that PI is using and/or the JS graphing library. I noticed the new PhotometricColorCalibration doing it too, but it's much quicker and disappears every time.

Eventually, I'd love to build a native-drawing graphing control instead of relying on this embedded WebView; that's great for quick setups but the interaction code I had to write with it is pretty quirky. I'll look for any hints in the PCC code if it's available.

[dld]

one other question - when opening the module in PI, besides the main interface window, a 2nd (blank) window opens behind it. any idea what that is about?

I have the same minor issue but I thought it was something I've done wrong.

[photonhunter1]

i can try to build it for OSX but i think i'm maybe behind a couple of revs on Xcode and don't have the latest PCL installed so it may take me a couple of days.

rob

Sorry for the noobie question - but how do you install the module at the Linux level? I know once it's installed I need to go to the Manage Modules feature in PI to ensure it's checked.

Thanks.

Mike

[cameronleger]

Hey Mike,
That's basically it. Wherever you have it and installed it from, it will keep looking for it there. If you'd like, you can move it somewhere that makes sense to you e.g. somewhere in the PixInsight folder, but that's purely maintenance and shouldn't affect it.

[bvalente]

was there ever a windows compile done on the latest version?

thanks

Brian

[cameronleger]

Sorry, no, I'll look into it this weekend and post it here

[bvalente]

Sorry, no, I'll look into it this weekend and post it here

fantastic! that would be great, i appreciate it

Brian

[cameronleger]

Hey Brian,
I literally got this latest reply as I was uploading the release to GitHub. It's ready https://github.com/cameronleger/PCL/releases/tag/01.04.01.0001

I simply pulled the latest changes, built the solution, and opened the module in PixInsight to make sure I didn't have the same OS X API version issues. I wasn't able to run it, but the latest version is built and opens at the least.

[photonhunter1]

Hey Mike,
That's basically it. Wherever you have it and installed it from, it will keep looking for it there. If you'd like, you can move it somewhere that makes sense to you e.g. somewhere in the PixInsight folder, but that's purely maintenance and shouldn't affect it.

Worked like a charm. Thanks Cameron.

Mike

[photonhunter1]

Successfully ran (and LOVE) the process! A few questions I hoping someone can help me with. Below is a screen shot of my FWHM weights after entering the subframe expression. I guess the first question I have is can we use the same formula structure as we use with the script? Here's the formula that I entered:

(10*(1-(FWHM-2.528)/(2.528-4.482)) + 10*(1-(Eccentricity-0.497)/(0.847-0.497)) + 30*(SNRWeight-1.1167)/(1.1479-1.1167)) + 50

As I understand it the lower the FWHM number the better the image. My next set of  questions relate to the following data:
-Index Image #3 has a FWHM of 2.602 (worst number), and a weighted score of 92.772 (highest score)
-Index Image #6 has a FWHM of 2.265 (second worst number) and a weighted score of 74.103 (lowest score)
-Index Image #7 has a FWHM of 2.257 (best number) and a weighted score of 88.084 (second best score)

Why would image #3, which has the worst FWHM number, have the best weighted score? And image #6 has the second worst FWHM number yet it has the lowest weighted score? If I am interpreting the data properly, the worst scored FWHM image (#3) will carry the most weight (92.772) into the final product rather than the best FWHM image (#7).

Lastly, to underscore my complete confusion and ignorance, highlighting my need for help - image #7 has the best FWHM score, has a better weighted score than image #6, but not the best score that I would expect it to have. Someone please point me in the right direction...