Encounter linked to admin bug

In which Wildbook did the issue occur?
Whiskerbook
What operating system were you using? (eg. MacOS 10.15.3)
Windows
What web browser were you using? (eg. Chrome 79)
Google chrome
What is your role on the site? (admin, researcher, etc)
admin
What happened?
The images that I have uploaded are the same as some of the encounters listed on an admin account (because we supplied some data for the PIE training)

If I go to name this encounter 287 then I get an error that says
Failure:
The following Encounters contain the same annotation but have a different individual ID. An annotation can only have one ID inherited from its Encounters.

https://whiskerbook.org/encounters/encounter.jsp?number=77aa6283-1126-4cf3-9183-39649d3e3d48

What did you expect to happen?

I expected to be able to see the individual ID

What are some steps we could take to reproduce the issue?

login to my account and try to add a new identity to this encounter

https://whiskerbook.org/encounters/encounter.jsp?number=77aa6283-1126-4cf3-9183-39649d3e3d48

If this is a bulk import report, send the spreadsheet to services@wildme.org with the email subject line matching your bug report

Hi, @evebohnett !

I see what you mean.

It’s a feature rather than a bug that Whiskerbook is not letting you assign the encounter Whiskerbook | Login to a new individual (the one that you want to name 287), while identical images are already linked to [the individual named Molly]. (Whiskerbook).

One solution would be to add this encounter image to the individual, “Molly”. Another solution might involve detaching the individual “Molly” from the encounter here: Whiskerbook | Login, which may or may not make sense from a research perspective (i.e., is this individual actually NOT Molly according to some researcher? It looks like that encounter is owned by @jason , so perhaps he has more insight into whether or not this individual should really have that name.

Cheers,
Mark

Thanks for your insight about this @MarkF. I guess the larger issue is that the photos become linked if they are the same. We are currently trying to run a zoo challenge where we have uploaded the same zoo data for 14 to 18 people to sort the data and that way we can demonstrate how well people are able to use the platform based on data where the individuals are known. So, I’m not sure how these features can be turned off for some accounts or if it’s part of the infrastructure.

Also, I’m not sure of the admin need these data to be uploaded anymore or if that was for their initial sorting for the PIE test.

Anyway, this will happen a lot to these 14 to 18 users if the photos become linked due to them being the same image. It’s one experiment that should take us a month or two to complete.

Hi, @evebohnett !
Jason H. can definitely weigh in on whether Molly still needs to exist on Whiskterbook after PIE has already been implemented (that’s a great question).

As for you zoo challenge work, if it’s just a proof-of-concept demonstration of how whiskerbook operates, one solution might be having the participants slightly edit the photos (one of my favorite tricks involves just adding a random shape to a non-animal part of the jpeg, which I do with my Mac’s built-in Preview app) before submitting them.
Would that make sense and be feasible in your case?
-Mark

Interesting that there is a seeming solution. Thanks so much for suggesting @MarkF
I could add a different watermark to the images for each user. It sounds like that would work. However the images are already uploaded. It’s around 35gb of images that now we are not going to use. Just FYI. I can upload the new watermarked ones and simply use those.

Hi @evebohnett and @MarkF

@MarkF’s solution of altering the pixels of the image to prevent this should get around the issue, though this may not be the only hurdle. Wildbook’s purpose is to de-duplicate. Intentional duplication will limit real world use while the duplicate images and IDs exist and will require cleanup afterward or the duplicated IDs and data will confuse IDs thereafter. So we’ll definitely need the bulk imports removed for the participants after.

A few additional points worth mentioning:

  • Our team will be generating the top-k matching results for snow leopards for the algorithm.
  • I fully respect that the 14-18 participants are testing how well matching can be done by humans with the Wildbook interface paired with the PIE and Hotspotter algorithms, but the system is not specifically designed for side-by-side tests (the subject of this thread), and we’re replacing this user interface with a new one (Codex) next year. I think there are some interesting aspects to this test, but it will be awkward with inexperienced users and an interface not designed for the purpose of side-by-side testing.

One example I’m already worrying about: how will users not see matches to each others IDs of the same individuals? This too can be worked around by setting each users’ data in a different Project or Location ID, but that requires an additional level of setup and cleanup to prevent short-term and long-term confusion with experiment test data versus real world photo ID data.

Thanks,
Jason

Thanks, @jason and @MarkF
it sounds like if I add a watermark to the images that they are no longer considered duplicates. I was already planning to remove all of the bulk imports from the zoo data after the study.

It sounds like the platform is being upgraded to this new codex interface, which is interesting news. That sounds exciting.

Also, in regards to the ID’s. For each user, I placed the photo sets in randomized locations in to different world cities. I also randomized the observation Ids, so they are not in the same order. It is very difficult for two users to cheat on the zoo test unless they work together and figure out the patterns.

I think the challenge is simply removing the duplicate images out of the system, so I’ll watermark them and upload them again and see if that works.

By the way, I have no experience or ability to delete the photo data completely out of the system, although I would do that too f there was a way I could do it. It may not be an issue for your server.

Best,
Eve Bohnett

@evebohnett

Are you able to see the Delete Encounter button after log in on the Encounter page in the Metadata section?

Yes @jason , I can see that button and often use it to delete encounters.

That should delete out all the assets of the Encounter (photos, machine learning annotations, etc.).

Did I misunderstand your question? Apologies if so.

@jason Thanks so much for taking the time to look into this. I was originally referring to bulk import photo data and uploaded that I would not use for any tasks.

In this case, I have simply overwritten the file names, so now there should be no extra photo data in the system taking up space.

Thanks for your concern.