add functionality to avoid overwriting/re-annotating previously annotated images in GUI tool

[jwschroeder3]

Currently the mm3_curateTrainingData.py GUI does not indicate whether a given image has already been curated and saved to training data.

Could either:

1. have indicator appear in window to tell you you've already done the image
2. write a file (curated.yaml, e.g.) to the experiment_dir that would indicate whether a given fov/peak/frame has been curated (1) or not (0). mm3_curateTrainingData.py would read this file and never even show the image/mask pairs that have already been curated and saved to training data, and it would have to update the yaml file as you curated data.

I'm open to other suggestions as well.

[jtsauls]

Having not tested anything yet, the first option seems better because you may want to fix your previous annotation and do want to overwrite the file.

[jwschroeder3]

I hadn't thought of that, but you're right. I'll work on implementing option 1. Also, if a previously curated mask does exist, I'm thinking we probably want that mask presented for editing rather than the original mask?

[jtsauls]

Yeah, you're right about that. It may seem better to just edit the segmented masks directly? That would make loading your previous work pretty straight forward in the current context.

It would also mean they could be used for lineage creation, say, if you didn't even want to run U-net segmentation again.

Pressing the "Save and Next" button wouldn't necessarily save phase contrast and mask file right then and there, but rewrite the segmentation mask and add the image fov/peak/timepiont to a list that marks it as "use for training data." At the end of running the GUI you could then go through all of those and save them out in the structure required for U-net training. Thoughts?

On a side note, this GUI has got me thinking of the GUI we will likely need to train the lineage creation data. One things that's really nice about the way you rewrote the GUI to read the segmentation data directly (as opposed to calculate it on the fly and use it at is was before), is that it allows me to use the Otsu segmentation method as a starter and then go with that. For lineage creation training, I will imagine we will need something similar, where the current method can give us a good seed that we can then edit. [Side side note: it may be good to have an intermediate data structure that contains the relationship data from cell regions but that isn't as big and complete at the cell objects themselves]. Eventually you hope to do everything with machine learning, but when you have nothing to start with (say, because you are now using a new species like yeast in the mother machine), a head start with the old method is useful.

[jwschroeder3]

Okay. For now I've done the PR to make the GUI load the mask that is already in the training data directory, if one exists. Stdout in your terminal will tell you if it loaded the mask from the training data directory for now, at least until I get a more sophisticated message written in.

I'm liking where you're going with the ideas for how to organize the information, and to just overwrite the old masks while compiling a list of which image/mask pairs to use for training data. I'll work on that, but I will say that it won't be a super high priority this week.

For a lineage creation GUI, I initially thought that wouldn't be necessary, but having tried to make some training data manually in a spreadsheet a few weeks ago, I agree that we need it. I think you're absolutely right that if we could start with current lineage annotations and update them with our GUI, we'll be in much better shape than if we were to do all the curation of the training data de novo. Let's chat some time about what we need the GUI to do and how we want it to look and feel. Then I can get started on that.

[jtsauls]

Sounds great. Getting close to pushing on the other issue. I'd be down to chat Friday or early next week.