psImagePowerSpectrum returns NaN image

[Paul Price]

Calling psImagePowerSpectrum on a 256x256 image results in an output image
composed of NaNs. This is because numElementsSquared goes as the number of
elements to the fourth power, which clocks a psS32 for a 256x256 image
(numElementsSquared = 0). Since OTA cells are 512x512, this range is not
sufficient.

The function works adequately when numCols, numRows and numElementsSquared are
all changed to psU64 types. This would give us the capability of handling
square images up to 64k pixels on each axis. This should be sufficient for our
needs, but a check for this should be added to the function.

I can't dream up a workaround.

[robert.desonia@…]

I didn't take your suggestion, as when I looked at where it was used, it was
better to be either a psF32 or psF64, depending on the input data type. This
avoids a integer->floating-point cast within a inner loop through the pixels,
potentially increasing performance.

Since floating-point is used, there is no practical limit in image size to
check, so no overflow check was added either.

[Paul Price]

Even better!

[Paul Price]

The problem has not been fixed. I will attach code to reproduce.

[Paul Price]

testFFT.c

[Paul Price]

I expect the fault still lies with the line:

psF32 numElementsSquared = numCols * numCols * numRows * numRows;

I suspect integer math is being performed, the result of which is then converted
to float, but the damage is already done.

The following fix works:

psF32 numElementsSquared = numCols * numRows;
numElementsSquared *= numElementsSquared;

[robert.desonia@…]

OK, I changed the line you highlighted to:

psF32 fNumCols = numCols;
psF32 fNumRows = numRows;
psF32 numElementsSquared = fNumCols * fNumCols * fNumRows * fNumRows;

That should not have any integer overflow problems as no integer math is
committed.

[Paul Price]

Verified.

Perhaps the code I provided could be used in the regression tests.