Prepending a prefix to window names

hi -

i’ve been using autointegrate for a few months, thanks for this great tool.

i often run PI for months at a time without quitting or closing windows. because autointegrate uses the same window names regardless of the project, i have to rename or close all the windows that AI generated before running AI again on a new set of files.

i’ve hacked in a window prefix control to the latest beta in github. however, i’m not sure i’ve captured every place where a window might be named. it seems to work at least in the way that i’m using AutoIntegrate.

if you are interested in this change should i fork the project on github and then do a pull, or would you just like to see the file so you can review the changes?

thanks - rob

Hi,

Sorry for late response.

That sounds like a good addition! I am also happy to hear that you have managed to get it working. Window naming stuff is pretty complex as it unfortunately is all over the code.

For the code changes, I would be happy to review those and maybe run some tests on my test set. I am ok whatever is the easiest for you.

I need to check what is the best way to integrate your changes to my branch. My experience with github is a bit limited. Feel free to suggest the best way to do it.

Jarmo

hi Jarmo, thanks,

i am not sure i got it all - i noticed the AutoMask window was still called AutoMask the other day. i need to go back and look at that.

i don’t have a lot of experience with github beyond running git clone (but i am familiar with other revision control systems). if you haven’t made changes to the script since i downloaded it then i guess there’s no need to do a merge and maybe you can just use diff to check the changes. or i can also generate a patch file with diff which highlights the differences. if you want to try using github then we’d both be learning it on the fly i suppose.

anyway let me know and if you just want the script/diff how should i send it? just attach it here?

Hi,

I do not have any open changes so whatever is in the github in image-integration branch is the latest.

You can attach the changed script here, or email me for example to astroimagetools@gmail.com, whatever you like.

The window naming is a bit complicated so it is easy to miss a few of those.

I would kind of like to do the change in the github way unless it gets too complicated. After a quick search I found this page that looks quite detailed.

Jarmo

ok thanks, i will read that. i only see master and the image-calibration branch, is that what you meant?

Yes. All my recent changes are in the image-calibration branch. It is the beta branch which I will merge back to master branch some day.

Jarmo

i guess i must have originally grabbed the beta 14 code as it looks like beta 16 is what’s at the head of image-calibration now. however, i should be able to create a patch from beta 14 (i did save the original file) and then apply that patch to my local (git) copy of beta 16.

one question - do you think i should create a branch for this, or just put it on image-calibration? for now i’m just on image-calibration. i guess if i create new branch then you need to do extra work to merge the changes in…

With Git in my opinion it is always useful to create a new branch and then merge commits from there to the target branch. If you need to do multiple commits you can squash them into one before merging back. So I think own branch gives more flexibility.

But on the other hand both methods should work fine. I use Git at the office and use both methods. I am not absolutely sure if Github makes things different.

Jarmo

ok - well for now i’m just on the image-calibration branch on my own local copy. i haven’t checked anything in yet. as i was experimenting with the below -

one problem with this whole idea is that the iconified windows end up sitting right on top of one another when you run multiple times. from reading the code it seems that it’s not possible to set (or probably get) the coordinates of an iconified window given the trick of moving the window to force the icon placement. the idea being to detect if there is already a column of icons and automatically add an X coordinate bias to make the icons for runs 2+ have their own column.

it also looks like there’s no method to shade a window from PJSR so switching to shaded windows instead of icons probably doesn’t fly either.

it would be kind of a hack but i think the only thing that can be done here is to let the user specify a “column bias” in the UI to manually set a location for the icons to sit.

I agree, icon placements is a problem.

I kind of remember that there is session/script specific storage available in PixInsight. In that case it would be possible to save last icon placement there. Then we would know the last icon place and continue from there. Close All or maybe a separate button could be used to clear the position.

Also some kind of manual mechanism that you suggested would be fine if there is no other way.

Jarmo

ok, well i checked in my changes on my fork of the repository, on the image-calibration branch. i didn’t generate a pull request yet but maybe you want to review and test the code.

i wasn’t totally consistent with the camel case. some of the variables i added are “underscore style” - if you want to change those please do.

the changes are:

window prefix UI control + logic
bumping the icons over on each run and saving the current column number to the PI settings, plus a reset button to get the icons back to the top left

also i mainly tested this on narrowband images so if you have a regression suite that uses LRGB that would probably be good.

let me know what you think and if there are any changes you want me to make.

rob

Hi Rob,

This is really great, well done! I really like how it was done, icons are just magically added to the right column. All prefixes with a quick test seemed correct too, I tried LRGB and narrowband.

I can do more test later today. I would not worry about camelcase vs underscore, it now matches well to the randomness of old code.

I think this is a very useful change. Working with different processing options or palettes is now easier. Subdirectory support helped with that but this is still a lot easier.

Jarmo

1 Like

alright! great to hear my changes look good. should i do the pull request or is that not actually necessary?

since window names have to be legal C++ variables i’m thinking maybe more sanity checking of the user-entered prefix might be a good idea. i took care of spaces and trailing underscores but maybe other non-alphanumeric characters should be filtered as well… also any characters in a prefix which belong to regexp control might cause problems when trying to remove prefixes. maybe it makes sense to just keep a “clean” copy of the window name arrays around instead of modifying the original and then trying to remove the previous prefix when it changes.

rob

I do not see the change so I believe you need to do the pull request.

I think it is a good idea to check for bad characters. I often try to use ‘-’ in image names and it fails. At least most common mistakes can be avoided that way.

You can do that now or later, both are fine for me.

Jarmo

ok i reworked the window_prefix sanitization. i think it will prevent the user from entering an illegal prefix now. i also fixed a bug in the code that calls the update functions - it would not update if the user set and then cleared the prefix.

i think i want to add a spin-box for the icon column, which would then show the user what the automatically incremented column is and let the user set it to whatever they want instead of just resetting it. but i guess i’ll make the pull request and you can merge what is there for now.

Great! I just merged the change. I would like to mention your contribution in the source and in the credits. Would that be ok and what name/text should I use, pfile, rpfile, Rob, something else?

I agree that manually setting the ison column could be useful in some cases. If you have like three different runs and delete the middle one, it would be nice to able to set the next position the the empty spot. I think this would be enough and more complex system is not needed.

Jarmo

oh - yeah i didn’t update the copyright section, wasn’t sure about that. anyway you can use “rob pfile” for the credit. i’ll work on the column controls.

the web page you referred me to describes deleting the fork after changes have been merged into the parent project but it seems like i should be able to keep working on my own fork and then do another pull request, right?

OK, I will update contributions with ‘rob pfile’.

You can continue working on your own fork. It is not a problem unless there would be big changes to the source image-calibration branch. Someone asked for a way to save all files as 16 bit diff. I may do that but I have no other plans at the moment so merging will not be a problem.

I think pretty soon after you are done I will merge the image-calibration branch to the master branch. I have not got any real feedback on image calibration as of course everyone uses WBPP (and they should) so no point of keeping this "beta " status.

Jarmo

ok great, thanks for the attribution!

yeah for my part i mostly use AI for images from telescope.live, which are precalibrated. for a while i was trying to calibrate the images myself but i gave up because it’s not easy to collect all the matching darks/bias/flats. i havent collected any subexposures from home in more than a year, so i haven’t really had to calibrate anything, thus no WBPP :frowning:

i’ve replaced the reset button for the column control with a spinbox and i’m testing it now. i did find a bug in the code that decrements the column count. it should only happen if closeAllWindows() is called with keep_integrated_images == false. but that fix will be in the new code so maybe there’s no reason to make the fix by itself.

rob