너 “또라이”지?

오늘 문제의 원인을 알고 내가 나한테 던진 말이다.

“너.. 또라이지?” ㅋㅋ

문제는 MySQL에서 BLOB Type으로 데이터를 저장한 후에 읽어보니 전체 데이터가 아닌 일부만 읽혀지는 것이였다. 테이블에 저장한 그림파일의 크기는 195,881KB. 그런데 읽혀지는 데이터 길이는 65,535KB. 저장할때 잘못된 건지.. 읽어올때 잘못된 것인지 고민하다가 이것저것.. MySQL 환경설정 파일도 건드려 보고 말이다. 환경설정 파일을 보고 MySQL… 이거 제대로 쓸라면 공부할거 너무 많은것 같다.. 라는 부담스런 생각도 들고… 뭐 여튼… 아무리 인터넷을 찾아봐도 BLOB 데이터가 전부 오지 않는 이유는 찾을 수가 없었다. 구글신에게 도움을 요청해도 없다는건…. 뭔가 이유가 “얼토당토” 않은 것이라는 확율이 90%이상이란 말인데… 하지만 여전이 나는 “MySQL 이놈이 분명이 BLOB 데이터의 크기를 제한하고 있는게 분명해. 봐… 65,535KB만 보내주잔아? 즉, 64K만 보내주고 있다구.. 분명 환경설정에서 전송 크기를 늘려주는 환경변수가 있을 것이고 그것만 늘려주면 될것야..”라고 확신하며 그다지 흥미롭지 않은 MySQL 환경 변수만을 뒤지기 시작했으나.. 도대체 이놈이다 싶은 놈이 없었다. 음… 혹시 BLOB의 최대 크기가 64KB아냐? 라는 생각에 찾아보니 그냥 BLOB만 있는게 아니라 TINYBLOB, MEDIUMBLOB, LONGBLOB 라는 Type도 있는게 아닌가.. 각각의 최대 크기를 보니까

  • BLOB는 2^16-1KB
  • TINYBLOB는 2^8-1KB
  • MEDIUMBLOB는 2^24-1KB
  • LONGBLOB는 2^32-1KB

였다. 봐.. 다 “65,535KB보다 크잔아..”라고 자신있게 확신한 후에, 역시 원인은 MySQL의 환경변수에 있어 하고 있는데..  근데 2^16이 몇이지? 라는 생각에 계산기를 뚜드려보니.. 2^16 = 65536 !! 으아~~ ㅜ_ㅜ 저 또라이 맞죠? ㅠ_ㅜ 그데 쓰고보니 또라이는 좀 심했다는 생각에 또 다시 ㅠ_ㅠ

나 이제 퇴근할래.. 지하철 끊기기 전에~

동적화소변화율을 고려한 움직이는 물체검출

지난주에 OpenCV를 이용해 화상카메라로부터 영상을 받아, 움직이는 물체를 검출해 보는 코드를 작성해 보았는데, 여기에 자동으로 움직이는 물체가 있을 시에 그 영상을 캡춰받아 자동으로 저장하도록 해보았다.

회사에서 퇴근하는 아무개님(초상권을 위해 모자이크 처리 ㅡㅡ;)
문제는 영상에서 움직이는 물체가 있는지 없는지의 기준이 필요한데, 그 기준을 동적화소변이율을 사용하였다. 동적화소변이율은 영상을 구성하고 있는 전체 화소값(0~255)에서 변화된 화소값의 차이를 다시 백분율로 계산한 것이다. 이 동적화소변화율은 그냥 어찌 저찌 해서 직접 만들어낸 공식이므로 영상관련 책을 암만… 찾아봐도 않나온다. ㅡ_ㅡ; 그래서 자세한 수식을 제시하면…

동적화소변이율=((모든 바뀐 픽셀 차이값의 합)/(영상을 구성하는 픽셀수*255))*100

사용하고 있는 화상카메라를 기준으로 했을때 동적화소변이율이 0.5% 미만일 경우 화면상에 움직이는 물체가 없다고 판단했을때 정확히 일치했다. 그리고 0.5이상일때부터 영상에 움직이는 물체가 나타나기 시작했다가 1% 이상일때 움직이는 물체가 화면의 중앙에 위치한 상태였다. 동적화소변이율이 1%일때의 영상을 날짜와 시간을 파일명으로 해서 저장하도록 했다.

다음 단계는 움직이는 물체가 “누구(Who)”인지를 자동으로 판별해 내는 것..! 두둥~! 이를 위해 필요한 알고리즘은 무엇인가?