Ghép panorama với góc rộng hơn

[manhthiep]

Anh không biết có chưa nhưng với pairwise hiện tại, anh đoán là mới support loại ảnh panorama có hình vành khăn.

Liệu support panorama với góc nhìn rộng hơn (thêm 2 tầng trên dưới nữa) có được không?

[izzyaf]

hiện tại đã hỗ trợ ghép ảnh nhiều tầng rồi anh ạ.

[manhthiep]

Lúc ấy format của pairwise nó như thế nào thế?

[nvkhoi]

Giống nhau cả anh ạ. File pairwise.txt chứa nhiều dòng, mỗi dòng là 1 cặp ảnh nối được với nhau. Ví dụ em có 36 tấm có tên là 0,..., 35 chia làm 3 tầng, mỗi tầng 12 tấm như test số 27 thì pairwise.txt sẽ là: //tầng 1 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 10 10 11 //tầng 2 12 13 13 14 14 15 15 16 16 17 17 18 18 19 19 20 20 21 21 22 22 23 //tầng 3 24 25 25 26 26 27 27 28 28 29 29 30 30 31 31 32 32 33 33 34 34 35 //giữa tầng 1 và tầng 2 0 12 1 13 2 14 3 15 4 16 5 17 6 18 7 19 8 20 9 21 10 22 11 23 //tầng 2 và tầng 3 12 24 13 25 14 26 15 27 16 28 17 29 18 30 19 31 20 32 21 33 22 34 23 35

Anh có thể xem qua test 21, 27, 30 ở đây https://drive.google.com/folderview?id=0By6PyWZq12fzfjJBenNOTlJscjUxelBvQzBVMW9XdHlnZmQ1Tng5WE9VcDNzcGJGbmNfVmM&usp=sharing Đó là những bộ test nhiều tầng có thể xem là lý tưởng nhất. Các bộ nhiều tầng nhưng ko lý tưởng (những tấm ở tầng trên có thể overlap với nhiều tấm ở tầng dưới) như test 9, 15, 16 thì cũng ghép được bằng cách vét cạn (ko dùng pairwise) nhưng thời gian sẽ rất khủng khiếp. Dĩ nhiên là nếu tạo pairwise chính xác thì thời gian xử lý sẽ giảm rất nhiều, nhưng tạo pairwise thế nào cho đúng là vấn đề lớn. Khi dùng robot thì các góc quay đã cố định nên cho ra bộ ảnh lý tưởng dễ tạo pairwise. Còn người dùng chụp thì có nhiều yếu tố khác ảnh hưởng, may ra xử lý thêm sensor thì mới tạo pairwise được.

[manhthiep]

Anh đã nói ngay từ đầu: làm thế nào để kết quả tốt nhất, chứ không phải làm thế nào để hỗ trợ nhiều trường hợp nhất, tức là mình có thể hạn chế tham số/điều kiện đầu vào (không ai cấm mình làm điều này).

Nếu nói như các chú, thì với 1 cặp (pair), ta chỉ biết là nó có thể ghép được thôi, chứ không cần biết là theo chiều nào (bên trái/bên phải/bên trên/bên dưới) à? Chương trình của các chú sẽ phải tự suy đoán? Nó có tốn nhiều thời gian và bộ nhớ không? Nếu có thì có khắc phục được không?

Bên anh mới thử 1 tầng, và chỉ có thể chấp nhận được với trường hợp có pairwise.txt; và anh chỉ cho phép chạy tối đa 2 tasks ghép ảnh cùng 1 lúc trong task queue. Chưa thử với nhiều tầng nên lát anh sẽ thử. Hy vọng là cũng chấp nhận được.

Kết quả bọn anh muốn đạt được là có thể ghép được:

• tốn ít thời gian + bộ nhớ nhất có thể,
• ít nhất là 2 tầng ảnh, với 2 camera (trước & sau),
• có kèm pairwise.txt,
• độ phân giải từng ảnh nếu cần thì resize ở dưới client trước (vì thời gian upload ảnh không phải nhỏ),
• output 1 ảnh chất lượng cao nhất thôi cũng được (hiện giờ là 2), bọn anh tự generate thumbnail bằng chương trình khác.

Các chú xem chương trình có thoả mãn được tất cả các điều trên không thì sửa.

[nvkhoi]

Anh check lại Git nhé, em vừa sửa lỗi khi tạo matching mask. Chỉ cần copy lại Stitcher::feed thôi anh. Cái đám sửa đổi còn lại ko liên quan gì nhiều đâu.

Với một cặp ảnh có thể nối với nhau, em xem trong mã nguồn thì nó sẽ ưu tiên cho chiều ngang trước (thực chất trong bước blend nó duyệt dòng trước duyệt cột). Những ảnh lộn xộn vừa ngang vừa dọc thì từ các bước trước (tìm vết cắt, tìm tham số cameras) các ảnh đã được xử lý để ghép lại mà ko gây ra biến dạng quá lớn (kiểu như anh đóng đinh đường chéo sẽ cố định hình bình hành ấy). Còn những ảnh chỉ thuần ghép theo chiều dọc thì khó thành công (hình bình hành ko có đường chéo bì bóp nó kiểu gì chẳng được). Ảnh càng nhiều tầng, thì thời gian xử lý càng tăng so với một tầng (dù là cùng số ảnh đầu vào) vì bước Estimate cameras dùng thuật toán không thể đa luồng được. Tốc độ tương phản với bộ nhớ chiếm dụng.

Những góp ý còn lại em sẽ cố.

Nguyễn Văn Khôi - Lớp CS0801 - SE61174

Vào 22:00 Ngày 21 tháng 04 năm 2015, Manh Thiep Nguyen < notifications@github.com> đã viết:

Anh đã nói ngay từ đầu: làm thế nào để kết quả tốt nhất, chứ không phải làm thế nào để hỗ trợ nhiều trường hợp nhất, tức là mình có thể hạn chế tham số/điều kiện đầu vào (không ai cấm mình làm điều này).

Nếu nói như các chú, thì với 1 cặp (pair), ta chỉ biết là nó có thể ghép được thôi, chứ không cần biết là theo chiều nào (bên trái/bên phải/bên trên/bên dưới) à? Chương trình của các chú sẽ phải tự suy đoán? Nó có tốn nhiều thời gian và bộ nhớ không? Nếu có thì có khắc phục được không?

Bên anh mới thử 1 tầng, và chỉ có thể chấp nhận được với trường hợp có pairwise.txt; và anh chỉ cho phép chạy tối đa 2 tasks ghép ảnh cùng 1 lúc trong task queue. Chưa thử với nhiều tầng nên lát anh sẽ thử. Hy vọng là cũng chấp nhận được.

Kết quả bọn anh muốn đạt được là có thể ghép được:

• tốn ít thời gian + bộ nhớ nhất có thể,
• ít nhất là 2 tầng ảnh, với 2 camera (trước & sau),
• có kèm pairwise.txt,
• độ phân giải từng ảnh nếu cần thì resize ở dưới client trước (vì thời gian upload ảnh không phải nhỏ),
• output 1 ảnh chất lượng cao nhất thôi cũng được (hiện giờ là 2), bọn anh tự generate thumbnail bằng chương trình khác.

Các chú xem chương trình có thoả mãn được tất cả các điều trên không thì sửa.

— Reply to this email directly or view it on GitHub https://github.com/iDoraemon/BiBo-Kit---Panorama/issues/7#issuecomment-94831260 .

[manhthiep]

À, cái lỗi ấy anh tự sửa rồi nhưng theo cách khác, quên report :P

Tốc độ tương phản với bộ nhớ thì anh e là không đúng, trường hợp người ta sử dụng memory để cache thì tốc độ sẽ nhanh hơn so với không cache. Cái này mang tính tương đối nên cần sử dụng hợp lý một tí, mới thành chương trình tốt được.

Ý anh hỏi là, với matching pairs định trước (thông qua pairwise.txt), thì khi ghép chú có xử lý các cặp này riêng rẽ không và có thể đối xử khác nhau không. Ví dụ: biết là sẽ ghép theo chiều ngang, cái nào trước, cái nào sau rồi thì sẽ khác với biết là ghép theo chiều dọc, cái nào trên, cái nào dưới...

• Chú có thể thử 2 trường hợp trên rồi benchmark xem cái nào nhanh/chậm hơn hay bằng nhau được không?
• Liệu có thể xử lý theo cách riêng 2 trường hợp ấy được không? Giả sử là chiều ghép, vị trí ảnh trong cặp đều đã biết.

Như đã nói như việc xoay ảnh lần trước, anh nghĩ, trường hợp nào có thể tối ưu được thì nên làm.

[nvkhoi]

Các matching pair định trước thì OpenCV nó cung cấp sẵn lớp Matcher xử lý song song sẵn rồi anh, thứ tự ko quan trọng. Dựa vào các feature tìm được của mỗi ảnh và matching mask đã nhập, lớp Matcher sẽ tìm các điểm chung của từng cặp, mặc kệ nó theo chiều ngang hay chiều dọc. Nhiệm vụ của pairwise chỉ là cho biết ảnh nào sẽ được ghép với ảnh nào. Matching mask đến đây là hết tác dụng. Ảnh được ghép với nhau như thế nào thì do bước thiết lập camera và tìm vết cắt quyết định. Ở những bộ ảnh nhiều tầng, em đã có thử xáo lại thứ tự các cặp như anh nói thì thấy là thời gian hầu như ko thay đổi gì cả. Vì lúc tạo ra matching mask chỉ có một. Điều làm tăng thời gian xử lý đáng kể ở các bộ ảnh nhiều tầng (gần phân nửa thời gian) chính là bước tìm thông số các camera ảo dựa trên điểm giao nhau của các ảnh đầu vào. Dù là có biết trước ảnh nào ghép theo chiều dọc, ảnh nào ghép theo chiều ngang thì cũng phải tính hết camera cho tất cả đầu vào để tìm camera trung tâm. Em đã đọc mã nguồn của BundleAdjuster (lớp chuyên việc tìm tham số camera) thì nó làm theo kiểu tối ưu từ từ, bước sau phụ thuộc bước trước nên ko thể tối ưu được gì nhiều.

Nguyễn Văn Khôi - Lớp CS0801 - SE61174

Vào 23:20 Ngày 21 tháng 04 năm 2015, Manh Thiep Nguyen < notifications@github.com> đã viết:

À, cái lỗi ấy anh tự sửa rồi nhưng theo cách khác, quên report :P

Tốc độ tương phản với bộ nhớ thì anh e là không đúng, trường hợp người ta sử dụng memory để cache thì tốc độ sẽ nhanh hơn so với không cache. Cái này mang tính tương đối nên cần sử dụng hợp lý một tí, mới thành chương trình tốt được.

Ý anh hỏi là, với matching pairs định trước (thông qua pairwise.txt), thì khi ghép chú có xử lý các cặp này riêng rẽ không và có thể đối xử khác nhau không. Ví dụ: biết là sẽ ghép theo chiều ngang, cái nào trước, cái nào sau rồi thì sẽ khác với biết là ghép theo chiều dọc, cái nào trên, cái nào dưới...

• Em có thể thử 2 trường hợp trên rồi benchmark xem cái nào nhanh/chậm hơn hay bằng nhau được không?
• Liệu có thể xử lý theo cách riêng 2 trường hợp ấy được không? Giả sử là chiều ghép, vị trí ảnh trong cặp đều đã biết.

Như đã nói như việc xoay ảnh lần trước, anh nghĩ, trường hợp nào có thể tối ưu được thì nên làm.

— Reply to this email directly or view it on GitHub https://github.com/iDoraemon/BiBo-Kit---Panorama/issues/7#issuecomment-94859152 .

[manhthiep]

Anh đâu bảo là xáo các cặp với nhau? Là đo sự sai khác thời gian giữa ghép chiều ngang và chiều dọc thôi mà...

Anh cần examine lại, bởi vì như hiện tại là tương đối chậm. Sử dụng cái có sẵn nhiều khi không có lợi. Nếu có cách nào chú override lại thì tốt.