Có khá nhiều tiêu chí để đánh giá kết quả, trong đó có thể kể đến 2 tiêu chí khá quan trọng đó là IN - tương tự như recall, nghĩa đánh giá xem có bao nhiêu objets/events của ground truth tìm thấy trong summary video, và TE - tương tư như usability, nghĩa là xem độ thân thiện với người dùng của summary video (nói cách khác, người dùng có thấy thoải mái, dễ chịu khi xem summary video hay không). Thông thường nếu recall cao thì sẽ phải trả giá cho TE (thấp), và ngược lại TE cao thì IN thường là thấp. NIST chỉ trả về kết quả, đánh giá hay dở, hơn thua là tùy vào các nhóm tự quyết định.
Năm nay CMU tiếp tục cung cấp baseline, đó là thuật toán tạo summary video bằng cách dùng fast forward với tốc độ 50x (task này hạn chế summary video chỉ có kích thước tối đa bằng 2% (1/50) so với kích thước của original video). Khi trong original video có nhiều retakes, sẽ có rất nhiều frames sẽ được lặp lại (được đánh giá thông qua RE). Ngoài ra do tốc độ 50x quá nhanh nên tiêu chí TE rất thấp. Điều đáng ngạc nhiên là năm ngoái còn có 2-3 nhóm hơn baseline ở tiêu chí IN, năm nay thì baseline vô địch luôn, với hơn 80% recall.
Để tiện cho việc so sánh giữa các runs, có thể làm đơn giản như sau. Trước hết là check trong sheet IN, chọn các runs nằm ở phần trên của bảng xếp hạng, sau đó check các runs này ở các sheet khác như RE, TE, JU. Một runs được xem là tốt nếu nó nằm ở phần trên của tất cả các bảng xếp hạng. Tuy nhiên điều này rất hiếm. Với các top runs ở sheet IN (CMU_xxx, UMPC-LIP6, ASAHIKASEI, ATTLabs1, BU-FHG, NTT_Lab) hầu như đều nằm ở bottom của các sheet khác. Với các runs nằm ở top của các sheet khác không phải là IN thì thông thường lại nằm ở bottom của sheet IN (NHK-STRL, NII1, etc). Như vậy có thể thấy các runs này chỉ để tham khảo mà thôi chứ ko thể coi là tốt được vì thiếu sự hài hòa giữa recall và usability. Theo tôi đánh giá, các runs tốt của đợt này là của CityU-HK (VIREO.1), DCU.2, FXPAL.1, TITECH.1. CityU-HK có kết quả tốt không có gì lạ vì năm ngoái họ cũng là nhóm có kết quả gần như tốt nhất. Tuy nhiên hệ thống của họ rất phức tạp vì tích hợp rất nhiều thứ.
Năm nay, tôi ko có ý định làm về task này vì Prof. giao cho một anh bạn đang là PhD student ở Chulalongkorn Uni, Thailand làm trong thời gian anh này làm internship ở NII, ngoài ra có thêm sự hỗ trợ của một visiting researcher người Thailand, là advisor của anh bạn PhD student (anh bạn này tốt nghiệp PhD ở Nhật cách đây vài năm). Hai người làm rất nghiêm túc từ tháng 2 cho đến tháng 5. Trước deadline một tuần tôi được Prof. giao nhiệm vụ giúp đỡ 2 bạn trên submit kết quả vì năm nay kết quả sẽ được để trên website của các nhóm tham gia và NIST viết chương trình tự động để tải về. Lúc đọc guideline, tôi mới nhận ra được là mỗi nhóm có thể submit đến 2 runs. Trước đó tôi nghĩ chỉ có 1 run nên ko quan tâm. Vậy là tôi tranh thủ làm trong vòng 1 tuần một run khác (NII.2). Tôi làm cũng khá nhanh vì kết thừa lại hầu hết các code của năm ngoái, với lại biết khá nhiều kinh nghiệm, trick về những chỗ xương xẩu nhất. Vậy là hi sinh luôn golden week cho task này để code.
Kết quả của NII-team lần này có 2 thái cực, run NII.1 của 2 bạn người Thailand cho kết quả rất tốt ở các tiêu chí đánh giá khác nhưng lại cho kết quả khá thấp ở recall-IN, trong khi run NII.2 của tôi làng nhàng ở giữa của hầu hết các tiêu chí đánh giá. Như vậy là khác với năm ngoái, run của tôi cho kết quả khá cao ở recall-IN nhưng lại chót bảng ở các tiêu chí khác, năm nay run của tôi đã đạt được mức cân bằng giữa recall và usability hơn.
Sau 2 năm theo đuổi task này, phải nói là nó rất thú vị. Thứ nhất, giới hạn 2% kích thước là một điều kiện ngặt nghèo. Cứ tưởng tượng một đoạn news 30 phút chỉ còn 0.6 phút (36 giây), nghĩa là chỉ có khoảng 36x25=900 frames mà thôi để chuyển tải các objects và events. Hãy tưởng tượng events kiểu: " 2 men in dark suits walk past Ford truck to building entrance " sẽ thấy cái giới hạn này khắc nghiệt như thế nào. Thứ hai, retake detection cũng là bài toán khá thú vị, nó giống như một bài toán về data mining (TheStarChallenge cũng có task AT3 tương tự, tìm các recurrent voice segments). Thứ ba là tính ứng dụng cao. Cứ tưởng tượng chúng ta dùng chương trình này để tạo các summary cho các video có trong database, chúng ta sẽ giúp người dùng có được cơ hội biết trước phần nào nội dung của video (kiểu như trailer) trước khi ra quyết định có nên xem toàn bộ video hay không. Ứng dụng này đặc biệt có giá trị trong trường hợp chia sẻ video qua mạng.
Sẽ có nhiều thông tin khác thú vị ở workshop TVS-ACMM'08 sắp tới vào tháng 10 khi các nhóm trao đổi về các thuật toán của mình. Tôi sẽ cập nhật sau.
Lê Đình Duy
Xem đầy đủ bài viết tại http://ledduy.blogspot.com/2009/07/trecvid-2008-bbc-rushes-summarization.html
No comments:
Post a Comment