Repository: opencv
Issue: OpenCV on Raspberry Pi Zero W - Floating point exception / black empty images
Labels: category: build/install,incomplete


[CMake_output.txt](https://github.com/opencv/opencv/files/4012939/CMake_output.txt)

- OpenCV => v4.2.0
- OS (cross-compilation) => macOS Catalina 10.15.1
- Target OS => Raspberry Pi Zero W, Raspbian Buster (10)
- Toolchain: crosstool-ng v1.23.0, armv6-rpi-linux-gnueabi

I am trying to utilise OpenCV 4 on the Raspberry Pi Zero W, running Raspbian Buster (10). When doing any transformations on a captured image, the application exits with a floating-point exception.

I have cross-compiled OpenCV with various options, most notably the ENABLE_VFPV3 option, with no luck. I always get the floating-point exception. I use **crosstool-ng** for the cross-compilation on macOS, and CMake (through Jetbrains CLion, mostly).

OpenCV is configured with the following options before being built:
```
-DCMAKE_TOOLCHAIN_FILE=armv6-rpi-linux-gnueabi-toolchain.cmake  -DBUILD_JPEG=ON -DBUILD_PNG=ON -DBUILD_TIFF=ON -DWITH_V4L=ON -DENABLE_VFPV3=ON -DBUILD_TESTS=OFF -DCMAKE_BUILD_TYPE=Debug -DBUILD_SHARED_LIBS=OFF
```

OpenCV builds without any issues, and so do the applications that utilise the libraries. I don't build the shared libs, as I want the compiled application to not be dependent on 3rd party libraries to be installed.

The toolchain file that I use for cross-compilation of both OpenCV and the test application:
```
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR arm)

set(CMAKE_CXX_FLAGS "-static-libstdc++")

set(CMAKE_SYSROOT /Volumes/crosstool/x-tools/armv6-rpi-linux-gnueabi/armv6-rpi-linux-gnueabi/sysroot)
set(CMAKE_OSX_SYSROOT /Volumes/crosstool/x-tools/armv6-rpi-linux-gnueabi/armv6-rpi-linux-gnueabi/sysroot)

set(CMAKE_C_COMPILER "/Volumes/crosstool/x-tools/armv6-rpi-linux-gnueabi/bin/armv6-rpi-linux-gnueabi-gcc")
set(CMAKE_CXX_COMPILER "/Volumes/crosstool/x-tools/armv6-rpi-linux-gnueabi/bin/armv6-rpi-linux-gnueabi-g++")
```

I have successfully compiled and run various applications with no issues up to this point, using this same setup.

A simple test application to reproduce the error:
```
#include <iostream>
#include "opencv2/imgproc/imgproc.hpp"
#include "opencv2/video/video.hpp"
#include "opencv2/videoio/videoio.hpp"

using namespace cv;
using namespace std;

int main( int argc, char** argv )
{
    VideoCapture cap(0); //capture the video from web cam

    if ( !cap.isOpened() )  // if not success, exit program
    {
        cout << "Cannot open the web cam" << endl;
        return -1;
    }

    while (true)
    {
        Mat image;

        bool bSuccess = cap.grab();

        if (!bSuccess) //if not success, break loop
        {
            cout << "Cannot read a frame from video stream" << endl;
            break;
        }

        cap.retrieve(image);

        cvtColor(image, image, COLOR_BGR2GRAY);

    }
    return 0;
}
```

The _CMakefiles.txt_:
```
cmake_minimum_required(VERSION 3.14)
project(vision)

set(CMAKE_CXX_STANDARD 17)

set(CMAKE_CXX_FLAGS "-static-libstdc++")

message( STATUS "Profile: ${PROFILE}" )

if ("${PROFILE}" STREQUAL "macos")
    include_directories(
            /usr/local/include/opencv4
    )
    link_directories(
            /usr/local/lib
            /usr/local/lib/opencv4/3rdparty
    )
elseif ("${PROFILE}" STREQUAL "arm")
    include_directories(
            ../opencv-arm/build/install/include/opencv4
    )
    link_directories(
            ../zlib/install/lib
            ../opencv-arm/build/install/lib
            ../opencv-arm/build/install/lib/opencv4/3rdparty
    )
else()
    message( ERROR "unsupported build profile" )
    return()
endif()

add_executable(vision main.cpp)

target_link_libraries(
        vision
        # video
        opencv_videoio
        opencv_video
        # gui
        opencv_highgui
        # image processing
        opencv_imgcodecs
        opencv_imgproc
        opencv_core
        libjpeg-turbo
        libjasper
        libtiff
        libpng
        libwebp
        ittnotify
        dl
        z
)

if ("${PROFILE}" STREQUAL "arm")
    target_link_libraries(
            vision
            tegra_hal
            pthread
    )
endif()
```
After attempting the color transformation (or any other transformation) on the RPi Zero, the application exits with a `Floating point exception`. Compiling and running on macOS works without any issues (`-DPROFILE=macos`).

My only thoughts at this stage are that the OpenCV compilation needs to do something special for the RPi Zero for the floating-point calculations to work. Any help/direction will be greatly appreciated.

I did make some progress in finding a workaround. Using remote GDB, I was able to pinpoint a divide-by-zero in the OpenCV parallelism implementation (`modules/core/src/parallel.cpp`, line 316). It seems ParallelLoopBodyWrapperContext.nstripes is zero. Following [this post](https://stackoverflow.com/a/56281760/3177406), I re-compiled OpenCV with parallelism disabled, which allows the processing to succeed. I've only managed to utilise the color conversion operation, though. Both _blur_ and _Canny_ produce empty/black images, although not causing the floating point exception.

The CMake configuration options that I now utilised are:
```
-DCMAKE_TOOLCHAIN_FILE=armv6-rpi-linux-gnueabi-toolchain.cmake  -DBUILD_JPEG=ON -DBUILD_PNG=ON -DBUILD_TIFF=ON -DBUILD_TESTS=OFF -DCMAKE_BUILD_TYPE=Debug -DBUILD_SHARED_LIBS=OFF -DWITH_IPP=OFF -DWITH_TBB=OFF -DWITH_OPENMP=OFF -DWITH_PTHREADS_PF=OFF
```

A deeper investigation will probably be needed into why the parallelism fails on the Pi Zero.