I’m wondering if it’s possible to save manual annotations (class labels) I created in TWS to segment a volume. It seems like I can keep improving annotations while TWS is open, but they’re gone as soon as plugin is closed.
Hello @alxndrkalinin and welcome to the ImageJ forum!
The traces of TWS are simply ROIs, so you can save them by using the ROI manager.
Maybe I missing something obvious, but is there a way to propagate existing tracks from inside of TWS to ROI manager? I already have a bunch of tracks in TWS, but ROI manager doesn’t see them. Moreover, it seems like the only way to add a new track to both TWS class and ROI list is to separately add it to the ROI list and TWS class.
Any active trace in the Trainable Weka Segmentation can be added to the ROI Manager by pressing its Add [t] button or hitting T. After adding the trace to a class, you can click the entry in the trace list (e.g.
trace 0) to activate it, and then add it to the ROI manager.
Note that if the sole purpose is to keep the traced data for improving the training later (on the same or on a different image), you should use the Save data and Load data buttons in TWS.
Just as @alxndrkalinin did, I am struggling with the handling of ROI traces by the plugin. In my case I need to train on a stack of >10 slices with a very large number of ROI traces across the stack, plus I would like to test this with a relatively large set of features activated.
I’m away from office working on a MacBook with 8GB of RAM and the above combination results in a memory error from the plugin during training. Saving data is not an option either because I get the same out of memory error (possibly implying that the memory issue arises during feature extraction).
To get around this I would like to prepare the ROI traces locally on my macbook and save them, transfer both the stack and saved traces to a remote machine with plenty of RAM, load them into the WEKA plugin on the remote machine (I use BackToMyMac) and train.
I learned from @imagejan’s post how to transfer traces to the ROI manager (btw it would be great to mention this possibility in the plugin wiki page). However, if one wants to repeat the training multiple times while changing the ensemble of features used, the whole process of re-assining ROIs from the ROI manager to each class becomes unduly long and prone to error. In my case it is particularly cumbersome as there is a time delay when operating on the remote machine.
In summary, I suggest adding a simple ‘save traces’/‘load traces’ command pair in the plugin GUI. New users like me might find it very intuitive and rely quite a bit on it!
Hi, did you figure out a way to efficiently save many traces for an image?
I take note. I will try to work on this as soon as I can.
Aside from saving traces, is there a way of importing ROIs from the ROI manager as traces/labels???
I’m using the ROI manager to interpolate rois, and at the moment, I’m clicking on each of the interpolated ROIs, and manually clicking “Add to Label” for each. I’m having to to this for 150 odd slices at a time, and it is frustratingly laborious.
So, can we transfer all ROis in the ROI manager to a classifier label?
I’ve started creating a Macro that still needs a bit optimization.
So far, I can open the saved ROIs and assign them again to the image, because there are commands that allow for that in Weka.
Yet, I am stuck to the point where the initial step of correlating labels and ROI creation in the first place is not yet possible using macros.
Indeed, I haven’t found a way to read the trace and assign ROI except doing [t],( which is even more painful, because when you put focus on Weka, [t] does not work, so instead, you’ll always have to do Ctrl+Shift+[t]).
The main routine is still manual:
- Create all class 1 ROIs in ROI manager using [t]
- Save them
- Delete everything and repeat for Class2
- Run macro that assigns ROI from .zip file to Weka traces
This is really not optimal since one loses the visual feedback of the traces.
I came to the conclusion that it was better to do all class 1 and all class2 separately, to avoid the pain of renaming every ROI immediately after hitting [t].