You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OpenCV python version: 4.10.0
Operating System / Platform: macOS 15.1.1 arm64 M2
Python version: 3.9.6 (/usr/bin/python3 provided by macOS)
Detailed description
The following code shows unexpected small negative numbers when trying to normalize an image between 0 and 1 while a comparison, which is mathematically not exactly the same, works fine. Note: The comparison img1 is keeping the offset from 0, I just used it for a quick check.
This appears to be the same as #6125 and #6170 which apparently has been fixed once in dev but then has been everted due to performance impacts.
This bug, if I don't have a misunderstanding of the OpenCV NORM_MINMAX definition, is serious as even small negative numbers can lead to critical follow up errors. For safety one can of course follow it with a img = np.clip(img, 0, 1) which is advised anyway for critical applications, but the result is mathematically slightly wrong.
If the performance impact can still be seen today with a fix, then I suggest to add at least internally a clip.
Datatype of img is np.float32. Changing to np.double like suggested in the older bug doesn't change anything.
System Information
OpenCV python version: 4.10.0
Operating System / Platform: macOS 15.1.1 arm64 M2
Python version: 3.9.6 (/usr/bin/python3 provided by macOS)
Detailed description
The following code shows unexpected small negative numbers when trying to normalize an image between 0 and 1 while a comparison, which is mathematically not exactly the same, works fine. Note: The comparison img1 is keeping the offset from 0, I just used it for a quick check.
This appears to be the same as #6125 and #6170 which apparently has been fixed once in dev but then has been everted due to performance impacts.
This bug, if I don't have a misunderstanding of the OpenCV NORM_MINMAX definition, is serious as even small negative numbers can lead to critical follow up errors. For safety one can of course follow it with a img = np.clip(img, 0, 1) which is advised anyway for critical applications, but the result is mathematically slightly wrong.
If the performance impact can still be seen today with a fix, then I suggest to add at least internally a clip.
Datatype of img is np.float32. Changing to np.double like suggested in the older bug doesn't change anything.
If needed I guess I would be able to attach a reproducer input image and code.
Steps to reproduce
Issue submission checklist
The text was updated successfully, but these errors were encountered: