Czy obrazy SVG wyglądają na lepiej pomniejszone niż pliki png, jpg lub gif w wysokiej rozdzielczości?

Wiem, że jeśli chcesz przeskalować obraz, to SVG to mądry wybór.

Jednak moją sytuacją jest to, że mam ikony, które chcę, aby użytkownicy mogli przesyłać za pośrednictwem CMS. Pliki SVG są nieco trudniejsze do utworzenia, więc jpg, gif lub png wydają się idealnym formatem dla administratorów.

Jeśli przesłane pliki są takie same lub większe niż rozmiar ekranu i są utrzymywane we właściwym stosunku, czy pliki jpg, gif lub png mogą być tak wysokiej jakości jak SVG po zmniejszeniu?

Zakładam, że przeglądarki muszą również antyializować plik SVG poniżej pewnego rozmiaru, więc prawdopodobnie rozmazują się tak samo jak każdy inny format, chociaż gify wydają się rozmazać więcej.

(Uwaga: proszę przeczytać własną odpowiedź PO przed tą, ponieważ moja odpowiedź jest komentarzem do dochodzenia PO)

Jest to znany problem Androida Chrome. W niektórych wersjach wyłączały wygładzanie, powodując, że kształty wektorowe były renderowane z wyraźnymi krawędziami. Powodem tego było zmniejszenie przeciążenia spowodowanego obliczeniami antyaliasingu. Z powodu skarg wydali aktualizację, która powinna była włączyć antyaliasing z powrotem.

W przepełnieniu stosu jest kilka wątków omawiających ten problem. Oto jeden z nich:
/programming/19875908/vectors-poorly-displayed-on-chrome-for-android-canvas

Nie mogłem znaleźć odniesienia do tego samego problemu w iPodzie Touch Safari, ale prawdopodobnie można bezpiecznie ekstrapolować i założyć, że problem jest taki sam.

Istnieją sposoby wymuszenia wymuszenia wygładzania, nawet gdy jest ono wyłączone, takie jak ta sztuczka, która zasadniczo dodaje nieco dopełnienia wokół elementu, powodując, że przeglądarka z jakiegoś powodu stosuje wygładzanie. Możesz także spróbować ustawić atrybut renderowania kształtu elementu na coś innego niż ostre krawędzie i sprawdzić, czy przeglądarka to honoruje.

Właśnie uruchomiłem test i jedyną różnicą wydaje się być przeglądarka mobilna.

Stworzyłem obraz ikony Twittera o wymiarach 990 x 900 pikseli (ta ikona wydaje się zbyt szczegółowa, aby można ją było dobrze skalować, więc jest dobra na ten test). Zapisałem to jako SVG, JPG, GIF, przezroczysty GIF (tylko kształt ptaka, bez koloru tła, zamiast dodawania tego z CSS), PNG, przezroczysty PNG.

Następnie zmniejszyłem je do 15 pikseli, 25 pikseli, 50 pikseli, 100 pikseli i 150 pikseli.

Oto wyniki w przeglądarce Firefox:

Oto wyniki w Chrome:

Jeśli powiększymy ekran o najmniejszych wynikach, aby zobaczyć, jakie piksele są generowane, Firefox (góra) nieznacznie przyciemnia krawędzie nieprzezroczystych wersji, ale wszystkie inne wyniki są bardzo podobne.

Jednak w przeglądarce IPod Touch Safari wersja SVG wydaje się dość rozmyta, a pozostałe dość pikselowane:

Podobny wynik widać również w systemie Android Chrome. Nie zrobiłem tego zrzutu ekranu.

Zastanawiam się, czy przyczyną tego może być gęstość pikseli, która jest główną różnicą w wyświetlaniu, choć byłoby to dla mnie bardziej sensowne, gdyby wszystkie obrazy były obsługiwane inaczej na urządzeniach mobilnych, niż tylko SVG.

Jeśli ktoś może wyjaśnić, dlaczego tak jest, prześlę zaakceptowaną odpowiedź. W przeciwnym razie, sądzę, że odpowiedź TL; DR zależy od tego, czy wolisz rozmyte lub pikselowane ikony (lub aby stworzyć wiele ikon o pikselach idealnych rozmiarów dla twoich responsywnych punktów przerwania).

edycja: Odtąd zauważyłem, że svgs są zwykle znacznie wyraźniejsze na urządzeniach Apple - ptak z Twittera mógł być zbyt szczegółowy, aby mógł to pokazać w moich testach powyżej, więc uważaj, że są one odpowiednim formatem dla ikon.

Istnieje bardzo ważne rozróżnienie między obrazami wektorowymi a obrazami bitmapowymi. Obrazy wektorowe, jeśli trochę uprościmy, są renderowane przez klienta, podczas gdy obrazy bitmapowe są renderowane przez Ciebie.

Oznacza to, że aplikacja, do której wysyłasz obraz ma więcej do powiedzenia na temat jego zachowania. Efektem końcowym jest to, że masz następujące wady :

• Aby obraz był reprezentatywny, potrzeba więcej zasobów
  • W takim przypadku renderowany może zdecydować się na obniżenie jakości, ponieważ nie ma wystarczających zasobów, aby zrobić to lepiej.
• Każdy system obrazowania ma swój własny zestaw dziwactw i wad
  • Utrudnia być konsekwentnym
  • Masz problemy z programistą

Z drugiej strony są z tego pewne zalety :

• Obraz można dowolnie skalować i mieć więcej opcji manipulacji.
  • Jest to po prostu wynik pracy wykonanej na końcu klienta, aby mogli poświęcić więcej czasu na obliczanie pikseli, aby uzyskać większy obraz, jeśli wyślesz elementy, które umie skalować.
• Dane w wielu przypadkach są mniejsze niż obraz w pikselach (choć nie musi tak być)

Niewiele można zrobić, jeśli system ma renderer błędów. Twoja aplikacja końcowa daje wybór, a oni mogą wykorzystać ten wybór do podjęcia złych decyzji.

Co jest lepsze

To zależy od tego, jak dobrze możesz renderować swój obraz i ile masz do dyspozycji przepustowości. Z pewnością możliwe jest lepsze renderowanie niż w przeglądarkach. Nic dziwnego, że można też wykonać lepszą robotę niż Illustrator. Ale wtedy tracisz wszystkie korzyści z odroczonego renderowania.

Istnieje trzecia opcja.

Jeśli nie jesteś zadowolony z wyników, zawsze możesz spróbować stworzyć własny silnik renderujący. Dzięki platformom obsługującym webgl możesz. Zobacz tutaj przykład . Ale to dość hardcorowe i nie oszczędza ci szczegółów implementacji.

(Za mało punktów, aby bezpośrednio skomentować odpowiedź Richarda B.)

Aby odpowiedzieć na twoje pytanie, Richard B, często widzimy ten efekt na elementach wymagających wygładzania na sprzęcie o niższej mocy. Dzieje się tak nawet w przypadku zaokrąglonych rogów elementów DOM, gdy wygładzanie jest zmniejszone lub usunięte z tych środowisk.

W naszej firmie mamy kilka przypadków, w których używamy sprzętu o niższej mocy i zaczęliśmy napotykać ten problem „bardzo postrzępionych kształtów”. Wyłączyliśmy / zmniejszyliśmy ilość antyaliasingu, aby poprawić wydajność. Jest to prawdopodobnie ten sam powód, dla którego testy na telefonie komórkowym zwróciły wyniki, które zrobiły.