Всемирная Паутина давно ужé обзавелась тремя разными способами отображения той или иной картинки в то время, когда она скачивается изъ Сѣти.
Во-первых, картинку можно показывать сверху вниз по мѣрѣ загрузки: как только скачивается очередная строчка пикселов, так сразу декодируется и поступает отображаться на экране. Или не сразу, а с небольшою задержкою, если формат предусматривает декодирование не раздѣльныхъ строк пикселов, а цѣлыхъ блоков (по восемь или даже по шестнадцать строк), как JPEG или WebP.
Во-вторых, можно поскорѣе заполнять всю площадь картинки размытым изображением, а затѣмъ «наводить на рѣзкость» — как правило, в этом случае читателю сайта приятнѣе дожидаться окончательной загрузки, ужé примѣрно видя (и предвкушая), что его ждёт. Но так как файл-то скачивается совершенно так же, как и в предшествующем случае (от первого байта къ послѣднему), то это формат файла должен предусматривать такую постепенность, а конкретная картинка — использовать эту (необязательную) возможность формата. Разные форматы графических файлов разными способами подошли къ рѣшенію такой задачи:
① Формат GIF предусматривает «чересстрочное» хранение строк пикселов: сперва скачивается каждая восьмая строчка (и этой осьмушки достаточно для получения полной картинки, но размытой по вертикали), затѣмъ ещё осьмушка, затѣмъ ещё четвертушка, затѣмъ оставшаяся половина строк.
② Формат PNG предусматривает перераспредѣленіе при хранении (для большей постепенности) не одних только строк пикселов, но также ещё и столбцов (по алгоритму Adam7), так что для первого представления об изображении достаточно скачать не одну восьмую, а всего-навсего одну шестьдесят четвёртую часть всѣхъ пикселов.
③ Формат JPEG предусматривает перераспредѣлённое хранение коэффициентов дискретного косинусного преобразования, начиная съ наиболѣе длинноволновых, так что картинка буквально «наводится на рѣзкость» по мѣрѣ скачивания. Нѣкоторое сходство равнопериодических коэффициентов способствует лучшей сжимаемости такого постепенного (progressive) файла JPEG (в отличие от простого перетасовывания пикселов, которое ухудшает сжимаемость файлов GIF и PNG и приводит к росту их объёма).
④ Формат WebP не предусматривает ничего даже отдалённо подобного, так что картинка WebP при скачивании может отображаться только сверху вниз.
В-третьих, картинку можно вообще не показывать по мѣрѣ загрузки, а только когда скачается вся цѣликомъ. Это происходит в трёх случаях:
➊ Когда адрес нѣкоторой картинки джаваскриптом подмѣняется на другой адрес, тогда браузер нѣкоторое время продолжает показывать прежнюю картинку, пока цѣликомъ не поступит новая изъ Сѣти.
➋ Браузер Internet Explorer (теперь ужé вышедший из употребления) полностью полагался на возможности декодирования изображений, предоставляемыя операционною системою, поэтому не мог постепенно декодировать progressive JPEG до тѣхъ поръ, пока поддержка такой постепенности не появилась в Windows (а она, по-видимому, появилась в Windows 7, то есть не раньше второй половины 2009 г.).
➌ Формат AVIF не предусматривает никакой постепенности декодирования (даже такой, которая сверху вниз), так что картинка может быть показана только опосля полного скачивания ея из Интернета.
Этот недостаток AVIF — важнѣйшій среди тѣхъ, с которыми поневоле придётся мириться ради тѣхъ достоинств формата AVIF, которые я перечислял в предшествующем сообщении.
Другой важный недостаток AVIF — недостаточная сила алгоритмов, обеспечивающих сжатие изображения без внесения потерь в него. Практически это означает, что AVIF будут охотно использовать только как средство сжатия с внесением потерь в изображения (которое в AVIF работает мощно), а для сжатия без потерь — с неохотою и только тогда, когда альтернативные способы ещё хуже. Примѣръ: если без потерь захочется хранить изображение, состоящее из тридцатибитных пикселов, то тогда на формат WebP нельзя полагаться (он ограничен 24 битами на пиксел), а файл PNG получился бы громадным (у формата PNG сразу за 24 битами слѣдуютъ 48 битов на пиксел, промежуточныя битности не предусмотрены), так что AVIF справится лучше их.
Во-первых, картинку можно показывать сверху вниз по мѣрѣ загрузки: как только скачивается очередная строчка пикселов, так сразу декодируется и поступает отображаться на экране. Или не сразу, а с небольшою задержкою, если формат предусматривает декодирование не раздѣльныхъ строк пикселов, а цѣлыхъ блоков (по восемь или даже по шестнадцать строк), как JPEG или WebP.
Во-вторых, можно поскорѣе заполнять всю площадь картинки размытым изображением, а затѣмъ «наводить на рѣзкость» — как правило, в этом случае читателю сайта приятнѣе дожидаться окончательной загрузки, ужé примѣрно видя (и предвкушая), что его ждёт. Но так как файл-то скачивается совершенно так же, как и в предшествующем случае (от первого байта къ послѣднему), то это формат файла должен предусматривать такую постепенность, а конкретная картинка — использовать эту (необязательную) возможность формата. Разные форматы графических файлов разными способами подошли къ рѣшенію такой задачи:
① Формат GIF предусматривает «чересстрочное» хранение строк пикселов: сперва скачивается каждая восьмая строчка (и этой осьмушки достаточно для получения полной картинки, но размытой по вертикали), затѣмъ ещё осьмушка, затѣмъ ещё четвертушка, затѣмъ оставшаяся половина строк.
② Формат PNG предусматривает перераспредѣленіе при хранении (для большей постепенности) не одних только строк пикселов, но также ещё и столбцов (по алгоритму Adam7), так что для первого представления об изображении достаточно скачать не одну восьмую, а всего-навсего одну шестьдесят четвёртую часть всѣхъ пикселов.
③ Формат JPEG предусматривает перераспредѣлённое хранение коэффициентов дискретного косинусного преобразования, начиная съ наиболѣе длинноволновых, так что картинка буквально «наводится на рѣзкость» по мѣрѣ скачивания. Нѣкоторое сходство равнопериодических коэффициентов способствует лучшей сжимаемости такого постепенного (progressive) файла JPEG (в отличие от простого перетасовывания пикселов, которое ухудшает сжимаемость файлов GIF и PNG и приводит к росту их объёма).
④ Формат WebP не предусматривает ничего даже отдалённо подобного, так что картинка WebP при скачивании может отображаться только сверху вниз.
В-третьих, картинку можно вообще не показывать по мѣрѣ загрузки, а только когда скачается вся цѣликомъ. Это происходит в трёх случаях:
➊ Когда адрес нѣкоторой картинки джаваскриптом подмѣняется на другой адрес, тогда браузер нѣкоторое время продолжает показывать прежнюю картинку, пока цѣликомъ не поступит новая изъ Сѣти.
➋ Браузер Internet Explorer (теперь ужé вышедший из употребления) полностью полагался на возможности декодирования изображений, предоставляемыя операционною системою, поэтому не мог постепенно декодировать progressive JPEG до тѣхъ поръ, пока поддержка такой постепенности не появилась в Windows (а она, по-видимому, появилась в Windows 7, то есть не раньше второй половины 2009 г.).
➌ Формат AVIF не предусматривает никакой постепенности декодирования (даже такой, которая сверху вниз), так что картинка может быть показана только опосля полного скачивания ея из Интернета.
Этот недостаток AVIF — важнѣйшій среди тѣхъ, с которыми поневоле придётся мириться ради тѣхъ достоинств формата AVIF, которые я перечислял в предшествующем сообщении.
Другой важный недостаток AVIF — недостаточная сила алгоритмов, обеспечивающих сжатие изображения без внесения потерь в него. Практически это означает, что AVIF будут охотно использовать только как средство сжатия с внесением потерь в изображения (которое в AVIF работает мощно), а для сжатия без потерь — с неохотою и только тогда, когда альтернативные способы ещё хуже. Примѣръ: если без потерь захочется хранить изображение, состоящее из тридцатибитных пикселов, то тогда на формат WebP нельзя полагаться (он ограничен 24 битами на пиксел), а файл PNG получился бы громадным (у формата PNG сразу за 24 битами слѣдуютъ 48 битов на пиксел, промежуточныя битности не предусмотрены), так что AVIF справится лучше их.