- add infrastructure support for Power9/VSX3
- fix missing VSX flags on GCC4.9 and CLANG4(#13210, #13222)
- fix disable VSX optimzation on GCC by using flag ENABLE_VSX
- flag ENABLE_VSX is deprecated now, use CPU_BASELINE, CPU_DISPATCH instead
- add VSX3 to arithmetic dispatchable flags
V4L (V4L2): Refactoring. Added missed camera properties. Fixed getting `INF` for some properties. Singlethread as always (#12893)
* cap_v4l:
1 Added cap_properties verbalization.
2 Set Get of properties elementary refactoring.
3 Removed converting parameters to/from [0,1] range.
4 Added all known conversion from V4L2_CID_* to CV_CAP_PROP_*
* cap_v4l:
1. Removed all query for parameters range.
2. Refactored capture initialization.
3. Added selecting input channel by CV_CAP_PROP_MODE. Default value -1 the channels not changed.
* cap_v4l:
1. Refactoring of Convert To RGB
* cap_v4l:
1. Fixed use of video buffer index.
2. Removed extra memcopy for grab image.
3. Removed device closing from autosetup_capture_mode_v4l2
* cap_v4l:
1. The `goto` was eliminated
2. Fixed use of temporary buffer index for V4L2_PIX_FMT_SN9C10X
3. Fixed use of the bufferIndex
4. Removed trailing spaces and unused variables.
* cap_v4l:
1. Alias for capture->buffers[capture->bufferIndex]
2. Reduced size of data for memcpy: bytesused instead of length
3. Refactoring. Code duplication. More info for debug
* cap_v4l:
1. Added the ability to grab and retrieveFrame independently several times
* cap_v4l:
1. Not need to close/open device for new capture parameters applying.
2. Removed using of device name as a flag that the capture is closed. Added sufficient function.
3. Refactoring. Added requestBuffers and createBuffers
* cap_v4l:
1. Added tryIoctl with `select` like was in mainloop_v4l2.
2. Fixed buffer request for device without closing the device.
3. Some static function moved to CvCaptureCAM_V4L
4. Removed unused defines
* cap_v4l:
1. Thread-safe now
* cap_v4l:
1. Fixed thread-safe destructor
2. Fixed FPS setting
* Missed brake
* Removed thread-safety
* cap_v4l:
1. Reverted conversion parameters to/from [0,1] by default for backward compatibility.
2. Added setting for turn off compatibility mode: set CV_CAP_PROP_MODE to 65536
3. Most static functions moved to CvCaptureCAM_V4L
4. Refactoring of icvRetrieveFrameCAM_V4L and using of frame_allocated flag
* cap_v4l:
1. Added conversion to RGB from NV12, NV21
2. Refactoring. Removed wrappers for known format conversions.
* Added `CAP_PROP_CHANNEL` to the enum VideoCaptureProperties.
CAP_V4L migrated to use VideoCaptureProperties.
* 1. Update comments.
2. Environment variable `OPENCV_VIDEOIO_V4L_RANGE_NORMALIZED` for setting default backward compatibility mode.
3. Revert getting of `CAP_PROP_MODE` as fourcc code in backward compatibility mode.
* videoio: update cap_v4l - compatibilityMode => normalizePropRange
* videoio(test): V4L2 MJPEG test
`v4l2-ctl --list-formats` should have 'MJPG' entry
* videoio: fix buffer initialization
to avoid "munmap: Invalid argument" messages
* Updated boxFilter implementations to use wide universal intrinsics
* boxFilter implementation moved to separate file
* Replaced ROUNDUP macro with roundUp() function
During the cluster-based detection of circle grids, the detected circle
pattern has to be mapped to 3D-points. When doing this the width (i.e.
more circles) and height (i.e. less circles) of the pattern need to
be identified in image coordinates.
Until now this was done by assuming that the shorter side in image
coordinates (length in pixels) corresponds to the height in 3D.
This assumption does not hold if we look at the pattern from
a perspective where the projection of the width is shorter
than the projection of the height. This in turn lead to misdetections in
although the circle pattern was clearly visible.
Instead count how many circles have been detected along two edges of the
projected quadrangle and use the one with more circles as width and the
one with less as height.
* Fix reading of black-and-white (thresholded) TIFF images
I recently updated my local OpenCV version to 3.4.3 and found out that
I could not read my TIFF images related to my project. After debugging I
found out that there has been some static analysis fixes made
that accidentally have broken reading those black-and-white TIFF images.
Commit hash in which reading of mentioned TIFF images has been broken:
cbb1e867e5
Basically the fix is to revert back to the same functionality that has been there before,
when black-and-white images are read bpp (bitspersample) is 1.
Without the case 1: this TiffDecoder::readHeader() function always return false.
* Added type and default error message
* Added stdexcept include
* Use CV_Error instead of throw std::runtime_error
* imgcodecs(test): add TIFF B/W decoding tests
* RGB2RGB initially rewritten
* NEON impl removed
* templated version added for ushort, float
* data copying allowed for RGB2RGB
* inplace processing fixed
* fields to local vars
* no zeroupper until it's fixed
* vx_cleanup() added back
- initialize arithmetic dispatcher
- add new universal intrinsic v_absdiffs
- add new universal intrinsic v_pack_b
- add accumulate version of universal intrinsic v_round
- fix sse/avx2:uint8 multiplication overflow
- reimplement arithmetic, logic and comparison operations into wide universal intrinsics
with full support for all types
- reimplement IPP arithmetic, logic and comparison operations in a sperate file arithm_ipp.hpp
- avoid scalar multiplication if scaling factor eq 1 and use integer multiplication
- move C arithmetic operations to precomp.hpp and delete [arithm_simd|arithm_core].hpp
- add compatibility with new opencv4 divide policy
"as opposed to" is a phrase of opposed meaning distinguished from or in contrast with. e.g., "an approach that is theoretical as opposed to practical"
synonyms: in contrast with, as against, as contrasted with, rather than, instead of, as an alternative to
example: "we use only steam, as opposed to chemical products, to clean our house"
Exceptions caught by value incur needless cost in C++, most of them can
be caught by const-reference, especially as nearly none are actually
used. This could allow compiler generate a slightly more efficient code.
- This is to accommodate the variabiilty in floating-point operations in new platforms/compilers
- Specifically due to the error margin found in NVIDIA Jetson TX2
