Icevision: Added Parsers for Common Data format

[oke-aditya]

🚀 Feature

It is difficult for beginners to write their own parsers. Also, the data format for most stuff is either COCO or PASCAL or similar templates.

Provide direct support for these through our Parsers. It makes it easier for both people to do write code and maintain code as it stays standard for both.

This makes it easier to use as well as makes it faster for people to quickly prototype and get their Dataset and dataloaders done.

[lgvaz]

Should we add parsers for examples we commonly use in the library?

I know I said before we don't want to have stuff like WheatParser in the library, but maybe it's a good idea? Worth discussing anyways

---

Maybe we can have a "hub" for parsers? Let me give you a high level analogy. People share notebooks for competitions on kaggle, so one of the first things you do when starting a new competition is to check notebooks, looking for snippets of code that loads the data, prepare transforms etc...

It would be cool if people could add their custom parsers to mantisshrimp directly, so other people could do something like from mantisshrimp.hub.parsers import WheatParser.

It has to be clear somehow that these should be maintained by other people and not from us, because for each dataset, they would be a custom parser.

It would be really great if something like this could happen. In some short time we would have a bunch of parsers for a bunch of very varied datasets, making it very very easy for beginners. Imagine if you're just starting out, and you find the airbus kaggle competition that happened some years ago, and all you have to do for starting exploring that is from mantisshrimp.hub.parsers import AirbusParser, or from mantisshrimp.hub.airbus import * because we can even provide default models and stuff.

This would also generate a bunch of example on how to use parsers, making it very likely that someone already handled a dataset that is at least similar to yours.

@oke-aditya, @ai-fast-track, @chho-work and @paras-jain I would love to hear your thoughts on this 😄

[oke-aditya]

Nice Idea. This could lead to quick and extensible data preprocessing. But again, it won't be maintained by us. This should be clear.

Only thing that we maintain is parser for common data formats.

[paras-jain]

Yes, we should only maintain parser for handling common data formats like COCO, PASCAL VOC and csv formats as mentioned by @oke-aditya.

[lgvaz]

I added a prototype for this in #89 , what do you all think?

I'm not sure that hub is the best place to put it, it's starts to confuse what is the purpose of hub. Is it use to add support to other libraries? Models? Datasets? Maybe everything at that's okay?

Another thing that bothers me is that this is inside the core library. That doesn't give the impression that this is community supported...

We want to make in a way that it's easier to get code into this than into the core library, we should not be so rigorous for quality of code regarding these extensions, for sure they don't need to be 100% tested like the rest of the library.

Should we make another library that only hosts community contributed stuff? I see other libraries trying to do this, but it never gets attention...

Uuugh, hard questions

[oke-aditya]

Hard Questions and hard choices. It should be like hub.models. hub.parsers, and then the list goes on.
Maybe if the community grows strong enough at some point we will decompose this library seperately as hub.

[lgvaz]

And we can also even provide pre-trained weights and experiments!

I believe wandb can be used for storing weights and run statistics.

[shimsan]

Parsers that support COCO and PASCAL JSON would definitely be an upgrade, and open the path to use many datasets that follow these standardized formats.

For example, right now, I have a dataset that I'm trying to parse, but I'm having to convert my COCO JSON to WheatParser CSV format because that is what the tutorial references.

[lgvaz]

Hello @shimsan, we actually implemented out of the box support for COCO and VOC (and forgot to close this issue 😅)

We actually need to provide a tutorial on how to use those parsers since they're so common, I'm going to open an issue on that, but for now, this is how you do it:

Let's say you load your annotations file as a dict:

annotations_dict = json.loads(Path(annotations.json").read())

Following COCO structure, inside this dict we have an images field with info about the images and a annotations field with the annotations themselves. You need to create a separate parser for each:

image_info_parser = datasets.coco.COCOImageInfoParser(infos=annotations_dict["images"], img_dir="path_to_images_dir")
annotations_parser = datasets.coco.COCOAnnotationParser(annotations=annotations_dict["annotations"])

And then combine them:

parser = CombinedParser(image_info_parser, annotations_parser)

You can then follow the rest of the steps normally

---

I know the whole process is a too verbose right now, I'm planing to add a helper function that combines all the steps to a single function call. But for now, I hope it's okay to use that 😃

---

I'm closing this issue because the proposed parsers are already implemented, feel free to open an issue if you have any further doubts!!

Happy coding!

[lgvaz]

@shimsan I just added the helper function, you can now do:

    parser = datasets.coco.parser(
        annotations_file="path_to_annotations.json",
        img_dir="path_to_images_dir",
    )