You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been directed towards RootPainter by colleagues in marine science. I'm considering which labeling tool suite to use in my lab, and I quite like this project because of the support for folks with biology backgrounds. When comparing to other open source tools (label-studio and CVAT in particular) I'm hesitant to adopt RootPainter simply because of the fixed model architecture (U-Net) that is implemented in the backend appears to be dry.
I can't see an easy way to implement a different model supported within the torch backend. If I'm wrong about that, then I think there just needs to be better documentation on supporting other model architectures.
I understand it wouldn't be an easy thing to refactor RootPainter to be model agnostic, but I think it will future-proof RootPainter a bit if the model architecture can be easily updated to keep up with state-of-the-art.
The text was updated successfully, but these errors were encountered:
Right now the model architecture is fixed, but it should not be that hard to change it. I'm working on evaluating some more recent architectures at the moment but I don't yet have a timeline for when it will be released as part of RootPainter.
Do you have any specific new models/architectures in mind?
Eventually I'd like to support https://onnx.ai but it isn't there yet.
I've been directed towards RootPainter by colleagues in marine science. I'm considering which labeling tool suite to use in my lab, and I quite like this project because of the support for folks with biology backgrounds. When comparing to other open source tools (label-studio and CVAT in particular) I'm hesitant to adopt RootPainter simply because of the fixed model architecture (U-Net) that is implemented in the backend appears to be dry.
I can't see an easy way to implement a different model supported within the torch backend. If I'm wrong about that, then I think there just needs to be better documentation on supporting other model architectures.
I understand it wouldn't be an easy thing to refactor RootPainter to be model agnostic, but I think it will future-proof RootPainter a bit if the model architecture can be easily updated to keep up with state-of-the-art.
The text was updated successfully, but these errors were encountered: