Fix randomresized params flaky

[fmassa]

Fixes #1170

The flakiness is due to the rounding in

vision/torchvision/transforms/transforms.py

Lines 645 to 646 in 5537790

	w = int(round(math.sqrt(target_area * aspect_ratio)))
	h = int(round(math.sqrt(target_area / aspect_ratio)))

We are guaranteed that the floating point values for the dimensions gives an aspect ratio between the requested range, but after rounding this doesn't hold anymore.

One possible fix would be to re-check that this is still the case after rounding in

vision/torchvision/transforms/transforms.py

Line 648 in 5537790

if w <= img.size[0] and h <= img.size[1]:

similar to what was done in #1181, but this won't guard us from going outside of the requested aspect ratio in the fallback implementation in

vision/torchvision/transforms/transforms.py

Lines 653 to 665 in 5537790

	# Fallback to central crop
	in_ratio = img.size[0] / img.size[1]
	if (in_ratio < min(ratio)):
	w = img.size[0]
	h = int(round(w / min(ratio)))
	elif (in_ratio > max(ratio)):
	h = img.size[1]
	w = int(round(h * max(ratio)))
	else: # whole image
	w = img.size[0]
	h = img.size[1]
	i = (img.size[1] - h) // 2
	j = (img.size[0] - w) // 2

Given that for arbitrary values of scale, ratio and sizes there is no guarantee that there exists an integer value that satisfies all the constraints, I decided instead to keep the implementation the same, but to increase the minimum scale that is allowed during the tests, so that rounding differences are amortized, and tests passes much more often.

The only fix that is done in the transforms here is to avoid empty-sized dimensions to be returned, which was a problem with the previous implementation.

[lw]

Ok for a mitigation, could be reworked some more to make it more robust.