I’m in the process of analysing 10 years worth of trailcam images in batches where the original data is stored in the following folder structure:
Reserve Name
Year (separate Project per year)
Station1 (approximately 40 stations per year, translating to “Sites” and “Deployments” in AddaxAI project, and most stations have 2 cameras taking images from both sides of target area. Between 1500 and 4500 images per station)
Camera1
Camera2
For some years the images do NOT include date and time taken info in their EXIF info. I processes several deployments, including checking labels and correcting as needed without time data - several days of manual review and verification.
BUT I then found a source .csv file containing date and time taken info per image. I can add this info back into the image files’ EXIF info, but the question is how can this then be reprocessed in AddaxAI without destroying all the analysis and verification work already done?
Question: Is AddaxAI capable of adding time data to images (either by rereading from EXIF, or via file upload) after their labels have been analysed and verified without having to start from scratch?
How will this also impact Counts and any results exported - can these then be updated again?
Thanks for your question. It looks like a nicely formatted dataset!
First thing I want to be clear on is that AddaxAI never edits your original images or videos. It only reads them. It can apply time offset to deployments inside AddaxAI, but that is just what gets wrttten to the database. Nothing changes your original images. That is AddaxAI rule and I would not dare to touch anyones original images.
Secondly, there is no way to pick up new capture times afterwards. The time is read once, when the files go into the database, and there is no feature to refresh it later. Reprocessing does read the new EXIF, but it deletes the old deployment first, and your verifications go with it. The files without a date are each put into their own event, which over counts animals when there are several images of the same individual, and you have no trap nights either.
What I would do is make sure all your images have the proper date and time in their EXIF (tag: DateTimeOriginal), and then reprocess them. I’m not sure how you analysed all the deployments (one at a time or all at once). That determines wehat AddaxAI thinks is a deployment (see: ). If you do not have all the deployments listed as individual deployments, you can split them using the split feature: Build a project | AddaxAI. Splitting is safe. It only moves the files to the new deployments, so your labels and verifications stay.
Then once you have all your deployments nicely ordered as deployments in AddaxAI deployments table, you can delete only the ones that lack the EXIF. Then use any of the EXIF tools below to add the proper EXIF, and then reprocess only the ones you have removed before. That will give you a nice and clear AddaxAI project with all the proper date times and metadata.
You can use any of the following tools for EXIF editing:
So: remove the faulty deployments only, write the times into the EXIF, then process those folders again.
For any future deployments, make sure the dates are right before you analyse. Add each camera folder as its own deployment rather than the whole year at once, then AddaxAI warns you per camera when it finds files without a date.
Counts and exports come from the database, so they are right again automatically.
I appologize for the late reply, but thanks for all the details!
Looks like I’ll have to scrap all analysis and classification work done so far and restart after I’ve updated my original images to include DateTimeOriginal info (I’ve used Exiftools in the past so technically trivial, but functionally a time consuming process to do).
But documentation also mentions “Put the time in the filename. End the name with addaxai-YYYYMMDD-HHMMSS before the extension, for example clip_addaxai-20250222-072314.mp4. AddaxAI reads the time from the name“ - is this still a supported option in latest version, or only EXIF reading?
As for processing: I used the upload function to load a list of sites, then uploaded deployments - both corresponding to my “Stationxx” folders. Uploading from CSV is a really useful feature an saves a lot of time! Adding each Deployment to the analysis queue is then very easy and error free and allows for running overnight…
Adding the ability to mass delete deployments (multi select on the Deployment screen) would be a high priority future enhancement request in my opinion - deleting them one by one is extremely time consuming.
Adding a feature to update time after initial analysis would be a very nice option to add to your (already very long!) feature development list
And just to be clear - all my rework is NOT because of AddaxAI bugs, design or other issues, but rather because of my apparent inability to read instructions and follow the documented process My issues are related to how I interpreted the system to work, not because of how it was designed to work. Keep up the great work!
No worries about the delay, and yes, that is the right plan: Write DateTimeOriginal into the files with exiftool, delete only the deployments that had no dates, and add those folders again. The rest of your verification work stays as it is.
The filename option still works in the latest version, for photos and videos. AddaxAI first looks at the date in the file itself, and only when it finds nothing there it reads the addaxai-YYYYMMDD-HHMMSS part of the filename. So for your years without EXIF it will be used. I would still go for exiftool if you can, then the date sits in the file and every other tool reads it too, where the filename trick is something only AddaxAI understands. Both are described here: Dates, times and timezones | AddaxAI
Good to hear the CSV import for sites and deployments works well for you. Deleting deployments in bulk is a fair request, at the moment it’s one at a time. I have put it on the list. Updating the times after the analysis is on the list too, but that one is bigger and further away, so for now fixing the files first stays the way.
This is exactly the kind of feedback that makes the app better. Thanks for that.
