Trainable Weka Segmentation Issues/Suggestions

@iarganda I really appreciate the tweaks you did for 3.2.29 but there were a few things I thought I should mention in case you are not yet aware of them. Some of them are issues and others are just suggestions; something that might make it easier for other users but aren’t strictly necessary. I am not sure if any of these are intentional and/or how hard a fix would be to implement.

  1. Window resizing still seems to not work. This isn’t really necessary but would be nice to have.
  2. When using 3D features and attempting to enable/disable Guassians via the macro language, Difference of Guasssians also gets enabled/disabled. There is an easy workaround but users just need to be aware of this.
  3. It would be nice if the setFeatures function could do more than one at a time.
  4. It is still possible to close the image before closing the plugin. Is that a potential issue or does the plugin already guard against that in some other way?
  5. It might be nice if it could use an image that has already been hidden using setBatchMode.
  6. 3.2.29 has better interaction with setbatchMode than 3.2.28 did, but there is still some interesting results. Given that you fixed some of them already, I am guessing this is a work-in-progress.
  7. I noticed that you have 3 public functions in your source (at least in 3.2.27) that aren’t mentioned on Two of them I don’t see a GUI component for so perhaps those aren’t ready yet or are leftover from testing in a previous version. However, I would guess that saveFeatureStack would be working properly.

Edit: Regarding 5 and 6, I was writing this while trying to write a macro. Upon testing, it seems that the plugin doesn’t run in batch mode anyways; so those two points are irrelevant.

Hello @Andrew_Shum,
Thanks for your exhaustive comments, I will go through them:

What do you mean? Using the magnifying glass or the “+” and “-” keys works for me… Which OS are you using? Maybe the image is to large for your screen?

I see! You mean using the following command from macro

call("trainableSegmentation.Weka_Segmentation.setFeature", "Gaussian=true");

That’s a bug indeed. I will fix it right away. Thanks!

Good point. I will see how to add that feature to the plugin.

Do you mean the original image? If that’s the case, I only make it invisible during the execution of the plugin.

Right! I should add them to documentation, thanks!

1 Like

I have experienced this with Ubuntu 14.04 with plugin v3.2.28 and I just tested it in a Windows 10 VM with plugin v3.2.29; both exhibit this behavior. I can resize the image itself but the frame and GUI don’t change. Here is a screen shot of what I am talking about.

Yes, that is the exact command.

Since I haven’t gone through your source code to find out exactly how it all works, I’ll try to explain the best I can and hope it makes sense. I first open the image I want to run the training with. With that image as the active image, I launch the plugin. The plugin launches and the regular image window disappears (although it is still listed in the list of windows). The plugin GUI appears with the image inside. It shows up as a separate window in the windows list and is assigned a different image number. Using the windows list (or the macro language), I select and close the hidden window that initially opened when I opened the training image. The plugin GUI and the image inside it remain open. Here is a macro version of the procedure:

image_id = getImageID();
run("Trainable Weka Segmentation 3D");
selectWindow("Trainable Weka Segmentation v3.2.28");
gui_id = getImageID();

The hidden window I close in this macro is the same window that remains open when closing the plugin via the macro language (using either run("Close") or close()).

I just had a chance to switch back to my Windows 7 OS (it is dual-booted, not a VM). The version I have on that one is 3.2.29 and I can increase/decrease the height (along image’s y-axis). However, I cannot decrease it below the height with which the GUI originally opens. I cannot adjust the width at all. By the way, my screen resolution is 1920x1080 and the image is 2352x975x9. Here is another screenshot with the GUI window as small as I can make it.

I have already fixed it in the latest version of the plugin.

I see! Yeah, that’s related to the fact that I’m only leaving the original image not visible and working on a copy. I could always close the original and keep my own copy open to be release at the end. Do you need something like that for a specific reason?

Yes! I have reproduced the error on my machine and it actually happens with other of my plugins. I’ll figure out a solution, thanks for reporting!

OK, this is fixed in the latest release of the Trainable Weka Segmentation. Thanks again for reporting!

Sorry for the late reply. I was busy with other things this past week. Thanks for making those fixes/adjustments; they are much appreciated.

No, I don’t need anything regarding this. I just wanted to know if closing the image I open (which is what I mean when I say “original”) before the plugin is done would affect the plugin. Since you are operating on a copy, I am guessing the answer is “No”; other than producing an error when the plugin attempts to close the original. This is good to know especially if I have a large stack. Since the plugin runs on a copy, I could probably close the original right away and recover the memory.

Exactly, that’s what I think too.

@iarganda Thanks again for addressing all of the points I previously mentioned. On February 8th, I downloaded a fresh copy of Fiji from the main download link and ran the updater to get the necessary packages from ImageScience. I then tried to run my macro and had a few issues. I have uploaded a ZIP file containing some text files. One of them is the macro I was trying to run and other others are the outputs in the log, console, and exception windows. The order that they appeared in was exceptions 1 through 3, the console message, and then exception 4. (6.8 KB)

I think they are all related to trying to save the feature stacks. Perhaps that is why you didn’t list in on the plugin’s page? If that function is still a work-in progress, don’t worry about it; there is no urgent need for it. I actually ran it twice just to make sure the errors were repeatable. The first time, the model also didn’t save. However, since it did save the second time, I am guessing that was just some random event.

Mmmm, could it be that you tried to change the class names before GUI was created? That’s a common problem when working with macros and they are usually solved by adding some wait commands.

Thanks for the suggestion. I hadn’t thought of that. I just figured the script would wait until run had finished opening the plugin. I must admit, I didn’t actually scroll all the way down so I didn’t know that was what the first 3 exceptions were for. I just figured that they were all related to saving the feature stacks.

However, I have reason to believe that, despite those exceptions, things probably ran as expected with regards to the class names. Looking at the data file from the same run as those exception messages, it appears that the class names were properly set. If you wish to see the file for yourself, just let me know and I can share via google drive or something. Unfortunately, the ARFF is too large for this site. Furthermore, there seems to be no issues when adding the traces.

Now, I did notice that I have 3 syntax errors in the version of the script I provided. Just to be sure, I fixed them and reran it through the File.makeDirectory call (I stopped there since the rest takes a while and is irrelevant to testing the class related functions in question). It still produced those first 3 exceptions. However, when I ran a newer version of the script (below with ZIP extension simply because this site doesn’t accept TXT files), I did not get any errors or exceptions. (4.1 KB)

The only significant difference between this version and a syntactically corrected version of the one I previously posted is that the new one doesn’t try to save the feature stacks via the macro.

Just had the same thing happen again when I tried to save via the macro but after saving the data. Also, it appears that the reason it didn’t save the model is that it never trained the model. The image that it saved (in both cases) as the result was actually just the input image. That seems odd to me. I would think the explanation for not training the model would be that the macro was aborted. However, if that is the case, then one would not expect the “result” to be saved. In the case of the first macro version, one would also not expect the data to be saved (which it was). Is the feature stack generation being done in a separate thread(s)? If so, then that might be another spot were the macro needs to be forced to wait for some time.

Sorry for the consecutive replies. After some more tests, it appears that the missing files and mis-saved image are likely due to some other cause that previously just happened to occur during the same runs where I tried to save from the macro. The two aren’t related at all; which makes more sense. Essentially, I just need to re-select the GUI before each command just to make sure the macro is running it on the correct image.

Also, I did add a delay between opening the plugin and using the commands. It seems to have solved the first 3 exceptions. Thanks for that suggestion. I don’t know exactly how long it takes, so I just put a delay of 10 seconds to be safe.


Quick update. I figured out how to get my script to automatically save the feature stacks. I don’t know if this is intentional or not, but in order to save the feature stacks via an IJM, you must first save the training data. It must be some difference in how the actual functions are called since, as I recall, this specific order is not required when using the GUI.

1 Like