Fix UnderflowError in _try_rescale_float when maxVal == 0.

[nup002]

In ImageItem.py, an UnderflowError exception is thrown in _try_rescale_float by numpy.nextafter() if the histogram levels minVal and maxVal are both 0. This PR fixes the problem by instead setting maxVal to the machine precision if maxVal is 0.

Tested and verified to resolve the issue without introducing new ones.

[NilsNemitz]

I have a dumb question:
Is it actually intentional that the existing code moves maxval to the next more negative number when maxval is already < 0? That makes rng negative below, and that seems conceptually a little strange.

If the intention is to clamp rng to a small positive number, then wouldn't
maxVal = math.nextafter( minVal, math.inf )
be what we want? (under all variations of maxVal <0 / ==0 / > 0)

Additional comment:
if minVal and maxVal are just simple numbers, then there's probably no need to potentially invoke the cupy version of nextafter here. I suspect that nextafter from the math library should be enough.

[NilsNemitz]

This (pre-existing) line seems redundant if the code above works as intended. If it is indeed still needed, then there's a kind of problem that gets past the check minVal == maxVal... Possibly something originating from mixed or non-float datatypes?

Is the real thing we want to avoid float(maxval - minval) == 0 ? Then the most robust path might be to directly check that. Something like

rng = float(maxVal - minVal)
if rng == 0.:
   maxVal = math.nextafter( minVal, math.inf )
   rng = float(maxVal - minVal)

maybe?

[pijyoi]

The code chunk actually comes from functions::makeARGB():

pyqtgraph/pyqtgraph/functions.py

Lines 1441 to 1462 in 21391e0

	if isinstance(levels, xp.ndarray) and levels.ndim == 2:
	# we are going to rescale each channel independently
	if levels.shape[0] != data.shape[-1]:
	raise Exception("When rescaling multi-channel data, there must be the same number of levels as channels (data.shape[-1] == levels.shape[0])")
	newData = xp.empty(data.shape, dtype=int)
	for i in range(data.shape[-1]):
	minVal, maxVal = levels[i]
	if minVal == maxVal:
	maxVal = xp.nextafter(maxVal, 2*maxVal)
	rng = maxVal-minVal
	rng = 1 if rng == 0 else rng
	newData[...,i] = rescaleData(data[...,i], scale / rng, minVal, dtype=dtype)
	data = newData
	else:
	# Apply level scaling unless it would have no effect on the data
	minVal, maxVal = levels
	if minVal != 0 or maxVal != scale:
	if minVal == maxVal:
	maxVal = xp.nextafter(maxVal, 2*maxVal)
	rng = maxVal-minVal
	rng = 1 if rng == 0 else rng
	data = rescaleData(data, scale/rng, minVal, dtype=dtype)

Back then, the goal was to make the code behave the same as makeARGB().

I would replace it with the following:

minVal, maxVal = levels
# if minVal == maxVal:
#     maxVal = xp.nextafter(maxVal, 2*maxVal)
rng = maxVal - minVal
rng = 1 if rng == 0 else rng

The goal is simply to avoid a division by zero shortly after.

This simple pattern can be found in:

1. pyqtgraph/pyqtgraph/graphicsItems/NonUniformImage.py

   Lines 123 to 129 in 21391e0

   	# normalize and quantize
   	mn, mx = self.getLevels()
   	rng = mx - mn
   	if rng == 0:
   	rng = 1
   	scale = len(lut) / rng
   	Z = fn.rescaleData(Z, scale, mn, dtype=int, clip=(0, len(lut)-1))

2. pyqtgraph/pyqtgraph/graphicsItems/PColorMeshItem.py

   Lines 272 to 276 in 21391e0

   	rng = z_max - z_min
   	if rng == 0:
   	rng = 1
   	norm = fn.rescaleData(self.z, scale / rng, z_min,
   	dtype=int, clip=(0, len(lut)-1))

[NilsNemitz]

Well, that looks like a dramatic reduction in complexity!

And unless I am missing some side effect in the rescale functions, the exact value of the combined scaling factor scale/rng should not matter when the output range is zero - or it should at least be very obvious if it does.

[j9ac9k]

I belive the issue this PR was meant to address is now addressed in #2944 ?