CODERNER

C++로 코드를 구현하던 중 갑자기 다음와 같은 오류가 났다. terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Aborted (core dumped) 보통 힙 메모리 부족할 때 발생하는 오류인데, 딱히 동적 할당을 무한히 반복하거나 객체 생성을 무한히 하는 것도 아닌데 갑자기 메모리 부족하다고 떴다. 메모리 사용이 폭발적으로 증가하는 병목 지점을 찾아보니 cv::cvtColor() 호출 지점이었다. cv::Mat cvimg = cv::imread(img_path); cv::Mat cvimg_gray; cv::cvtColor(cvimg, cvimg_gray, cv::COLOR_BGR2GRAY); //..

내 맘대로 Introduction 이 논문은 DDPM의 분석 보고서라고 볼 수 있다. DDPM이라는 논문에서 제시한 파라미터 하나 하나를 뜯어보면서 어떻게 바꿨을 때 향상이 있었는지 보여주고, trade-off 관계가 있다면 경향이 어떤지 보여주는 논문이다. 정말 보고서와 같은 논문인다. 핵심적인 아이디어는 따라서 없다. 사실 이제는 쓸모 없는 내용도 많아서 그냥 대충 읽어도 될 것 같다. 말이 너무 많다ㅠ 메모하며 읽기 DDPM을 분석하는 논문답게 DDPM 수식을 상당히 자세하게 recap하고 시작한다. 첫번째로 주목한 점은 DDPM 은 reverse process distribution을 찾아나갈 때 mean 값만 집중하지 std값은 특정값으로 가정해버리면서 버린다는 점이다. (실험적으로 특별하지 않..

내 맘대로 Introduction 이 논문은 DDPM이 전개한 식 (w/ Markov chain 가정)을 관찰한 결과, non-Markovian 식으로도 전개할 수 있다는 것을 발견하고 식을 정립한 논문이다. 이전 time stamp만이 현재 time stamp 결과를 결정하는 관계 (markovian)에서 원본 이미지 + 이전 time stamp가 현재 time stamp를 결정하는 관계로 모델링하면서 문제를 다르게 풀었다. 이 논문이 역작으로 꼽히는 이유는 모델링 방법을 바꿨음에도 수식을 전개하다보면 결국 DDPM과 같은 결론을 얻게 된다는 것을 증명했고, 본인들이 전개한 식의 특수 케이스가 DDPM 식이라는 것도 밝혀냈다. 한마디로 DDPM을 부분 집합으로 보게 만들어 버릴만한 더 큰 집합을 찾아낸..

기본적으로 작성하면서 꼭 이해해야 될 것 같다고 생각한 내용들을 적어두고, 나중에 복붙하기 편하게 정리해두고자 한다. 1) C 버전 지정 if (NOT CMAKE_C_STANDARD) set(CMAKE_C_STANDARD 99) endif() 웬만하면 최신 99 사용하면 된다. 2) C++ 버전 지정 if (NOT CMAKE_CXX_STANDARD) set(CMAKE_CXX_STANDARD 20) endif() C++부터는 버전을 좀 봐야 함. 98, 11, 14, 17, 20, 23, 26 존재함. 대충 20쓰는 것 좋을 듯함. 3) compile option 지정 if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang") add_com..

${ROOT} |-app | |-CMakeLists.txt (3) |-core | |-CMakeLists.txt (2) |-CMakeLists.txt (1) 모든 코드가 CMakeLists.txt 파일 하나로 정리되지는 않는다. 가능은 하다만 팩토링 측면에서 너무 길고 지저분해지므로 권장되는 방식이 아니다. 보통 C++ 프로젝트를 작성할 때 위와 같이 나누곤 하는데 최소 3개로 나누어서 사용한다. CMakeLists.txt (1) (1)의 경우, 프로젝트 전체를 한 번에 build할 때 사용되는 CMakeList로써 큰 설정들만 들어간다. find_package : 프로젝트 전체에 걸쳐 쓰일 것 cmake_module : find_package 실패에 대비한 FindXXX.cmake 파일 추가 pkg_s..

find . -name "FILE_NAME" -type f find . -name "DIRECTORY_NAME -type d find . -empty find . -name "FILE_NAME" -delete Linux에서 파일 경로 찾는 일이 생각보다 빈번한데 root 위치에서 find 커맨드를 이용하면 손쉽게 찾을 수 있다. 자주쓰는 flag는 다음과 같다. -name : 이름을 적으면 된다. prefix* 혹은 *postfix 형태로 전체 찾기가 유용하다. -type : d는 디렉토리, f는 파일을 의미한다. 찾고자 하는 대상 타입에 따라 지정해두면 리스트를 줄일 수 있다. -empty : 정리하는 과정에서 비어있는 디렉토리나 파일을 찾기 쉽다. -delete : 앞선 조건에 맞는 파일들을 직접 지..

ERROR: failed to solve: failed to read dockerfile: open /var/lib/docker/tmp/buildkit-mount837859110/Dockerfile: no such file or directory 도커 이미지 빌드 시 위 오류를 볼 수 있다. 아주 단순한 실수. 도커 파일을 이름을 "Dockerfile"이 아닌 다른 이름으로 해뒀기 때문이다. 예를 들어, "DockerFile"로 해뒀으면 위 오류가 난다. (내가 자주 그럼 ㅠ) 항상 정확하게 하기 위해서 -f tag를 쓰는 것이 좋다. 도커 파일의 이름을 직접 지정해주는 방식. docker build IMAGE_NAME:TAG -f ./DockerCustomFile . ERROR: "docker buil..

DockerFile이 있을 때, 다음과 같이 한줄을 입력하면 도커 이미지를 빌드할 수 있다. docker build -t IMAGE_NAME:TAG . 여기서 IMAGE_NAME에 해당하는 부분은 말그대로 이미지 입력을 넣으면 되고, TAG 부분에는 버전 관리용으로 사용할 이름을 넣으면 된다. 지정하지 않을 시 :latest 가 기본값으로 들어간다.  Tip. DockerFile을 여러개로 나누어서 사용하는 방법DockerFile로 이미지를 빌드할 때, 이미지가 무거워질수록 빌드가 부담스러워진다. 한 번만 빌드하고 끝난다면 아무 상관없지만 혹 개발 단계에서 이것저것 여러번 변경하면서 빌드를 시도한다면 빌드 시간이 길어지므로 불편함이 커진다. 예를 들어, OpenCV, Ceres 등 묵직한 라이브러리들을 ..

DockerFile로 이미지를 직접 빌드할 때 가끔 중간에 무한 루프 걸리는 부분이 있다. 설치하려는 라이브러리 중 일부가 사용자의 입력을 받은 뒤 설치되도록 되어있다면 무한 루프가 걸린다. 대표적인 예로, ubuntu base image를 가져와서 시작하는 대부분은 다음과 같은 문제일 것이다. Preconfiguring packages ... Configuring tzdata ------------------ Please select the geographic area in which you live. Subsequent configuration questions will narrow this down by presenting a list of cities, representing the time zo..

내 맘대로 Introduction 요즘 segment anything 이후로 anything을 붙이는 것이 유행이 돼버린 것 같다. 이 논문은 대규모 데이터를 먹여 monodepth 성능을 끌어올린 논문이다. MiDAS와 사실 거의 비슷한 논문이라고 할 수 있는데 6200만장에 달하는 unlabeled data를 먹여서 성능을 어떻게 끌어올릴 수 있을지 고민한 차이점이 있다. 핵심 아이디어는, DinoV2 + depth를 teacher로 두어서 unlabeled data를 pseudo labeled data로 만들어 사용하는 것과,feature가 DinoV2 feature를 닮도록 regularization을 가해서 semantic prior를 잃지 않도록 하는 내용이다. 새로운 loss나 이론적인 내용..