요즘은 하루하루가 다르게 ㅎㄷㄷ 입니다. 모바일 쓰나미와 HTML5를 필두로한 변화의 급물살 덕에 정신을 차릴 수가 없군요. 주말에 멍때리고 하루이틀만 정보수집을 게을리하면 월요일엔 감당하기 힘들정도로 압뷁이 심합니다.
구글이 기어스 프로젝트를 중단하기로 했다고 합니다. 차세대 웹표준 기술로 주목받는 HTML5를 활성화 시키기 위해서라고 합니다. HTML5가 표준으로 자리잡으면 플래시나 실버라이트 JavaFX같은 RIA 플랫폼 들이 적잖이 타격을 입을 것이라는 것이 일반론이 되어가고 있습니다.
IT 공룡들에게 적당히 묻어가지 않으면 살아남기 힘든 한명의 개발자 로서 고민이 많습니다. 1~2년 정도 전부터 UX 개발에 매력을 느끼고 있고 작년 에는 Flex와 AIR에 상당히 많은 시간을 투자했습니다. 개발자가 자기 개발을 할때도 줄서기를 잘해야 합니다. 앞으로 잘나갈 기술에 투자를 해야 하는거죠.(제 논리 입니다!) HTML5의 사용이 일반화 되는 시점이 오더라도 플래시가 완전히 사용되자 않는다거나 하지는 않을 것입니다. 그래도 줄을 잘섰다고 말하긴 역시나 힘듭니다. (자신의 내공마저 쓸모없게 되지는 않습니다!)
모바일 쓰나미는 2008년 말부터 예상을 하고 있었습니다. 이듬해 봄에 대표님에게 선물받은 아이팟 터치는 확실히 불을 댕겨주었습니다. 지금은 아이폰에 상당히 큰 비중을 두고 자기개발을 하고있고 안드로이드 역시 정조준 중입니다. IT 공룡들은 저마다 제각각의 스마트폰 플랫폼을 내놓고 있습니다. 이미 너무 많고 상이해서 모든 플랫폼을 학습하는건 무리입니다.
자신을 좀더 고부가 가치를 지닌 상품으로 만들어줄 기술을 습득하고 갈고 닦는 것은 개발자의 숙명입니다. 더욱이 요즘같은 시기에 (열린생각으로)새로운 기술을 습득을 게을리하며 1~2년만 흘러버리면 도태되어 버리고 맙니다. 신중히 선택하고 집중하여야 할 시기입니다.
뭔가 더 이야기 하고 싶은 내용이 많았는데 이틀 밤을 샜더니 생각이 잘 정리가 되지 않는 군요. 그냥 마무리는.. 공부하세요!
위 기사를 보면, "장면을 인식할 수 있는 동영상 검색엔진 개발"이라는 문구가 참 이색적이었다. 예전부터 야후의 "야미", 네이버에서의 반자동 동영상 검색등이라는 이야기가 흘러나왔는데, 이렇게 구체적으로 장면 인식 기반 동영상 검색이라는 걸 보니 참 세상은 좋아진 것 같다.
하지만, 장면 인식이란게 conv2군의 생각으로는 키 프레임(key frame)을 찾아내는 것을 가리키는 듯 하다. 키 프레임에 대한 정의는 보통 장면 첫 화면이다. 즉, 키 프레임의 쉬운 예로는 동영상을 보면 갑자기 변화하는 화면을 들 수 있다.
아무튼 장면 인식을 하려면 샷 검출(shot detection) 이라는 전처리 과정과 키 프레임 추출 순으로 이루어져야 한다.
첫째, 샷 검출 과정에 대해서는 통상 여섯 가지 패턴 기반으로 둔 것을 이용한 것으로 잘 알려져 있다.
1. 컷(cut) : 급격하게 변화할 때 2. 페이드 인/아웃(fade in/out) : 영상이 점차 또렷화 하거나 혹은 희미해질 때 3. 디졸브(dissolve) : 오버래핑(overlapping) 할 때 즉 겹쳐질 때 4. 와이프(wipe) : 한 화면이 한쪽으로 사라지면서 연이어 다음 영상이 나타날 때 5. 객체가 움직일 때 6. 카메라의 상황 : 상하좌우, 기울이기, 줌인/줌아웃 등
1~4는 장면 전체가 바뀔 때이고, 5~6은 장면내에서의 일부가 바꿔졌을 때이다.
둘째, 키 프레임 추출(key-frame extraction)에 있어서는 한 장면 내 연속된 프레임 즉 유사한 내용이 있을 것이므로, 샷 검출 전 후의 프레임 집합에서 가장 정보를 많이 담고 있을 프레임 선택한다. 그게 바로 키 프레임이다. 그렇지만 통상 장면의 첫 부분을 키 프레임으로 하는 게 대부분이다.
장면 인식 과정에서 필요한 처리는 여러 가지가 있으나, 대표적인 예는 다음과 같다.
1. 키 프레임 수를 줄이기 : 이전의 키 프레임과 유사하면 통합 2. 샷 검출시에 대한 보정 : 잡음이나 이상한 것이 들어간 프레임을 잘못 추출했을 때 버리기 3. 정확한 샷 검출과 빠른 속도로 수행
그러면 결국 한 동영상당 수십개~수백개 이상의 키 프레임만 추출된다. 이걸 갖고 스토리 보드 구성한다고 한다. 그래서 동영상 관리 솔루션의 기능 중의 하나는 각 키프레임에 대한 정보(시작 위치)를 갖고, 해당 키 프레임을 누르면 동영상 시연하는 것을 들 수 있겠다. 참고로 이미 8년전에 Excalibur에서 그렇게 시연하는 것을 본 적이 있다.
이와 같이 프리챌에서는 장면 전환 검색이란게 아마도 스토리 보드로 된 것을 쭈욱~~~ 찾아보면 되는 것을 가리키는 건 아닐까 싶다. 하지만 진작 키 프레임으로 검색한다면 필요한 게 바로 CBIR(Content-Based Image Retrieval : 내용기반 이미지 검색) 이다.
진정한 동영상 검색을 하려면 CBIR를 갖추어야 할 필요가 있다. 하지만 지금으로부터 8년전에는 CBIR를 개발하는 회사가 몇몇 있었는데, 지금은 코난테크놀로지 밖에 없을 정도로 명맥이 끊겨져 있다. (있다면 conv2군에게 댓글로 알려주시길 바란다. 즉시 수정하겠다.)
동영상의 특징이 아주 다양하므로, 이에 맞춰 최적화할 수 있는 CBIR를 만들 수 있는 개발자가 프리챌에 있다면 좋은 현상이다. 왜냐하면 앞에서 말했다시피 CBIR 개발자는 요즘 눈을 닦아봐도 안보이기 때문이다. 어디로 숨었는지 모르겠지만, 일단 프리챌에 이미 있다고 가정해야 할 것 같다. 과연 그 분이 누군지 알고 싶다. conv2군도 한 수 배우고 싶을 정도의 고수이신듯 하다.
그 정도의 검색엔진 만들기 위한 팀원 구성에 대해서는 아마도 이렇게 될 듯 하다.
1. 동영상 관련 전문가 : 샷 검출 & 키프레임 추출 알고리즘 보유 2. 비전 전문가(혹은 영상처리 전문가) : 검색을 위한 특징 벡터 추출 알고리즘 전문가 3. 이미지 검색엔진 개발자 : 색인 구조 설계, 전처리기, 색인, 검색 모듈 개발 4. 정보 검색엔진 개발자 : 키 프레임 관련 메타데이터 색인/검색 5. 동영상 검색엔진 서비스 개발자 : 검색엔진 API를 이용해 웹으로 검색케 함.
그런데, 1~5번을 한꺼번에 할 수 있는 분은 가장 톱 레벨로 올라서 있을 정도일 거다. 실제로 정보검색엔진과 동영상 처리, 이미지 검색엔진을 모두 다 할 수 있는 거면 대단한 고수다. 정보검색도 어려운데 이미지 검색까지 겸한다면 일당백이므로, 구글에서 모셔가야 할 인재이지 않을까. 하지만 현실상 어려우므로 최소한 인원으로 꾸려간다면 최소한 3명 정도만 있어도 괜찮겠다. 단지 시간과 시행착오를 감당할 수 있다는 전제를 깔아둔다.
아무튼 프리챌의 개발 이야기에 대해서는, 엄청나게 많이 쌓이는 UCC 동영상 데이터에 대한 검색 요구가 높아져가고 있음을 보여주는 사례라고 할 수 있겠다.
참! CBIR를 어떻게 구현하나고요? 구현하는 방법에 대해서는, conv2군이 집필한 "오픈소스 CxImage를 이용한 Visual C++ 디지털 영상처리"에 szSearch 라는 프로젝트를 실었으니 한번 보길 바란다. 여기서 키 프레임만 추출해서 색인 시키고 검색하면 될 것이다. 너무 간단한가요? ^^;
8년전에는 두 발자국을 앞서 내딛었다면, 이젠 반 발자국밖에 남지 않을 정도로 멀티미디어 검색 엔진 시장은 이미 막 오른 상태이다. 하지만 그것을 만들 수 있는 개발자는 도대체 어디에 있는 걸까? 하물며 정보검색엔진 개발자도 귀하다고 하는데....
끝으로, 옛 CBIR 개발자로서 당부하건데, 프리챌이 꼭 성공하길 바란다. 그래야 conv2군이 술 한잔 걸치고 같이 이야기 할 수 있는 기회가 많아지니까... 그동안 CBIR 개발자라는 설움(?)이 많았는데 말이지... 그래서 성공한다면, 언젠가 어른이 될 딸래미에게 "아빠가 옛날에 CBIR를 만들었단다" 라고 자신있게 말할 수 있을 거니까... ^^;
* 추신 : 동영상 검색에 대해 CBIR를 배제한 채, 정보검색엔진 이론과 접목한다면 아마도 이렇게 될겁니다. 즉, 동영상에서 관심 객체를 추출한 후, 자동으로 이것과 관련한 품질 높은 메타데이터를 만듭니다. 그 다음 이걸 검색하거나 더 나아가서 그 메타데이터간의 관계를 온톨로지로 표현하여 활용하는 방법 등이 있겠습니다. 이와 같이 보다 더 좋은 서비스를 제공하는 방법이 있습니다. 일단 프리챌의 동영상 검색 서비스 자체가 CBIR 기반인지, 정보검색 기반인지, 두 가지를 혼합하여 제공하는지에 대해 추이를 지켜봐야 할 것입니다.
