Cám ơn bác đã "lì xì" đầu năm, chúc bác sớm có em loa nhé 😁
Em có góp ý thêm mình dùng render html hơi có rủi ro nhưng mình filter kỹ là được, chắc công ty bác có khắc phục rồi.
Trong trường hợp bài viết trên thì bị dính lỗi SSRF, kẻ tấn công có thể khai thác thông tin các internal service thông qua việc inject param url là có thể access các thông tin API máy chủ bên trong, các trang quản trị,... Ví dụ em thử xem ip của Docker em đang chạy (lì xì bác em bug đầu năm =)) )
Nếu bạn muốn truy xuất dữ liệu Google Sheets từ 1 website khác (không phải web app của Google) thì hoàn toàn có thể được. Nhưng như vậy đồng nghĩa với việc viết lại hoàn toàn ^.^.
Nếu bạn muốn tìm hiểu thì search theo từ khóa 'Google Sheets API". Nhưng mình khuyên thật, nếu không rành về code thì không nên tìm hiểu làm gì. Google Apps Scrip là gà nhà nên được hỗ trợ sẵn rất nhiều tính năng, còn nhúng vào website khác sẽ đối diện với nhiều vấn đề kỹ thuật khác cần bạn giải quyết.
khoảng cách giữa các item có thể là Gap, 5 item 1 dòng thì bên ngoài bằng 1 display flex, bên trong mỗi item con sẽ đều đặt flex 1 thì chiều rộng như nhau
Các phương pháp cắt nhỏ ảnh để dự đoán trên từng patch là phương pháp có thể nghĩ ra dễ dàng nhất khi mình xử lý một bức ảnh có kích thước lớn, nhưng nó lại có khá nhiều hạn chế trên thực tế (tất nhiên sẽ tùy thuộc vào dữ liệu bạn sử dụng)
Hiện giờ bạn có thể thấy các mô hình sẽ có đầu vào là một ảnh nếu gọi là to thì có kích thước (ví dụ 712x712), giả sử bạn có một bức ảnh (ví dụ là ảnh vệ tinh) có kích thước 10.000x10.000 thì bạn sẽ phải chia bức ảnh ra khoảng 14x14 = 196 patches khác nhau (chưa tính chia kiểu các patches overlapped lẫn nhau), việc model tính toán 196 lần (kể cả theo batch size) cho một bức ảnh là cực kỳ tốn chi phí cũng như thời gian.
Hai là chỉ đơn giản cắt nhỏ như vậy thì có thể nó sẽ hoạt động với bộ dữ liệu ảnh kích thước lớn với phân phối objects đa số có kích thước nhỏ (ví dụ detect xe cộ từ ảnh vệ tinh). Nhưng với một sample super-resolution, khi mà cả object nhỏ (khoảng vài pixels) và object lớn (có thể lên tới hàng nghìn pixels - so với ví dụ 10.000x10.000), việc cắt nhỏ ảnh có thể sẽ cắt nhỏ object lớn, khiến chúng không thể nhận đạng được nữa, hoặc sau khi cắt nhỏ ra patches, các object nhỏ với vài pixels theo tỷ lệ của patch vẫn rất nhỏ.
Ba là có những bộ dữ liệu trên thực tế của một số công ty (ít nhất là với kinh nghiệm bản thân) thì phân phối kích thước của objects là cực kỳ rộng, sẽ không ổn định như các bộ public nhỏ hơn (và phân phối tính chất dữ liệu càng rộng thì lượng dữ liệu phải càng nhiều để có thể giúp mô hình học được - theo cuốn "Understanding machine learning theory algorithms" mình đọc thấy khá hay), vì vậy chỉ đơn giản là đưa dữ liệu vào các mô hình Object Detection phổ biến để chạy thôi cũng rất là tốn chi phí, thời gian và công sức rồi.
Còn về các nghiên cứu cho loại bài toán này, có thể bây giờ chúng ta đa số vẫn đang bị hạn chế về mặt phần cứng nên chưa thể sử dụng những mảng nghiên cứu lớn được (như video understanding (3D CNN, Spatial Action Localization, ...), Super-resolution (ảnh vệ tinh, ảnh y tế, ...), ...), nhưng theo như mình tìm hiểu thì mình có thể recommend cho bạn paper SNIP và SNIPPER của B. Singh and L. S. Davis, cải thiện được rất nhiều về tốc độ (training và inference) và độ chính xác.
THẢO LUẬN
Happy new year
Bài viết hay quả cảm ơn anh nhiều lắm. Chúc mừng năm mới anh
Cám ơn bác đã "lì xì" đầu năm, chúc bác sớm có em loa nhé 😁
Em có góp ý thêm mình dùng
render htmlhơi có rủi ro nhưng mình filter kỹ là được, chắc công ty bác có khắc phục rồi. Trong trường hợp bài viết trên thì bị dính lỗi SSRF, kẻ tấn công có thể khai thác thông tin các internal service thông qua việc inject paramurllà có thể access các thông tin API máy chủ bên trong, các trang quản trị,... Ví dụ em thử xem ip của Docker em đang chạy (lì xì bác em bug đầu năm =)) )Ngoài ra thì cái
Open Graph Protocolcũng từng được nhiều ae lợi dụng khai thác, em gửi ví dụ của Twitter, bác có thể xem thêm các report trên hackerone tham khảo thêm https://twitter.com/BugBountyHQ/status/868242771617792000Hay quá bro ạ ❤️
Bài viết khá hay 😃 tks chủ thớt
Bài viết hay
hi anh, series này có ra tiếp nữa ko anh
@nampt.me ,bạn ơi xài hết 500 giờ làm sao để có thể xài tiếp
Thank bro nha. Ăn tết vui vẻ
@thanhle27 Bài hay đấy
Ăn tết vui vẻ nhé
tks
bài này giống triển khai hơn là tìm hiểu
8tr5 dữ v
thank a vì bài viết hay a. Anh có thể giải đáp giúp em tai sao dùng 2 minIO trong docker compose và dùng nginx để làm gì ạ. Thank anh nhiều
nếu dùng kafka thì có thể rollback bằng cách replay event
@nhakhoaminhthanh bạn thử vào link này rồi liên hệ vs admin xem nào https://www.trangvang.biz/lien-he.html
Nếu bạn muốn truy xuất dữ liệu Google Sheets từ 1 website khác (không phải web app của Google) thì hoàn toàn có thể được. Nhưng như vậy đồng nghĩa với việc viết lại hoàn toàn ^.^. Nếu bạn muốn tìm hiểu thì search theo từ khóa 'Google Sheets API". Nhưng mình khuyên thật, nếu không rành về code thì không nên tìm hiểu làm gì. Google Apps Scrip là gà nhà nên được hỗ trợ sẵn rất nhiều tính năng, còn nhúng vào website khác sẽ đối diện với nhiều vấn đề kỹ thuật khác cần bạn giải quyết.
Bài viết đọc dễ hiểu, Cảm ơn tác giả
khoảng cách giữa các item có thể là Gap, 5 item 1 dòng thì bên ngoài bằng 1 display flex, bên trong mỗi item con sẽ đều đặt flex 1 thì chiều rộng như nhau
Các phương pháp cắt nhỏ ảnh để dự đoán trên từng patch là phương pháp có thể nghĩ ra dễ dàng nhất khi mình xử lý một bức ảnh có kích thước lớn, nhưng nó lại có khá nhiều hạn chế trên thực tế (tất nhiên sẽ tùy thuộc vào dữ liệu bạn sử dụng)
Hiện giờ bạn có thể thấy các mô hình sẽ có đầu vào là một ảnh nếu gọi là to thì có kích thước (ví dụ 712x712), giả sử bạn có một bức ảnh (ví dụ là ảnh vệ tinh) có kích thước 10.000x10.000 thì bạn sẽ phải chia bức ảnh ra khoảng 14x14 = 196 patches khác nhau (chưa tính chia kiểu các patches overlapped lẫn nhau), việc model tính toán 196 lần (kể cả theo batch size) cho một bức ảnh là cực kỳ tốn chi phí cũng như thời gian.
Hai là chỉ đơn giản cắt nhỏ như vậy thì có thể nó sẽ hoạt động với bộ dữ liệu ảnh kích thước lớn với phân phối objects đa số có kích thước nhỏ (ví dụ detect xe cộ từ ảnh vệ tinh). Nhưng với một sample super-resolution, khi mà cả object nhỏ (khoảng vài pixels) và object lớn (có thể lên tới hàng nghìn pixels - so với ví dụ 10.000x10.000), việc cắt nhỏ ảnh có thể sẽ cắt nhỏ object lớn, khiến chúng không thể nhận đạng được nữa, hoặc sau khi cắt nhỏ ra patches, các object nhỏ với vài pixels theo tỷ lệ của patch vẫn rất nhỏ.
Ba là có những bộ dữ liệu trên thực tế của một số công ty (ít nhất là với kinh nghiệm bản thân) thì phân phối kích thước của objects là cực kỳ rộng, sẽ không ổn định như các bộ public nhỏ hơn (và phân phối tính chất dữ liệu càng rộng thì lượng dữ liệu phải càng nhiều để có thể giúp mô hình học được - theo cuốn "Understanding machine learning theory algorithms" mình đọc thấy khá hay), vì vậy chỉ đơn giản là đưa dữ liệu vào các mô hình Object Detection phổ biến để chạy thôi cũng rất là tốn chi phí, thời gian và công sức rồi.
Còn về các nghiên cứu cho loại bài toán này, có thể bây giờ chúng ta đa số vẫn đang bị hạn chế về mặt phần cứng nên chưa thể sử dụng những mảng nghiên cứu lớn được (như video understanding (3D CNN, Spatial Action Localization, ...), Super-resolution (ảnh vệ tinh, ảnh y tế, ...), ...), nhưng theo như mình tìm hiểu thì mình có thể recommend cho bạn paper SNIP và SNIPPER của B. Singh and L. S. Davis, cải thiện được rất nhiều về tốc độ (training và inference) và độ chính xác.