Нужно ли загружать больше сжатых изображений PNG?

Question

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

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

РЕДАКТИРОВАТЬ: В ответ на ответы, которые я получил, я хочу отметить, что это не является чисто сетевой проблемой. Пользователи Windows могут не заметить этого, но большинство значков, используемых в среде рабочего стола, хранятся со сжатием PNG, и десятки из них должны отображаться при запуске системы. Огромный штриховой рисунок, на который я ссылался, был в основном обоями для рабочего стола, такими как на http://simpledesktops.com/, но различные постеры, ресурсы по видеоиграм и другие вещи могли бы соответствовать этому описанию.

Answer 1

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

Если вы хотите минимизировать размер файла при сохранении файла PNG, жертва приходит во время, необходимое для сжатия файла.

PNG сжимает данные изображения с помощью DEFLATE (тот же алгоритм, который используется в zlib и PKZIP). Один из способов DEFLATE экономит пространство - это кодирование повторяющихся последовательностей байтов, просто указав длину пробега и расстояние до того места, где оно ранее появилось в потоке. (Например, A B C D E F A B C A B C D может быть закодирован как A B C D E F [3,-6] [4,-9] . (Он также может быть закодирован как A B C D E F [3,-6] [3,-3] D )

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

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

Как правило, чем меньше битов он читает, тем быстрее будет распаковка PNG.

Answer 2

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

Я нашел большой PNG-файл в Интернете, открыл его в GIMP и сохранил 2 его версии - 1 с уровнем сжатия 9 (очень маленький) и 1 с уровнем сжатия 0 (большой).

Сильно сжатый файл был 1,8 мегабайта, слегка сжатый png - 4,7 мегабайта. Изображение было чем-то, что я схватил с Google, и было изображением звездного скопления.

Затем я написал скрипт для преобразования изображения из png в tif (в предположении, что TIF - относительно несжатый формат файла, довольно быстрый) 200 раз и рассчитал время вывода. В каждом случае я быстро запускал сценарий и прерывал его через несколько секунд, чтобы любое системное кэширование могло вступить в силу перед выполнением полного теста, тем самым уменьшая влияние диска io (и мой компьютер использует SSD, что также минимизирует это влияние). Результаты были следующими:

Converting the small file 200 times - 1 minute, 16.07 seconds
Converting the large file 200 times - 1 minute, 22.39 seconds

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

Но это не учитывает время, необходимое для загрузки файла. Это, конечно, будет зависеть от скорости вашего соединения, расстояния до сервера и размера файла. Если для передачи большого файла требуется больше, чем примерно 0,5 секунды, а затем маленького файла, то (в моей системе - это более старый ультрабук, такой медленный, что дает консервативный сценарий), лучше отправлять более сжатые файлы. файл. В этом случае - это означает отправку 5,8 мегабайта в секунду, что примерно равно 60 мегабитам в секунду, исключая проблемы с задержкой.

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

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

Answer 3

Нет, на самом деле все, что вам нужно сделать, это поднять 64-пиксельный PNG и 64-пиксельный JPG, чтобы увидеть, как время, необходимое для распаковки, настолько ничтожно мало, что может быть несущественным ... прямо перед тем, как вы поймете, что вы слишком много времени проводил, думая об этом. :) Потому что мы говорим о таких небольших по размеру изображениях в пикселях, которые составляют иконку. При увеличении размера jpg как формат с потерями также не сохранит изображение. Вот где png как формат без потерь действительно сияет.

С технической точки зрения, вы правы в отношении доли повышения производительности в миллисекундах, которое вы получите, если не будете распаковывать формат без потерь, такой как png, просто эта доля вряд ли принесет вам много пользы, потому что вы Вы не сможете ничего сделать со временем, которое вы сэкономили. Jpg полезен только потому, что он все еще может сохранять 90% своего качества при 64 пикселях, даже несмотря на то, что он выделяет небольшую часть своей оригинальной детализации, которую он просто слишком мал, чтобы заметить. PNG почти столь же целесообразен, хотя его качество как формат без потерь не страдает вообще, что делает его намного лучшим выбором IMO.

Есть ли какая-то прагматическая причина, почему вы так долго обдумывали это?

Так что было бы лучше иметь представление о том, что вы считаете «огромными линейными файлами», если у вас есть законный вопрос о том, куда вы идете с этим.