The bounding box x/y ordering returned by `detect_fn` is unacceptable

[TACIXAT]

For some reason it returns ymin, xmin, ymax, xmax. According to this poll [1] it should at least be xmin, ymin, xmax, ymax, and preferably xmin, xmax, ymin, ymax. I am not sure what maniac chose this ordering because I couldn't find the source after lazily searching for detection_boxes in this repository, but I'd like to see this code to understand what type of person would do this.

1. https://twitter.com/TACIXAT/status/1387972255460720641

[TACIXAT]

Further evidenced by other libraries following the x0, y0, x1, y1 convention -

https://pillow.readthedocs.io/en/stable/reference/ImageDraw.html?highlight=rectangle#PIL.ImageDraw.ImageDraw.rectangle

Is this insanity in Tensorflow even documented anywhere? I have only seen it unofficially documented in external package's code -

https://github.com/tensorflow/models/blob/master/research/object_detection/utils/visualization_utils.py#L1235

[UsharaniPagadala]

@TACIXAT
Could you please have a look at this documentation if it helps. and also you can check this master on models for object detection.Thanks

[TACIXAT]

Ah yes, that is similar to the one I linked that shows the usage, but not the base format. I think this is a feature request for TF3, to change the API to return x first as is standard.