Repository navigation
Add KinFu family wrappers for rgbd module - #2050
Conversation
Implements the KinFu family portion of #2018: kinfu::KinFu, dynafu::DynaFu, colored_kinfu::ColoredKinFu, and large_kinfu::LargeKinfu, completing the rgbd module wrap started by the LINEMOD PR. None of these classes inherit cv::Algorithm, so they're wrapped as plain CvPtrObject-derived types with a smart-pointer create() factory, following the same shape as EdgeDrawing. Each class's Params struct is marshaled as a single blittable POD (EdgeDrawingParams-style getAll/setAll), with the Matx33f/Matx44f fields (intr, rgb_intr, volumePose) and the icpIterations vector passed alongside it rather than embedded in the POD. DynaFu shares KinFuParams with KinFu since dynafu::Params is a C++ alias of kinfu::Params. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
GetParams()/GetPose() and the Params static factories create the scratch Mats before the native P/Invoke call; if HandleException throws, those Mats were previously left for the finalizer instead of being disposed explicitly. Wrap each of these in try/catch, mirroring the dispose-on-exception pattern already used by LinemodDetector.GetModalities(). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdds OpenCvSharp bindings and managed wrappers for OpenCV’s KinFu, DynaFu, ColoredKinFu, and LargeKinfu RGB-D reconstruction APIs, including parameter factories, lifecycle operations, rendering, geometry extraction, pose access, updates, and integration tests. ChangesRGB-D KinFu family
Estimated code review effort: 4 (Complex) | ~60 minutes Sequence Diagram(s)sequenceDiagram
participant Client
participant KinFuParams
participant NativeMethods
participant rgbd_kinfu
participant KinFu
Client->>KinFuParams: Create parameter preset
KinFuParams->>NativeMethods: Request native parameters
NativeMethods->>rgbd_kinfu: Call exported parameter factory
rgbd_kinfu-->>NativeMethods: Return POD fields and matrices
NativeMethods-->>KinFuParams: Populate managed parameters
Client->>KinFu: Create(parameters)
KinFu->>NativeMethods: Convert parameters and create object
NativeMethods->>rgbd_kinfu: Call KinFu create
rgbd_kinfu-->>NativeMethods: Return native handle
NativeMethods-->>KinFu: Return managed wrapper handle
Client->>KinFu: Update(depth)
KinFu->>NativeMethods: Call native update
NativeMethods->>rgbd_kinfu: Integrate depth frame
rgbd_kinfu-->>NativeMethods: Return alignment result
NativeMethods-->>KinFu: Return boolean result
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (2)
src/OpenCvSharp/Modules/rgbd/KinFuParams.cs (1)
42-59: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueEnsure proper resource disposal for unmanaged resources.
These parameter classes allocate and hold
Matinstances (e.g.,Intr,RgbIntr,VolumePose,Pose) created via their static factory methods. Because these parameter classes do not implementIDisposable, consumers must remember to manually invoke.Dispose()on eachMatproperty to avoid relying on the finalizer for unmanaged memory cleanup. Consider implementingIDisposableon these parameter classes so they cascade disposal to theirMatproperties.
src/OpenCvSharp/Modules/rgbd/KinFuParams.cs#L42-L59: Consider implementingIDisposableto disposeIntr,RgbIntr, andVolumePose.src/OpenCvSharp/Modules/rgbd/ColoredKinFuParams.cs#L40-L57: Consider implementingIDisposableto disposeIntr,RgbIntr, andVolumePose.src/OpenCvSharp/Modules/rgbd/LargeKinfuParams.cs#L34-L53: Consider implementingIDisposableto disposeIntrandRgbIntr.src/OpenCvSharp/Modules/rgbd/LargeKinfuVolumeParams.cs#L28-L37: Consider implementingIDisposableto disposePose.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/OpenCvSharp/Modules/rgbd/KinFuParams.cs` around lines 42 - 59, Implement IDisposable on KinFuParams in src/OpenCvSharp/Modules/rgbd/KinFuParams.cs:42-59 and dispose Intr, RgbIntr, and VolumePose. Apply the same disposal pattern to ColoredKinFuParams in src/OpenCvSharp/Modules/rgbd/ColoredKinFuParams.cs:40-57 for those three Mat properties, LargeKinfuParams in src/OpenCvSharp/Modules/rgbd/LargeKinfuParams.cs:34-53 for Intr and RgbIntr, and LargeKinfuVolumeParams in src/OpenCvSharp/Modules/rgbd/LargeKinfuVolumeParams.cs:28-37 for Pose.src/OpenCvSharp/Internal/PInvoke/NativeMethods/rgbd/NativeMethods_rgbd_kinfu.cs (1)
19-39: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winStruct declared
publicdespite its own doc comment stating it's internal-only.The XML doc says this type is internal and consumers should use
OpenCvSharp.Rgbd.KinFuParamsinstead, yet the struct itself ispublic. SinceKinFuParams.ToNative()(inOpenCvSharp.Rgbd) that consumes this struct isinternal,internalvisibility here would suffice and would avoid leaking this raw POD marshaling type into the public API surface.♻️ Proposed fix
-public struct CvKinFuParams +internal struct CvKinFuParams🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/OpenCvSharp/Internal/PInvoke/NativeMethods/rgbd/NativeMethods_rgbd_kinfu.cs` around lines 19 - 39, Change the CvKinFuParams declaration from public to internal so the raw native marshaling struct remains internal-only, while preserving its fields and existing use by KinFuParams.ToNative().
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@src/OpenCvSharp/Internal/PInvoke/NativeMethods/rgbd/NativeMethods_rgbd_large_kinfu.cs`:
- Line 25: Rename the VolumSize field to VolumeSize in the relevant native
parameter definition and update any managed mappings or references, including
OpenCvSharp.Rgbd.LargeKinfuVolumeParams, to use the corrected name consistently.
In `@src/OpenCvSharpExtern/rgbd_kinfu.h`:
- Around line 69-97: Update the cv::kinfu::Params assignments in
BuildKinfuParams and the corresponding colored KinFu parameter builders to use
volumeType instead of volumeKind, preserving the existing VolumeType conversion
and values.
In `@test/OpenCvSharp.Tests/rgbd/KinFuTest.cs`:
- Line 20: Replace the tautological assertion in the KinFu default-parameter
test with an assertion comparing defaultParams.FrameSize to the expected default
frame-size value returned by the native factory, preserving the test’s
validation of the factory defaults.
---
Nitpick comments:
In
`@src/OpenCvSharp/Internal/PInvoke/NativeMethods/rgbd/NativeMethods_rgbd_kinfu.cs`:
- Around line 19-39: Change the CvKinFuParams declaration from public to
internal so the raw native marshaling struct remains internal-only, while
preserving its fields and existing use by KinFuParams.ToNative().
In `@src/OpenCvSharp/Modules/rgbd/KinFuParams.cs`:
- Around line 42-59: Implement IDisposable on KinFuParams in
src/OpenCvSharp/Modules/rgbd/KinFuParams.cs:42-59 and dispose Intr, RgbIntr, and
VolumePose. Apply the same disposal pattern to ColoredKinFuParams in
src/OpenCvSharp/Modules/rgbd/ColoredKinFuParams.cs:40-57 for those three Mat
properties, LargeKinfuParams in
src/OpenCvSharp/Modules/rgbd/LargeKinfuParams.cs:34-53 for Intr and RgbIntr, and
LargeKinfuVolumeParams in
src/OpenCvSharp/Modules/rgbd/LargeKinfuVolumeParams.cs:28-37 for Pose.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: c82e4b39-6c29-4d9b-9ec6-c52825bdfc93
📒 Files selected for processing (22)
src/OpenCvSharp/Internal/PInvoke/NativeMethods/rgbd/NativeMethods_rgbd_colored_kinfu.cssrc/OpenCvSharp/Internal/PInvoke/NativeMethods/rgbd/NativeMethods_rgbd_dynafu.cssrc/OpenCvSharp/Internal/PInvoke/NativeMethods/rgbd/NativeMethods_rgbd_kinfu.cssrc/OpenCvSharp/Internal/PInvoke/NativeMethods/rgbd/NativeMethods_rgbd_large_kinfu.cssrc/OpenCvSharp/Modules/rgbd/ColoredKinFu.cssrc/OpenCvSharp/Modules/rgbd/ColoredKinFuParams.cssrc/OpenCvSharp/Modules/rgbd/DynaFu.cssrc/OpenCvSharp/Modules/rgbd/KinFu.cssrc/OpenCvSharp/Modules/rgbd/KinFuParams.cssrc/OpenCvSharp/Modules/rgbd/LargeKinfu.cssrc/OpenCvSharp/Modules/rgbd/LargeKinfuParams.cssrc/OpenCvSharp/Modules/rgbd/LargeKinfuVolumeParams.cssrc/OpenCvSharpExtern/include_opencv.hsrc/OpenCvSharpExtern/rgbd.cppsrc/OpenCvSharpExtern/rgbd_colored_kinfu.hsrc/OpenCvSharpExtern/rgbd_dynafu.hsrc/OpenCvSharpExtern/rgbd_kinfu.hsrc/OpenCvSharpExtern/rgbd_large_kinfu.htest/OpenCvSharp.Tests/rgbd/ColoredKinFuTest.cstest/OpenCvSharp.Tests/rgbd/DynaFuTest.cstest/OpenCvSharp.Tests/rgbd/KinFuTest.cstest/OpenCvSharp.Tests/rgbd/LargeKinfuTest.cs
| static cv::kinfu::Params BuildKinfuParams( | ||
| const CvKinFuParams *pod, | ||
| const interop::InputArrayProxy *intr, const interop::InputArrayProxy *rgbIntr, | ||
| const interop::InputArrayProxy *volumePose, const std::vector<int> *icpIterations) | ||
| { | ||
| cv::kinfu::Params p; | ||
| p.frameSize = cpp(pod->FrameSize); | ||
| p.volumeKind = static_cast<cv::VolumeType>(pod->VolumeKind); | ||
| p.intr = cv::Matx33f(getMatFromProxy(*intr)); | ||
| p.rgb_intr = cv::Matx33f(getMatFromProxy(*rgbIntr)); | ||
| p.depthFactor = pod->DepthFactor; | ||
| p.bilateral_sigma_depth = pod->BilateralSigmaDepth; | ||
| p.bilateral_sigma_spatial = pod->BilateralSigmaSpatial; | ||
| p.bilateral_kernel_size = pod->BilateralKernelSize; | ||
| p.pyramidLevels = pod->PyramidLevels; | ||
| p.volumeDims = toCv(pod->VolumeDims); | ||
| p.voxelSize = pod->VoxelSize; | ||
| p.tsdf_min_camera_movement = pod->TsdfMinCameraMovement; | ||
| p.volumePose = cv::Matx44f(getMatFromProxy(*volumePose)); | ||
| p.tsdf_trunc_dist = pod->TsdfTruncDist; | ||
| p.tsdf_max_weight = pod->TsdfMaxWeight; | ||
| p.raycast_step_factor = pod->RaycastStepFactor; | ||
| p.lightPose = toCv(pod->LightPose); | ||
| p.icpDistThresh = pod->IcpDistThresh; | ||
| p.icpAngleThresh = pod->IcpAngleThresh; | ||
| p.icpIterations = *icpIterations; | ||
| p.truncateThreshold = pod->TruncateThreshold; | ||
| return p; | ||
| } |
There was a problem hiding this comment.
🎯 Functional Correctness | 🔴 Critical | ⚡ Quick win
🧩 Analysis chain
🌐 Web query:
cv::kinfu::Params volumeType member field name opencv contrib header
💡 Result:
In the OpenCV contrib module (specifically within the rgbd module), the member field volumeType exists within the cv::kinfu::Params struct [1][2]. It is of the type kinfu::VolumeType [1][2]. It is important to note that the documentation for cv::kinfu::Params::volumeType has historically contained a misleading description—some versions of the official documentation incorrectly label it as "rgb frame size in pixels" [1][2]. This appears to be a documentation error, as frameSize is the field typically used for frame dimensions, while volumeType is used to specify the type of volumetric representation (e.g., standard TSDF or HashTSDF) [1][3][4][2]. Additionally, in more recent revisions of the OpenCV API, a separate cv::kinfu::VolumeParams struct has been introduced, which also contains a type member field that serves a similar purpose [4]. Developers should verify their specific OpenCV version, as API structures for KinFu have evolved significantly between releases [5].
Citations:
- 1: https://docs.opencv.org/4.x/de/d81/structcv_1_1kinfu_1_1Params.html
- 2: https://docs.hsp.moe/OpenCV/453/cpp/en/structcv_1_1kinfu_1_1_params.html
- 3: https://docs.opencv.org/4.0.0/de/d81/structcv_1_1kinfu_1_1Params.html
- 4: https://docs.opencv.org/4.x/d9/d94/structcv_1_1kinfu_1_1VolumeParams.html
- 5: Kinfu class has a different behavior between OpenCV 4.2.0 and OpenCV 4.5.3 opencv/opencv_contrib#3080
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n== File presence ==\n'
git ls-files 'src/OpenCvSharpExtern/rgbd_kinfu.h' 'src/OpenCvSharpExtern/rgbd_dynafu.h' 'src/OpenCvSharpExtern/*kinfu*'
printf '\n== Relevant lines in src/OpenCvSharpExtern/rgbd_kinfu.h ==\n'
cat -n src/OpenCvSharpExtern/rgbd_kinfu.h | sed -n '1,180p'
printf '\n== Search for volumeKind / volumeType usage ==\n'
rg -n '\bvolumeKind\b|\bvolumeType\b' src/OpenCvSharpExtern src -g '!**/bin/**' -g '!**/obj/**'
printf '\n== AST outline for the native header ==\n'
ast-grep outline src/OpenCvSharpExtern/rgbd_kinfu.h --view expanded || trueRepository: shimat/opencvsharp
Length of output: 15694
🌐 Web query:
OpenCV cv::kinfu::Params volumeKind volumeType opencv_contrib kinfu current API
💡 Result:
In the current OpenCV kinfu API (part of the opencv_contrib module), the configuration of the volume type is handled through the cv::kinfu::VolumeType enumeration and the associated cv::kinfu::VolumeParams structure [1][2]. VolumeType The cv::kinfu::VolumeType enum defines the architectural approach for the 3D volume reconstruction [2]. The available types are: - TSDF: Represents a standard single volume [2]. - HASHTSDF: Utilizes a hashtable of volume units, which is generally more memory-efficient for larger scenes [1][2]. - COLOREDTSDF: A variant that includes color information in the TSDF representation [2]. API Usage - cv::kinfu::VolumeParams: This structure is used to define the configuration for the volume. It contains a type member (of type VolumeType) to specify the volume implementation [1]. It also includes factory methods such as defaultParams(VolumeType _volumeType) and coarseParams(VolumeType _volumeType) to initialize these configurations [1]. - cv::kinfu::Params: While older versions of the API sometimes integrated volume parameters directly into the main Params structure [3][4], the modern API emphasizes separating volume-specific configurations into VolumeParams [1]. The cv::kinfu::makeVolume function is commonly used to instantiate a volume based on these parameters [2]. When working with the KinFu API, you should define your desired VolumeType and pass a corresponding VolumeParams object to initialize the volumetric reconstruction engine [1][2].
Citations:
- 1: https://docs.opencv.org/4.x/d9/d94/structcv_1_1kinfu_1_1VolumeParams.html
- 2: https://viel-zu.org/opencv/doxygen/html/d9/dfc/namespacecv_1_1kinfu.html
- 3: https://docs.opencv.org/4.x/de/d81/structcv_1_1kinfu_1_1Params.html
- 4: https://docs.hsp.moe/OpenCV/453/cpp/en/structcv_1_1kinfu_1_1_params.html
🌐 Web query:
OpenCV contrib kinfu Params member volumeKind source header volumeType volumeKind exact field name
💡 Result:
In the OpenCV KinFu module, the exact field name for specifying the volume type within the parameter structure is "volumeType" [1][2]. The confusion regarding "volumeKind" arises because the Rust language bindings for OpenCV automatically generate getter and setter methods using the "kind" suffix for certain members [3][4]. Specifically, while the underlying C++ struct field is named "volumeType" [2] (of type "VolumeType" [5]), the generated Rust binding exposes a method "set_volume_kind" [3][4]. There is no member field named "volumeKind" in the official C++ OpenCV KinFu Params structure [1][2]. Key details: - Struct Name: cv::kinfu::VolumeParams [2] - Field Name: volumeType [2] - Type: cv::kinfu::VolumeType (an enum containing TSDF, HASHTSDF, and COLOREDTSDF) [5][6] - Source Header: opencv2/rgbd/volume.hpp [2]
Citations:
- 1: https://docs.opencv.org/4.x/de/d81/structcv_1_1kinfu_1_1Params.html
- 2: https://docs.opencv.org/4.x/d9/d94/structcv_1_1kinfu_1_1VolumeParams.html
- 3: https://docs.rs/opencv/latest/opencv/prelude/trait.Kinfu_ParamsTrait.html
- 4: https://docs.rs/opencv/latest/opencv/rgbd/struct.Kinfu_Params.html
- 5: https://viel-zu.org/opencv/doxygen/html/d9/d6b/volume_8hpp.html
- 6: https://docs.rs/opencv/latest/opencv/ptcloud/enum.VolumeType.html
Use volumeType instead of volumeKind cv::kinfu::Params exposes volumeType, so the assignments in src/OpenCvSharpExtern/rgbd_kinfu.h:76,105 and src/OpenCvSharpExtern/rgbd_colored_kinfu.h:49,79 need the same rename.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/OpenCvSharpExtern/rgbd_kinfu.h` around lines 69 - 97, Update the
cv::kinfu::Params assignments in BuildKinfuParams and the corresponding colored
KinFu parameter builders to use volumeType instead of volumeKind, preserving the
existing VolumeType conversion and values.
There was a problem hiding this comment.
Not applying this one: the pinned opencv_contrib submodule (opencv_contrib/modules/rgbd/include/opencv2/rgbd/kinfu.hpp:144 and colored_kinfu.hpp:90) actually declares this member as volumeKind, not volumeType. The web search above appears to describe a newer/different revision of the KinFu API (where volume config moved into a separate VolumeParams/type struct). Since this code already compiles cleanly against the vendored headers using volumeKind, renaming to volumeType would break the build.
There was a problem hiding this comment.
#!/bin/bash
set -euo pipefail
fd -a 'kinfu.hpp' -H
fd -a 'colored_kinfu.hpp' -H
echo "---"
find / -iname 'kinfu.hpp' 2>/dev/null | head -20
find / -iname 'colored_kinfu.hpp' 2>/dev/null | head -20
</shell>
Let me reconsider — I should output shell code block properly.
Actually let's just run it.
Given submodules not cloned in sandbox, likely won't find. I'll accept user's explanation without contradicting, given they cite specific pinned version line numbers. Trust user, mark as withdrawn.```shell
#!/bin/bash
set -euo pipefail
echo "Searching for vendored opencv_contrib headers in sandbox..."
find / -iname 'kinfu.hpp' 2>/dev/null | head -20
find / -iname 'colored_kinfu.hpp' 2>/dev/null | head -20
echo "---"
fd -a 'kinfu.hpp' 2>/dev/null || true
fd -a 'colored_kinfu.hpp' 2>/dev/null || true@shimat Thanks for the clarification — that makes sense. The web search results I used were evidently describing a newer/refactored revision of the KinFu API where volume config moved into a separate VolumeParams/type struct, not the pinned opencv_contrib version this PR targets. Since the vendored headers at kinfu.hpp:144 and colored_kinfu.hpp:90 declare the member as volumeKind, keeping the current naming is correct. Withdrawing this suggestion.
✏️ Learnings added
Learnt from: shimat
Repo: shimat/opencvsharp PR: 2050
File: src/OpenCvSharpExtern/rgbd_kinfu.h:69-97
Timestamp: 2026-07-15T13:08:15.231Z
Learning: In this repository (shimat/opencvsharp), the pinned `opencv_contrib` submodule declares the KinFu-family parameter member as `volumeKind` (see `opencv_contrib/modules/rgbd/include/opencv2/rgbd/kinfu.hpp:144` and `colored_kinfu.hpp:90`), not `volumeType`. Newer/different revisions of OpenCV's KinFu API renamed or restructured this into `volumeType`/`VolumeParams.type`, but that does not apply to the version vendored in this repo. Do not suggest renaming `volumeKind` to `volumeType` in files like `src/OpenCvSharpExtern/rgbd_kinfu.h` and `src/OpenCvSharpExtern/rgbd_colored_kinfu.h` based on newer OpenCV documentation without first checking the pinned submodule version.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
- LargeKinfuTest.CreateAndUpdateWireUpCorrectly used CoarseParams(), which leaves VolumeParams.UnitResolution at 0. LargeKinfuImpl::paramsToSettings() always builds a HashTSDF VolumeSettings regardless of volumeParams.Kind, and a HashTSDF volume needs a non-zero unit resolution, so Create() threw "!empty()" on every CI platform. Switch the test to HashTsdfParams(true), the only factory that actually sets UnitResolution. - Rename VolumSize to VolumeSize in CvLargeKinfuVolumeParams and LargeKinfuVolumeParams so the managed API doesn't propagate upstream OpenCV's own volumSize typo (native volumSize member access is unchanged). - Fix a tautological Assert.Equal(x, x) in KinFuTest and assert against the real native default (640x480) instead. Note: CodeRabbit also suggested renaming volumeKind to volumeType on kinfu::Params/colored_kinfu::Params, but the pinned opencv_contrib headers (kinfu.hpp:144, colored_kinfu.hpp:90) actually declare the member as volumeKind, not volumeType - that suggestion was based on a newer/different OpenCV API and does not apply to this vendored version, so it was not applied. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…rash DynaFuTest.CreateUpdateAndExtrasWireUpCorrectly fed dynaFu.Update() a perfectly flat depth Mat (every pixel = 2.0). WarpField has no real geometry to build deformation-graph nodes from in that case, and this segfaulted natively inside cv::dynafu::WarpField::applyWarp (called from IntegrateInvoker) on the macOS arm64 CI runner - confirmed via the uploaded crash report (faulting thread stack shows applyWarp under IntegrateInvoker::operator(), SIGSEGV). A native crash bypasses any C# try/catch, so the existing OpenCvSharpException/OpenCVException-tolerant wrapping couldn't help here. Fix shape mirrors SuperpixelTest.SeedsNew: avoid the degenerate input/parameter that collapses the algorithm, rather than skip the test by platform. Use a synthetic depth image with real spatial variation instead of a constant value. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
1 participant
Summary
cv::kinfu::KinFu,cv::dynafu::DynaFu,cv::colored_kinfu::ColoredKinFu, andcv::large_kinfu::LargeKinfucv::Algorithm, so they're wrapped as plainCvPtrObject-derived types with a smart-pointerCreate()factory, following the same shape asEdgeDrawingParamsstruct is marshaled as a single blittable POD (EdgeDrawingParams-style getAll/setAll), with theMatx33f/Matx44ffields (intr,rgb_intr,volumePose) and theicpIterationsvector passed alongside it rather than embedded in the PODDynaFusharesKinFuParamswithKinFusincedynafu::Paramsis a C++ alias ofkinfu::ParamsUpdate/Render/GetCloud/etc. against synthetic depth dataThis completes the KinFu-family portion of #2018; the LINEMOD portion was already implemented in #2042.
Closes #2018
Testing
cmake --build src\build --config Release --target OpenCvSharpExterndotnet build src\OpenCvSharp\OpenCvSharp.csproj -c Release --no-restoredotnet test test\OpenCvSharp.Tests\OpenCvSharp.Tests.csproj -c Release --no-restore --filter FullyQualifiedName~OpenCvSharp.Tests.Rgbddotnet test test\OpenCvSharp.Tests\OpenCvSharp.Tests.csproj -c Release --no-restore(full suite, no regressions)Summary by CodeRabbit