[FEATURE] Accept kwcoco as input/output

[Erotemic]

trafficstars

Is your feature request related to a problem? If so, Please describe.

I'd like to use a local install of dive to visualize and annotate my datasets. These are typically stored in the kwcoco format.

Describe the solution you'd like

I'd like to be able to point to a kwcoco file and ingest it, annotate or modify the data and then export to a kwcoco file.

Describe alternatives you've considered

Converting to CSV and then uploading, but I'd rather not.

Additional context

The docs aren't as pretty as DIVE, but I do think the format is superior to anything else out there on the market as a static dataset transport.

https://gitlab.kitware.com/computer-vision/kwcoco

I've cloned and am installing DIVE. I'm going to see how easy it might be for me to add this feature. I'd like to understand this codebase better.

[Erotemic]

Also, I've been taking notes and building up general feedback as I learn how to use this tool. Overall, its really slick! The responsiveness and visuals are great! The interface is usable, but I have a few notes:

https://github.com/Kitware/dive/pull/1090/files#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5

[subdavis]

hey Jon, we'd like to have this too! Here's a couple questions that might help clarify this ask.

• Are you asking about web, desktop, or both? Web (the thing you get with docker-compose) already supports kwcoco import (but not export). The Electron desktop client does not. Based on your pull request, it looks like you're using web, so I think this may just be a case where it wasn't clear how to use KWCOCO with your data. Maybe you can help us make it more clear.
• I agree KWCoco is a nice format to work with. We have particular needs for this tool which prevents us from making it the de-facto standard, but first-class support on both platforms would be great.
• Here's our data format documentation if you haven't seen it: https://kitware.github.io/dive/DataFormats/#coco-and-kwcoco

I'm glad you're interested in using DIVE. Perhaps we could meet sometime to explain the current state of kwcoco support, making the UI more intuitive, and what your needs are.

Also, fwiw, I don't think the approach in Upload.vue is quite the right way to go.

Installing a development instance on the local machine (in a way that ideally allows real-time hacking)

• Server development docs (hot reload) https://github.com/Kitware/dive/tree/main/server
• Client development docs (hot reload) https://github.com/Kitware/dive/tree/main/client

How to ingest a dataset (ideally you can either drag/drop a kwcoco file, a directory of images, a selection of images files), or point to it via a local path on the interface.

This will differ between web and desktop because browsers are limited in how they're allowed to interact with the filesystem, mostly for security reasons.

https://kitware.github.io/dive/Web-Version/#uploading-data is the docs, but I agree they could be more clear.

[Erotemic]

• I'm mainly interested in some local "development" variant. If that is a desktop app, or a local service I run on localhost, it doesn't matter. I was using the docker-compose method of running a server and then using chrome to interact with it.

• All I care about is that it is easy to import / export. The format is not designed for use as a live read/write backend, so I wouldn't expect a responsive application to work with it natively. However, if you have a computer-vision use-case that the kwcoco spec doesn't support, then we should talk about extending kwcoco so there is always a 1-to-1 between what DIVE and kwcoco can handle - and that may include DIVE-specific non-schema properties, which kwcoco is designed for.

I think a meeting would be productive.

The notes I made on usability was based on trying to use the program without reading the docs first. The current design makes it fairly easy to intuit how to use the system without spending time reading documentation (users love when they don't have to read the docs), but I think there are minor tweaks that could make it easier (plus minus technical constraints).

I have no doubt that my approach to JS is wrong. I'm a fish out of water in that world. In the meeting I'm hoping I can get some help figuring out the most effective way to start hacking on this.