When using OCL, the results of goodFeaturesToTrack() vary slightly from
run to run. This appears to be because the order of the results from
the findCorners kernel depends on thread execution and the sorting
function that is used at the end to rank the features only enforces are
partial sort order.
This does not materially impact the quality of the results, but it
makes it hard to build regression tests and generally introduces noise
into the system that should be avoided.
An easy fix is to change the sort function to enforce a total sort on
the features, even in cases where the match quality is exactly the same
for two features.
Non existence of _FPU_EXTENDED definition on powerpc64 (like it is for apple and arm)
prevent compilation when WITH_CUDA is set. Adding powerpc64 as case to not use these
definitions
modifié: modules/cudalegacy/test/TestHaarCascadeApplication.cpp
modifié: modules/cudalegacy/test/test_precomp.hpp
Signed-off-by: Thierry Fauck <tfauck@free.fr>
I have seen that you can input a Mat_<float> on StereoBM, but the value seems the same as CV_16S.
I changed it so, only if you input a Mat_<float> it makes use of a previously truncated 4 bits, giving more resolution to Disparity Matrix. (The algorithm stays the same, it's not more precise).
If any other input Mat is given, it changes nothing.
Major changes:
- modify the Base64 functions to compatible with `cvWriteRawData` and so
on.
- add a Base64 flag for FileStorage and outputs raw data in Base64
automatically.
- complete all testing and documentation.