Is your feature request related to a problem? Please describe.
We need to be able to assign whole-image labels in CURATE, and this needs to be auditable (i.e. logged).
Describe the solution you'd like
Unlike with ANNOTATE, where the user makes lots of little changes then submits them all at once like a git commit, whole-image labels should be committed to etebase immediately, as soon as the user clicks. We'll need to define a callback in DOMINATE that does this and pass it down to CURATE. It will work by fetching the most recent annotationObject for the given image, adding (or removing) a label to (or from) it, and saving the new object back to etebase. This fits into the same system described in https://github.com/gliff-ai/annotate/issues/151, where each image a user works on has a collection of annotationObjects which are named sequentially - labeling a whole image should just add one more object to that sequence, whose only difference to the previous object will be the addition or removal of a label.
Describe alternatives you've considered
Depending on how we do the user interface for this, it might make sense to batch label updates for the same image - so if the user adds three labels to one image, then that becomes one new annotation snapshot in etebase, not three.
Additional context
We can't expect users to label images just from thumbnails, so we'll need a labeling interface where images are shown at close to full screen size in a box, with arrows to go to the next or previous image and buttons for labeling. Then if the user adds multiple labels, we can commit them all at once when they go to the next image or close the box. Could make that a different issue though.
Is your feature request related to a problem? Please describe.
We need to be able to assign whole-image labels in CURATE, and this needs to be auditable (i.e. logged).
Describe the solution you'd like
Unlike with ANNOTATE, where the user makes lots of little changes then submits them all at once like a git commit, whole-image labels should be committed to etebase immediately, as soon as the user clicks. We'll need to define a callback in DOMINATE that does this and pass it down to CURATE. It will work by fetching the most recent
annotationObject
for the given image, adding (or removing) a label to (or from) it, and saving the new object back to etebase. This fits into the same system described in https://github.com/gliff-ai/annotate/issues/151, where each image a user works on has a collection ofannotationObject
s which are named sequentially - labeling a whole image should just add one more object to that sequence, whose only difference to the previous object will be the addition or removal of a label.Describe alternatives you've considered
Depending on how we do the user interface for this, it might make sense to batch label updates for the same image - so if the user adds three labels to one image, then that becomes one new annotation snapshot in etebase, not three.
Additional context
We can't expect users to label images just from thumbnails, so we'll need a labeling interface where images are shown at close to full screen size in a box, with arrows to go to the next or previous image and buttons for labeling. Then if the user adds multiple labels, we can commit them all at once when they go to the next image or close the box. Could make that a different issue though.