well the icon does exist and seems to be a product of the script, see screenshot. this is from SHO processing of some telescope.live images:
interestingly the icon is broken even before the script tries to close it. so something is weird here… as far as i know this is a window that the script has always created for me, unless i have something configured wrong.
rob
Maybe I misunderstood the window name part as I thought that the name was only _Integration_RGB. But yes, a window with Integration_RGB in the name is generated every time. You get those from PixelMath mapping (function runPixelMathRGBMapping) or channel combination (function CombineRGBimage). In case or narrowband images the window is created by PixelMath as we set P.createNewImage = true. For channel combination the window is created by script.
It is very much possible that the image goes broken at some later phase of the script. I could not see anything really strange done for that window. Maybe collecting autointegrate logs when this happens would give some hints.
oh - the BBS software removed my ‘generic prefix name’ which i enclosed in GT/LT signs, sorry about that. that’s why it looked like i was talking about _Integration_RGB with no prefix. anyway, i’ll check the logs.
rob
this seems to have something to do with AutoContinue… maybe this is wrong usage, but what i have been doing is set a prefix and output directory, then loading a TL HSO dataset and first running with an HSO mapping. i then quit the script and start it again, and this time select a different narrowband mapping, like Helix HOO, then click AutoContinue.
i can see that the script is deiconifying tl_helix_Integration_RGB when AutoContinue is clicked. i’m wondering if it’s incorrectly trying to use that RGB image for something - my assumption is that because the narrowband mapping is different, a new RGB file must be created (and indeed it is, after AutoContinue has run, i see tl_helix_Integration_RGB1 which has the different mapping.) on the other hand, how would the script know that the mapping has changed and thus it needs to make a new RGB?
it’s at this point that the PI interface is messed up. the icon for tl_helix_Integration_RGB will not deiconify, but if i go into the view explorer and double click the image, it opens. if i then iconify it, there’s a 2nd icon for that image. either icon when double-clicked opens the image, and if i close the image then the other icon causes segfaults on the console when i interact with it.
can you reproduce this? am i doing AutoContinue wrong?
i guess i am doing this wrong based on the tooltips. i thought it was OK because the script does produce the correct new RGB mapping after running AC. but it looks like along the way something goes wrong with the original RGB image.
Thanks, this was a good catch. I was able to reproduce the problem with your description.
The problem happened when using AutoContinue with narrowband images and “window_prefix + Integration_RGB” window exists. AutoContinue did not detect the existing window and continued processing images. PixInsight then generated a “window_prefix + Integration_RGB1” name and this caused problems with the script window and icon management. The end result was a broken icon that cannot be deleted and I guess sometimes accessing the icon crashes PixInsight. I cannot fully explain why or how the icon is broken, though.
I added some checks for existing windows before starting the processing. I also added checks that when we rename or create windows they have a correct name. This will stop processing and may happen pretty late in the process but hopefully those early checks should cover most cases.
shoot, so i missed a case where the window prefix was necessary. sorry about that. it sounds like the bug does not predate the window prefix code - i was hoping maybe it was the cause of the PI instability you were talking about.
thanks for fixing that.
My understanding is that this is not specific to window prefix. I have seen these PixInsight windows ending with “1” before after some user error but I did not remember seeing this problem. So it could be a new PixInsight problem. I remember they did some changes in one of the latest version, maybe Qt changes or something. Or even more likely it is just random.
juan is pretty busy right now with trying to get -10 finished but maybe when he’s done i can roll back this change and ask him to take a look at what is going wrong here. i need to package it succinctly for him though.
i think the “1” windows are an internal way of keeping window names unique, but i’m not sure if this is part of the core application or if each process that might create a window first checks to see if a window with the name already exists and adds a number.
Sounds great! I was also thinking if it would be possible to create a minimal script that reproduces the issue. I might give it a try. Or please let me know if you plan to do it yourself.
I reproduced an icon that cannot be opened. I can close it and no crashes but hopefully this is the same issue that you have seen.
/*
To run the test you need two windows in workspace, “T” and “B”.
I used the same image (Integration_H) and just copied it with
different names.
Window "T" must be iconized before running the program to
reproduce the problem.
Program generates a icon "T" that cannot be opened.
*/
#feature-id Test
#feature-info Testing for a bug
function findWindow(id)
{
for (var i in ImageWindow.windows) {
if (ImageWindow.windows[i].mainView.id == id) {
return ImageWindow.windows[i];
}
}
return null;
}
function main()
{
var idWin = findWindow(“B”);
var newId = “T”;
var P = new PixelMath;
P.expression = “B*0.5”;
P.createNewImage = true;
P.newImageId = newId;
P.executeOn(idWin.mainView);
var newWin = findWindow(newId);
newWin.show();
newWin.iconize();
}
main();
let me try this out and see if it is similar. PI didn’t always crash but i would get segfault info on the PI console when trying to manipulate the orphan icon.
it looks like the problem only occurs if the window T is iconized when the script starts, in terms of there being an orphaned icon.
T is still around and can be opened from the View explorer, but the original icon has been messed up by the script. if you then iconify T you get two icons named T. if you close the new image, eventually manipulating the old T icon will cause the whole application to segfault. maybe not a surprise as there’s likely a dangling pointer.
i’ll report this to juan today.
juan could not reproduce this but i’ve given him a project, the script file, and a screen recording of it happening. you are using windows, right?
i think he didn’t do anything past execution of the script - of course the problem comes after that when you can’t deiconize T and then a 2nd copy of the icon T is created if you use the view explorer to open T and iconize it.
he did notice that you can’t get a handle on a new image if there was a name conflict (meaning, you can’t tell what the new image was, T1, T2, etc.) so he’s going to add a read-only property to the PM process which tells you what the output image was called.
rob
ok he was able to reproduce it and will be fixed in -10. thanks for the code.
Great! Thanks for pushing this forward. And yes, I am on Windows.
with any luck this was the source of the instabilities you saw, but it is true that PJSR can be a little unstable.
I have done some updates. These are quite big and potentially introduce new problems so I created a new branch icon-management for these.
Basically there are three different enhancements: manual icon column management, persistent settings section and StarXTerminator support. Unfortunately I did these all at the same time so they are all in the same commit.
Persistent settings section
Options in the Persistent settings section are saved using the PixInsight Setting mechanism. They are remembered and automatically set when the script starts. So there is no need to save these settings to a process icon.
Manual icon column management
By default the icon column for a new window prefix is automatically managed by the script. Script tries to track used icon column positions and assign free ones for new runs.
Sometimes, like when using multiple workspaces, this automatic management does not work optimally. In that case it is possible to manually set the icon column for a window prefix. This can be enabled by setting Manual icon column control in the Persistent settings section. The change will be effective when restarting the script.
When manual icon control is enabled there is a new control Icon column. With that control it is possible to manually set the column where icons are placed. The default for the Icon column is Auto where the icon column is chosen automatically. Last icon column is remembered and automatically restored when the script starts.
Note: I am not sure if we need Manual icon column control option as there is Auto option in the Icon column list.
StarXTerminator support
In addition to StarNet it is possible to use StarXTerminator to remove stars from an image. StarXTerminator can be selected by choosing the option Use StarXTerminator. To use StarXTerminator as a default it is possible to set the option Default StarXTerminator in the Persistent settings section.
StarXTerminator is a commercial product that needs to be licensed and installed separately.
ok, let me get on that branch and pull the code so i can try some tests.
i should probably buy starxterminator now that the PI module exists.
Thanks, that would be great. It is a bit early stage and there many combinations.
It would be interesting too see what happens if you try StarXTerminator and you do not have it. I have not done any checks that the function exists. I hope it will start without it.
I have had StarXTerminator only for a few days now. So far results have looked really good, at least for LRGB. I tested once linear star removal on narrowband channel images before PixelMath and that did not go well. But I have not tested it really that much yet.