Fix issue in refine_bboxes and add doctest

[Erotemic]

The BBoxHead.refine_boxes function was failing in cases where there is only a single roi in an image. When this happened the squeeze function removed all dimensions of the tensor and it became a scalar. This caused issues when trying to index into the rois tensor because it did not keep its two dimensional shape and that cause an assertion to fail in regress_by_class.

This issue is fixed by specifying that we are squeezing over dimension 1. This prevents the 0-th dimension from collapsing and guarantees that rois keeps its 2d shape.

Also while I was in this function I noticed the assertion:

        img_ids = rois[:, 0].long().unique(sorted=True)
        assert img_ids.numel() == len(img_metas)

this will fail if in the corner case where an image doesn't have an roi. Changing the == to a <= fixes this problem. I tested for this case and the rest of the logic works fine.

Speaking of test cases I added a doctest for this function so I could debug it. I was having a difficult time running it without the functions in Kitware's kwarray and kwimage vision utility libraries. I added simple versions of the kwimage.Boxes.random and kwarray.ensure_rng functions in a new file mmdet/core/bbox/demodata.py. These functions let a developer generate random valid bounding boxes, which is very useful for writing tests (and sometimes algorithms!).

Lastly when constructing pos_is_gts for the test, I ran into an issue where I really needed the kwarray.group_items function. I didn't want to simply dump that function in this file or the demodata file. So I simply used it and added a # xdoctest: +REQUIRES(module:kwarray) to the doctests, so it wont run unless that module exists.

I could port that code to a utility library here to avoid the dependency on kwarray, but I'm not sure where it goes. Alternatively, kwarray is a pure-python pip installable module, so it's not the end of the world if its added as a dependency.

[hellock]

Did you intend random(num, scale, rng)?

[Erotemic]

I did yes. Fixing.

[hellock]

As a temporary solution, kwarrary can be added as a test-time dependency in tests/requirements.txt.
For future usage except for unittests, I suggest porting it to mmcv.

[hellock]

torch.from_numpy(tlbr) would be better.

[Erotemic]

Are they not equivalent in this case? The numpy array is already a float32, so there shouldn't be any difference in calling FloatTensor vs from_numpy. Am I understanding this wrong? I'm basing my understanding on this thread: https://stackoverflow.com/questions/48482787/pytorch-memory-model-torch-from-numpy-vs-torch-tensor

[hellock]

from_numpy() avoids the data copy. BTW, Torch.FloatTensor(input) less preferred than the new api torch.tensor(input) in new versions of pytorch.

[Erotemic]

Good to know, thanks for the info!

[Erotemic]

The latest push should fix the issues in the test. I also added a unittest variant of the doctest as well. The unit test is more comprehensive and tests multiple values of n_rois and n_imgs. I also ensured that all randomness was seeded in the unit-test variant so chances that cause issues in the future will be easier to reproduce. The doctest variant still contains some non-determinism.