Remove deprecated CommaInitializer API - #29948
This goes hand in hand with https://github.com/opencv/opencv_contrib/pull/4217
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [ ] The feature is well documented and sample code can be built with the project CMake
imgproc: fix NaN in phaseCorrelateIterative for float32 input - #29871
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [x] The feature is well documented and sample code can be built with the project CMake
### Summary
`cv::phaseCorrelateIterative` could return the image boundary as the detected shift (e.g. `(-32, -32)` for a 64x64 image) for ordinary float32 input, while the same input in float64 and the non-iterative `cv::phaseCorrelate` both return the correct shift. Reported in #29849 with a reproducer.
### Problem
`calculateCrossPowerSpectrum()` divided by the bin magnitude without a zero check. When a frequency bin of the cross power spectrum has exactly zero magnitude, the division produces NaN (0/0). A single NaN bin is enough: after the inverse DFT the whole correlation landscape becomes NaN, `minMaxLoc` degenerates, the peak lands on the wraparound corner, and the function exits through the out-of-bounds fallback returning `L3peak - L3mid = (-N/2, -M/2)`.
This is reachable with perfectly valid input: for a 64x64 image, bins where either frequency component hits Nyquist produce `dft1[bin] * conj(dft2[bin]) = 0` for Gaussian-like windows (the Hanning-windowed images issue #29849 used), because one of the DFT factors is exactly zero there.
### Solution
Two changes in `calculateCrossPowerSpectrum()`, both matching what the non-iterative implementation already does:
1. Guard the zero-magnitude case: a bin with zero magnitude has undefined phase, so write 0 instead of dividing by zero. `cv::divSpectrums()` handles the same situation by adding an epsilon to the denominator; zeroing the bin is equivalent here and keeps the output strictly on the unit circle.
2. Accumulate in `double` before rounding back to the storage type, as `cv::divSpectrums()` does in its CV_32F branch. This also protects large images, where float32 products of DFT bins can overflow to inf.
### Testing
- Reproduced #29849 with the issue's reproducer ported to C++: float32 returned `(-32, -32)` before the fix, `(-2.96, 1.99)` after (float64 reference: `(-2.94, 1.96)` for the true shift (-3, +2)).
- Added regression test `Imgproc_PhaseCorrelationIterative/64x64_float32_accuracy` covering this case. Verified it fails without the fix (returns `(-32, -32)`) and passes with it.
- `opencv_test_imgproc`: all 1635 tests pass with the fix (opencv_extra testdata, 5.x branch). The pre-existing `float32_overflow` and accuracy tests for the non-iterative path also pass.
Iterative Phase Correlation #28146
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [x] The feature is well documented and sample code can be built with the project CMake
Vincent Rabaud
Pranshul Soni
zdenyhraz