Rename package suggestion

[stemann]

Hi

We are trying to get an object detection interface package registered: https://github.com/IHPSystems/ObjectDetectors.jl

We will shortly also be pushing and registering implementations of ObjectDetectors, e.g. DetectronObjectDetectors, TensorFlowObjectDetectors (that PyCall to FAIRs Detectron and TF OD API).

Would you mind renaming this package to be more specific to its actual implementation (YOLO (YOLOv3) trained on COCO implemented with Flux) ? E.g. YoloFluxObjectDetector(s)?

Best regards,
Jesper

[r3tex]

Nice initiative! Although you could just have made PR to this repo and added more architectures. :)
There are quite a few industrial applications using this package right now so we don't want to change names too quickly. Looking forward to seeing what your initiative is building.

[IanButterworth]

I second @r3tex's comments. Renaming this package isn't an option because of industrial use, and indeed, this package was set up to be algorithm agnostic.

Would you consider PR-ing those methods to this repo? Seems like exciting work!

[stemann]

I completely agree that it is too soon to rename this package - there's a lot more functionality for the end user here right now.

The aim in ObjectDetectors is to make it easy to swap out object detector implementations - being purely an interface for detectors and representing detections (sort of what datumaro does for CVAT). The code in ObjectDetectors is quite bad right now - we have an update coming shortly (too).

The hope is that it will be easy to compare SoTA detectors in the large Python frameworks with e.g. object detection in Flux (e.g. this package) - and have Julia/Flux implementations come out on top, of course :-)

I think it would bloat this package to add PyCall-dependencies (which in turn would be dependent on env./container with python, PyTorch, detectron etc.).

Very excited to hear that there are industrial applications of this package (don't hesitate to elaborate in a DM :-)

[IanButterworth]

The aim in ObjectDetectors is to make it easy to swap out object detector implementations

That's the same aim for the architecture here. Note that yolo is in its own directory and module. Though because it's currently the only one in here, there may be unintentional breakages in that generalization.

I think it would bloat this package to add PyCall-dependencies

Agreed. To be honest, a single package covering all object detector types could get quite heavy. I'd be inclined to keep Flux implementations together here, as that wouldn't increase load time

Perhaps it's worth highlighting all the object detection packages in the ecosystem that I know of, and their various backends

• https://github.com/r3tex/ObjectDetector.jl (YOLO v3 in Flux)
• https://github.com/IanButterworth/YOLO.jl (YOLO v2 in Knet)
• https://github.com/IanButterworth/Darknet.jl (Lib wrapper for AlexeyAB's yolo fork, needs updating as v4 was just released on that fork)
• https://github.com/benjaminwsebastian/MaskRCNN.jl (Knet, seems abandoned)
• https://github.com/DhairyaLGandhi/maskrcnn (Flux, not a package yet)

[stemann]

First of all - thank you both for responding swiftly and openly.

And sorry again for the naming clash: We have been using ObjectDetectors (named Detectors) in that form since 2018 - also in a number of industrial applications.

I think the aim of ObjectDetectors is a little different: The aim is to only provide a generic interface - and not provide any (real) implementations. As a consequence ObjectDetectors can have fewer dependencies - not even relying on Flux - there's nothing neural network about the ObjectDetectors package. Right now, it looks like the package will only rely on GeometryBasics.

The aim is only to provide representation of detectors and detections - to enable easy comparison and integration of different implementations.

Usage example - on its own - with the included dummy/static detector implementation:

using ObjectDetectors

static_detector = StaticObjectDetector{BoundingBoxDetection}(BoundingBoxDetection(0, 0, 4, 3))
detections = detect(image, static_detector) # detections will be a Vector{BoundingBoxDetection} with one element: BoundingBoxDetection(0, 0, 4, 3)

In combination with this package (e.g. renamed to FluxObjectDetectors and modified to implement a generic interface):

using ObjectDetectors
using FluxObjectDetectors

yolo_flux_detector = YOLO.v3_608_COCO(batch=1, silent=true)
detections = detect(image, yolo_flux_detector) 

These are some of the types to be provided and their hierarchy:

graph TD

BoundingBoxDetection --> AbstractObjectDetection
RotatedBoundingBoxDetection --> AbstractObjectDetection
PolygonDetection --> AbstractObjectDetection

AbstractBoundingBoxDetector --> AbstractObjectDetector
StaticObjectDetector --> AbstractObjectDetector

And thank you for the list - didn't know the last two.

There's also ObjectDetectionStats.

[giordano]

We will shortly also be pushing and registering implementations of ObjectDetectors, e.g. DetectronObjectDetectors, TensorFlowObjectDetectors (that PyCall to FAIRs Detectron and TF OD API).

Would you mind renaming this package...

I'm not sure what you're trying to accomplish, but renaming a package doesn't remove it from the registry. Packages can't simply be removed from the registry, renaming technically means to create a new package, which happens to have the same functionalities as the older one, but the older name is not removed.

[stemann]

We will shortly also be pushing and registering implementations of ObjectDetectors, e.g. DetectronObjectDetectors, TensorFlowObjectDetectors (that PyCall to FAIRs Detectron and TF OD API).
Would you mind renaming this package...

I'm not sure what you're trying to accomplish, but renaming a package doesn't remove it from the registry. Packages can't simply be removed from the registry, renaming technically means to create a new package, which happens to have the same functionalities as the older one, but the older name is not removed.

@giordano Ah - yeah, that's right; I was focused on the rename functionality of Pkg(3) where a rename is possible given that the UUID is kept. But I see the concern for the ecosystem wrt. package renames in the General registry.

For the sake of argument: What to do in such a case? If there was a compelling argument for renaming a package in the General registry? (if we assume we actually get some solid code pushed to https://github.com/IHPSystems/ObjectDetectors.jl ? We would not be able to register our other object detection packages without getting ObjectDetectors registered:

• Object Detection XML IO (XML readers/writers)
• Object Detection YAML Data Sets (reading/writing YAML-defined data sets for object detection)

[stemann]

Renamed ObjectDetectors to ImageAnnotations.