Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reset RepeatInnotation number of visual elements to min_repeats #12

Open
thomassajot opened this issue Feb 6, 2020 · 1 comment
Open

Comments

@thomassajot
Copy link

When labelling one image to n > min_repeats elements, the following images to be labelled keep the same n rows (instead of displaying min_repeats).

@danlester
Copy link
Member

danlester commented Feb 7, 2020

As in #10 this would depend on there definitely being a concept of a 'blank' row, but this might depend on the data (there is no way of knowing if e.g. a MultiInnotation was intentionally set to the zero index for example).

In some ways, the min_repeats parameter is a bit pointless as there are a fixed number of rows in the underlying data anyway. By clicking Add you're not really adding a new row, just exposing it to the user in the UI.

I think ideally these two concepts would be combined, if appropriate at all, and automatically when viewing a new data index you would get to see all the non-blank rows plus one extra blank row if available (ready for the next row to be input).

However, as it stands, the Add functionality is a bit cumbersome. When you click it, if there is a BoundingBoxInnotation you then have to click inside that in order for it to be active, otherwise you will just replace whichever (non-blank) row was already active.

So if most of your data instances need e.g. 5-10 non-blank rows when completely annotated, you would have to click Add 5-10 times on every image before you can draw on it. My point is that the functionality is designed intentionally as it stands - far better to always display 10 rows in my opinion.

But in that case, why not just always display max_repeats rows...? Well, I guess that's because you might want to leave room for 100 rows, even if most data instances will only need 5-10. But then, for this to make sense, you'd ideally have a way to hide rows after you have viewed one of the 100-row data instances.

In fact, this raises a more important point: if your data already has multiple non-blank rows when you instantiate the Innotater, some of your rows will be hidden if min_repeats is too low. You have to click Add to reveal them!

So again, maybe Add is the problem here - we should always just display max_repeats rows and not have an Add button at all. I think the only way to make this reliable is either to have a way to identify non-blank rows (in which case we can be flexible and do what we want) or remove the Add row button.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants