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.
Đúng là cả một thế hệ cứ đăm đắm react nên không biết behind the scenes thực tế nó như thế nào. Đơn cử như mấy bài viết Virtual Dom thực sự hiện tại chưa bài viết nào mô tả được các virtual dom hoạt động ví dụ như ánh xạ qua origin dom như thế nào hay tại sao cần get/set state thì mới render được, etc. Nhiều khi ở công ty train cho các bạn mới hay thậm chí lâu năm vì cái Virtual dom thông qua Js proxy mà cảm thấy trầm cẻm vì mọi người cứ nói là Virtual dom của react đơn giản(Trong khi mình đang hướng dẫn mọi người tự tạo ra cái virtual dom của bản thân ))). Còn vụ bid dự án thì công ty nào outsource ở tầng thứ 2,3 thì chỉ nhận về và implement theo công nghệ chỉ định sẵn thì không nói, công ty mình làm thị trường Eng nên phải tới khảo sát trực tiếp dự án từ khách hàng rồi đưa ra phương án cho họ từ đầu nên thường chọn những công nghệ mà backer là mấy ông lớn để chốt cho nhanh(FE thì react, BE/cloud thì .Net vs Azure nhưng thằng .Net thì perfomance tốt thật nhanh hơn java khá nhiều).
Vụ bid thì mình không rành nhưng có vẻ community ít thì cũng nhiều người không giám chọn option khác ngoài react.
Điểm trừ của việc quá nhiều người dùng react mà không phân tích prop/cons là có một thế hệ chỉ biết code react mà không linh hoạt chuyển sang framework hay js thuần được.
Nếu mà được lựa chọn thì reactive programing vẫn là số 1. Vì mấy thằng DOM ảo thực sự lắm vấn đề. Thằng react làm lâu năm vẫn thấy nó quá lởm so với Solidjs hay Svelte. Kể cả so sánh với angular thì không hề tốt hơn ở client side render còn SSR thì Nextjs mạnh hơn phần còn lại rồi nên khó cạnh tranh. Tại sao React hot thì là do cách marketing của facebook chém gió là DOM ảo nhanh hơn(thực tế là nhanh hơn ở trải nghiệm phát triển chứ không phải performance). Ngoài ra ở Việt Nam rất chuộng đơn giản đi bid dự án bên nước ngoài cứ lấy thằng React(Backer facebook) ra bid cho nó nhanh đỡ nhì nhằng. Angular thì tai tiếng vụ AngularJs => Angular 2. Kể ra Angular cũng thiệt thòi, thằng Vue giờ nó cũng đổi API xoành xoạch v2 => v3 khác hoàn toàn thì không thấy ai kêu. Còn việc develop với react cái ứng dụng CRUD kiểu management thì quá đơn giản nhưng dùng vào mấy con end user thấy render loạn cả lên. Đã có rất nhiều developer nổi tiếng nói về vấn đề của react. Thậm chí thằng useEffect còn được gọi với cái tên useFootGun ))). Trên js framework benchmark thì thằng React này luôn đội sổ https://krausest.github.io/js-framework-benchmark/current.html. Có thằng react + rxjs thì nhanh hơn được tẹo nhưng chung quy với cơ chế render kiểu react thì design với rxjs khó thật sự(Không để ý là subscribe tới chết).
Hoặc đơn giản hơn là cắt ảnh to thành nhiều ảnh nhỏ rồi dùng các model đã có.
Việc nghiên cứu các mô hình cho ảnh to gặp nhiều khó khăn mà kết quả đem lại k quá đáng kể
@tanthinhdt Chào bạn, theo quan điểm của mình thì khi mô hình đủ tin cậy thì việc sử dụng pseudo labelling sẽ có tác dụng cao, còn nó không quá phụ thuộc vào số lượng class quá lớn. Về các vấn đề này mình nghĩ bạn có thể thử nghiệm xem
cái đó bạn gặp trường hợp giống mình nè, không biết sửa sao nên mình làm thành cái file .bat ở trong chứa 2 bộ code để mở file google.exe và file virus.pyw rồi mình làm cái đường dẫn file .bat ra màn hình cái theo vị trí icon của thằng google rồi bỏ vô chọn icon cho file .bat có icon của google
THẢO LUẬN
@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.
Bài biết đã được gỡ spam rồi. Cảm ơn bạn đã quan tâm.
Đúng là cả một thế hệ cứ đăm đắm react nên không biết behind the scenes thực tế nó như thế nào. Đơn cử như mấy bài viết Virtual Dom thực sự hiện tại chưa bài viết nào mô tả được các virtual dom hoạt động ví dụ như ánh xạ qua origin dom như thế nào hay tại sao cần get/set state thì mới render được, etc. Nhiều khi ở công ty train cho các bạn mới hay thậm chí lâu năm vì cái Virtual dom thông qua Js proxy mà cảm thấy trầm cẻm vì mọi người cứ nói là Virtual dom của react đơn giản(Trong khi mình đang hướng dẫn mọi người tự tạo ra cái virtual dom của bản thân
))). Còn vụ bid dự án thì công ty nào outsource ở tầng thứ 2,3 thì chỉ nhận về và implement theo công nghệ chỉ định sẵn thì không nói, công ty mình làm thị trường Eng nên phải tới khảo sát trực tiếp dự án từ khách hàng rồi đưa ra phương án cho họ từ đầu nên thường chọn những công nghệ mà backer là mấy ông lớn để chốt cho nhanh(FE thì react, BE/cloud thì .Net vs Azure nhưng thằng .Net thì perfomance tốt thật nhanh hơn java khá nhiều).
Vụ bid thì mình không rành nhưng có vẻ community ít thì cũng nhiều người không giám chọn option khác ngoài react.
Điểm trừ của việc quá nhiều người dùng react mà không phân tích prop/cons là có một thế hệ chỉ biết code react mà không linh hoạt chuyển sang framework hay js thuần được.
Nếu mà được lựa chọn thì reactive programing vẫn là số 1. Vì mấy thằng DOM ảo thực sự lắm vấn đề. Thằng react làm lâu năm vẫn thấy nó quá lởm so với Solidjs hay Svelte. Kể cả so sánh với angular thì không hề tốt hơn ở client side render còn SSR thì Nextjs mạnh hơn phần còn lại rồi nên khó cạnh tranh. Tại sao React hot thì là do cách marketing của facebook chém gió là DOM ảo nhanh hơn(thực tế là nhanh hơn ở trải nghiệm phát triển chứ không phải performance). Ngoài ra ở Việt Nam rất chuộng đơn giản đi bid dự án bên nước ngoài cứ lấy thằng React(Backer facebook) ra bid cho nó nhanh đỡ nhì nhằng. Angular thì tai tiếng vụ AngularJs => Angular 2. Kể ra Angular cũng thiệt thòi, thằng Vue giờ nó cũng đổi API xoành xoạch v2 => v3 khác hoàn toàn thì không thấy ai kêu. Còn việc develop với react cái ứng dụng CRUD kiểu management thì quá đơn giản nhưng dùng vào mấy con end user thấy render loạn cả lên. Đã có rất nhiều developer nổi tiếng nói về vấn đề của react. Thậm chí thằng useEffect còn được gọi với cái tên useFootGun
))). Trên js framework benchmark thì thằng React này luôn đội sổ https://krausest.github.io/js-framework-benchmark/current.html. Có thằng react + rxjs thì nhanh hơn được tẹo nhưng chung quy với cơ chế render kiểu react thì design với rxjs khó thật sự(Không để ý là subscribe tới chết).
Bài viết hay. Cảm ơn anh !
@DucTT99 Vâng em cảm ơn câu trả lời của anh ạ
em chuẩn bị đặt 1 con flipper zero ai cần ko e đặt cho 8.5tr
Hoặc đơn giản hơn là cắt ảnh to thành nhiều ảnh nhỏ rồi dùng các model đã có. Việc nghiên cứu các mô hình cho ảnh to gặp nhiều khó khăn mà kết quả đem lại k quá đáng kể
chuyên thiết kế trang sức kim cương, moissanite cao cấp với giá thành cực tốt: https://igold.vn/
Cảm ơn bạn . Mình cũng góp nhặt mỗi nơi một tý thôi ạ 😄
Dùng google translate copy vào mà cũng đăng cho bằng được
@tanthinhdt Chào bạn, theo quan điểm của mình thì khi mô hình đủ tin cậy thì việc sử dụng pseudo labelling sẽ có tác dụng cao, còn nó không quá phụ thuộc vào số lượng class quá lớn. Về các vấn đề này mình nghĩ bạn có thể thử nghiệm xem
cái đó bạn gặp trường hợp giống mình nè, không biết sửa sao nên mình làm thành cái file .bat ở trong chứa 2 bộ code để mở file google.exe và file virus.pyw rồi mình làm cái đường dẫn file .bat ra màn hình cái theo vị trí icon của thằng google rồi bỏ vô chọn icon cho file .bat có icon của google
thanks bài viết của b rất nhiều mình đã giải quyết đc vấn đề với biến cùng Get
bài viết hay quá, bạn ra phần 2 sớm nhé