Hi PepperoniPingu ,
Thanks for the feedback, this is really useful. The reason behind switching this to required login / API key is that exports for RVC4 can take significantly longer due to potential quantization. In DepthAIv3, we also take care of some things for you such as abstracting shave settings for series 2 (= packaging this into the model itself and allowing DepthAI to choose the most optimal configuration for you). As a consequence, a simple page like before could result into timeouts with slightly larger models, which is why we decided to retain it only for DepthAIv2 and our Series 2 devices, while handling the exports as jobs in Hub AI and storing the models for you once conversion finishes. As a side benefit, we provide model management and allow model swapping in applications if you are using Hub (currently supported for OAK4 and will be exposed for OAK2 in the future) to allow for easier deployments. You can retain model management as is, but we can also share some early access API to our model management if you want to take advantage of it in case it would be helpful for you.
I tried the ModelConverter python API. It's good for the most part. Have two complaints: api key reqiuired, and, can't convert models with the same name twice. So I have to add a uuid to the model name.
Here, we would recommend using the same model name, and just naming the variant differently. We can streamline this by pre-populating a random name in case "model", "variant", or "instance" name is empty. Let's create a feature request in GitHub @KlemenSkrlj and link it here so it can be tracked, please. As for the API key, we will require this for the reasons above.
Maybe I should just switch to the local modelconverter docker instead, it doesn't seem like HubAI is aimed at my usecase. That would allow scripting the whole training + conversion.
You can, of course, switch to docker-based modelconverter, however, you have to manage the environment yourself. The purpose of HubAI is to abstract that, and expose both API and friendly UI, that helps you achieve what you need without having to use Docker. It sounds like we are not quite there yet on the UI and we are already brainstorming internally on how to simplify this based on your feedback. We are also open to any suggestions you may have on how to simplify it further.
I hope this gives some insights into architectural decisions we had to make, and helps you understand what we are aiming to achieve. Once again, thanks for the feedback, we really appreciate it!
