kwcoco issueshttps://gitlab.kitware.com/computer-vision/kwcoco/-/issues2024-03-17T13:29:28-04:00https://gitlab.kitware.com/computer-vision/kwcoco/-/issues/2Annotations should be allowed to be stored in their own "space/view".2024-03-17T13:29:28-04:00Jon CrallAnnotations should be allowed to be stored in their own "space/view".@perri.akiva brought up an issue that if a mask is created that aligns with a "video", forcing the user to transform it to align with an "image" might cause artifacts in raster annotations.
Recall, there are 3 spaces that we are concern...@perri.akiva brought up an issue that if a mask is created that aligns with a "video", forcing the user to transform it to align with an "image" might cause artifacts in raster annotations.
Recall, there are 3 spaces that we are concerned with: "video-space", "image-space", and "auxiliary-space". Each auxiliary image contains a transform that warps it into "image-space". Each image contains the transform that warps it into "video-space".
A potential workaround might be to add a 4th "annotation-space" and each annotation can contain a "warp_ann_to_img" property (defaulting to the identity) that can be used to save annotations in any native coordinates, but preserve alignment with the rest of the data.1.0Jon CrallJon Crallhttps://gitlab.kitware.com/computer-vision/kwcoco/-/issues/3KWCoco grab should be expanded to include more datasets2021-06-18T21:04:42-04:00Jon CrallKWCoco grab should be expanded to include more datasets* It should be easy to access and reproduce experiments on standardized benchmarks.
* kwcoco grabdata should offer simple command line script to download the official (verify hashes) dataset and convert the dataset to kwcoco format.
* ...* It should be easy to access and reproduce experiments on standardized benchmarks.
* kwcoco grabdata should offer simple command line script to download the official (verify hashes) dataset and convert the dataset to kwcoco format.
* currently only cifar10, cifar100, and camvid. The VOC official download URL no longer works.
* should be kept up to date to combat link rot.
* The CLI help should enumerate available datasets, and how large the download and final size is estimate to be.
* Good next datasets: coco, imagenet, torchvision.datasets1.0https://gitlab.kitware.com/computer-vision/kwcoco/-/issues/5Sqlite + Postgress SQLAlchemy backend and optimizations2023-10-04T11:48:33-04:00Jon CrallSqlite + Postgress SQLAlchemy backend and optimizationsThe current coco_sql_dataset is an experimental SQL backend using sqlalchemy and custom sqlite3 in certain places.
The custom sqlite3 makes the speed manageable when performing very large searches on coco datasets.
It would be good to ...The current coco_sql_dataset is an experimental SQL backend using sqlalchemy and custom sqlite3 in certain places.
The custom sqlite3 makes the speed manageable when performing very large searches on coco datasets.
It would be good to make an alternative pure sqlalchemy version and support a postgress backend.
It would be good to improve the read-only cache mechanism, and also allow the sql dataset to serve as the main data.kwcoco.sqlite file in a kwcoco bundle directory.
Eventually write support and conversion back to the dictionary form would be good to have.
This may involve optimization of the hacky table structure I currently have setup.1.0Jon CrallJon Crallhttps://gitlab.kitware.com/computer-vision/kwcoco/-/issues/6Feature: Sharding2022-01-18T10:50:23-05:00Jon CrallFeature: ShardingOne strategy for handling larger datasets or distributed datasets would be sharding. We already have a method for doing a union of two kwcoco files, it would be useful if there was a mechanism to store data for a single dataset across mu...One strategy for handling larger datasets or distributed datasets would be sharding. We already have a method for doing a union of two kwcoco files, it would be useful if there was a mechanism to store data for a single dataset across multiple files, i.e. one or more files for all of the images, and then one ore more file for each annotations. In the limit, we could have one annotation file per image. One challenge is that annotations need to reference images and category ids. We would either need to duplicate image / category information or provide a way to reference it.Jon CrallJon Crallhttps://gitlab.kitware.com/computer-vision/kwcoco/-/issues/7Annotation Keyframes2022-08-19T11:43:15-04:00Jon CrallAnnotation KeyframesThe current annotation format is redundant and inefficient for video processing. Annotations are often duplicated in every frame of a video. It would be better to incorporate the idea that two annotations in a track should be interpolate...The current annotation format is redundant and inefficient for video processing. Annotations are often duplicated in every frame of a video. It would be better to incorporate the idea that two annotations in a track should be interpolated between two keyframes.Jon CrallJon Crallhttps://gitlab.kitware.com/computer-vision/kwcoco/-/issues/11Termonology: Space -> View?2024-03-15T22:26:30-04:00Jon CrallTermonology: Space -> View?The original terminology for a resolution and alignment of an asset / image / video was "space", and it is used in many places. However the term "view" might be more intuitive. I'm opening this issue for discussion on this and other term...The original terminology for a resolution and alignment of an asset / image / video was "space", and it is used in many places. However the term "view" might be more intuitive. I'm opening this issue for discussion on this and other termonology issues. I would like it to be the case that the terms in the code match the terms in the prose.https://gitlab.kitware.com/computer-vision/kwcoco/-/issues/12Track-ID Refactor2024-03-15T22:32:06-04:00Jon CrallTrack-ID RefactorThe track table didn't always exist, and a track used to just be a `"track_id": str` as part of an annoation dict. This means there are lots of kwcoco files out there that have track name as its internal "id". This makes the SQL view dif...The track table didn't always exist, and a track used to just be a `"track_id": str` as part of an annoation dict. This means there are lots of kwcoco files out there that have track name as its internal "id". This makes the SQL view difficult to use. We want all internal ids to be integers for efficiency.
We need a tool to convert old-track styles to the new style where there is a track dictionary with a `{"id": int, "name": str}`, and each annotation has `"track_id": int`. If it was quick to check we could run it on demand.
After we are sure that we can assume the old-style track-id can't get into critical sections of code, we need to remove workarounds that have been added to aid in the migration, or at least the ones with significant overhead.