Hình ảnh SVG có được thu nhỏ tốt hơn so với png, jpg hoặc gif có độ phân giải cao không?


15

Tôi biết rằng nếu bạn muốn mở rộng hình ảnh, thì SVG là một lựa chọn sáng suốt.

Tuy nhiên, tình huống của tôi là tôi có các biểu tượng mà tôi muốn người dùng có thể tải lên thông qua một CMS. Các SVG chỉ là một chút phức tạp hơn để tạo ra, và vì vậy jpg, gif hoặc png dường như là định dạng lý tưởng cho quản trị viên.

Nếu được tải lên cùng hoặc lớn hơn kích thước hiển thị và được giữ đúng tỷ lệ, jpg, gifs hoặc png có thể có chất lượng cao như một SVG khi giảm kích thước không?

Giả định của tôi là các trình duyệt cũng cần phải chống lại một Svg dưới một kích thước nhất định, vì vậy chúng có khả năng làm mờ nhiều như bất kỳ định dạng nào khác, mặc dù gifs dường như mờ hơn nhiều.


4
Một câu hỏi hay nhưng tôi tin rằng câu trả lời là "nó phụ thuộc vào trình duyệt".
usr2564301

Câu trả lời:


7

(Lưu ý: vui lòng đọc câu trả lời của chính OP trước câu trả lời này, vì câu trả lời của tôi là nhận xét về cuộc điều tra của OP)

Đây là sự cố đã biết của Android Chrome. Trên một số bản dựng của họ, họ vô hiệu hóa khử răng cưa khiến hình dạng vectơ được hiển thị với các cạnh sắc nét. Lý do cho điều này là để giảm quá tải được tạo ra bằng các tính toán khử răng cưa. Do phàn nàn, họ đã phát hành một bản cập nhật nên đã kích hoạt tính năng khử răng cưa.

Có một số chủ đề trong Stack Overflow thảo luận về vấn đề này. Đây là một trong số đó:
/programming/19875908/vector-poorly-displayed-on-chrom-for-android-canvas

Tôi không thể tìm thấy tài liệu tham khảo cho cùng một vấn đề trên IPod Touch Safari nhưng có lẽ nó an toàn để ngoại suy và cho rằng vấn đề là như nhau.

Có nhiều cách để cố gắng buộc khử răng cưa ngay cả khi nó bị vô hiệu hóa, chẳng hạn như thủ thuật này về cơ bản thêm một chút phần đệm xung quanh thành phần khiến trình duyệt vì lý do nào đó áp dụng khử răng cưa. Bạn cũng có thể thử đặt thuộc tính kết xuất hình dạng của phần tử thành một cái gì đó khác với các cạnh sắc nét và xem trình duyệt có tôn vinh nó không.


Thêm -webkit-backface-mức độ hiển thị: ẩn có nghĩa là những người không phải là Svss làm mờ trên iPod theo cách chính xác giống như các Svss và trả lời câu hỏi của tôi - tức là không cần phải chọn cái khác khi thu nhỏ. Điều kỳ lạ là bản sửa lỗi Android dường như không chuẩn hóa hành vi kết xuất trên phiên bản Android Chrome / trình duyệt bản địa của tôi, nhưng đó là một vấn đề khác. Cảm ơn bạn đã giúp đỡ.
Richard B

13

Tôi vừa chạy thử nghiệm và sự khác biệt duy nhất xuất hiện là trên các trình duyệt di động.

Tôi đã tạo một hình ảnh 990 x 900px của biểu tượng Twitter (biểu tượng đó dường như quá chi tiết một thiết kế để mở rộng tốt, rất tốt cho thử nghiệm này). Tôi đã lưu cái này dưới dạng SVG, JPG, GIF, GIF trong suốt (chỉ là hình con chim, không có màu nền, thay vào đó thêm cái này bằng CSS), PNG, PNG trong suốt.

Sau đó tôi thu nhỏ chúng xuống còn 15px, 25px, 50px, 100px và 150px.

Đây là kết quả trong Firefox: nhập mô tả hình ảnh ở đây

Đây là kết quả trong Chrome: nhập mô tả hình ảnh ở đây

Nếu chúng tôi phóng to vào một loạt các kết quả nhỏ nhất để chúng tôi có thể thấy các pixel nào đang được tạo, thì Firefox (trên cùng) sẽ làm tối các cạnh trên các phiên bản không trong suốt, nhưng tất cả các kết quả khác đều rất giống nhau.

nhập mô tả hình ảnh ở đây

Tuy nhiên, trên trình duyệt IPod Touch Safari, phiên bản SVG có vẻ khá mờ và các phiên bản khác khá pixel:

nhập mô tả hình ảnh ở đây

Một kết quả tương tự cũng được nhìn thấy trên Android Chrome. Tôi chưa chụp ảnh màn hình này.

Tôi tự hỏi liệu lý do cho điều này có thể liên quan đến mật độ pixel, đó là sự khác biệt chính trong màn hình, mặc dù điều đó sẽ có ý nghĩa hơn với tôi nếu tất cả các hình ảnh được xử lý khác nhau trên thiết bị di động, thay vì chỉ là SVG.

Nếu ai đó có thể giải thích lý do tại sao lại như vậy, thì tôi sẽ chuyển dấu kiểm trả lời được chấp nhận. Mặt khác, tôi đoán câu trả lời TL; DR là tùy thuộc vào việc bạn thích các biểu tượng bị mờ hoặc pixel (hoặc để tạo nhiều biểu tượng ở kích thước pixel hoàn hảo cho các điểm dừng đáp ứng của bạn).

chỉnh sửa: Tôi đã quan sát thấy rằng các Svss thường rõ ràng hơn nhiều trên các thiết bị của apple - chú chim twitter có thể đã quá chi tiết để hiển thị trong các thử nghiệm của tôi ở trên, vì vậy cảm thấy rằng chúng là định dạng phù hợp để sử dụng cho các biểu tượng.


SVG được kết xuất tại thời điểm hiển thị và có thể hưởng lợi từ AA, các phần còn lại có độ phân giải cố định và chỉ có một AA mà chúng có thể có là 2 lần; mơ hồ; và giảm, điều này sẽ không thực sự có ích, ngoại trừ trong các tình huống "khử màn hình". Đối với SVG, một phương pháp AA cố định (như FSAA 4x đơn giản trên bảng) sẽ trở nên quá tích cực khi bạn chỉ có chiều rộng 8px và việc lấy mẫu xuống luôn dẫn đến một số mờ.
Yorik

Lưu ý rằng loại tỷ lệ và lấy mẫu lại phụ thuộc vào phần mềm. Hầu hết đi cho "nhanh" hoặc "cân bằng" thay vì Chất lượng.
Yorik

3

Có một sự phân biệt rất quan trọng giữa hình ảnh vector và hình ảnh bitmap. Hình ảnh vector, nếu chúng ta đơn giản hóa một chút, được hiển thị bởi máy khách trong khi hình ảnh bitmap đang được hiển thị bởi bạn.

Điều này có nghĩa là ứng dụng mà bạn gửi hình ảnh sẽ nói rõ hơn về cách ứng xử. Kết quả cuối cùng là bạn có những nhược điểm sau :

  • Phải mất nhiều tài nguyên hơn để làm cho hình ảnh có thể trình bày
    • Trong trường hợp này, kết xuất có thể chọn giảm chất lượng vì nó không có đủ tài nguyên để làm điều đó tốt hơn.
  • Mỗi hệ thống hình ảnh có tập hợp các quirks và lỗ hổng riêng
    • Làm cho nó khó hơn để được nhất quán
    • Bạn gặp vấn đề của một lập trình viên

Mặt khác, có một số lợi ích của việc này:

  • Hình ảnh có thể được thu nhỏ tự do và có nhiều tùy chọn thao tác hơn.
    • Đây chỉ đơn giản là kết quả của công việc được thực hiện ở phần cuối của máy khách để họ có thể dành nhiều thời gian hơn cho việc tính toán pixel để có được bức tranh lớn hơn nếu bạn gửi các yếu tố mà nó biết cách chia tỷ lệ.
  • Dữ liệu trong nhiều trường hợp nhỏ hơn hình ảnh pixel (mặc dù không phải vậy)

Bạn không thể làm gì nhiều nếu một hệ thống có trình kết xuất lỗi. Ứng dụng cuối cùng của bạn là một lựa chọn và họ có thể sử dụng lựa chọn đó để đưa ra quyết định tồi.

Cái nào tốt hơn

Nó phụ thuộc vào mức độ bạn có thể kết xuất hình ảnh của mình và mức độ băng thông mà bạn có. Chắc chắn có thể thực hiện kết xuất tốt hơn so với những gì trình duyệt làm. Không thực sự đáng ngạc nhiên một người có thể làm một công việc tốt hơn so với Illustrator cũng. Nhưng sau đó, bạn mất tất cả những lợi ích của việc hiển thị hoãn lại.

Có một lựa chọn thứ ba.

Nếu bạn không hài lòng với kết quả, bạn luôn có thể cố gắng tạo công cụ kết xuất của riêng mình. Với các nền tảng hỗ trợ webgl bạn có thể. Xem ở đây cho một ví dụ . Nhưng điều này khá khó và không giúp bạn tiết kiệm chi tiết thực hiện.


2

(Chưa đủ điểm để nhận xét trực tiếp câu trả lời của Richard B.)

Để trả lời câu hỏi của bạn Richard B, chúng ta thường thấy hiệu ứng này đối với các yếu tố cần khử răng cưa trên phần cứng có công suất thấp hơn. Điều này thậm chí xảy ra trên các phần tử DOM được làm tròn góc, khi khử răng cưa bị giảm hoặc loại bỏ khỏi các môi trường đó.

Tại công ty của chúng tôi, chúng tôi có một số trường hợp sử dụng phần cứng công suất thấp hơn và bắt đầu gặp phải vấn đề "hình dạng rất lởm chởm" này. Chúng tôi đã vô hiệu hóa / giảm số lượng khử răng cưa để cải thiện hiệu suất. Đây có thể là lý do tương tự các thử nghiệm của bạn trên thiết bị di động đã trả về kết quả họ đã làm.


Làm cho ý nghĩa như là một lý do. Mặc dù vậy, các SVG xấu hổ dường như không có sự nhất quán với các loại hình ảnh khác.
Richard B

1
@RichardB, Chà, chúng khác với hình ảnh thông thường. Bạn thực sự có thể tương tác với chúng như thể chúng là các nút DOM. Đường dẫn và hình dạng của chúng nhận các sự kiện và thuộc tính CSS giống như các nút DOM thực, vì vậy nếu hiểu biết của tôi là chính xác, chúng sẽ theo cùng một đường dẫn kết xuất như các nút khác và điều đó có ý nghĩa trong bối cảnh này. Hình ảnh là các hộp rasterized và đi qua một kênh kết xuất khác, đôi khi thậm chí khắc hết không gian trên GPU.
Brak
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.