Feature/sg 729 abstract cocodataset

[Louis-Dupont]

Abstracting Coco dataset.
Changes bewteen the coco and its abstraction:

• init parameters have different names (they also represent different things)

[dagshub]

Join the discussion on DagsHub!

[BloodAxe]

LGTM.

But I also wanted to leave my 5 cents here:

I think at some point we would need to make something DatasetReader class with logic to parse a dataset in whatever format into List of samples and use that to instantiate dataset classes. What I mean is this:

class COCODetectionDatasetReader:
  def __init__(images_dir, annotation_file, with_crowd, ...):
       ...
  
  def load_samples() -> List[DetectionSample]:
       ...

reader = COCODetectionDatasetReader(...)
samples = reader.load_samples()
dataset = DetectionDataset(samples, transforms)

So the idea is DetectionDataset has zero knowledge about where the data is coming from. E.g instead of sub classing we use composition, which is more flexible:

reader = COCODetectionDatasetReader(...)
reader = PascalVOCDetectionDatasetReader(...)
reader = DetectionDatasetReader(...)

And DetectionSample to provide all necessary information for a single image sample:

@dataclass
class DetectionSample
   image_path: str
   bboxes: np.ndarray # [N, 4] in XYXY format
   labels: np.ndarray # [N]
   is_crowd: np.ndarray # [N]      

Note, let's say for some customer we have to have additional label attached to bbox. No problem:

@dataclass
class CustomerSpecificDetectionSample(DetectionSample):
   additional_property: np.ndarray # [N]


class CustomerSpecificDetectionDatasetReader:
  def load_samples() -> List[CustomerSpecificDetectionSample]:
       ...

I realize this is much of work and def. goes out of the scope of this PR.
So this is more to raise an awareness and suggest this for future sprints.

[Louis-Dupont]

It sounds like a great idea, I guess that we could also make it so that load_samples would be a generator to provide an option not to cache labels.