Изображения SVG выглядят лучше в уменьшенном виде, чем в высоком разрешении png, jpg или gif?


15

Я знаю, что если вы хотите увеличить изображение, то SVG - мудрый выбор.

Однако моя ситуация такова, что у меня есть значки, которые я хочу, чтобы пользователи могли загружать через CMS. SVG создавать немного сложнее, поэтому jpg, gif или png кажется идеальным форматом для администраторов.

Если загруженный файл имеет размер экрана больше или равен размеру экрана и имеет правильное соотношение, могут ли jpgs, gifs или pngs быть такого же высокого качества, как SVG, при уменьшении их размера?

Я предполагаю, что браузеры должны также сглаживать SVG ниже определенного размера, так что они, скорее всего, будут размыты так же, как и любой другой формат, хотя GIFs, кажется, размывают больше.


4
Хороший вопрос, но я считаю, что ответ «это зависит от браузера».
usr2564301

Ответы:


7

(Примечание: пожалуйста, прочитайте собственный ответ ФП до этого, так как мой ответ - комментарий к расследованию ФП)

Это известная проблема Android Chrome. На некоторых сборках они отключили сглаживание, в результате чего векторные фигуры отображались с четкими краями. Причиной этого было снижение перегрузки, создаваемой вычислениями сглаживания. Из-за жалоб они выпустили обновление, которое должно было включить антиалиасинг обратно.

В переполнении стека обсуждается несколько вопросов. Вот один из них:
/programming/19875908/vectors-poorly-displayed-on-chrome-for-android-canvas

Я не смог найти ссылку на ту же проблему на IPod Touch Safari, но, вероятно, это безопасно экстраполировать и предположить, что проблема та же.

Есть способы попробовать принудительно сглаживать сглаживание, даже когда оно отключено, например, этот трюк, который в основном добавляет немного отступов вокруг элемента, заставляя браузер по какой-то причине применять сглаживание. Вы также можете попытаться установить для атрибута рендеринга формы элемент, отличный от четких краев, и посмотреть, соблюдает ли его браузер.


Добавление -webkit-backface-visibility: hidden означает, что не-svgs размываются на iPod точно так же, как svgs, и это отвечает на мой вопрос - т.е. нет необходимости выбирать одно поверх другого при уменьшении. Как ни странно, исправление Android, похоже, не стандартизирует поведение рендеринга в моей версии Android Chrome / нативного браузера, но это другая проблема. Спасибо за вашу помощь.
Ричард Б

13

Я только что выполнил тест, и единственная разница, кажется, на мобильных браузерах.

Я создал изображение значка Twitter размером 990 x 900 пикселей (этот значок выглядит слишком детально, чтобы обеспечить хорошее масштабирование, поэтому этот тест хорош). Я сохранил это как SVG, JPG, GIF, прозрачный GIF (просто фигура птицы, без цвета фона, вместо добавления с помощью CSS), PNG, прозрачный PNG.

Затем я сократил их до 15px, 25px, 50px, 100px и 150px.

Вот результаты в Firefox: введите описание изображения здесь

Вот результаты в Chrome: введите описание изображения здесь

Если мы увеличим скриншот с наименьшими результатами, чтобы мы могли видеть, какие пиксели генерируются, тогда Firefox (вверху) слегка затемняет края непрозрачных версий, но все остальные результаты очень похожи.

введите описание изображения здесь

Тем не менее, в браузере IPod Touch Safari версия SVG выглядит довольно размытой, а остальные довольно пикселированными:

введите описание изображения здесь

Аналогичный результат также наблюдается на Android Chrome. Я не сделал скриншот этого.

Интересно, может ли это быть связано с плотностью пикселей, которая является основным различием в отображении, хотя для меня было бы больше смысла, если бы все изображения обрабатывались на мобильных устройствах по-разному, а не только в SVG.

Если кто-то может объяснить, почему это так, то я перенесу галочку принятого ответа. В противном случае, я предполагаю, что ответ TL; DR заключается в том, что это зависит от того, предпочитаете ли вы размытые или пиксельные значки (или для создания множества значков с идеальными размерами пикселей для ваших отзывчивых контрольных точек).

edit: с тех пор я заметил, что svgs обычно намного яснее на устройствах apple - птица twitter, возможно, была слишком подробной, чтобы ее можно было увидеть в моих тестах выше, поэтому чувствую, что они являются правильным форматом для значков.


SVG визуализируется во время отображения и может использовать AA, остальные имеют фиксированное разрешение, и единственный AA, который они могут иметь, это рендеринг 2x; размытие; и уменьшить, что на самом деле не поможет, кроме как в «очистке экрана». Для SVG фиксированный метод АА (как и в случае с простым 4х FSAA) будет чрезмерно агрессивным, когда у вас только ширина 8px, а понижающая дискретизация всегда приводит к некоторому размытию.
Йорик

Обратите внимание, что тип масштабирования и передискретизации зависит от реализации программного обеспечения. Большинство идет на «быстрый» или «сбалансированный» вместо качества.
Йорик

3

Существует очень важное различие между векторными изображениями и растровыми изображениями. Векторные изображения, если мы немного упростим, отображаются клиентом, в то время как растровые изображения воспроизводятся вами.

Это означает, что приложение, в которое вы отправляете изображение, больше говорит о его поведении. Конечным результатом является то, что у вас есть следующие недостатки :

  • Требуется больше ресурсов, чтобы сделать изображение презентабельным
    • В этом случае отрендеренный может отказаться от качества, потому что у него недостаточно ресурсов, чтобы сделать это лучше.
  • Каждая система визуализации имеет свой набор причуд и недостатков.
    • Трудно быть последовательным
    • Вы получаете проблемы программиста

С другой стороны, есть некоторые преимущества этого:

  • Изображение можно свободно масштабировать и иметь больше манипулятивных опций.
    • Это просто результат работы, проделанной на стороне клиента, поэтому они могут тратить больше времени на вычисление пикселей, чтобы получить большую картину, если вы отправляете элементы, которые знают, как масштабировать.
  • Данные во многих случаях меньше, чем пиксельное изображение (хотя это необязательно)

Если в системе есть глючный рендерер, вы мало что можете сделать. Ваше окончательное заявление - выбор, и они могут использовать этот выбор для принятия неверных решений.

Что лучше

Это зависит от того, насколько хорошо вы можете визуализировать ваше изображение и сколько пропускной способности у вас есть в вашем распоряжении. Конечно, можно сделать лучший рендер, чем браузеры. Не удивительно, что можно сделать лучше, чем Illustrator. Но тогда вы потеряете все преимущества отложенного рендеринга.

Есть третий вариант.

Если вы не удовлетворены результатами, вы всегда можете попробовать сделать свой собственный движок рендеринга. С платформами, которые поддерживают webgl, вы можете. Смотрите здесь для примера . Но это довольно хардкорно и не спасает вас от деталей реализации формы.


2

(Недостаточно очков, чтобы прокомментировать ответ Ричарда Б. непосредственно.)

Чтобы ответить на ваш вопрос, Ричард Б, мы часто видим этот эффект на элементах, нуждающихся в сглаживании на оборудовании с низким энергопотреблением. Это даже происходит на элементах DOM с закругленными углами, когда сглаживание уменьшается или удаляется из этих сред.

В нашей компании у нас есть несколько случаев, когда мы используем аппаратное обеспечение с низким энергопотреблением, и мы начали сталкиваться с этой проблемой «чрезвычайно зубчатых краев». Мы отключили / уменьшили количество сглаживания для повышения производительности. Это, вероятно, та же самая причина, по которой ваши тесты на мобильном телефоне дали результаты, которые они сделали.


Имеет смысл в качестве причины. Однако позор SVG не соответствует другим типам изображений.
Ричард Б.

1
@RichardB, ну, они как бы отличаются от обычных изображений. Вы можете взаимодействовать с ними, как если бы они были узлами DOM. Их пути и формы получают события и свойства CSS точно так же, как и реальные DOM-узлы, поэтому, если я правильно понимаю, они следуют тому же пути рендеринга, что и другие узлы, и это имеет смысл в этом контексте. Изображения представляют собой растрированные блоки и проходят через другой канал рендеринга, иногда даже выделяя пространство на GPU.
Брак
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.