DynAIkonTrap issueshttp://gitlab.dynaikon.com/dynaikontrap/dynaikontrap/-/issues2021-12-08T12:15:04Zhttp://gitlab.dynaikon.com/dynaikontrap/dynaikontrap/-/issues/12Retrain SSDLite TFlite models on 320x320 input size data2021-12-08T12:15:04ZRoss GardinerRetrain SSDLite TFlite models on 320x320 input size data
### Summary
Picamera requires that output images must be sized in a multiple of 32. This was not known when model input size was fixed at 300x300px. This creates some messyness.
### Necessity/problem to solve
As a result, a hack is ...
### Summary
Picamera requires that output images must be sized in a multiple of 32. This was not known when model input size was fixed at 300x300px. This creates some messyness.
### Necessity/problem to solve
As a result, a hack is used to size the saved raw data to 320x320px, and then scale down before inference. This is needless extra compute for every raw frame, takes up more disk space than is required and is generally messy.
### Details
An attempt has been made to simply resize the input of the model before quantisation. However, this has resulted in precision/recall loss when compared with the original.
### Expected effort
The proper fix to this is to re-train SSDLite Mobilenet v2 models with an input buffer sized 320x320. This should create a model with the correct input buffer size, without as much accuracy loss.
**Person hours**:
I suspect this would take a couple of days
**Difficulty**:
Not too difficult if TF OD API is set up.
### I could work on this
Yes, I intend to at some point in the future.Ross GardinerRoss Gardinerhttp://gitlab.dynaikon.com/dynaikontrap/dynaikontrap/-/issues/11Don't distirbute JSON with trap code2021-08-30T13:15:06ZMiklas RiechmannDon't distirbute JSON with trap code<!---
Please read this!
Use this template if you have a suggestion to improve the project.
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "suggestion" label:
https://gitlab.dynaikon.com/...<!---
Please read this!
Use this template if you have a suggestion to improve the project.
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "suggestion" label:
https://gitlab.dynaikon.com/c4c/dynaikontrap/issues?label_name%5B%5D=suggestion
and verify the issue you're about to submit isn't a duplicate.
--->
### Summary
Don't distribute a default settings.json with our code. The system loads defaults anyway.
### Necessity/problem to solve
Changes between versions (new fields/functionality) meant we had introduced a `"version"` field to the JSON to verify the JSON will be compatible between camera trap versions. The problem is that this means every update requires us to maintain the version field in the JSON. If we forget to do this, it would result in the default JSON that not working with the current code version (an error/warning is displayed and default values used instead).
### Details
I would suggest simply removing the JSON from the repo to reduce overheads for us and reduce the risk of a non-functioning default system. This means users can generate a JSON if they want to modify settings. If they want to keep their custom settings between versions they would need to regenerate the file with the newest tuner.py (as would be the case anyway). The difference is that we can't accidentally provide an "incompatible" JSON due to an incorrect `"version"` field.
This could be followed up at some point with an updated tuner.py that handles old settings.json files and tries to use them with the newest version.
### Expected effort
<!-- Use the following two headings to indicate effort needed. Type "-" for each if you aren't able to estimate this -->
**Person hours**:
<1
**Difficulty**:
Easy -- remove a file
### I could work on this
YesMiklas RiechmannMiklas Riechmann