물체인식을 적용한 이미지처리를 논한다면 OpenCV와 Darknet 그리고 그래픽카드(GPU)를 이용한다면 CUDA를 빼놓을 수 없다. 프로젝트 진행을 라즈베리 파이 혹은 NVIDIA Jetson과 같은 모바일 플랫폼 적용시키기 위해 운영체계를 리눅스로 선택할 수 있다. 그러나 본 문서가 작성된 2019년 기준으로 인터넷에는 아직 우분투 16.04 LTS에서의 CUDA Toolkit 9 및 OpenCV 3을 설치하는 방법을 주로 설명한다. 그 이상 버전의 리눅스 및 라이브러리 설치 방법이 하나의 문서로 제대로 정리되어 있지 않으며, 만일 있더라도 라이브러리 웹사이트에서 알려주는 절차를 벗어나는 게 있어 신빙성에 의심을 가질 수도 있다.
본 내용은 2019년 기준으로 안정적인 우분투 최신 버전인 18.04 LTS에 CUDA Toolkit 10.0 및 OpenCV 4.0.1, 그리고 YOLOv3 알고리즘을 위해 필요한 Darknet을 설치하는 방법을 라이브러리 웹사이트에서 알려주는 절차를 최대한 벗어나지 않으면서 각 라이브러리마다 호환이 가능하도록 알려준다. 우분투 18.04 LTS를 설치하는 방법은 생략하며, 라이브러리 설치를 위주로 CUDA, OpenCV, 그리고 YOLOv3 순서로 진행한다. 본 절차에 사용된 GPU는 NVIDIA GeForce GTX 1070이다.
본 내용은 2019년 기준으로 안정적인 우분투 최신 버전인 18.04 LTS에 CUDA Toolkit 10.0 및 OpenCV 4.0.1, 그리고 YOLOv3 알고리즘을 위해 필요한 Darknet을 설치하는 방법을 라이브러리 웹사이트에서 알려주는 절차를 최대한 벗어나지 않으면서 각 라이브러리마다 호환이 가능하도록 알려준다. 우분투 18.04 LTS를 설치하는 방법은 생략하며, 라이브러리 설치를 위주로 CUDA, OpenCV, 그리고 YOLOv3 순서로 진행한다. 본 절차에 사용된 GPU는 NVIDIA GeForce GTX 1070이다.
소프트웨어: CUDA Toolkit 10.0
일반적으로 CPU에서 멀티코어라고 하면 여러 개의 뇌를 가지고 있어 여러 정보를 코어마다 할당하여 더 빠른 시간 내에 작업을 처리할 수 있도록 한다. 이와 마찬가지로, NVIDIA GPU 제품에도 코어가 존재하며, 이들을 사용할 수 있도록 하는 라이브러리가 바로 CUDA (혹은 CUDA 드라이버)이다. NVIDIA GeForce GTX 1070 제품 안에는 1,920개의 CUDA 코어가 들어있다. CPU보다 훨씬 많은 코어를 가지고 있으나, 각 코어가 가지는 위력은 CPU의 코어에 비해 매우 빈약하여 GPU로는 하나의 작업을 집중적으로 처리할 수 있는 CPU를 대체하는데는 아직 부족하다. 그 대신 GPU의 CUDA는 물체인식에 필요한 엄청난 연산을 수많은 CUDA 코어로 분산시켜 병렬처리가 가능한 강력한 장점을 지닌다. 이러한 라이브러리를 프로그래밍에 접목시킬 수 있도록 하는 소프트웨어가 바로 CUDA Toolkit이며, 이 과정에서 적합한 CUDA 라이브러리도 함께 설치된다.
CUDA Toolkit 10.0 설치
CUDA Toolkit을 설치하기 전에 전체적으로 리눅스 시스템에 설정해 주어야 할 것이 있다: 바로 BIOS에서 Secure Boot를 비활성화시키는 거다. Secure Boot가 그래픽 카드에 접속하는데 필요한 커널에 제약을 걸어버리기 때문에 정상적인 사용을 위해서는 Secure Boot를 비활성화 해야 한다.참조: NVIDIA Forum: NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver
Secure Boot 비활성화 이후, CUDA Toolkit 10.0을 설치하기 전에 학습에 사용할 컴퓨터가 CUDA를 사용할 수 있는 여건이 되는지 확인해야 한다. 점검 사항은 GPU의 CUDA, 지원가능 리눅스 체계, GCC 설치 여부, 그리고 커널 버전 호환성을 확인한다. 본 내용은 NVIDIA CUDA Installation Guide for Linux (리눅스를 위한 NVIDIA CUDA 사전설치 점검사항)을 참조하였다.
- GPU의 CUDA 사용가능 여부 확인:
아래의 코드는 현재 리눅스 체계에서 인식한 GPU를 확인하는 터미널 명령어이지만 CUDA를 확인하지 않는다.
$ lspci | grep -i nvidiaCUDA 사용가능 여부 확인은 NVIDIA에서 제공하는 CUDA 사용가능한 GPU 목록을 확인해야 한다. 터미널에서 인식한 GPU가 목록에 없을 경우, 이는 컴퓨터가 CUDA를 사용할 수 없는 GPU를 탑재하였음을 의미한다. CUDA를 사용하기 위해서는 반드시 목록에 명시된 GPU를 사용해야 한다.
- 지원가능 리눅스 체계 여부 확인:
아래의 코드는 현재 리눅스가 어떠한 운영체계 기반 하에 돌아가고 있는지를 확인한다.
$ uname -m && cat /etc/*release
CUDA를 사용하기 위해서는 적어도 운영체계는 64비트이어야 한다. 지원 가능한 리눅스 운영체계 내용은 시스템 요구사항 내용을 참고하도록 한다.
- 시스템 GCC 설치 여부 확인:
아래의 코드는 현재 리눅스 시스템에 개발에 사용될 GCC가 설치되었는지 확인한다.
$ gcc -v
GCC가 설치되지 않았으면 개발에 필요한 패키지인gcc및g++그리고make등을 설치하는 아래의 명령어를 입력한다.$ sudo apt install build-essential
만일 GCC만 설치하기를 원하면sudo apt-get install gcc명령어를 입력하여 GCC만 설치할 수 있다.
- 리눅스 커널의 버전 호환성 확인:
컴퓨터의 하드웨어와 직접적으로 상호작용을 하는 가장 작은 단위의 업데이트 가능한 소프트웨어를 커널(kernel)이라고 부른다. 이 커널이 제대로 작동하기 위해서는 동일한 버전의 커널 헤더 (kernel-header) 및 커널 개발 패키지(kernel development package; kernel-devel)가 필요하다.
커널 헤더는 리눅스 커널 전용의 C 헤더 파일을 담고 있으며, 커널을 컴파일하는데 시스템 환경 정의 및 커널과 상호작용하는 코드에 다양한 함수를 제공한다. 커널 개발 피키지는 커널을 컴파일하고 커널의 일부로써 실행될 파일(예. 커널 모듈)을 담는 파일 패키지이다. 즉, 커널은 NVIDIA GPU 하드웨어를 정상적으로 실행하기 위해서 반드시 확인해야 하는 사항이다. 잘못된 커널 버전의 설치는 GPU의 정상적 실행을 보장하지 않는다.
현재 리눅스에서 사용 중인 커널은 아래의 명령어로 확인할 수 있다.$ uname -r
이를 토대로 커널 버전에 맞는 커널 헤더 및 커널 개발 패키지를 다음 명령어를 통해 설치한다.$ sudo apt-get install linux-headers-$(uname -r)
위의 점검사항이 모두 확인되었으며 CUDA 설치가 가능하다고 판단될 시, CUDA Toolkit 10.0 Archive 웹페이지에서 안내하는 절차를 그대로 이행한다. 아래는 .deb 확장장 (network) 방식을 채택하여 설치하였으며, .run 확장자는 다루지 않았다.
$ sudo dpkg -i cuda-repo-ubuntu1804_10.0.130-1_amd64.deb $ sudo apt-key adv --fetch-keys https://developer.download.nvidia.com/compute/cuda/repos/ubuntu1804/x86_64/7fa2af80.pub $ sudo apt-get update $ sudo apt-get install cuda-10-0.deb 확장자 파일로 설치를 하되 라이브러리 패키지를 CUDA 10.0으로 유지시키기 위해서는 마지막 4단계에서
sudo apt-get install cuda-10-0이라고 명시를 해야한다. 이를 명시하지 않을 경우 자동적으로 CUDA가 새 버전 출시 시 업그레이드되는 불상사를 격게 된다.
위의 절차를 정상적으로 마쳤으면 CUDA 10.0 Toolkit 및 그래픽 드라이버가 설치되었을 거다. CUDA 10.0이 제대로 설치되었는지 확인하기 위해서는 아래의 명령어로 확인한다:
$ cat /usr/local/cuda/version.txt마지막 4단계에서
cuda-10-0이라고 명시를 하였으면 CUDA VERSION 10.0.130과 같이 CUDA 10.0이라고 나타나지만, 라이브러리를 명시하지 않았으면 더 높은 버전의 CUDA가 설치되었을 거다.
POWER9 문서 내용은 무시하면 되며, 이에 대한 설명은 아래와 같다.
NVIDIA에서 제공한 CUDA 설치 문서에서는 POWER9은 설치 이후에 반드시 점검해야 하는 사항이라고 설명한다. 심지어 POWER9 요소를 처리하지 않을 시 CUDA 드라이버는 실행되지 않는다고 하지만, POWER9는 간단히 설명하자면 IBM에서 제작한 고성능 서버용 CPU이다. 심지어 대부분 사용자들은 자신들이 사용하는 CPU가 POWER9인지도 모르는 상황에서 NVIDIA가 거의 포괄적으로 일반화하여 반드시 작업하라거 설명한 것은 NVIDIA의 문서작성에 문제가 있음을 지적한다.
참조: NVIDIA Forum: Power9 for Ubuntu16.04
CUDA 10.0 검증
검증을 위해 작업 중인 현재 터미널 창에 일시적 환경변수를 설정한다. 명령어 export를 통해 현재 터미널 창에서만 일시적 환경변수를 지정해 주고 이후 해당 터미널에서 실행되는 모든 프로세스에서도 설정한 환경변수를 바로 사용할 수 있도록 한다. 즉, 실수로 터미널 창을 닫았다면 아래의 명령어를 다시 입력해 주어야 한다는 의미이다.$ export PATH=/usr/local/cuda-10.0/bin${PATH:+:${PATH}}
CUDA Toolkit이 제대로 설치되었는지를 버전을 확인하여 알아볼 수 있다.
$ nvcc -V위의 명령어가 작동하지 않으면 방금 전에 언급한 환경변수 설정을 잘못한 것이다.
echo $PATH 명령어를 통해 경로를 제대로 설정하였는지 확인한다.
CUDA Toolkit를 설치하는 과정에서 그래픽 드라이버도 같이 설치된다. 그래픽 드라이버 확인은 아래의 명령어로 확인할 수 있다.
$ cat /proc/driver/nvidia/version위의 명령어가 작동하지 않으면 리눅스를 재부팅을 해본다. 그래도 여전히 문제가 생기면 Secure Boot가 활성화되어 있음을 의심해야 한다. BIOS에 들어가 제대로 꺼져있는지 확인하며, CUDA 및 그래픽 드라이버 재설치는 필요없다.
CUDA 및 그래픽 드라이버 버전을 확인한 것으로 설치가 제대로 되었으며, 컴퓨터에서 정상 작동한다는 보장을 할 수 없다. Ubuntu 18.04.02 LTS 기준으로 CUDA를 설치하면
/usr/local/cuda-10.0/samples에 CUDA 샘플을 돌릴 수 있는 파일들이 존재한다. 이들을 ~/NVIDIA_CUDA-10.0_Samples 경로로 복사하여 빌드를 한다.
$ mkdir ~/NVIDIA_CUDA-10.0_Samples $ cd ~/NVIDIA_CUDA-10.0_Samples $ cp -r /usr/local/cuda-10.0/samples/* . $ make빌드를 완료했으면
./bin/x86_64/linux/release/deviceQuery를 실행시킨다. 아래는 실행 시 나타난 하나의 예제이다.
./deviceQuery Starting...
CUDA Device Query (Runtime API) version (CUDART static linking)
Detected 1 CUDA Capable device(s)
Device 0: "GeForce GTX 1070"
CUDA Driver Version / Runtime Version 10.1 / 10.0
CUDA Capability Major/Minor version number: 6.1
Total amount of global memory: 8112 MBytes (8505524224 bytes)
(15) Multiprocessors, (128) CUDA Cores/MP: 1920 CUDA Cores
GPU Max Clock rate: 1683 MHz (1.68 GHz)
Memory Clock rate: 4004 Mhz
Memory Bus Width: 256-bit
L2 Cache Size: 2097152 bytes
Maximum Texture Dimension Size (x,y,z) 1D=(131072), 2D=(131072, 65536), 3D=(16384, 16384, 16384)
Maximum Layered 1D Texture Size, (num) layers 1D=(32768), 2048 layers
Maximum Layered 2D Texture Size, (num) layers 2D=(32768, 32768), 2048 layers
Total amount of constant memory: 65536 bytes
Total amount of shared memory per block: 49152 bytes
Total number of registers available per block: 65536
Warp size: 32
Maximum number of threads per multiprocessor: 2048
Maximum number of threads per block: 1024
Max dimension size of a thread block (x,y,z): (1024, 1024, 64)
Max dimension size of a grid size (x,y,z): (2147483647, 65535, 65535)
Maximum memory pitch: 2147483647 bytes
Texture alignment: 512 bytes
Concurrent copy and kernel execution: Yes with 2 copy engine(s)
Run time limit on kernels: Yes
Integrated GPU sharing Host Memory: No
Support host page-locked memory mapping: Yes
Alignment requirement for Surfaces: Yes
Device has ECC support: Disabled
Device supports Unified Addressing (UVA): Yes
Device supports Compute Preemption: Yes
Supports Cooperative Kernel Launch: Yes
Supports MultiDevice Co-op Kernel Launch: Yes
Device PCI Domain ID / Bus ID / location ID: 0 / 1 / 0
Compute Mode:
< Default (multiple host threads can use ::cudaSetDevice() with device simultaneously) >
deviceQuery, CUDA Driver = CUDART, CUDA Driver Version = 10.1, CUDA Runtime Version = 10.0, NumDevs = 1
Result = PASS
본 내용에서 확인해야 할 내용은 세 가지이다:
- CUDA 사용 가능한 장치 탐색여부:
Detected 1 CUDA Capable device(s) - 시스템에서 사용하고 있는 장치가 맞는지 확인 여부:
Device 0: "GeForce GTX 1070" - 최종적 샘플 시험 결과:
Result = PASS
./bin/x86_64/linux/release/bandwidthTest를 통해 대역폭 시험을 실행한다. 아래는 위와 동일한 시스템 및 그래픽 장치에서의 대역폭 시험 결과를 보여준다.
[CUDA Bandwidth Test] - Starting... Running on... Device 0: GeForce GTX 1070 Quick Mode Host to Device Bandwidth, 1 Device(s) PINNED Memory Transfers Transfer Size (Bytes) Bandwidth(MB/s) 33554432 12486.8 Device to Host Bandwidth, 1 Device(s) PINNED Memory Transfers Transfer Size (Bytes) Bandwidth(MB/s) 33554432 12776.3 Device to Device Bandwidth, 1 Device(s) PINNED Memory Transfers Transfer Size (Bytes) Bandwidth(MB/s) 33554432 192464.5 Result = PASS NOTE: The CUDA Samples are not meant for performance measurements. Results may vary when GPU Boost is enabled.본 내용에서 확인해야 할 내용은 두 가지이다:
- 호스트 시스템 및 장치들의 그래픽 장치와의 통신으로 측정값이 나왔는지 확인 여부.
- 최종적 대역폭 시험 결과:
Result = PASS
CUDA 10.0 제거
CUDA를 정상적인 절차를 거쳐 제거하기 위해서는 Toolkit 및 드라이버를 모두 삭제해야 한다. 아래는 .deb 확장자 파일로 설치한 경우 각각 CUDA 10.0 Toolkit 및 드라이버를 삭제하는 명령어이다.$ sudo apt-get --purge remove "*cublas*" "cuda*" $ sudo apt-get --purge remove "*nvidia*".run 확장자로 설치하였을 경우는 삭제 방법이 다르므로 문서를 확인하도록 한다.
라이브러리: OpenCV 4.0.1
이미지처리의 대표적인 라이브러리로 OpenCV를 뽑을 수 있다. OpenCV 4는 2018년에 출시된 C++11로 작성된 라이브러리이므로, 이전 버전의 OpenCV 3와의 차이점이라면 C 언어 API가 사라졌다는 것이다. OpenCV 라이브러리가 정식으로 C++ 위주로 작성되었다는 점을 제외하고는 이전의 버전과 큰 차이는 없다. 또한 CUDA 코어의 병렬처리로 계산시간을 확연히 줄이기 위해 필요한 CUDA 라이브러리 버전과의 호환성이 아직까지 유효하다는 점에서 OpenCV 4.0.1을 선택하였다.
OpenCV 4.0.1 설치
OpenCV 4.0.1에 대한 설치 방법은 OpenCV 웹사이트에서도 명시되어 있으나, 본 문서에서는 각 절차에 대한 설명과 해석을 담아 이해를 도울 것이다. 설치는 Ubuntu 10.04을 통해서만 검증되었으므로, Ubuntu 18.04 LTS에도 작동할 수 있으나 일부 설치 과정에서는 문제가 생길 수가 있다. 그러므로 본 문서는 설치 중 발생할 수 있는 오류에 대한 대안과 주의사항을 알려주기 위해 작성되었다.OpenCV 4.0.1를 설치하기 위해 필요한 라이브러리 및 패키지를 아래의 명령어를 통해 설치한다.
$ sudo apt-get install build-essential $ sudo apt-get install cmake git libgtk2.0-dev pkg-config libavcodec-dev libavformat-dev libswscale-dev $ sudo apt-get install python-dev python3-dev python-numpy python3-numpy libtbb2 libtbb-dev libjpeg-dev libpng-dev libtiff-dev libdc1394-22-dev위의 명령어에서 설치한 것은 순서대로 다음과 같다:
- 컴파일에 필요한
gcc및make명령어를 사용할 수 있도록 하는 패키지를 설치. - OpenCV를 설치하는데 직접적으로 필요한 라이브러리 및 패키지 설치.
- 그 외에 필수요소가 아닌 선택적 설치 요소이며 OpenCV에 사용하는데 유용한 패키지 설치.
python3-dev 및 python3-numpy가 추가되었으며, 이 패키지들이 있어야 OpenCV 설치를 Python3과 연동시켜 사용할 수 있다. 이 중에서 JasPer 관련 패키지 중 하나인 libjasper-dev는 비록 선택적 설치 요소로 되어 있으나, Ubuntu 17.0 이상부터 sudo apt-get install libjasper로 설치가 불가해졌다.
E: Unable to locate package libjasper-dev해당 JasPer 패키지를 설치하기 위해서는 이전 Ubuntu 버전의 패키지를 통해 설치하는 우회 방법을 적용할 수 있다.
$ sudo add-apt-repository "deb http://security.ubuntu.com/ubuntu xenial-security main" $ sudo apt update $ sudo apt install libjasper1 libjasper-dev
참조: GitHub: OpenCV Issue #8622
본격적으로 설치를 진행하기 전에 OpenCV 소스코드를 처리할 개별의 작업폴더를 만들기를 권장한다. 본 예시에서는 작업폴더를
OpenCV라고 지정하였다. 그 안에 wget 명령어를 통해 OpenCV 설치에 필요한 소스파일들을 한꺼번에 다운로드할 수 있다.
$ mkdir ~/OpenCV $ cd ~/OpenCV $ wget -O opencv-4.0.1 https://github.com/opencv/opencv/archive/4.0.1.zip $ wget -O opencv_contrib-4.0.1.https://github.com/opencv/opencv_contrib/archive/4.0.1.zip $ wget -O opencv_extra-4.0.1 https://github.com/opencv/opencv_extra/archive/4.0.1.zip다운로드한 파일들은 다음과 같다.
opencv-4.0.1: OpenCV 4.0.1를 설치하는 주요 소스코드opencv_contrib-4.0.1: OpenCV 4.0.1에 추가적인 모듈을 제공하는 부가 소스코드opencv_extra-4.0.1: OpenCV 4.0.1 설치 검증용 파일
OpenCV 주요 소스코드
opencv-4.0.1 폴더 안에 설치에 필요한 Makefile 및 프로젝트 파일을 담을 임시 폴더 build를 생성하고 이동한다.
$ mkdir ~/OpenCV/opencv-4.0.1/build $ cd ~/OpenCV/opencv-4.0.1/build빌드의 첫 번째 단계로
cmake를 통해 Makefile 생성한다.
CUDA 10.0 샘플 설치 과정에서는 Makefile이 있어make명령어를 통해 컴파일하여 바로 빌드(build; 소스코드를 컴퓨터에서 실행할 수 있는 독립적 소프트웨어로 변환시키는 절차 혹은 그 결과물)를 생성하였으나, 이와 달리 OpenCV는 우선cmake명령어를 통해 빌드 환경을 구축하고 빌드를 생성한다.
이렇게 CMake이 사용되는 빌드에는 두 단계를 거쳐서 빌드가 이루어지는데, 이에 대한 장점은 이름에서 힌트를 얻을 수 있듯이 크로스-플랫폼 특징이다(Cross-platform Make). 일반적인 빌드에 필요한 Makefile은 시스템 아키텍처(MS 윈도우, 애플, 안드로이드 등)에 의존하므로 서로 다른 플랫폼에서는 마찬가지로 서로 다른 Makefile이 필요하다. 그러나 CMake가 있으면 시스템 아키텍처와 설정한 시스템 환경을 기반으로 적합한 Makefile을 생성한다.
cmake 명령어로 Makefile을 만드는데 설정할 시스템 환경은 다음과 같이 한다.
$ cmake -DCMAKE_BUILD_TYPE=Release \ -D CMAKE_INSTALL_PREFIX=/user/local \ -D OPENCV_EXTRA_MODULES_PATH=../../opencv_contrib-4.0.1/modules/ \ -D OPENCV_GENERATE_PKGCONFIG=ON \ # GUI and NVIDIA CUDA cache -D WITH_OPENGL=ON \ -D WITH_CUDA=ON \ -D WITH_CUFFT=ON \ -D WITH_CUBLAS=ON \ -D BUILD_opencv_cudacodec=OFF \ # Hardware acceleration and data transfer cache -D WITH_TBB=ON \ # Install verification cache -D BUILD_JAVA=OFF \ -D BUILD_EXAMPLES=OFF \ -D INSTALL_C_EXAMPLEs=ON \ -D INSTALL_PYTHON_EXAMPLES=ON \ # OpenCV-Python cache -D PYTHON_DEFAULT_EXECUTABLE=usr/bin/python3 \ ..CMake가 빈 폴더에 빌드를 시작하면 우선적으로
CMakeCache.txt를 생성한다. 이 파일 안에 -D 옵션으로 입력한 설정 캐시(cache)들이 들어가며 CMake 프로젝트 생성에 기여하게 된다 (예. 환경변수 등). 빌드 옵션들은 CMakeList.txt에서 확인할 수 있다.
빌드 캐시 중에서
-D OPENCV_GENERATE_PKGCONFIG는 사용이 권장되지 않는 캐시이며 곧 사용되지 않을 캐시이기도 한다. 일부 사용자들은 해당 캐시를 켜야만 OpenCV를 빌드할 수 있다고 하지만, 이는 사실이 아니다. 이에 대한 내용은 OpenCV 4.0.1 실행 - 실행법: C++에서 자세히 다뤄질 거다. 그러나 해당 캐시를 켜놓은 이유는 YOLOv3와 관련이 있다.
또한
BUILD_opencv_cudacodec=OFF 캐시는 반드시 해제하도록 한다: nvcuvid.h 헤더로부터 발생된 오류이며, 해당 헤더는 더이상 사용되지 않는다. 그러므로 빌드가 불가능한 모듈이기에 빌드 선택지에서 제외해야 한다.
터미널에서 명령어를 입력하는 방법 이외에 Ubuntu에서는 CMake를 GUI를 통해 손쉽게 캐시를 선택하고 해제할 수 있도록 Ubuntu Software에서 제공한다. CMake GUI로 빌드를 할 시에는 다음과 같이 설정한다.
Where is the source code:→/home/<username>/OpenCV/opencv-4.0.1Where to build the binarries:→/home/<username>/OpenCV/opencv-4.0.1/build
Configure 버튼을 누르면 Makefile 형식을 지정할 수 있으며, 일반적인 Unix Makefiles로 선택하여 진행한다. 프로그램은 빌드 디버깅으로 필요한대로 캐시 설정을 바꿔준다. 만일 PYTHON_DEFAULT_EXECUTABLE과 같이 목록에 없는 캐시는 Add Entry 버튼을 눌러 직접 추가한다. Makefile을 본격적으로 생성할 준비가 되었으면 Generate 버튼을 눌러 생성한다.
CMake를 통해 적합한 Makefile을 생성하였으면 컴파일을 시작한다. Makefile로 빌드를 생성하는 방법은 CUDA Toolkit 10.0 샘플 설치와 동일한 방법으로
make 명령어를 사용하면 되지만, OpenCV는 빌드를 여러 개의 스레드로 나누어 작업하는 것을 권장한다. 분할 작업으로 빠른 컴파일 처리를 위해 본 컴퓨터의 CPU 코어 개수는 아래의 명령어로 확인할 수 있다.
$ nproc --all본 컴퓨터는 코어 개수가 8개 이상으로 나왔으므로 작업을 7개로 분할시켜 컴파일을 진행한다.
$ cd ~/OpenCV/opencv-4.0.1/build $ make -j7컴파일 도중에 CUDA와 관련되어 다음과 같이 오류가 흔히 나타나는 것을 확인할 수 있다.
In file included from /home/gko95/OpenCV/opencv-4.0.1/modules/core/include/opencv2/core/cuda/functional.hpp:50:0,
from /home/gko95/OpenCV/opencv_contrib-4.0.1/modules/cudalegacy/src/cuda/fgd.cu:50:
/usr/local/cuda/include/device_functions.h:54:2: warning: #warning "device_functions.h is an internal header file and must not be used directly. This file will be removed in a future CUDA release. Please use cuda_runtime_api.h or cuda_runtime.h instead." [-Wcpp]
#warning "device_functions.h is an internal header file and must not be used directly. This file will be removed in a future CUDA release. Please use cuda_runtime_api.h or cuda_runtime.h instead."
^~~~~~~
본 내용을 해석하면 이는 다행이 오류가 아닌 경고문이다. 현재 사용되고 있는 모듈들은 device_functions.h 헤더를 사용하고 있는데 이는 차후 CUDA 버전에는 사용되지 않을 것이므로 cuda_runtime_api.h 혹은 cuda_runtime.h 헤더를 사용할 것은 당부하는 메시지이다. 아직은 device_functions.h가 CUDA 디렉토리에 존재하여 오류가 아닌 경고문에 그친거다.
컴파일은 OpenCV에 사용되는 수많은 라이브러리들이
~/OpenCV/opencv-4.0.1/build에 생성되었으나 아직 리눅스에 적용 가능하도록 설치되지 않았다. 아마 cmake_install.cmake가 라이브러리 설치를 담당하는 파일로 추정되며, 캐시에서 설정하였던 /usr/local 경로로 라이브러리들이 설치된다.
$ sudo make install라이브러리 설치 경로가 현재 작업 중이 폴더와 전혀 별개인 것을 보면 알 수 있듯이,
build 파일 전체적으로는 아무런 수정사항이 없다.
CMake 캐시 목록
아래는 OpenCV 4.0.1의 CMake 빌드 옵션에 대한 설명이며, 전부는 아니지만 눈여겨 볼 필요가 있는 몇 가지를 다룬다.| 환경설정 | 설명 |
|---|---|
CMAKE_BUILD_TYPE |
Release 타입: CMake로 시스템 아키텍처에 따라 최대한 최적화하여 정식 빌드 파일들을 생성한다.Debug 타입: CMake로 정식 빌드를 만들지 않고, 최적화 없이 빌드를 디버깅한다. 프로그래밍에서의 디버깅과 동일한 개념으로 볼 수 있다. |
CMAKE_INSTALL_PREFIX |
기본 CMake 설치 경로이다 (기본값: /usr/local). |
OPENCV_EXTRA_MODULES_PATH |
opencv_contrib 폴더의 추가모듈 경로를 입력받고 참고하여 빌드를 진행한다. |
OPENCV_GENERATE_PKGCONFIG |
pkg-config 빌드 도구를 위한 .pc 파일을 생성한다 (기본값: OFF); 사용 비권장. |
BUILD_DOCS |
OpenCV 빌드 규정 문서 생성한다 (기본값: OFF). |
아래는 영상과 관련된 빌드 옵션이다: V4L (Video4Linux)는 리눅스에서 실시간 영상을 위한 드라이버와 API를 종합적으로 제공한며, FFmpeg는 영상과 오디오, 그리고 그 외의 멀티미디어 파일을 다루는데 사용되는 다양한 소프트웨어 및 라이브러리를 제공한다. Xine은 유닉스-기반 OS (예. 리눅스, 맥OS)를 위한 멀티미디어 플레이어 프로그램이다.
| 환경설정 | 설명 |
|---|---|
WITH_V4L |
빌드 시 V4L (Video4Linux) 지원을 포함시킨다 (기본값: ON). |
WITH_FFMPEG |
빌드 시 FFmpeg 지원을 포함시킨다 (기본값: ON). |
WITH_XINE |
빌드 시 Xine 지원을 포함시킨다 (기본값: OFF). |
아래는 그래픽과 관련된 빌드 옵션이다: QT("cute"라고 읽음)란, GUI 및 다양한 플랫폼에서 동작시킬 수 있는 어플리케이션을 개발하는데 사용된다. GTK도 마찬가지로 GUI 개발에 사용되지만, QT는 완성된 프레임워크를 제공한다면 GTK는 GUI Toolkit를 제공한다. 둘 다 GUI를 지원하지만 QT를 설치하지 않았으므로 GTK 설정으로 유지한다. OpenGL(Open Graphic Library)는 2D 및 3D 벡터 그래픽을 렌더링하는데 사용되는 API를 지원하는 라이브러리이며, GPU와 상호작용하여 동작한다. CUDA 지원 빌드 여부도 존재하며, CUDA를 사용하는 본 프로젝트의 경우에는 CUDA와 관련된 모든 빌드 옵션은 켜두기를 권장한다.
| 환경설정 | 설명 |
|---|---|
WITH_QT |
빌드 시 QT 백엔드 지원을 포함시킨다. |
WITH_GTK |
빌드 시 GTK 지원을 포함시킨다. |
WITH_OPENGL |
빌드 시 OpenGL(Open Graphic Library) 지원을 포함시킨다. |
WITH_CUDA |
빌드 시 NVIDIA CUDA Runtime 지원을 포함시킨다. |
WITH_CUFFT |
빌드 시 NVIDIA CUDA Fast Fourier Transform (FFT) 라이브러리 지원을 포함시킨다. |
WITH_CUBLAS |
빌드 시 NVIDIA CUDA Basic Linear Algebra Subprogram (BLAS) 라이브러리 지원을 포함시킨다. |
다음은 하드웨어 성능과 관련된 빌드 옵션이다: TBB(Threading Building Blocks)란, 멀티코어 프로세서에서 병렬 컴퓨팅을 위해 인텔에서 개발한 C++ 템플릿 라이브러리이다. 즉, 하나의 컴퓨팅을 작은 단위의 작업으로 나누어서 처리할 수 있도록 한다. 인텔에서 개발한 또다른 멀티스레딩 소프트웨어 라이브러리인 IPP(Integrated Performance Primitives)는 멀티미디어 및 데이터 처리 어플리케이션에 특화되었다. IEEE 1394는 고속통신 및 동기식 실시간 데이터 전송을 위한 직렬 통신 인터페이스 기준을 의미한다. 이는 USB 통신과 비교가 되며, 비록 2.0에 비해서는 전송속도가 빠르지만 3.0부터는 USB가 우위를 차지하였다.
| 환경설정 | 설명 |
|---|---|
WITH_TBB |
빌드 시 인텔의 TBB 지원을 포함시킨다 (기본값: OFF). |
WITH_IPP |
빌드 시 인텔의 IPP 지원을 포함시킨다 (기본값: OFF). |
WITH_1394 |
빌드 시 IEEE 1394 지원을 포함시킨다 (기본값: ON). |
다음은 OpenCV 설치 후 점검을 위한 빌드 옵션이다.
| 환경설정 | 설명 |
|---|---|
BUILD_EXAMPLES |
OpenCV 예시 전체를 설치한다; C, Python, Android (기본값: OFF). |
INSTALL_C_EXAMPLES |
C 언어 기반의 OpenCV 예시 파일들을 함께 설치한다 (기본값: OFF). |
INSTALL_PYTHON_EXAMPLES |
Python 기반의 OpenCV 예시 파일들을 함께 설치한다 (기본값: OFF). |
명령어의 맨 마지막에
..은 상위폴더를 의미한다: 현재 위치한 폴더는 ~/OpenCV/opencv-4.0.1/build이며 CMakeList.txt 파일은 ~/OpenCV/opencv-4.0.1에 있기 때문에 상위폴더로 이동한 것이다.OpenCV 4.0.1 검증
OpenCV 웹사이트에서는 OpenCV가 제대로 설치되었는지 확인하는 절차를 설명한다. 설치 절차에서 받은 세 개의 파일 중에서opencv_extra-4.0.1 파일이 여기에서 사용된다. 설치 점검을 위해서는 CMake 단계에서 반드시 BUILD_TEST=ON으로 옵션을 설정해야 한다. 설정하지 않을 시, opencv_test_core이라는 파일이 생성되지 않아 설치 점검이 불가능하다.설치 점검 전에 사용될 시험데이터들을 환경변수로 불러와야 한다.
$ export OPENCV_TEST_DATA_PATH=/home/<username>/OpenCV/opencv_extra-4.0.1/testdata환경변수 추가는
export 없이도 할 수 있으나 프로세스에 바로 적용되지 않아 시험이 실패한다고 한다.점검 시험에 필요한 파일 위치는
opencv-4.0.1/build/bin/opencv_test_core에 있다.
$ ./bin/opencv_test_core이 중에서 시험 실패 내용이
Core_globbing.accuracy와 연관되었다면 이는 환경변수 설정가 제대로 되지 않은 것이므로 환경변수를 다시 한 번 확인할 필요가 있다.
OpenCV 4.0.1 실행
설치 검증도 중요하지만, OpenCV는 실질적이면서도 시각적으로 실행되는 것을 확인할 수 있는 유틸리티 프로그램이다. OpenCV를 개발 용도에 맞게 사용할 수 있어야 하며, 본 내용은 기본적인 OpenCV 실행법에 대하여 설명한다. 두 가지의 부문으로 나눌 것이며 전자는 C++, 그리고 후자는 Python3에서의 실행법을 다룬다.실행법: C++
C++ 언어로 작성된 OpenCV 예제코드는OpenCV/opencv-4.0.1/samples/cpp 내에 들어있으며, 그 중에서 본 문서는 얼굴인식인 facedetect 파일을 실행을 목표한다. 그러나 아직 프로그래밍 언어로 작성된 .cpp 파일로 존재하며, 실행 가능한 오브젝트 파일로 컴파일 해야 한다.컴파일을 하는 대표적인 방법으로는
gcc 혹은 g++이 있다. 이들은 build-essential 설치에 이미 포함되어 있어 별도로 설치할 필요가 없다. GNU Compiler Collection으로, 이들은 여러 프로그래밍 언어를 지원해주는 컴파일러 프로그램으로, 전자는 C 및 C++ 언어 컴파일러라면 후자는 C++ 전용 컴파일러인 차이점이 있다.
gcc 'pkg-config --cflags --libs <file_name>'
pkg-config를 사용하면 어떠한 OS나 배포판이든 컴파일을 하는데 필요한 라이브러리 및 링크할 라이브러리들을 바로 가져와 컴파일을 더 쉽게 진행할 수 있다. 이는 각 다른 OS 및 배포판이 컴파일 플래그가 각자 다르다는 점을 고려하면 pkg-config는 gcc 컴파일을 더욱 쉽게 한다.
그러나 최근 버전의 OpenCV는 빌드 옵션에서 기본적으로pkg-config이란, 소프트웨어가 컴파일하는데 필요한 설치된 라이브러리를 조회하는 컴퓨터 프로그램이다. 라이브러리가 설치되면 .pc 확장자 파일이 생성된다. 아래는libpng라이브러리의 .pc 파일을 예시로 사용하여 확인하자.prefix=/usr/local exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${exec_prefix}/include Name: libpng Description: Loads and saves PNG files Version: 1.2.8 Libs: -L${libdir} -lpng12 -lz Cflags: -I${includedir}/libpng12위의 코드는 환경변수이며libdir및 >includedir은 각각libpng라이브러리와 헤더 파일이 위치한 경로를 의미한다. 이름과 버전은libpng및1.2.8이다. 프로그램이 본 패키지를 사용하는데 있어 추가적으로 컴파일이 필요한 종속 라이브러리 목록을 나열한다.Cflags는 반드시 필요한 컴파일러 flag이며,-I는 include path 플래그를 의미한다. (여기에서 플래그(flag) 값이란 컴퓨터 과학에서 함수나 프로세스의 흐름을 제어하는 값을 뜻한다.)
Libs는 컴파일러 링크 플래그를 담는다. Linker란, 컴퓨터 유틸리티 프로그램으로 컴파일러에서 생성된 하나 이상의 오브젝트 파일들을 하나의 실행파일 혹은 라이브러리 파일 또는 또다른 오브젝트 파일로 만든다.-L는 library path 플래그를 의미하며,-l은 라이브러리 이름 플래그이다.
OPENCV_GENERATE_PKGCONFIG=OFF로 설정되어 있어 pkg-config 지원이 처음부터 꺼져있다. pkg-config의 기능이 매우 제한적인 이유로 심지어 해당 옵션 자체가 차후에는 없어질 것으로 보인다(deprecated). 이전 버전의 OpenCV에 익숙한 유저들은 OPENCV_GENERATE_PKGCONFIG=ON으로 설정을 변경하여 사용하기를 추천하지만 권장되지 않은 방법이다.OpenCV에서 대신 CMake를 사용하여 예제코드를 빌드(컴파일 절차 포함)하기를 권장한다. 심지어 CMake를 사용할 수 있도록
opencv-4.0.1/samples 경로 안에는 CMakeList.txt 파일이 존재한다. 그러므로 우선 해야할 작업은 예제코드를 컴파일 할 수 있는 Makefile을 CMake로 생성해야 한다. 절차적 이해를 돕기위해 OpenCV/opencv_samples-4.0.1이란 새로운 폴더에 예제코드를 저장한다.
$ mkdir ~/OpenCV/opencv_samples-4.0.1 $ cd ~/OpenCV/opencv_samples-4.0.1 $ cmake ../opencv-4.0.1/samples혹은 OpenCV GUI를 사용한다면 다음과 같이 경로를 설정한다.
Where is the source code:→/home/<username>/OpenCV/opencv-4.0.1/samplesWhere to build the binarries:→/home/<username>/OpenCV/opencv_samples-4.0.1
OpenCV/opencv_samples-4.0.1에는 Makefile 및 컴파일에 필요한 파일들이 함께 생성된다. C++ 예제코드는 OpenCV/opencv_samples-4.0.1/cpp 안에 종합적으로 들어있으며, 그 안에는 얼굴인식을 담당하는 CMakeFiles/example_cpp_facedetect.dir 파일도 들어있다. Makefile이 있는 ./cpp 경로로 이동하여 컴파일을 진행한다.
$ cd cpp $ make그러면
OpenCV/opencv_samples-4.0.1/cpp에 C++ 예제코드 전체가 실행가능한 오브젝트 파일로 빌드된 것을 확인할 수 있다. 바로 이 파일들을 실행하여 사용하면 되지만, 실행 위치는 주요 소스코드가 있는 OpenCV/opencv-4.0.1이어야 한다. 이는 얼굴인식에 필요한 리소스들이 OpenCV/opencv-4.0.1/data 내에 들어있으며 상대주소가 적용되어있기 때문이다.
$ cd ../../opencv-4.0.1 $ ./../opencv_samples-4.0.1/cpp/example_cpp_facedetect웹캠이 장착되어 있은 컴퓨터라면 카메라 화면이 나타나 (인식률은 매우 낮지만) 얼굴을 인식한다. 만일 오브젝트 파일 실행 위치에 상관하지 않고 정상적인 작동을 원하면 추가 명령어를 넣어주어야 한다. 예를 들어
/home/<username>에서 바로 작동시켜보려고 하자.
$ cd ~ $ ./OpenCV/opencv_samples-4.0.1/cpp/example_cpp_facedetect --cascade="/home/<username>/OpenCV/opencv-4.0.1/data/haarcascades/haarcascade_frontalface_alt.xml" --nested-cascade="/home/<username>/OpenCV/opencv-4.0.1/data/haarcascades/haarcascade_eye_tree_eyeglasses.xml"명령어 중에서
--cascade 및 --nested-cascade는 원래 소스코드에서 입력 데이터를 받을 수 있는 변수 cascade와 nested_cascade로, cv::CommandLineParser에서 확인할 수 있다(그러면 scale이란 변수도 존재함을 알 수 있다). 바로 이들이 OpenCV/opencv-4.0.1/data 내에 위치한 얼굴인식에 필요한 리소스들이다.실행법: Python3
Python3 파일 실행법은 간단하다. 컴파일 작업 필요없이 바로 해당 파일을 바로 실행시키면 된다. 그러기에 CMake 등을 통한 빌드 작업이 불필요하며, 바로OpenCV/opencv-4.0.1/samples/python 안에 있는 파일을 실행하면 된다. 여기에서 얼굴인식인 facedetect.py 실행에는 Python3을 통해 실행되어야 한다.
$ cd ~/OpenCV/opencv-4.0.1 $ python3 /home/<username>/OpenCV/opencv-4.0.1/samples/python/facedetect.py그러나 본 소스코드는 독립적으로 실행될 수 없으며, 외부 스크립트를 모듈로 가져와 사용하기 때문이다.
facedetect.py를 사용하기 위해서 필요한 소스코드 파일은 동일한 폴더에 들어있는 video.py, common.py 그리고 tst_scene_render.py이다.마찬가지로 다른 위치에서 정상적인 실행을 원하며 다음과 같이 변수를 입력해 주어야 한다.
$ python3 /usr/local/share/opencv4/samples/python/facedetect.py --cascade "/usr/local/share/opencv4/haarcascades/haarcascade_frontalface_alt.xml" --nested-cascade "/usr/local/share/opencv4/haarcascades/haarcascade_eye_tree_eyeglasses.xml"
OpenCV 4.0.1 제거
본 프로젝트는 YOLOv3 학습 모델을 OpenCV에 사용할 수 있도록 하기 위해서는 OpenCV 3.4.2 이상이어야 한다. 그러나 JetPack 4.2는 자동적으로 3.3.1을 설치하는 관계로 새로 설치해야 할 필요가 있다. 그 전에 충돌을 방지하기 위해 JetPack 4.2로부터 설치된 OpenCV 3.3.1을 우선적으로 제거해야 한다.설치할 때에는 빌드 경로에서
sudo make install 명령어를 통해 컴파일로 통해 생성된 라이브러리들을 /usr/local에 설치하였다. 설치한 라이브러리들을 제거하기 위해서는 동일한 빌드 경로로 이동하고 아래의 명령어로 OpenCV 라이브러리들을 제거할 수 있다.
$ sudo make uninstall위의 방법은 빌드 경로를 알고 있을 경우 OpenCV를 제거하는 정석이다. 그러나 NVIDIA JetPack 4.2로부터 설치된 OpenCV는 빌드 경로를 알 수 없어 직접 OpenCV 파일들을 하나씩 찾아서 삭제해야 한다. OpenCV 파일을 전부 찾아 제거하는 터미널 명령어는 다음과 같다.
$ sudo find / -name "*opencv*" -exec rm -i {} \;
만일 탐색한 파일들이 무엇인지 확인하기 위해서는 뒤에 있는 제거 명령어 -exec rm -i {} \; 무시하고 입력하면 볼 수 있다.
알고리즘: YOLOv3
YOLOv3는 현재까지 물체인식 중에서 최고의 효율성을 자랑하는 알고리즘이다. YOLOv3는 라이브러리나 소프트웨어가 아닌 알고리즘인 관계로 개별적인 설치는 불가능하며, Darknet이란 프레임워크를 통해 사용해야 한다. 비록 Darknet 설치가 필수라도 CUDA 및 OpneCV와의 연동이 가능하다. 즉, CUDA 가속으로 전산처리가 빨라진 OpenCV의 이미지처리 효율을 YOLOv3 알고리즘을 결합하여 사용할 수 있다.
YOLOv3 설치
본 내용은 물체인식 알고리즘 YOLOv3를 사용하기 위해 필요한 Darknet 설치법을 설명한다.OpenCV와 마찬가지의 이유로, Darknet 전용의 개별 작업경로를 홈 디렉토리에 생성하고, 인터넷에서 Darknet 빌드에 필요한 파일들을 다운로드한다. 다운로드를 마친 파일을 빌드하기 이전까지 과정을 아래의 명령어로 처리한다
$ mkdir ~/Darknet $ cd Darknet $ git clone https://github.com/pjreddie/darknet.git $ cd darknet빌드를 진행하기 전에 설치한 CUDA와 OpenCV 설정하기 위해 Makefile을 아래와 같이 수정한다.
GPU=1 CUDNN=0 OPENCV=1 OPENMP=0 DEBUG=0우선 CUDA와 관련된
GPU=1 설정 아래에 빌드를 진행하기 전에는 CUDA 10.0 검증에서 사용했던 환경변수를 다시 한 번 넣어주어야 한다. Darknet이 nvcc 경로를 찾으려고 하는데 환경변수 없이는 찾을 수가 없기 때문이다. 그 외에는 GPU 설정은 아무런 문제가 없다.문제는 바로 OpenCV와의 버전 호환성이다. 여기에서 만일 OpenCV 캐시 중
OPENCV_GENERATE_PKGCONFIG=OFF로 해제되어 있다면 .pc 확장자 파일이 생성되지 않는다. Darknet은 OpenCV가 있는지를 패키지 설정 내용이 들어있는 .pc 파일을 통해 확인하나 해당 파일이 존재하지 않으면 OpenCV를 접목시킬 수가 없다. 그러한 이유로 OpenCV 설치에서 OPENCV_GENERATE_PKGCONFIG=ON 설정이 필수이다.그렇지만 아무리 .pc 확장자 파일이 있더라도 빌드는 오류와 함께 실패한다. 오류이 내용은 다음과 같다:
Package opencv was not found in the pkg-config search path.
Perhaps you should add the directory containing `opencv.pc'
to the PKG_CONFIG_PATH environment variable
No package 'opencv' found
./src/image_opencv.cpp:5:10: fatal error: opencv2/opencv.hpp: No such file or directory
#include "opencv2/opencv.hpp"
^~~~~~~~~~~~~~~~~~~~
compilation terminated.
Makefile:86: recipe for target 'obj/image_opencv.o' failed
make: *** [obj/image_opencv.o] Error 1
다시말해, Darknet은 opencv.pc를 찾도록 되어있으나 OpenCV 4.0.1을 설치하면 opencv4.pc가 생성되어 찾지를 못하고 있다. 이를 해결하기 위해서는 Makefile 내용 중에서 pkg-config가 찾을 파일을 opencv.pc에서 opencv4.pc로 변경한다.
ifeq ($(OPENCV), 1) COMMON+= -DOPENCV CFLAGS+= -DOPENCV LDFLAGS+= `pkg-config --libs opencv4` -lstdc++ # Originally `pkg-config --libs opencv` COMMON+= `pkg-config --cflags opencv4` # Originally `pkg-config --cflags opencv` endif하지만 곧 이어 다른 오류가 발생한다.
./src/image_opencv.cpp:12:1: error: ‘IplImage’ does not name a type; did you mean ‘image’? IplImage *image_to_ipl(image im) ^~~~~~~~ image compilation terminated due to -Wfatal-errors. Makefile:86: recipe for target 'obj/image_opencv.o' failed make: *** [obj/image_opencv.o] Error 1해당 오류는 OpenCV에서 제공하던 C 언어 API 중 하나인
IplImage 구조체 자료형을 더이상 지원하지 않으면서 발생한 문제이다. 이는 IplImage에만 극한된 게 아니며 OpenCV가 전체적으로 C 언어 라이브러리에서 C++ 라이브러리로 전환되면서 나타난 현상이다. 이를 해결하기 위해서 사용자는 직접 C 언어 API를 C++ 언어 API인 cv::Mat로 변경해주어야 한다.
참조: Darknet Issue #1347, #1348 (문제 및 해결방안)
이 두 문제를 해결하는 방법으로 darknet-fix-opencv-4.patch 패치를 GitHub에서 찾을 수 있다. 본 패치는 Darknet 빌드를 OpenCV 4 이상의 버전에 적용시킬 수 있도록 하며, 비록 YOLOv3 개발자가 만든 패치가 아니지만 마이크로소프트 직원이 수정한 것으로 충분한 신빙성이 있다.
$ mv darknet-fix-opencv-4.patch ~/Darknet $ patch -p1 < ../darknet-fix-opencv-4.patch여기에서
-p1이란, patch 파일에 명시된 경로에서 첫 번째 주소를 제외해서 진행한다는 의미이다. 이해를 돕기 위해 해당 패치 내용을 예시로 본다:
diff --git a/Makefile b/Makefile index 63e15e6..c148d4b 100644 --- a/Makefile +++ b/Makefile @@ -42,8 +42,8 @@ CFLAGS+=$(OPTS) ifeq ($(OPENCV), 1) COMMON+= -DOPENCV CFLAGS+= -DOPENCV -LDFLAGS+= `pkg-config --libs opencv` -lstdc++ -COMMON+= `pkg-config --cflags opencv` +LDFLAGS+= `pkg-config --libs opencv 2> /dev/null || pkg-config --libs opencv4` -lstdc++ +COMMON+= `pkg-config --cflags opencv 2> /dev/null || pkg-config --cflags opencv4` endif여기에서
a/Makefile은 패치 이전의 Makefile이고, b/Makefile은 패치 이후의 Makefile이며, 이들 경로의 첫 번째 주소인 a와 b를 제외하게 된다. 결과적으로, 만일 ~/Darknet/darknet에서 터미널을 실행하였으면 본 주소는 ~/Darknet/darknet/Makefile이 되는 셈이다. 다시 말해, -p1은 여러 파일 및 하위폴더가 존재하는 파일에 패치를 적용하는데 사용된다.위의 모든 설정이 완료되었으면 빌드를 시작한다.
$ cd ~/Darknet/darknet $ make컴파일 도중에서
nvcc 문제가 발생하였으면 CUDA 10.0 환경변수 설정을 다시 한 번 확인하기를 바란다.다음과 같이
ldconfig 명령어를 입력을 하여 커널이 사용할 동적 링크 라이브러리 목록을 파일을 빌드한다. 본 단계는 Darknet 웹사이트에서 언급된 절차는 아니며, 이는 일부 컴퓨터에서 나타날 오류를 해결하기 위한 것이다.
$ sudo ldconfig이를 마무리로 Darknet 프레임워크 설치는 마무리된다.
YOLOv3 검증 및 실행
아래는 OpenCV와의 연동을 시험하는 절차이다. 해당 명령어는 여러장의 독수리 사진이 나타나게 한다.$ ./darknet imtest data/eagle.jpg일부 컴퓨터는 다음 오류가 나타날 수 있다.
./darknet ./darknet: error while loading shared libraries: libopencv_highgui.so.3.4: cannot open shared object file: No such file or directory이는 커널의 동적 링크 라이브러리 접속과 관련된 문제이므로
ldconfig 명령어로 이를 해결할 수 있다.
진짜 너무 많은 도움되었습니다 좋은글 감사드립니다.
ReplyDelete