nareshmlx/opencv-pr huggingface dataset:
**File:** samples/cpp/text_skewness_correction.cpp
**Change Type:** added
**Context:** PR #16170: added tutorial for text skewness correction -  ### This pull request changes Given an image containing a rotated block of text at an unknow...

**Code Changes:**
```diff
@@ -0,0 +1,74 @@
+/*
+This tutorial demonstrates how to correct the skewness in a text.
+The program takes as input a skewed source image and shows non skewed text.
+
+*/
+
+#include <opencv2/core.hpp>
+#include <opencv2/imgcodecs.hpp>
+#include <opencv2/highgui.hpp>
```

Review comment:
space is missing after type.
**File:** samples/cpp/text_skewness_correction.cpp
**Change Type:** added
**Context:** PR #16170: added tutorial for text skewness correction -  ### This pull request changes Given an image containing a rotated block of text at an unknow...

**Code Changes:**
```diff
@@ -0,0 +1,74 @@
+/*
+This tutorial demonstrates how to correct the skewness in a text.
+The program takes as input a skewed source image and shows non skewed text.
+
+*/
+
+#include <opencv2/core.hpp>
+#include <opencv2/imgcodecs.hpp>
+#include <opencv2/highgui.hpp>
```

Review comment:
The same is applicable for Python code too.
**File:** samples/cpp/text_skewness_correction.cpp
**Change Type:** added
**Context:** PR #16170: added tutorial for text skewness correction -  ### This pull request changes Given an image containing a rotated block of text at an unknow...

**Code Changes:**
```diff
@@ -0,0 +1,74 @@
+/*
+This tutorial demonstrates how to correct the skewness in a text.
+The program takes as input a skewed source image and shows non skewed text.
+
+*/
+
+#include <opencv2/core.hpp>
+#include <opencv2/imgcodecs.hpp>
+#include <opencv2/highgui.hpp>
```

Review comment:
Extra line is not required here
**File:** samples/python/text_skewness_correction.py
**Change Type:** added
**Context:** PR #16170: added tutorial for text skewness correction -  ### This pull request changes Given an image containing a rotated block of text at an unknow...
**Review Line:** 7

**Code Changes:**
```diff
+Text skewness correction
+This tutorial demonstrates how to correct the skewness in a text.
+The program takes as input a skewed source image and shows non skewed text.
+
+Usage:
+        python text_skewness_correction.py --image "Image path"
+'''
+
+import numpy as np
+import cv2 as cv
+import sys
```

Review comment:
Please add reference to `imageTextR.png` as in C++ code.
**File:** samples/python/text_skewness_correction.py
**Change Type:** added
**Context:** PR #16170: added tutorial for text skewness correction -  ### This pull request changes Given an image containing a rotated block of text at an unknow...

**Code Changes:**
```diff
@@ -0,0 +1,58 @@
+'''
+Text skewness correction
+This tutorial demonstrates how to correct the skewness in a text.
+The program takes as input a skewed source image and shows non skewed text.
+
+Usage:
+        python text_skewness_correction.py --image "Image path"
+'''
+
```

Review comment:
Empty lines inside and after if statement are not consistent, it confuses reader.
**File:** samples/cpp/text_skewness_correction.cpp
**Change Type:** added
**Context:** PR #16170: added tutorial for text skewness correction -  ### This pull request changes Given an image containing a rotated block of text at an unknow...
**Review Line:** 59

**Code Changes:**
```diff
+        angle = (90.0f + angle);
+    }
+
+    //Obtaining the rotation matrix
+    Point2f center((image.cols) / 2.0f, (image.rows) / 2.0f);
+    Mat M = getRotationMatrix2D(center, angle, 1.0f);
+    Mat rotated;
+
+    // Rotating the image by required angle
+    stringstream angle_to_str;
+    angle_to_str << fixed << setprecision(2) << angle;
```

Review comment:
Why image center? What is about box's center?
**File:** samples/cpp/text_skewness_correction.cpp
**Change Type:** added
**Context:** PR #16170: added tutorial for text skewness correction -  ### This pull request changes Given an image containing a rotated block of text at an unknow...
**Review Line:** 45

**Code Changes:**
```diff
+    int erosion_size = 1;
+    Mat element = getStructuringElement( MORPH_RECT, Size(2*erosion_size+1, 2*erosion_size+1), Point(erosion_size, erosion_size) );
+    erode(thresh, thresh, element);
+
+    cv::Mat coords;
+    findNonZero(thresh, coords);
+
+    RotatedRect box = minAreaRect(coords);
+    float angle = box.angle;
+
+    // The cv::minAreaRect function returns values in the range [-90, 0)
```

Review comment:
Erode filter may help with random noise.
**File:** samples/python/text_skewness_correction.py
**Change Type:** added
**Context:** PR #16170: added tutorial for text skewness correction -  ### This pull request changes Given an image containing a rotated block of text at an unknow...

**Code Changes:**
```diff
@@ -0,0 +1,58 @@
+'''
+Text skewness correction
+This tutorial demonstrates how to correct the skewness in a text.
+The program takes as input a skewed source image and shows non skewed text.
+
+Usage:
+        python text_skewness_correction.py --image "Image path"
+'''
+
```

Review comment:
`angle` handling code is differ from C++ code.
**File:** samples/python/text_skewness_correction.py
**Change Type:** added
**Context:** PR #16170: added tutorial for text skewness correction -  ### This pull request changes Given an image containing a rotated block of text at an unknow...

**Code Changes:**
```diff
@@ -0,0 +1,58 @@
+'''
+Text skewness correction
+This tutorial demonstrates how to correct the skewness in a text.
+The program takes as input a skewed source image and shows non skewed text.
+
+Usage:
+        python text_skewness_correction.py --image "Image path"
+'''
+
```

Review comment:
In python, I have used `coords = np.column_stack(np.where(thresh > 0))` whereas in cpp I have used `findNonZero` due to which python code gives an angle to be complimentary of the cpp code
**File:** samples/cpp/text_skewness_correction.cpp
**Change Type:** added
**Context:** PR #16170: added tutorial for text skewness correction -  ### This pull request changes Given an image containing a rotated block of text at an unknow...
**Review Line:** 59

**Code Changes:**
```diff
+        angle = (90.0f + angle);
+    }
+
+    //Obtaining the rotation matrix
+    Point2f center((image.cols) / 2.0f, (image.rows) / 2.0f);
+    Mat M = getRotationMatrix2D(center, angle, 1.0f);
+    Mat rotated;
+
+    // Rotating the image by required angle
+    stringstream angle_to_str;
+    angle_to_str << fixed << setprecision(2) << angle;
```

Review comment:
The lines of text are parallel so you can rotate about any point and the rotated image will be correct. Rotating about the image center is better because the image gets rotated uniformly about all the edges and corners but if we rotate about a box which is near to say right corner then the text at the left corner will be displaced by a lot and if the margin is thin then we might lose some of the words.
**File:** samples/python/text_skewness_correction.py
**Change Type:** added
**Context:** PR #16170: added tutorial for text skewness correction -  ### This pull request changes Given an image containing a rotated block of text at an unknow...

**Code Changes:**
```diff
@@ -0,0 +1,58 @@
+'''
+Text skewness correction
+This tutorial demonstrates how to correct the skewness in a text.
+The program takes as input a skewed source image and shows non skewed text.
+
+Usage:
+        python text_skewness_correction.py --image "Image path"
+'''
+
```

Review comment:
I believe it is better to use similar API calls in both C++/Python samples (which produce similar results) to avoid Users confusion. Please use `findNonZero()` in Python code too.
**File:** modules/imgproc/src/resize.cpp
**Change Type:** modified
**Context:** PR #16146: Improve resize 8u3 - I wasn't impressed with my workaround for the OOB fix. Let's fix it with little or no regressing of performance. This ...
**Review Line:** 1628

**Code Changes:**
```diff
@@ -1631,7 +1625,7 @@ struct HResizeLinearVecU8_X4
                 const uchar *S1 = src[k+1];
                 int *D1 = dst[k+1];
 
-                for( dx = 0; dx < len0; dx += cn )
+                for( dx = 0; (xofs[dx] + cn) < smax; dx += cn )
                 {
                     v_int16x8 a = v_load(alpha+dx*2);
                     v_store(&D0[dx], v_dotprod(v_reinterpret_as_s16(v_load_expand_q(S0+xofs[dx]) | (v_load_expand_q(S0+xofs[dx]+cn)<<16)), a));
@@ -1642,12 +1636,14 @@ struct HResizeLinearVecU8_X4
             {
```

Review comment:
> + cn As we reading 4 bytes (`v_load_expand_q()`), so I believe we should count these `+ 4` somewhere. (in meaning I would like to see " + 4" / " - 4" in the code directly)
**File:** modules/imgproc/src/resize.cpp
**Change Type:** modified
**Context:** PR #16146: Improve resize 8u3 - I wasn't impressed with my workaround for the OOB fix. Let's fix it with little or no regressing of performance. This ...
**Review Line:** 1628

**Code Changes:**
```diff
@@ -1631,7 +1625,7 @@ struct HResizeLinearVecU8_X4
                 const uchar *S1 = src[k+1];
                 int *D1 = dst[k+1];
 
-                for( dx = 0; dx < len0; dx += cn )
+                for( dx = 0; (xofs[dx] + cn) < smax; dx += cn )
                 {
                     v_int16x8 a = v_load(alpha+dx*2);
                     v_store(&D0[dx], v_dotprod(v_reinterpret_as_s16(v_load_expand_q(S0+xofs[dx]) | (v_load_expand_q(S0+xofs[dx]+cn)<<16)), a));
@@ -1642,12 +1636,14 @@ struct HResizeLinearVecU8_X4
             {
```

Review comment:
This loop is predicated on single units of the input matrix (cn), not vector unit size. Would you prefer a variable similar to `int step = (vuint32x4::nlanes/cn)*cn;` to replace the direct usage of cn? The 8u3 case can easily port to larger vector sizes (the 75% efficiency may show more).
**File:** modules/imgproc/src/resize.cpp
**Change Type:** modified
**Context:** PR #16146: Improve resize 8u3 - I wasn't impressed with my workaround for the OOB fix. Let's fix it with little or no regressing of performance. This ...
**Review Line:** 1628

**Code Changes:**
```diff
@@ -1631,7 +1625,7 @@ struct HResizeLinearVecU8_X4
                 const uchar *S1 = src[k+1];
                 int *D1 = dst[k+1];
 
-                for( dx = 0; dx < len0; dx += cn )
+                for( dx = 0; (xofs[dx] + cn) < smax; dx += cn )
                 {
                     v_int16x8 a = v_load(alpha+dx*2);
                     v_store(&D0[dx], v_dotprod(v_reinterpret_as_s16(v_load_expand_q(S0+xofs[dx]) | (v_load_expand_q(S0+xofs[dx]+cn)<<16)), a));
@@ -1642,12 +1636,14 @@ struct HResizeLinearVecU8_X4
             {
```

Review comment:
This note is not about the "step". It is about the limit, like `xofs[dx] + cn + 4 < some_buffer_limit` > 8u3 case can easily port to larger vector sizes Make sense, there are several algorithm implementations which process 4 pixels (4*3 = 12 bytes) per iteration. Image resolutions are usually divided by 4 (640x480, 1280x720, etc), so they don't require heavy tail processing.
**File:** modules/imgproc/src/resize.cpp
**Change Type:** modified
**Context:** PR #16146: Improve resize 8u3 - I wasn't impressed with my workaround for the OOB fix. Let's fix it with little or no regressing of performance. This ...
**Review Line:** 1628

**Code Changes:**
```diff
@@ -1631,7 +1625,7 @@ struct HResizeLinearVecU8_X4
                 const uchar *S1 = src[k+1];
                 int *D1 = dst[k+1];
 
-                for( dx = 0; dx < len0; dx += cn )
+                for( dx = 0; (xofs[dx] + cn) < smax; dx += cn )
                 {
                     v_int16x8 a = v_load(alpha+dx*2);
                     v_store(&D0[dx], v_dotprod(v_reinterpret_as_s16(v_load_expand_q(S0+xofs[dx]) | (v_load_expand_q(S0+xofs[dx]+cn)<<16)), a));
@@ -1642,12 +1636,14 @@ struct HResizeLinearVecU8_X4
             {
```

Review comment:
Any unit not a multiple of cn doesn't make sense here. Adding + 4 only guarantees 1 more operation which can safely vectorize does not get vectorized. The only thing the vector loop must satisfy is that it never touches the final cn bytes of src or dst. It strides by 3B.
**File:** modules/imgproc/src/resize.cpp
**Change Type:** modified
**Context:** PR #16146: Improve resize 8u3 - I wasn't impressed with my workaround for the OOB fix. Let's fix it with little or no regressing of performance. This ...
**Review Line:** 1628

**Code Changes:**
```diff
@@ -1631,7 +1625,7 @@ struct HResizeLinearVecU8_X4
                 const uchar *S1 = src[k+1];
                 int *D1 = dst[k+1];
 
-                for( dx = 0; dx < len0; dx += cn )
+                for( dx = 0; (xofs[dx] + cn) < smax; dx += cn )
                 {
                     v_int16x8 a = v_load(alpha+dx*2);
                     v_store(&D0[dx], v_dotprod(v_reinterpret_as_s16(v_load_expand_q(S0+xofs[dx]) | (v_load_expand_q(S0+xofs[dx]+cn)<<16)), a));
@@ -1642,12 +1636,14 @@ struct HResizeLinearVecU8_X4
             {
```

Review comment:
`v_load_expand_q()` reads 4 bytes, so we must check that all these 4 bytes are fit into the buffer range limits.
**File:** modules/imgproc/src/resize.cpp
**Change Type:** modified
**Context:** PR #16146: Improve resize 8u3 - I wasn't impressed with my workaround for the OOB fix. Let's fix it with little or no regressing of performance. This ...
**Review Line:** 1628

**Code Changes:**
```diff
@@ -1631,7 +1625,7 @@ struct HResizeLinearVecU8_X4
                 const uchar *S1 = src[k+1];
                 int *D1 = dst[k+1];
 
-                for( dx = 0; dx < len0; dx += cn )
+                for( dx = 0; (xofs[dx] + cn) < smax; dx += cn )
                 {
                     v_int16x8 a = v_load(alpha+dx*2);
                     v_store(&D0[dx], v_dotprod(v_reinterpret_as_s16(v_load_expand_q(S0+xofs[dx]) | (v_load_expand_q(S0+xofs[dx]+cn)<<16)), a));
@@ -1642,12 +1636,14 @@ struct HResizeLinearVecU8_X4
             {
```

Review comment:
Right, the first 3 bytes are always valid. It's the fourth that is OOB if and only if `dx >= (dwidth - cn) || xofs[dx] >= (swidth - cn)`. Note the test also preserves the cases where `xmax < dwidth`.
**File:** modules/imgproc/src/resize.cpp
**Change Type:** modified
**Context:** PR #16146: Improve resize 8u3 - I wasn't impressed with my workaround for the OOB fix. Let's fix it with little or no regressing of performance. This ...
**Review Line:** 1628

**Code Changes:**
```diff
@@ -1631,7 +1625,7 @@ struct HResizeLinearVecU8_X4
                 const uchar *S1 = src[k+1];
                 int *D1 = dst[k+1];
 
-                for( dx = 0; dx < len0; dx += cn )
+                for( dx = 0; (xofs[dx] + cn) < smax; dx += cn )
                 {
                     v_int16x8 a = v_load(alpha+dx*2);
                     v_store(&D0[dx], v_dotprod(v_reinterpret_as_s16(v_load_expand_q(S0+xofs[dx]) | (v_load_expand_q(S0+xofs[dx]+cn)<<16)), a));
@@ -1642,12 +1636,14 @@ struct HResizeLinearVecU8_X4
             {
```

Review comment:
We must check that all 4 bytes valid. Through **explicit check** (with 4 bytes, not through "obfuscated" conditions). Make it clear for review. We already have that mistake, so let avoid similar mistakes in the future.
**File:** modules/imgproc/src/resize.cpp
**Change Type:** modified
**Context:** PR #16146: Improve resize 8u3 - I wasn't impressed with my workaround for the OOB fix. Let's fix it with little or no regressing of performance. This ...
**Review Line:** 1628

**Code Changes:**
```diff
@@ -1631,7 +1625,7 @@ struct HResizeLinearVecU8_X4
                 const uchar *S1 = src[k+1];
                 int *D1 = dst[k+1];
 
-                for( dx = 0; dx < len0; dx += cn )
+                for( dx = 0; (xofs[dx] + cn) < smax; dx += cn )
                 {
                     v_int16x8 a = v_load(alpha+dx*2);
                     v_store(&D0[dx], v_dotprod(v_reinterpret_as_s16(v_load_expand_q(S0+xofs[dx]) | (v_load_expand_q(S0+xofs[dx]+cn)<<16)), a));
@@ -1642,12 +1636,14 @@ struct HResizeLinearVecU8_X4
             {
```

Review comment:
Checking a non-modulo 3 value against such a loop counter is at best accidental correctness, and at worst subtly wrong. (e.g failing to account for src[] offset as was the original bug, which was a different bug altogether). The loop touches 1 + 1/3 8c3 values per iteration, but increments by 1.
**File:** modules/imgproc/src/resize.cpp
**Change Type:** modified
**Context:** PR #16146: Improve resize 8u3 - I wasn't impressed with my workaround for the OOB fix. Let's fix it with little or no regressing of performance. This ...
**Review Line:** 1628

**Code Changes:**
```diff
@@ -1631,7 +1625,7 @@ struct HResizeLinearVecU8_X4
                 const uchar *S1 = src[k+1];
                 int *D1 = dst[k+1];
 
-                for( dx = 0; dx < len0; dx += cn )
+                for( dx = 0; (xofs[dx] + cn) < smax; dx += cn )
                 {
                     v_int16x8 a = v_load(alpha+dx*2);
                     v_store(&D0[dx], v_dotprod(v_reinterpret_as_s16(v_load_expand_q(S0+xofs[dx]) | (v_load_expand_q(S0+xofs[dx]+cn)<<16)), a));
@@ -1642,12 +1636,14 @@ struct HResizeLinearVecU8_X4
             {
```

Review comment:
As far as I understand fourth value will be OOB on writing when `dx >= (dwidth - cn)` and will be OOB on reading when `(xofs[dx] + cn) >= (swidth -cn)`. So the condition could be `(xofs[dx] + 2*cn) < smax` or `(xofs[dx] + cn + 4) <= smax`
**File:** modules/imgproc/src/resize.cpp
**Change Type:** modified
**Context:** PR #16146: Improve resize 8u3 - I wasn't impressed with my workaround for the OOB fix. Let's fix it with little or no regressing of performance. This ...
**Review Line:** 1628

**Code Changes:**
```diff
@@ -1631,7 +1625,7 @@ struct HResizeLinearVecU8_X4
                 const uchar *S1 = src[k+1];
                 int *D1 = dst[k+1];
 
-                for( dx = 0; dx < len0; dx += cn )
+                for( dx = 0; (xofs[dx] + cn) < smax; dx += cn )
                 {
                     v_int16x8 a = v_load(alpha+dx*2);
                     v_store(&D0[dx], v_dotprod(v_reinterpret_as_s16(v_load_expand_q(S0+xofs[dx]) | (v_load_expand_q(S0+xofs[dx]+cn)<<16)), a));
@@ -1642,12 +1636,14 @@ struct HResizeLinearVecU8_X4
             {
```

Review comment:
That isn't wrong, but will overlook safe vector ops. It ignores how smax is selected. `smax >= (swidth - cn)` can only be met if `dx >= dmax`. This can never be true since xofs[] is by design an array of increasingly large offsets.
**File:** modules/imgproc/src/resize.cpp
**Change Type:** modified
**Context:** PR #16146: Improve resize 8u3 - I wasn't impressed with my workaround for the OOB fix. Let's fix it with little or no regressing of performance. This ...
**Review Line:** 1628

**Code Changes:**
```diff
@@ -1631,7 +1625,7 @@ struct HResizeLinearVecU8_X4
                 const uchar *S1 = src[k+1];
                 int *D1 = dst[k+1];
 
-                for( dx = 0; dx < len0; dx += cn )
+                for( dx = 0; (xofs[dx] + cn) < smax; dx += cn )
                 {
                     v_int16x8 a = v_load(alpha+dx*2);
                     v_store(&D0[dx], v_dotprod(v_reinterpret_as_s16(v_load_expand_q(S0+xofs[dx]) | (v_load_expand_q(S0+xofs[dx]+cn)<<16)), a));
@@ -1642,12 +1636,14 @@ struct HResizeLinearVecU8_X4
             {
```

Review comment:
Sorry for mistake in the previous message. I've been confused by the change of `smax` meaning. So due to the way `smax` is defined we could state that `smax < swidth - cn` therefore `(xofs[dx] + cn) < smax` check ensures that `xofs[dx] + cn < swidth - cn` or that `xofs[dx] + cn <= swidth - cn - 1` equal to `xofs[dx] + cn <= swidth - 4` Both statements ensure safe reading of 4 values starting from `xofs[dx] + cn` however the latter clearly states that it safe for reading of strictly 4 values while the former rather looks like safe reading of a pixel triplet. Direct mention of 4 values(or even better of v_int32x4::nlanes) is important to avoid introduction of OOB mistakes when the code will be migrated to wide universal intrinsics.
**File:** modules/photo/src/seamless_cloning.cpp
**Change Type:** modified
**Context:** PR #15929: Update seamless_cloning.cpp - ### This pullrequest changes resolves #15927

**Code Changes:**
```diff
@@ -51,8 +51,8 @@ static Mat checkMask(InputArray _mask, Size size)
 {
     Mat mask = _mask.getMat();
     Mat gray;
-    if (mask.channels() == 3)
-        cvtColor(mask, gray, COLOR_BGR2GRAY);
+    if (mask.channels() > 1)
+        cvtColor(mask, gray, COLOR_BGRA2GRAY);
     else
     {
```

Review comment:
Need to ensure somehow that Rect args are still valid.
**File:** modules/photo/src/seamless_cloning.cpp
**Change Type:** modified
**Context:** PR #15929: Update seamless_cloning.cpp - ### This pullrequest changes resolves #15927

**Code Changes:**
```diff
@@ -51,8 +51,8 @@ static Mat checkMask(InputArray _mask, Size size)
 {
     Mat mask = _mask.getMat();
     Mat gray;
-    if (mask.channels() == 3)
-        cvtColor(mask, gray, COLOR_BGR2GRAY);
+    if (mask.channels() > 1)
+        cvtColor(mask, gray, COLOR_BGRA2GRAY);
     else
     {
```

Review comment:
How can I pull sturkmen72's code in order to work on this?
**File:** modules/photo/src/seamless_cloning.cpp
**Change Type:** modified
**Context:** PR #15929: Update seamless_cloning.cpp - ### This pullrequest changes resolves #15927
**Review Line:** 55

**Code Changes:**
```diff
     Mat mask = _mask.getMat();
     Mat gray;
-    if (mask.channels() == 3)
-        cvtColor(mask, gray, COLOR_BGR2GRAY);
+    if (mask.channels() > 1)
+        cvtColor(mask, gray, COLOR_BGRA2GRAY);
     else
     {
         if (mask.empty())
```

Review comment:
> COLOR_BGR2GRAY Should work with both BGR/BGRA input too.
**File:** 3rdparty/carotene/CMakeLists.txt
**Change Type:** modified
**Context:** PR #16369: carotene: Replace ipcp-unit-growth with ipa-cp-unit-growth on gcc >= 10 - gcc 10+ has renamed this option, therefore check for gcc version ...

**Code Changes:**
```diff
@@ -20,8 +20,11 @@ if(CMAKE_COMPILER_IS_GNUCC)
     # - matchTemplate about 5-10%
     # - goodFeaturesToTrack 10-20%
     # - cornerHarris 30% for some cases
-
-    set_source_files_properties(${carotene_sources} COMPILE_FLAGS "--param ipcp-unit-growth=100000 --param inline-unit-growth=100000 --param large-stack-frame-growth=5000")
+    if(CMAKE_CXX_COMPILER_VERSION VERSION_LESS "10.0.0")
+        set_source_files_properties(${carotene_sources} COMPILE_FLAGS "--param ipcp-unit-growth=100000 --param inline-unit-growth=100000 --param large-stack-frame-growth=5000")
+    else()
+        set_source_files_properties(${carotene_sources} COMPILE_FLAGS "--param ipa-cp-unit-growth=100000 --param inline-unit-growth=100000 --param large-stack-frame-growth=5000")
```

Review comment:
Please use single call of `set_source_files_properties(${carotene_sources} COMPILE_FLAGS ...)` ``` if(CMAKE_CXX_COMPILER_VERSION VERSION_LESS "10.0.0") set(carotene_sources_flags "--param ipcp-unit-growth=100000") else() set(carotene_sources_flags "--param ipa-cp-unit-growth=100000") endif() set_source_files_properties(${carotene_sources} COMPILE_FLAGS "--param inline-unit-growth=100000 --param large-stack-frame-growth=5000 ${carotene_sources_flags}") ```
**File:** cmake/OpenCVFindOpenEXR.cmake
**Change Type:** modified
**Context:** PR #16294: cmake: fix Linux system OpenEXR detection

**Code Changes:**
```diff
@@ -20,6 +20,8 @@ if(WIN32)
     elseif(MSVC)
         SET(OPENEXR_LIBSEARCH_SUFFIXES Win32/Release Win32 Win32/Debug)
     endif()
+elseif(UNIX)
+    SET(OPENEXR_LIBSEARCH_SUFFIXES ${CMAKE_LIBRARY_ARCHITECTURE})
 endif()
 
 SET(SEARCH_PATHS
@@ -39,6 +41,25 @@ MACRO(FIND_OPENEXR_LIBRARY LIBRARY_NAME LIBRARY_SUFFIX)
```

Review comment:
Consider using `CMAKE_LIBRARY_ARCHITECTURE` variable instead.