I have collected Telescope Live calibration files twice. Not an easy task and I am not even sure I picked the right files.
Your plan sounds good, no need for separate fixes. At least for me it works just fine.
With narrowband files I often try different palettes from same Integration_[HSO] files. I am thinking if your changes could be used to automatically rename result files with palette name. Or maybe with user specified name. So you would use default Integration_* files as input for AutoContinue but the final files would have a prefix to separate them. I guess this would need an option to default names as an input.
i don’t have a good grasp on the AutoContinue logic, i need to study it. i just did a couple of tests and i can see that AutoContinue can’t find the RGB file after quitting and re-starting the script, because i didn’t enter a window prefix on the second run. but it does find the RGB file if i re-enter the prefix. maybe this means that the window prefix itself should also be saved in the settings just for convenience.
i do see that you can force the script to autocontinue on an open image in a drop-down menu though.
but i think you are asking about something different. how do you ask the script to re-use the [HSO] files but make a new narrowband mapping?
That was just a thought and not sure if it is worth doing. But I sometimes use autocontinue so that:
I run the normal workflow using for example SHO palette
I choose keep integrate images and click Close all, it leaves Integration_* images
I choose a different palette like HOO and click AutoContinue
After step 1 I need to make a copy of the SHO palette image if I want to keep it. The end result always has the same name and sometimes I think that it would be nice to have the palette name on it. This is not directly related to your changes, I was just thinking that it might help with that change.
oh, i think i understand now… if the autocontinue code sees an RGB file then it uses that, otherwise it will look for the linear Integration_[HSO] files and so you can play with the mappings.
i think maybe since the name of the mapping you’re doing is already known (since it’s selected in the script) that you could rename the final product image with the mapping name but then of course you have the problem of keeping track of that new name for RGB AutoContinue… and then if there are multiple RGB files with different mappings then it’s no longer clear which one should be used for RGB AutoContinue. the window prefix stuff could be used for this but it seems like now you’ve got a user-supplied prefix and a script-generate prefix at the same time, which complicates things.
I have now moved all 1.00 Beta changer to the master branch. So the master version is now 1.00. I have updated the web site to include beta changes. Thanks again for your effort and good changes.
great! that is a huge merge. hopefully there aren’t too many bugs, let me know if someone reports a problem with the window prefix stuff and i miss it here.
BTW i asked juan about getting better icon position/window position support in PI and he said in 1.8.9 there will be a new Workspace object that gives you control over all this stuff.
not sure if it is worth working on that right away as it would prevent the script from running on older versions of PI without a bunch of version check code.
Sounds great! It surely would be helpful. Also AutoIntegrate does not understand workspaces so it would be good to be able to use different workspaces. But I have never checked that so maybe there is a way for different workspaces already there.
I agree on the version problem. For example right now Debayering defaults that I took with 1.8.8-8 will crash on 1.8.8-6. So compatibility between different version is a real issue.
OK i will take a look. on #1 it makes sense because i increment it when the user presses run. didn’t realize that you’d get a file dialog and that it could be canceled. maybe the logic should only increment if processing was successful. i hope that’s not like trying to solve the halting problem
on #2 off the top of my head i cant remember if i did this on purpose/had a reason or if it’s a side effect of something else, i’ll look.
Great if you can check this! I wonder would it make sense to postpone the icon column increment to the point where we actually iconize something…
Extra processing is some kind of exception in the AutoContinue as you just continue from the final image and do not overwrite previously processed data.
ok i added a global variable to track if anything was iconized during the current invocation and only increment the column if that variable is true after the script returns to the button handler. i made a pull request.
that also seems to have fixed the AutoContinue thing but maybe i was not doing what you were doing, so let me know if that is still broken and how to reproduce it.
I did some testing and it seemed to work fine. I still have some old problems with icons and AutoContinue but no new ones found yet
Should the winPrefix be saved also at exit? Now it is not possible to clear it except by running some processing. If I set the prefix and do a run and then clear it before exit, the next time I will get the prefix back again.
i just thought it should be saved so that if you come back to the script to do autocontinue you don’t have to set it again. since the console window covers up the icons it’s even hard to know what it was, if you have forgotten it.
that kind of makes the script work the way it did before there were any window prefixes at all. i guess if you were to save the window prefix every time it changes then you would be able to clear it out before exit?
I agree that it is good idea to save it so that it will be automatically there the next time. I was just thinking that if I manually clear the prefix before exit then there would no prefix the next time.
Saving every time it changes should do the trick. Maybe saving at exit would work too. I guess some testing will show what looks logical and works in more cases.
