In which Wildbook did the issue occur? FlukeBook
What is your role on the site? admin/researcher
What happened? unintentionally replaced the historical data from Sighting 9, August 26 2019 with different photos.
What did you expect to happen? I wanted to test the algorithm by importing Full Frame photos with slightly different file names for one sighting from 2019. However, upon import, it seems to have displaced the historical data with the full frame images adopting the original file names (not the new ones) and clearing the previous ID #s for that sighting.
What are some steps we could take to reproduce the issue?
2019 S09 Bulk import was done last week with these full frame images (not cropped and rotated) and different file names. Don’t know what happened and if we can go back and recover that historical data/images and run this test?
If this is a bulk import report, send the spreadsheet to firstname.lastname@example.org with the email subject line matching your bug report
Just to clarify, you recently uploaded a bulk import that shared the same image file names as a previous upload and the new bulk import replaced the images from your previously imported encounters with the shared name?
Not quite. I recently uploaded bulk import of Full frame images from one 2019 sighting that was included as cropped and rotated images in our training set (what I am calling our historical data). The file names were differentiated by adding “FF” to the end of the file name. I was curious as to testing the detection, annotation, and then matching of those full frame images against what should have already been there, but in a different field of view.
However, none of the other 2019 data was showing up in the matching table, and if it did, it didn’t have an ID number associated with it. I dug into the data (exported all our encounters) and the only 2019 Aug 26, files look to be the new ones.
@Anastasia , @jwaite
Thanks for meeting with us today! Based on the testing we did during the call, the bulk import ran into a permissions issue during the test upload, then fell back on info from the previous import to fill in the blanks.
Possible solution: Change the spreadsheet filename slightly (even by one character) and delete the old import and re-upload it.
Here’s the bulk import video I referenced regarding the photo review screen and how to skip to it if you’ve already uploaded your images but just need to update your spreadsheet. The link goes to the time-stamped part of the video.
Well, I did as you recommended. The import was deleted, and a newly named xls was reimported. However, upon exporting all of our data again to view what all is there, the original 2019 S09 data didn’t reappear.
I guess I might delete the import again and then export the data and see what it has?
My primary indicator is:
- original file name is in NOTES, this wasn’t the case for the historical data
- only about 122 images/encounters show up in the exported data, not 244 as to be expected if it was the original 2019 S09 photos and the new Full Frame photos.
I’m assuming this is also reflected in some blank matches that Janice ran into today… no image, no file name?
Thanks for the update. I’ll need to run this by Jason when he’s no longer absorbed with the server outage.
Here is an example of blanks coming up in the results (#s 10, 20, 27, 31, 37, and 39):
@Anastasia , @jwaite
I deleted the 2019-08-26 bulk import and went back into our data and exported. the xls shows the bulk import image data for this date. However, when I actually scroll through our data table there are no images in there for that date. I guess I can always reimport the cropped/rotated historical data xls and see if those reconnect with the cropped/rotated images on the server?
Interesting. So despite the encounters from the import having been deleted, the data is still showing up in an export?
Yes, I exported the data and the lines for 26-Aug 2019 shows up in that table (again without IDs and with the original file name pushed to Note) but the images do not show up when I scroll through my encounter data itself on fluke book.
Can you share the URL to the search results you exported so I can take a closer look at what’s going on?
Thanks! I’ll dig into this today and see if I can figure out what’s happening.
Hi there, I tried to upload a xls of the ‘historic’ data for 2019 S09, BUT it says there were no images found that matched the file names I supplied. I wasn’t 100% sure what file names Jason H used when he uploaded our historical data for testing and development but I dug into data online and exports and it looks like I should have done this correctly. I just used our original file names and removed the “-” and “_” like our current protocol.
I’ll email you the xls I was using
I didn’t have an “aha” moments while reviewing the sheets today, but I’m going to keep working on it tomorrow and try to get Jason’s input on it as soon as he’s done with the server work. Thanks for your patience.
@jwaite About those missing match candidates, this was from a recently run match, right? If so this is likely a bug I’ll also need to get Jason’s input on.
I’ll send you the spreadsheet I downloaded yesterday when I exported the search for all of your encounters, but I wasn’t able to find any for August 26, 2019. The only August encounters it displays for 2019 are for the 4th and the 5th.
Hmm. interesting. I’ll export it now too.
Should I just bulk import the original “historical” Cropped and rotated images and xls for that sighting? I tried importing just the xls yesterday but it didn’t find the images. I’m pretty sure I should have have the image names correct based on the other names of images from that year.
I added Jason to the thread to see if he had any insight into the image names not matching up. I’m hesitant to provide a suggestion on this one without his input because I don’t want to inadvertently complicate things even more.