A bug feedback about assertions (Level: warning)

[name-used]

edition: mmdet v3.3.0， Version hash code: af063a6
Location: mmdet.datasets.transforms.geometric.py:: line 85-93
contents:

assert isinstance(min_mag, float), \
    f'min_mag should be type float, got {type(min_mag)}.'
assert isinstance(max_mag, float), \
    f'max_mag should be type float, got {type(max_mag)}.'
assert min_mag <= max_mag, \
    f'min_mag should smaller than max_mag, ' \
    f'got min_mag={min_mag} and max_mag={max_mag}'
assert isinstance(reversal_prob, float), \
    f'reversal_prob should be type float, got {type(max_mag)}.'

Problem: Harsh and incorrect assertions

In the assertion here, min_mag, max_mag, and reversar_probe logically belong to floating-point numbers.
But in practical use, passing integers should also be allowed.
For example, reversar_probe can allow passing 0 or 1.
However, assertion will be failed as "isinstance(int(x), float) is False".
In addition, the assertion error message on line 93 uses type (max_mag) instead of type (reversar_probe)

[name-used]

Another bug (Level: error)
edition: mmdet v3.3.0， Version hash code: b98f372
Location: mmdet.datasets.transforms.transforms.py:: line 3148-3157
content:

# Paste source objects to destination image directly
img = dst_img * (1 - composed_mask[..., np.newaxis]
) + src_img * composed_mask[..., np.newaxis]
bboxes = src_bboxes.cat([updated_dst_bboxes[valid_inds], src_bboxes])
labels = np.concatenate([dst_labels[valid_inds], src_labels])
masks = np.concatenate(
[updated_dst_masks.masks[valid_inds], src_masks.masks])
ignore_flags = np.concatenate(
[dst_ignore_flags[valid_inds], src_ignore_flags])

dst_results['img'] = img

the variable composed_mask comes from np.where which returns dtype np.int64
but image usually use dtype np.uint8
after calculate at line: 3148, the dtype of variable img becomes np.int64 too
and then, there are errors in post_process such as Resize ——
mmcv.image.geometric.py:: line 119 use cv2.resize which cannot deal with dtype np.int64

what's more, Exception indication is not clear enough for debug
It will be better if every Exception raised within transform-pipeline could show relationship to its config item.