coco_url field for images/video?

[csbrown-noaa]

It looks like the COCO Spec has a coco_url field for images. This interfaces nicely with the reference pycocotools implementation's .download() method, which fetches the file from the coco_url and saves it locally to the file_name. It looks as though the kwcoco schema does not have a coco_url field on the image type? This is somewhat unfortunate, because a URL permits one to unambiguously and uniquely define a single file (even if the file_names conflict, for example). It is also useful for video streams that may not live locally, but exist as a stream over the internet. Also, for non-local processing environments (e.g. for prediction-as-a-service setups) where, say, data are defined by their location in a cloud environment rather than a local file path.

Is there hope for supporting a coco_url field for images and video to preserve compatibility with COCO format, and to empower non-local computing?

[Erotemic]

URL permits one to unambiguously and uniquely define a single file

While it does give you an endpoint, I want to warn you that it's not unambiguous as URLs can and do rot. There also isn't a mechanism that ensures what you asked for is what you got.

The schema allows for any field to be given, so adding a coco_url field won't prevent anything from working, and there is an internal method _ensure_image_data that does go and grab the data if it can.

I'm open to wider support of the feature though. It's a good idea to be able to store a remote reference to larger data.

It might be interesting to support the idea of "mirrors" or "remote-reference" that gives a list of places you might look for the data as well as a sha256 hash to check that the data you asked for is the data you get. I'd also be interested in adding support for content addressable storage like bittorrent magnet URLs or IPFS addresses.

[csbrown-noaa]

it's not unambiguous as URLs can and do rot.

Agreed that it's not guaranteed, but it's at least unambiguous. A leaf file_name of example.jpg may be any number of distinct images, but https://kitware.com/example.jpg is <=1 thing at any given time.

Checked out _ensure_image_data. It seems to reference a url field which is neither in the original COCO spec nor in the kwcoco schema. It seems a bit odd that the kwcoco reference implementation would support a specific undocumented extension of the standard.

In any case, we can go ahead, I agree that the standard supports arbitrary extensions, so we can design our implementation around using a coco_url field. I'm just scared to go forking things willy-nilly, yeah? :)

[Erotemic]

It seems a bit odd that the kwcoco reference implementation would support a specific undocumented extension of the standard.

It was likely an initial experiment in the direction of the coco_url, and I bet I didn't like that there was a coco_url and a flickr_url, so I put in a generic url (You'll note that if that isn't given it falls back to coco_url), but then never made anything public because I never finished the feature.

I can add official support for coco_url as a backward compatibility measure, and have the validator ensure you don't put some non-url like thing in there. That's not a hard lift on my end.

[Erotemic]

I pushed up a PR here with the feature if you want to check if that meets your needs: https://gitlab.kitware.com/computer-vision/kwcoco/-/merge_requests/117

[csbrown-noaa]

It's on the schema reference, so that's +100 for me. Thanks! ❤️