You can remove any weird annotations. I uploaded a turtle in Internet of Turtles once and it annotated just its fin instead of its face or body. 
I’d suggest keeping the more closely-cropped annotation and deleting the larger one.
I’m glad it’s finally cooperating for you!
sounds good - if I click remove annotation is seems to still keep the extra encounter it created - is there a way to remove the extra annotation and encounter at once?
It depends. Here’s the doc section that explains why the answer depends on the details of the encounter.
Hi Anastasia, I think this example falls in the case of:
- If multiple Annotations are present on an image, but the removed Annotation is the only Annotation from this image on this Encounter, then both the Annotation and the image are removed from the Encounter. The image (a.k.a. “MediaAsset”) and its other Annotations reside still on other Encounters.
So, is there no way to remove the extra erroneous encounters that are created by duplicate annotations of the same individual? It seems like this will just cause extra bloating and confusion in my database.
Oh, you can delete any encounters you don’t want regardless of the annotation status. I was just answering specifically in terms of if deleting an annotation meant deleting an encounter at the same time.
You can edit the Metadata section and find a Delete Encounter button there. Here’s the doc section on deleting encounters for reference.
Gotcha - thanks! I should have made that part of my question clearer
I don’t suppose there is a way to delete multiple encounters at once? It looks like there are a couple hundred extra I’ll want to get rid of from my bulk import.
Unfortunately, there isn’t. Encounters have to be deleted one at a time.
While I was working on updating the status of old support requests, I can across one post that explains that multiple annotations in an image creating additional encounters is by design: 1 Encounter submission creates other encounters for each picture - #2 by MarkF
You likely don’t need to remove the extra encounters unless doing so makes it easier for you to track and organize your data.
Another question on this whole process: how will I be able to tell when the batch identification is done running?
It would show on the encounter level. You’d click on the hamburger menu on the image and click on “match results”.
If it’s greyed out, you can try again later or click on “start another match”. The queue is still pretty full, so hold off on starting a match unless it’s been a while and it’s still stuck.
I see that ‘match results’ is an option for some of my encounters, but when I click on it the page it opens seems to get stuck ‘attempting to fetch results’. Is it typical for this step to be quite slow? e.g. the page has been open for ~30 minutes and the results still have not loaded.
No, it shouldn’t take that long. Is there a specific encounter you’d like to troubleshoot? You can post the URL here so I can try and replicate the issue.
Hi Anastasia,
I tried again this morning on the same encounter and this time the PIE results opened much more quickly (within a few seconds), but for the other two algorithms after a few minutes it still says ‘attempting to fetch results’. Here’s the link for the encounter.
Thanks for the link! I’m getting the same thing on my end.
It looks like there’s a backlog of jobs on Flukebook due to the image server running out of space. We’re working on this right now. I’ll update here when that’s been taken care of.
The disc space issue has been fixed, but we’ve had to resubmit jobs that got stuck when there wasn’t enough space to process them. Right now there’s a backlog of large jobs in Flukebook as those finish processing. Thanks for your patience. Matches should start working normally after the jobs complete.
thanks for the update - do you have a rough estimate on the timeline for that? Hours, days, weeks?
I’m estimating another day or so. Last night there were about 600 re-run jobs and right now there are 300.
One thing to keep in mind with the time estimate displayed in Flukebook is that it’s a reflection of past work only and doesn’t make a prediction. Since the most recent past jobs were stuck due to low disc space, the time predicted on the site will be off for a little while.
thanks. I noticed in another topic you mentioned that small jobs will be prioritized, so I guess mine might be delayed further since it is a larger job, is that right?
Right. Currently, Wildbooks accept jobs on a first come, first-served basis which can cause problems if someone has 20 images to import and another user has 1000. Eventually, we’d like the system to automatically move smaller jobs up in the queue so they’re not stuck behind the larger ones but for now when that happens, we have to manually do that when a bottleneck occurs.