src/OpenCvSharpExtern/aruco.h (1)

135-135: Unrelated formatting change in ArUco file.

This indentation adjustment to cornersVec declaration appears unrelated to the EdgeDrawing wrapper implementation described in the PR objectives. Consider removing unrelated changes to keep the PR focused.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/OpenCvSharpExtern/aruco.h` at line 135, The change to the ArUco header is
an unnecessary formatting-only edit; revert the altered line that declares
cornersVec (the declaration "std::vector<std::vector<cv::Point2f> >
cornersVec(cornersLength1);") back to its original formatting or remove the
whitespace-only edit so the ArUco file remains unchanged—ensure only
EdgeDrawing-related files contain PR changes and leave the symbols and
declarations (e.g., cornersVec) identical to their prior state.

src/OpenCvSharp/Modules/ximgproc/Enum/GradientOperator.cs (1)

1-27: Consider using GradientOperator enum type in EdgeDrawingParams.EdgeDetectionOperator.

The enum is well-documented, but per the context snippet from EdgeDrawing.cs, EdgeDrawingParams.EdgeDetectionOperator is declared as int rather than GradientOperator. This reduces type safety—users must know to cast the enum or use raw integers.

If the int type is required for P/Invoke struct layout compatibility, consider adding a strongly-typed convenience property that wraps the int field, or document the expected usage in the property's XML comment.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/OpenCvSharp/Modules/ximgproc/Enum/GradientOperator.cs` around lines 1 -
27, EdgeDrawingParams currently exposes EdgeDetectionOperator as an int which
reduces type safety; change the API to use the GradientOperator enum where
possible by replacing the int-typed property with a GradientOperator-typed
property (or add a new strongly-typed wrapper property) so consumers can use
GradientOperator.PreWitt/Sobel/etc. Update the EdgeDrawingParams class
(EdgeDrawingParams.EdgeDetectionOperator) to either change its type to
GradientOperator or add a pair of members: keep the existing int field for
P/Invoke compatibility and add a new property like EdgeDetectionOperatorEnum of
type GradientOperator that gets/sets the underlying int field (performing safe
casts and validation), and update any usages in EdgeDrawing/EdgeDrawing.cs to
use the enum property.

src/OpenCvSharp/Internal/Vectors/VectorOfVec6d.cs (2)

15-19: Clarify the SafeHandle ownership pattern.

The constructor passes ownsHandle: false and releaseAction: null to OpenCvPtrSafeHandle, but cleanup is handled in DisposeUnmanaged(). While this works correctly, it's somewhat unusual—typically the SafeHandle would own the release responsibility.

This pattern appears intentional to maintain consistency with the base CvObject disposal pattern, but a brief comment explaining why ownsHandle: false is used here would improve maintainability.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/OpenCvSharp/Internal/Vectors/VectorOfVec6d.cs` around lines 15 - 19, The
VectorOfVec6d constructor creates the native pointer via
NativeMethods.vector_Vec6d_new1() and wraps it with OpenCvPtrSafeHandle using
ownsHandle: false and releaseAction: null; add a concise comment in the
VectorOfVec6d() constructor explaining that ownsHandle is false intentionally
because actual cleanup is delegated to the class's DisposeUnmanaged()
(consistent with the CvObject disposal pattern) so reviewers understand why the
SafeHandle does not own the release responsibility; reference
OpenCvPtrSafeHandle, DisposeUnmanaged, and NativeMethods.vector_Vec6d_new1 in
the comment for clarity.

---

33-41: Potential integer overflow when casting nuint to int.

The Size property casts nuint to int, which could overflow for vectors larger than int.MaxValue (2.1 billion elements). However, given that each Vec6d is 48 bytes, this would require ~100GB of memory, making overflow practically impossible in real-world usage.

The current implementation is acceptable, but if future-proofing is desired, consider returning nuint or long and updating callers accordingly.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/OpenCvSharp/Internal/Vectors/VectorOfVec6d.cs` around lines 33 - 41, The
Size property in VectorOfVec6d currently casts the nuint returned by
NativeMethods.vector_Vec6d_getSize(CvPtr) to int which can overflow; change the
Size API to return nuint (or long) instead of int and propagate that change
through all callers (update any code using VectorOfVec6d.Size to handle the
wider type), or if you must keep an int API add an explicit safe check: get the
nuint value from NativeMethods.vector_Vec6d_getSize(CvPtr), GC.KeepAlive(this),
then if the value > int.MaxValue throw or clamp before casting; reference
VectorOfVec6d.Size and NativeMethods.vector_Vec6d_getSize when making the
change.

src/OpenCvSharpExtern/ximgproc_EdgeDrawing.h (1)

132-193: Extract the params marshaling into helpers.

ximgproc_EdgeDrawing_getParams, ximgproc_EdgeDrawing_setParams, and ximgproc_EdgeDrawing_Params_default now each spell out the full field copy. Since this wrapper is being used as a reference implementation, centralizing the CvEdgeDrawingParams ⇄ EdgeDrawing::Params projection will make the next params addition much harder to miss.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/OpenCvSharpExtern/ximgproc_EdgeDrawing.h` around lines 132 - 193, The
three functions ximgproc_EdgeDrawing_getParams, ximgproc_EdgeDrawing_setParams,
and ximgproc_EdgeDrawing_Params_default duplicate field-by-field marshaling;
extract this logic into two helper routines (e.g., ToNativeParams(const
CvEdgeDrawingParams&, cv::ximgproc::EdgeDrawing::Params&) and ToCvParams(const
cv::ximgproc::EdgeDrawing::Params&, CvEdgeDrawingParams&)) and replace the
copies in getParams, setParams, and Params_default to call these helpers (use
obj->params with ToCvParams in get/default and use ToNativeParams then
obj->setParams in setParams) so future param additions are handled in one place
and reduce duplication.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

src/OpenCvSharp/Internal/PInvoke/NativeMethods/ximgproc/NativeMethods_ximgproc_EdgeDrawing.cs (1)

2-2: Reduce layering coupling between Internal interop and module namespace.

NativeMethods_ximgproc_EdgeDrawing.cs (Internal layer) currently depends on OpenCvSharp.XImgProc for CvEdgeDrawingParams. Consider moving CvEdgeDrawingParams into an Internal interop-struct location so module wrappers depend on Internal, not vice versa.

Also applies to: 51-57

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/OpenCvSharp/Internal/PInvoke/NativeMethods/ximgproc/NativeMethods_ximgproc_EdgeDrawing.cs`
at line 2, The Internal interop file NativeMethods_ximgproc_EdgeDrawing.cs
should not depend on the module namespace: move the CvEdgeDrawingParams
definition out of OpenCvSharp.XImgProc into an Internal interop struct (e.g., in
the same Internal/PInvoke namespace used by other native wrappers), replace the
using OpenCvSharp.XImgProc and update all references in
NativeMethods_ximgproc_EdgeDrawing (and any other occurrences in this file) to
the new Internal struct type, and ensure the module-level wrapper continues to
map/translate between the public CvEdgeDrawingParams API type and the new
Internal interop struct so layering is one-directional (module -> Internal).