Future of repository

[jdrakes]

@SixK I wanted to reach out and see what your plans are for this project? I am very interested in using this code and am willing to help maintain the code based on your goals.

[SixK]

Hi Jdrakes,

I have no particular plan, my main goal is to get at least the same features than original JsBroks coco-annotator code.
I just wanted to make it more maintenable using recent libraries.
There is still few bugs remaining, some features like pinch or watchdog that have been removed and could be nice to reintroduce.

We can imagine:

• to modernize html design
• Optimize docker images to make them more slim (specially AI docker image that take about 23Go !).
• Make docker images more modular (specially for AI docker image)
• Find better auto segment tools than SAM, SAM2 and Zim (if better tools exists).
• Add possibility to segment image using Yolo framework (or any other framework. I've already added this possibility with Detectron2, but it probably don't work anymore with actual docker images)
• Add features like substract segmentation masks from SAM (Coco-annotator already do this for some tools using Ctrl+Shift key combination if my memory is good)
• Use LLM for segmentation

I'm open to any improvements and any help is welcome.

[jdrakes]

How much time and resources do you plan to commit to this project? I ask because my team likes the ideas you have put together, and we want to make the code more production ready. We want to introduce the following:

• formatting (backend, frontend)
• linting
• replace flask with Fast API
• Update the Dockerfiles to be more performant (read as smaller and composable)
• Update the VUE code to leverage components in the architecture
• Etc

Do you plan on having fast turnaround on PRs we put up? Would you prefer we come on as assistant maintainers?

[SixK]

I'll spend time on this project as long there is things to do and I have no other priority projects.

I approve all things you listed,
I will only be reserved on Fast API cause of async/wait logic.
I seen someone already converted JsBroks coco-annotator backend to Fast API (coco-annotator fastapi) and I had a reflection on trying to integrate it or not, but I feared it to be too much pain and Flask is one of the most used and supported backend.

For fast PR, It will depend on PR.
For most of them I will probably integrate rapidly.
Major changes may need more reflection.
It's actually the case with actual ntjess PR (#12), I like the idea to make docker-compose more modular, but I dislike the idea to make containers more complicated to start (docker-compose -f docker-compose.yml -f docker-compose.dev.yml up).
I planed to try this PR during holidays at end of week.

[jdrakes]

What are the reservations about Fast API and the async/await?

[SixK]

It's just the fact that await implies async that implies await... and async.
Asynchronous may also cause some race conditions errors that are hard to solve.

To the other side, Fast API is said fast due to asynchronous and may simplify some code (not sure about this, but it should).

[jdrakes]

I see, I will mull over your responses.

what does IA mean in relation to this codebase?

[SixK]

IA (in french) or AI (in english) is for Artificiel Intelligence. This is mainly some unsupervised models like Sam, Sam2 or Zim. But also some models like DETR or RCNN. I also added a framework like Detrectron2, but in this case model is based on classes. This can be usefull to train a model and reuse it to label new images to improve model. I could also add something like yolo... But Sam, Sam2 and Zim are probable best tools to segment objects. I could also try to add an LLM like ollama, but I don't know if it would be usable.

[ntjess]

@SixK thanks for your feedback.

After looking through the codebase we are very excited with the ideas you have extended from the original coco-annotator and placed on your roadmap. There is great overlap with products we are building at our company, and this would provide a better starting point for an open-source version than S3A, which is our current open annotator (desktop only). Feel free to can scan the changes we made in our clone. Implemented updates include:

• Improved the compose process beyond Simplify docker-compose logic #12
• Significantly improved the Dockerfile setup -- now only 2 images exist (backend & frontend), no build_base_image.sh is needed, and multistage builds produce much smaller container sizes with no code duplication
• Removed 5+ year old segmentation models in favor of newer sam2/zim options
• Began modularizing the frontend code to reduce duplication

We're happy to provide you maintainer access if you're interested! We are planning additional improvements such as hardening the codebase, providing more devops-friendly features, reducing the pre-existing linter errors from the original coco-annotator project, and other items from this thread (all under the same OSS Apache 2 license).

[SixK]

Thank's, I have to spend time to test adumbra project.

At first look, I see a great project reorganization.
README.md need more informations.
Code has been cleaned up.
Dialogs (Modals) has been separated. (great idea).
There is probably more things I don't have seen yet.

Really good job, I have to see how to contribute.
Regarding my code, there is probably still lot of improvements to do.
Moving from vue2 to vue3.4+ has not been an easy move.