ptcloud , photo test suit cleanup - #29742
## Test suite cleanup
### Given real assertions
- **ptcloud** — `HugeSceneGrowthTest`: zero assertions, including a `// Reset check` comment followed by no check.
- **ptcloud** — `PointCloud.SaveBadExtension`: passed an empty vertex set, so it exited at the empty-input guard and never reached the extension code it is named for.
- **ptcloud** — new `PointCloud.SaveEmptyVertices`: covers the early-return branch the above was hitting by accident.
### Moved
- **photo** — `Photo_Denoising.speed` → `perf/perf_denoising.cpp`: a `getTickCount` + `printf` stopwatch in the accuracy suite, asserting nothing, costing 393 ms per run.
### Library fixes found while doing the above
- **ptcloud** — `findPlanes` now converts 3-channel input instead of reshaping it: `Mat_<Vec4f>::operator=` reshapes when depths match, so a 320×240 `CV_32FC3` input silently became 240×240.
- **ptcloud** — new `RGBD_Plane.regression_3channel_matches_4channel`: nothing covered the documented 3-channel path, since all 40 `RgbdPlaneGenerate` cases feed `CV_32FC4`.
### 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
ptcloud: fix NaN bypass in TSDF volume integration bounds check - #29766Fixes#29763.
A singular or near-singular `cameraPose` makes `Matx44f::inv()` return NaN. That NaN reaches the SIMD bounds check in `integrateTsdfVolumeUnit()`, which rejects out-of-range pixels by ORing `v_lt(pt, 0)` with `v_ge(pt, upLimits)`. Under IEEE 754 both comparisons return false for NaN, so the check lets it through silently. `v_floor(NaN)` then produces an indefinite integer value (`INT_MIN` on x86), and the resulting row/column index reads out of bounds in `v_load_low()`.
Added `v_not_nan()` to the mask so a NaN lane is always treated as out of range, matching the NaN-guard idiom already used elsewhere in OpenCV (e.g. `bilateral_filter.simd.hpp`). The scalar fallback of the same function goes through `bilinearDepth()` in `tsdf_functions.hpp`, which had the identical gap (`pt.x < 0 || pt.x >= ...` also can't catch NaN), so that's covered too. Added a regression test using the singular pose from the issue's reproducer; note it can only confirm no voxel gets corrupted, not the crash itself, since that needs ASan on x86 to reproduce reliably.
### 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 (`5.x`, `ptcloud` doesn't exist on `4.x`)
- [x] There is a reference to the original bug report and related work (#29763)
- [x] There is an accuracy test (`Volume.issue_29763`), self-contained (no `opencv_extra` test data needed); not applicable: performance test (not a perf-sensitive change)
- [x] N/A: this is a bug fix, not a new feature -- no new public API or documentation needed
Close the cv::viz3d namespaces outside the trailing #ifdef HAVE_OPENGL
block. Previously the closing braces were inside the guard, so a build
with OpenGL disabled dropped them and failed with
'expected }' at end of input'.
Add ColorHashTSDFVolume implementation #27823
# Add ColorHashTSDFVolume implementation [[#25155](https://github.com/opencv/opencv/issues/25155)]
## Description
Added a new ColorHashTSDFVolume implementation that combines the benefits of HashTSDFVolume's efficient spatial hashing with color support. This provides memory-efficient RGB-D fusion with better performance compared to regular ColorTSDFVolume.
### Key Features
- Hash-based spatial data structure for efficient storage
- Color integration during volume updates
- Raycast with color interpolation
- Compatible with existing TSDF interfaces
- CPU implementation with parallel processing support
### Implementation Details
- Added new ColorHashTSDFVolume class with create() factory method
- ColorVoxel structure combining TSDF and RGB data
- Spatial hashing for efficient voxel lookup
- Weighted running average for color updates
- Trilinear interpolation during raycasting
- Unit tests for basic operations and edge cases
### Files Modified/Added
- modules/3d/src/rgbd/color_hash_volume.hpp - New header defining ColorHashTSDFVolume interface
- modules/3d/src/rgbd/color_hash_volume.cpp - Implementation of ColorHashTSDFVolume
- modules/3d/test/test_color_hash_volume.cpp - Unit tests
### Performance
The implementation uses spatial hashing to only store voxels near surfaces, significantly reducing memory usage compared to regular ColorTSDFVolume while maintaining similar processing speed.
### Testing
Added unit tests that verify:
- Basic integration and raycasting operations
- Empty volume handling
- Memory usage patterns
### Future Work
- GPU/OpenCL implementation
- Additional color interpolation methods
- Extended comparison tests with other volume types
Documentation fixes, Added How to use pre-built opencv doc #29288
closes: https://github.com/opencv/opencv/issues/29263
co-authored by: @kirtijindal14 @Akansha-977
### 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
- [ ] 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.
- [x] The feature is well documented and sample code can be built with the project CMake
objc: Fix VolumeType enum name clash on MacOS #29262
### Pull Request Readiness Checklist
- [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
- [ ] The feature is well documented and sample code can be built with the project CMake
**Problem**
When the ObjC wrapper is generated, the global enum `cv::VolumeType` from the ptcloud module is emitted as `typedef NS_ENUM(int, VolumeType)`. macOS defines `typedef OSType VolumeType` in CoreServices, which leads to a typedef-redefinition error during the framework build.
**Fix**
`add_enum()` in `gen_objc.py` now handles namespace-global enums by falling back to a module-level lookup (`self.Module`) when the enum has no enclosing class. A new `gen_dict.json` entry maps `VolumeType` -> `PtcloudVolumeType`, and the import generation automatically uses the renamed enum.
Fixes#29260
Dedicated pointcloud module #29224
OpenCV contrib: https://github.com/opencv/opencv_contrib/pull/4134
### 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
- [ ] The PR is proposed to the proper branch
- [ ] 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
