Media is too big
VIEW IN TELEGRAM
Вот видеозапись того, как я #сегодня проѣзжалъ #Геленджик примѣрно в направлении хребта #Маркотх (вершины которого покрыты низкими облаками), став на #моноколесо.
Отправная точка — #набережная.
Конечная точка — улица Луначарского и далѣе к углу Туристической.
(Разумѣется, это было частью болѣе продолжительной поѣздки. О ея причинѣ я разсказалъ въ Твиттерѣ.)
Отправная точка — #набережная.
Конечная точка — улица Луначарского и далѣе к углу Туристической.
(Разумѣется, это было частью болѣе продолжительной поѣздки. О ея причинѣ я разсказалъ въ Твиттерѣ.)
🐦 Опубликован очередной сборник моих твиттеровских микроблогозаписей.
ipfs.io
Twitter: @FidonetRunes
Ad lux tenebrae (@svartvind) 2019-12-21 09:24:25 (UTC) https://twitter.com/svartvind/status/1208317286848839682 Рыбный ларёк в Мурманске во время снегопада. Снимок: Amos Chapple RFE/RL. TJ (@tjournal➡
В конце 2019 года многие глядят в 2020 год с намѣреніемъ предвидѣть перемѣны, которые в нём произойдут.
Одна изъ вѣроятныхъ перемѣнъ состоит в том, что сайтостроение в 2020 году, вполне вѣроятно, будет выглядеть нѣсколько иначе, чѣмъ прежде. Формат GIF будет рѣже использоваться для анимаций, а формат PNG будет рѣже использоваться для сжатия изображений, совершаемого без потерь. Тѣ теги picture и source в языке HTML5, которые сейчас используют для указания нѣсколькихъ версий одного и того же изображения, отличающихся количеством пикселов, также будут для этой цѣли использоваться порѣже.
Всё это будет именно одна-единственная перемѣна, происходящая от одной причины — от появления нового графического формата JPEG XL. Он развивает идеи популярного (но старинного, 1992 года) формата JPEG вот в каком направлении:
1️⃣ Формат JPEG не содержал какой-либо поддержки анимаций. (Это привело ко многодесятилетней популярности анимаций в формате GIF, который только въ послѣдніе годы слегка потеснён был форматом «зацикленные видеоролики без звука».) Формат JPEG XL обещает обеспечить поддержку анимаций.
2️⃣ Формат JPEG для устранения избыточности использовал код Хаффмана. (Также предусматривалась возможность использовать арифметическое кодирование, но не возымела широкое примѣненіе, так как в то время запатентованность алгоритма воспрепятствовала этому.) Формат JPEG XL обещает использовать современные методы сильного сжатия данных — Brotli и ANS.
3️⃣ Формат JPEG поддерживал постепенное отображение файла по мѣрѣ его загрузки из Сѣти. В отличие от формата PNG, в котором подобное постепенное отображение достигалось реальною перестановкою пикселов в файле (по алгоритму Adam7) и оттого нерѣдко приводило к ухудшению сжимаемости (к росту объёма файла), формат JPEG использовал перестановку коэффициентов дискретного косинусного преобразования, что чаще усиливало сжимаемость (уменьшало объём файла). Но если скачивающийся файл PNG с постепенным отображением имѣлъ видъ картинки кратно меньшего размѣра (в два, в четыре, в восемь раз меньшей по ширине и высоте), растянутой затѣмъ до полнаго размѣра файла, то скачивающийся файл JPEG с постепенным отображением имѣлъ вид полноразмѣрной картинки «не въ фокусѣ», по мѣрѣ её скачивания постепенно «наводящейся на рѣзкость». Формат JPEG XL поэтому обещает использовать подход, превосходящий достоинства того и другого: при подготовке файла к постепенному отображению будет изготовляться картинка кратно меньшего размера (уменьшение высоты вдвое ➡️ уменьшение ширины вдвое ➡️ уменьшение высоты ещё вдвое ➡️ уменьшение ширины ещё вдвое ➡️ и такъ далѣе), но изготовляться не примитивною перестановкою (оставляющею за собою хуже сжимаемую мѣшанину пикселов, как Adam7), а двумерным вейвлетным преобразованием Альфреда Хаара, оставляющим за собою разностные (а значит, для изображений с плавными цвѣтовыми переходами — небольшие и оттого лучше сжимаемые) величины. Формат JPEG XL также обещает в самóм же файле явное указание положения границ между многократно уменьшенным основным изображением и каждым очередным набором разностей, потребных для очередного удвоения этой миниатюры по высоте или по ширине — это как раз и значит, что сайтостроителям не понадобится создавать серию тегов source внутри тега picture и указывать в них файлы разного размѣра для дисплеев с разной шириной или разной плотностью пикселов: сам браузер сможет использовать один и тот же файл JPEG XL, не докачивая его с сервера до конца въ тѣхъ случаях, когда изображение нужно не в полном размѣрѣ, а в половинном, или четвертном, или ещё меньшем. Частично уйдут в прошлое (станут ненужными) и всѣ ухищрения (в том числе градиентные или векторные), въ послѣдніе годы популярные при изготовлении малоразмѣрныхъ заглушек (для показа на мѣстѣ изображения до начала его загрузки из Сѣти), так как самое начало (буквально пара сотен байтов) файла JPEG XL, готового к постепенному отображению, может само по себе служить заглушкою, полученною на очередном шаге преобразования Хаара (его шагов, в отличие от Adam7, в JPEG XL может быть явно больше семи — скажем, пара десятков).
Одна изъ вѣроятныхъ перемѣнъ состоит в том, что сайтостроение в 2020 году, вполне вѣроятно, будет выглядеть нѣсколько иначе, чѣмъ прежде. Формат GIF будет рѣже использоваться для анимаций, а формат PNG будет рѣже использоваться для сжатия изображений, совершаемого без потерь. Тѣ теги picture и source в языке HTML5, которые сейчас используют для указания нѣсколькихъ версий одного и того же изображения, отличающихся количеством пикселов, также будут для этой цѣли использоваться порѣже.
Всё это будет именно одна-единственная перемѣна, происходящая от одной причины — от появления нового графического формата JPEG XL. Он развивает идеи популярного (но старинного, 1992 года) формата JPEG вот в каком направлении:
1️⃣ Формат JPEG не содержал какой-либо поддержки анимаций. (Это привело ко многодесятилетней популярности анимаций в формате GIF, который только въ послѣдніе годы слегка потеснён был форматом «зацикленные видеоролики без звука».) Формат JPEG XL обещает обеспечить поддержку анимаций.
2️⃣ Формат JPEG для устранения избыточности использовал код Хаффмана. (Также предусматривалась возможность использовать арифметическое кодирование, но не возымела широкое примѣненіе, так как в то время запатентованность алгоритма воспрепятствовала этому.) Формат JPEG XL обещает использовать современные методы сильного сжатия данных — Brotli и ANS.
3️⃣ Формат JPEG поддерживал постепенное отображение файла по мѣрѣ его загрузки из Сѣти. В отличие от формата PNG, в котором подобное постепенное отображение достигалось реальною перестановкою пикселов в файле (по алгоритму Adam7) и оттого нерѣдко приводило к ухудшению сжимаемости (к росту объёма файла), формат JPEG использовал перестановку коэффициентов дискретного косинусного преобразования, что чаще усиливало сжимаемость (уменьшало объём файла). Но если скачивающийся файл PNG с постепенным отображением имѣлъ видъ картинки кратно меньшего размѣра (в два, в четыре, в восемь раз меньшей по ширине и высоте), растянутой затѣмъ до полнаго размѣра файла, то скачивающийся файл JPEG с постепенным отображением имѣлъ вид полноразмѣрной картинки «не въ фокусѣ», по мѣрѣ её скачивания постепенно «наводящейся на рѣзкость». Формат JPEG XL поэтому обещает использовать подход, превосходящий достоинства того и другого: при подготовке файла к постепенному отображению будет изготовляться картинка кратно меньшего размера (уменьшение высоты вдвое ➡️ уменьшение ширины вдвое ➡️ уменьшение высоты ещё вдвое ➡️ уменьшение ширины ещё вдвое ➡️ и такъ далѣе), но изготовляться не примитивною перестановкою (оставляющею за собою хуже сжимаемую мѣшанину пикселов, как Adam7), а двумерным вейвлетным преобразованием Альфреда Хаара, оставляющим за собою разностные (а значит, для изображений с плавными цвѣтовыми переходами — небольшие и оттого лучше сжимаемые) величины. Формат JPEG XL также обещает в самóм же файле явное указание положения границ между многократно уменьшенным основным изображением и каждым очередным набором разностей, потребных для очередного удвоения этой миниатюры по высоте или по ширине — это как раз и значит, что сайтостроителям не понадобится создавать серию тегов source внутри тега picture и указывать в них файлы разного размѣра для дисплеев с разной шириной или разной плотностью пикселов: сам браузер сможет использовать один и тот же файл JPEG XL, не докачивая его с сервера до конца въ тѣхъ случаях, когда изображение нужно не в полном размѣрѣ, а в половинном, или четвертном, или ещё меньшем. Частично уйдут в прошлое (станут ненужными) и всѣ ухищрения (в том числе градиентные или векторные), въ послѣдніе годы популярные при изготовлении малоразмѣрныхъ заглушек (для показа на мѣстѣ изображения до начала его загрузки из Сѣти), так как самое начало (буквально пара сотен байтов) файла JPEG XL, готового к постепенному отображению, может само по себе служить заглушкою, полученною на очередном шаге преобразования Хаара (его шагов, в отличие от Adam7, в JPEG XL может быть явно больше семи — скажем, пара десятков).
Блок-схема преобразований, совершаемых над иллюстрацией при сохранении её в формате JPEG XL.
Источник: Jon Sneyers, «Next-generation image formats for the Internet», июнь 2019 г., Imagecon 2019.
Источник: Jon Sneyers, «Next-generation image formats for the Internet», июнь 2019 г., Imagecon 2019.
Переход от многофайлового подхода к ситуации с различною плотностью пикселов и различною шириною устройств к однофайловому подходу за счёт возможности частичного скачивания файла JPEG XL (подготовленного к постепенному отображению по мѣрѣ скачивания), обеспечивающей получение нужной (кратно уменьшенной) версии изображения.
Источник: Jon Sneyers, «Next-generation image formats for the Internet», июнь 2019 г., Imagecon 2019.
Источник: Jon Sneyers, «Next-generation image formats for the Internet», июнь 2019 г., Imagecon 2019.
This media is not supported in your browser
VIEW IN TELEGRAM
Результат примѣненія первых четырёх шагов двумерного вейвлетного преобразования Альфреда Хаара къ чёрно-бѣлой фотографии.
Источник: Jon Sneyers, «Next-generation image formats for the Internet», июнь 2019 г., Imagecon 2019.
Источник: Jon Sneyers, «Next-generation image formats for the Internet», июнь 2019 г., Imagecon 2019.
4️⃣ Формат JPEG предусматривал перевод пикселов RGB въ цвѣтовое пространство YCbCr, чѣмъ обеспечивалось нѣкоторое уменьшение информационной избыточности (которое дополнительно могло быть усилено примѣненіемъ цвѣтовой субдискретизации с отбрасыванием до половины информации, содержащейся в исходных пикселах). Формат JPEG XL обещает перевод въ нѣкое болѣе новое цвѣтовое пространство XYB, лучше соотвѣтствующее возможностям человѣческаго зрѣнія, а также предлагает современный инструмент устранения информационной избыточности (для сжатия изображения) за счёт обнаружения и использования взаимосвязи между цветовыми и яркостными значениями пикселов (chroma from luma, сокращённо — CfL; приём не слишком новый, поскольку примѣрно он же используется и в видеоформате AV1, напримѣръ).
Источник иллюстрации: Jon Sneyers, «Next-generation image formats for the Internet», июнь 2019 г., Imagecon 2019.
Источник иллюстрации: Jon Sneyers, «Next-generation image formats for the Internet», июнь 2019 г., Imagecon 2019.
5️⃣ Формат JPEG сжимал всѣ участки изображения с равным качеством (и с равными потерями данных). Формат JPEG XL, работая в режиме сжатия с потерями, обещает оставлять меньше информации (и вносить бóльшие потери) на тѣхъ участках изображения, которые изначально не слишком содержательны — на таких, напримѣръ, как однотонный (или почти однотонный) фон. За счёт этого будет экономиться объём файла (или, при сохранении объёма файла, наращиваться качество значимых участков изображения).
Источник иллюстрации: Jon Sneyers, «Next-generation image formats for the Internet», июнь 2019 г., Imagecon 2019.
Источник иллюстрации: Jon Sneyers, «Next-generation image formats for the Internet», июнь 2019 г., Imagecon 2019.
6️⃣ Для формата JPEG существовал и вариант со сжатием, совершаемым без каких-либо потерь, но он (в отличие от основного стандарта) широкой поддержки не получил. Использовавшиеся в нём предикторы были близкими аналогами фильтров PNG, а ведь формат PNG поддерживал также дополнительный альфа-канал изображения (обеспечивавший возможность задавать полную или частичную прозрачность пикселов) и оттого обошёл JPEG по возможностям хранения изображений без потерь. Формат JPEG XL навёрстывает это отставание, обещая поддерживать и сжатие без потерь, и хранение альфа-канала прозрачности, и даже возможность употребления дополнительных каналов, имеющих альтернативное предназначение (в частности, возможность хранить канал глубины, необходимый фотокамерам, совмещённым с лазерными дальномерами — как у Intel RealSense, напримѣръ). За счёт болѣе современных методов сжатия (Brotli, ANS, CfL) формат JPEG XL обещает «убить» (навсегда превзойти собою) формат PNG, поддерживая пересохранение из PNG в JPEG XL, совершаемое без потерь и обеспечивающее экономию нѣсколькихъ десятков процентов объёма файла. А так как формат JPEG XL обещает и поддержку анимации, то «убить» он собирается и GIF, и анимированные PNG.
7️⃣ За прошедшее десятилетие был предложен ряд новых форматов сжатия изображений, основанных на форматах сжатия ключевых кадров в видеозаписях: WebP, BPG, HEIF (HEIC), AVIF — всѣ они обеспечивают очень хорошее (и от формата к формату постепенно улучшающееся) соотношение объёма и качества, хотя и не без недостатков, свойственных их происхождению: не поддерживают постепенное отображение по мѣрѣ скачивания из Сѣти (потому что создавались с расчётом на то, что ключевой кадр придёт сразу весь), а также с бóльшими потерями кодируют (сильнѣе размывают) тѣ элементы изображения, которые не содержат рѣзкихъ цвѣтовыхъ переходов (а это не только фон, но и, напримѣръ, щёки персонажиц), так как за доли секунды на кадре видеозаписи эти потери не замѣтны. Однако же за четверть вѣка накопилася масса файлов JPEG, для экономии мѣста изрядно сжатых в своё время (а несжатые оригиналы либо утрачены, либо их и не было никогда, если JPEG прямо из фотокамеры пришёл изрядно сжатым). Такие файлы JPEG бесполезно переужимать в любом из только что перечисленных новых форматов (несмотря на всѣ явные достоинства этих форматов), потому что получится либо ясно видное нарастание ошибок сжатия, либо возрастание объёма файла (которым обессмысливается переужатие), либо сочетание и того, и другого недостатка. Формат JPEG XL обещает, однако, освободиться от этой ловушки, поддерживая особый формат пересжатия, ориентированный специально на файлы JPEG и сохраняющий их данные (то есть коэффициенты дискретного косинусного преобразования), не подвергая их внесению дополнительных потерь, но зато использующий современные методы сжатия без потерь (Brotli и ANS) для большей экономии объёма файла, а также и современный метод улучшения видимого качества изображения (указание использовать деблокирующий фильтр после декодирования), который не обязателен (то есть можно обойтись без его указания, если поставлена задача сохранить внешний вид прежней картинки без измѣненій, хотя бы и улучшающих вид её). Это позволяет формату JPEG XL не просто «убить» прежний JPEG (навсегда превзойти его по степени сжатия с надёжным сохранением прежнего или нѣсколько лучшаго вида иллюстраций), но и обеспечить полную обратную совместимость с ним (возможность в любой момент без потерь вытащить данные в формате прежнего JPEG из файла JPEG XL — напримѣръ, для скармливания их во браузер из 2019 года, ещё не наученный воспринимать JPEG XL) в этом частном случае староJPEGового происхождения.
Короче говоря, цѣль JPEG XL состоит в том, чтобы замѣнить собою (к лучшему!) и старый JPEG, и GIF, и PNG (как обычный, так и анимированный), а также изрядно превзойти и WebP, и BPG, и HEIF (HEIC), и AVIF, предлагая отсутствующие у них возможности: постепенное или неполное отображение, дополнительные каналы, сжатие без потерь, обратную совместимость со старым JPEG, etc.
Буквально «всѣхъ убью, один останусь».
One JPEG to rule them all.
7️⃣ За прошедшее десятилетие был предложен ряд новых форматов сжатия изображений, основанных на форматах сжатия ключевых кадров в видеозаписях: WebP, BPG, HEIF (HEIC), AVIF — всѣ они обеспечивают очень хорошее (и от формата к формату постепенно улучшающееся) соотношение объёма и качества, хотя и не без недостатков, свойственных их происхождению: не поддерживают постепенное отображение по мѣрѣ скачивания из Сѣти (потому что создавались с расчётом на то, что ключевой кадр придёт сразу весь), а также с бóльшими потерями кодируют (сильнѣе размывают) тѣ элементы изображения, которые не содержат рѣзкихъ цвѣтовыхъ переходов (а это не только фон, но и, напримѣръ, щёки персонажиц), так как за доли секунды на кадре видеозаписи эти потери не замѣтны. Однако же за четверть вѣка накопилася масса файлов JPEG, для экономии мѣста изрядно сжатых в своё время (а несжатые оригиналы либо утрачены, либо их и не было никогда, если JPEG прямо из фотокамеры пришёл изрядно сжатым). Такие файлы JPEG бесполезно переужимать в любом из только что перечисленных новых форматов (несмотря на всѣ явные достоинства этих форматов), потому что получится либо ясно видное нарастание ошибок сжатия, либо возрастание объёма файла (которым обессмысливается переужатие), либо сочетание и того, и другого недостатка. Формат JPEG XL обещает, однако, освободиться от этой ловушки, поддерживая особый формат пересжатия, ориентированный специально на файлы JPEG и сохраняющий их данные (то есть коэффициенты дискретного косинусного преобразования), не подвергая их внесению дополнительных потерь, но зато использующий современные методы сжатия без потерь (Brotli и ANS) для большей экономии объёма файла, а также и современный метод улучшения видимого качества изображения (указание использовать деблокирующий фильтр после декодирования), который не обязателен (то есть можно обойтись без его указания, если поставлена задача сохранить внешний вид прежней картинки без измѣненій, хотя бы и улучшающих вид её). Это позволяет формату JPEG XL не просто «убить» прежний JPEG (навсегда превзойти его по степени сжатия с надёжным сохранением прежнего или нѣсколько лучшаго вида иллюстраций), но и обеспечить полную обратную совместимость с ним (возможность в любой момент без потерь вытащить данные в формате прежнего JPEG из файла JPEG XL — напримѣръ, для скармливания их во браузер из 2019 года, ещё не наученный воспринимать JPEG XL) в этом частном случае староJPEGового происхождения.
Короче говоря, цѣль JPEG XL состоит в том, чтобы замѣнить собою (к лучшему!) и старый JPEG, и GIF, и PNG (как обычный, так и анимированный), а также изрядно превзойти и WebP, и BPG, и HEIF (HEIC), и AVIF, предлагая отсутствующие у них возможности: постепенное или неполное отображение, дополнительные каналы, сжатие без потерь, обратную совместимость со старым JPEG, etc.
Буквально «всѣхъ убью, один останусь».
One JPEG to rule them all.
Необратимое пересохранение изображения из JPEG в WebP (съ замѣтнымъ ростом объёма файла и с небольшой потерей данных) и обратимое пересохранение изображения из JPEG в JPEG XL (со значительной экономией объёма файла, с отсутствием потерь данных и с небольшим ростом наблюдаемого качества изображения).
Источник: Jon Sneyers, «Next-generation image formats for the Internet», июнь 2019 г., Imagecon 2019.
Источник: Jon Sneyers, «Next-generation image formats for the Internet», июнь 2019 г., Imagecon 2019.
Сильное сглаживание щёк персонажицы при сохранении в формате HEIC.
Источник: Jon Sneyers, «Next-generation image formats for the Internet», июнь 2019 г., Imagecon 2019.
Источник: Jon Sneyers, «Next-generation image formats for the Internet», июнь 2019 г., Imagecon 2019.
Объём нефотографических иллюстраций, пересохранённых в JPEG XL в режиме сжатия без потерь, составляет в среднем 70% от объёма файлов PNG (который принят за 100%, поэтому умѣстно предполагать, что из PNG эти иллюстрации и брались).
Объём восьмибитных и двенадцатибитных фотографий, пересохранённых в JPEG XL в режиме сжатия без потерь, составляет в среднем соответственно 88% и 96% от объёма файлов JPEG 2000 (который принят за 100%, поэтому умѣстно предполагать, что из JPEG 2000 эти фотографии и брались).
Источник: Jon Sneyers, «Next-generation image formats for the Internet», июнь 2019 г., Imagecon 2019.
Объём восьмибитных и двенадцатибитных фотографий, пересохранённых в JPEG XL в режиме сжатия без потерь, составляет в среднем соответственно 88% и 96% от объёма файлов JPEG 2000 (который принят за 100%, поэтому умѣстно предполагать, что из JPEG 2000 эти фотографии и брались).
Источник: Jon Sneyers, «Next-generation image formats for the Internet», июнь 2019 г., Imagecon 2019.
JPEG XL.7z
5.4 MB
Jon Sneyers, «Next-generation image formats for the Internet», июнь 2019 г., Imagecon 2019.
Архивная копия для читателей, не способных открыть первоисточник на сайте Slideshare ввиду блокировок, наложенных на этот сайт Роскомнадзором.
Архивная копия для читателей, не способных открыть первоисточник на сайте Slideshare ввиду блокировок, наложенных на этот сайт Роскомнадзором.
Ознакомившись с одиннадцатью предшествующими сообщениями, нѣкоторые из моих читателей навѣрняка пожелают узнать поподробнѣе: а когда именно начнёт в 2020 году наступать то будущее, в котором останется один-единственный формат графических файлов?
По-видимому, довольно скоро.
Во всяком случае, двѣ недѣли тому назад группа JPEG на своём восемьдесят пятом заседании решила, что настала пора открывать исходный код программного обеспéчения JPEG XL, а также и что переход на стадию черновика международного стандарта состоится ужé в январе будущего (2020) года. Понятно, что это не предсказание грядущего, а всего лишь декларация о намѣреніяхъ, но и она способна и должна послужить нам поводом для оптимизма.
Кое-какой исходный код уж и открыт. Напримѣръ, дѣйствуетъ гугловский перекодировщик из JPEG в JPEG XL (работающий в том сáмом режиме обратной совместимости с JPEG, который без потерь, но зато и без Хаара). Естественно, одного его не достаточно, но ведь и разговоры об открытии исходного кода нѣкоего болѣе универсального кодировщика происходили на прошлой недѣлѣ въ Твиттерѣ.
Нѣсколько позже поддержка JPEG XL будет потихоньку появляться и во браузерах Всемирной Паутины. Даже можно заранее предвидеть, и предвидеть небезосновательно, что сперва она появится в Google Chrome и во браузерах на его движке (в Opera, в Microsoft Edge, etc.), поскольку гугловский формат PIK был одним из извѣстныхъ источников вдохновения для JPEG XL (а другим был FUIF от Cloudinary), так что самих себя отчего бы и не поддержать им. Можно заранее предвидеть ещё, что послѣднею поддержка JPEG XL появится во браузере Safari компании Apple, потому что Apple традиционно неохотно поддерживает идеи Google. (Ну, напримѣръ, Safari до сих пор не поддерживает формат WebP, появившийся в сентябре 2010 года. Я вѣрю в их способность и с поддержкою формата JPEG XL затянуть дѣло лѣтъ на десять, а не то и на пятнадцать.) Фонд Мозиллы, в свою очередь, вполне способен породить на свѣтъ какую-нибудь такую новую версию своего Файерфокса, которая будет полноцѣнно поддерживать новый формат, но на которую пользователи станут переходить с превеликою неохотою, потому что в ней же (или ещё ранѣе) заодно отвалится интерфейс одного или нескольких популярных расширений. (Я очень хорошо помню, напримѣръ, что начало поддержки формата WebP в Файерфоксе в январе нынешнего года происходит на фоне длящегося вот ужé болѣе двухъ лѣтъ отказа от поддержки программного интерфейса, ранѣе служившего для управления сеансами, и что число жертв этого отказа оцѣнивается как близкое к миллиону людей: 600 000 пользователей у расширения Tab Mix Plus, 300 000 у Session Manager, 60 000 у Tab Session Manager, 8000 у MySessions, и такъ далѣе — что привело к появлению форкнутого браузера Basilisk и притом ещё к началу уменьшения доли пользователей Файерфокса во Всемирной Паутине.)
Поддержка JPEG XL, надо сказать, потребует от браузеростроителей не одной только готовности засунуть декодер во браузер (что и прежде удавалось продѣлать с декодером каждого графического формата, так что это привычно и не слишком трудно), но также и готовности придумывать что-нибудь насчёт поддержки небывалой возможности неполного скачивания JPEG XL (для экономии траффика) в обстоятельствах небольшой ширины страницы или небольшой плотности пикселов. Чего доброго, тут и до перемѣнъ в языках CSS и HTML также дойдёт дѣло, чтобы дать авторам сайтов возможность как-нибудь управлять происходящим. Я вполне готов допустить, напримѣръ, что кому-нибудь ну очень захочется скачивать файлы JPEG XL, подготовленные к постепенному отображению, не только не до конца файла, но и не от начала файла — а начало вмѣсто того сохранять ещё и прямо в HTML в виде data-адреса (согласно RFC 2397), как это сейчас дѣлается съ нѣкоторыми другими малоразмѣрными заглушками, показываемыми перед началом скачивания файлов (и дѣлается как раз для того, чтобы заглушка приходила прямо в HTML побыстрѣе, исключая даже то время ожидания, которое в противном случае расходуется в сáмом начале запроса файла с сервера, расходуется на сам же этот запрос ещё до начала скачивания).
По-видимому, довольно скоро.
Во всяком случае, двѣ недѣли тому назад группа JPEG на своём восемьдесят пятом заседании решила, что настала пора открывать исходный код программного обеспéчения JPEG XL, а также и что переход на стадию черновика международного стандарта состоится ужé в январе будущего (2020) года. Понятно, что это не предсказание грядущего, а всего лишь декларация о намѣреніяхъ, но и она способна и должна послужить нам поводом для оптимизма.
Кое-какой исходный код уж и открыт. Напримѣръ, дѣйствуетъ гугловский перекодировщик из JPEG в JPEG XL (работающий в том сáмом режиме обратной совместимости с JPEG, который без потерь, но зато и без Хаара). Естественно, одного его не достаточно, но ведь и разговоры об открытии исходного кода нѣкоего болѣе универсального кодировщика происходили на прошлой недѣлѣ въ Твиттерѣ.
Нѣсколько позже поддержка JPEG XL будет потихоньку появляться и во браузерах Всемирной Паутины. Даже можно заранее предвидеть, и предвидеть небезосновательно, что сперва она появится в Google Chrome и во браузерах на его движке (в Opera, в Microsoft Edge, etc.), поскольку гугловский формат PIK был одним из извѣстныхъ источников вдохновения для JPEG XL (а другим был FUIF от Cloudinary), так что самих себя отчего бы и не поддержать им. Можно заранее предвидеть ещё, что послѣднею поддержка JPEG XL появится во браузере Safari компании Apple, потому что Apple традиционно неохотно поддерживает идеи Google. (Ну, напримѣръ, Safari до сих пор не поддерживает формат WebP, появившийся в сентябре 2010 года. Я вѣрю в их способность и с поддержкою формата JPEG XL затянуть дѣло лѣтъ на десять, а не то и на пятнадцать.) Фонд Мозиллы, в свою очередь, вполне способен породить на свѣтъ какую-нибудь такую новую версию своего Файерфокса, которая будет полноцѣнно поддерживать новый формат, но на которую пользователи станут переходить с превеликою неохотою, потому что в ней же (или ещё ранѣе) заодно отвалится интерфейс одного или нескольких популярных расширений. (Я очень хорошо помню, напримѣръ, что начало поддержки формата WebP в Файерфоксе в январе нынешнего года происходит на фоне длящегося вот ужé болѣе двухъ лѣтъ отказа от поддержки программного интерфейса, ранѣе служившего для управления сеансами, и что число жертв этого отказа оцѣнивается как близкое к миллиону людей: 600 000 пользователей у расширения Tab Mix Plus, 300 000 у Session Manager, 60 000 у Tab Session Manager, 8000 у MySessions, и такъ далѣе — что привело к появлению форкнутого браузера Basilisk и притом ещё к началу уменьшения доли пользователей Файерфокса во Всемирной Паутине.)
Поддержка JPEG XL, надо сказать, потребует от браузеростроителей не одной только готовности засунуть декодер во браузер (что и прежде удавалось продѣлать с декодером каждого графического формата, так что это привычно и не слишком трудно), но также и готовности придумывать что-нибудь насчёт поддержки небывалой возможности неполного скачивания JPEG XL (для экономии траффика) в обстоятельствах небольшой ширины страницы или небольшой плотности пикселов. Чего доброго, тут и до перемѣнъ в языках CSS и HTML также дойдёт дѣло, чтобы дать авторам сайтов возможность как-нибудь управлять происходящим. Я вполне готов допустить, напримѣръ, что кому-нибудь ну очень захочется скачивать файлы JPEG XL, подготовленные к постепенному отображению, не только не до конца файла, но и не от начала файла — а начало вмѣсто того сохранять ещё и прямо в HTML в виде data-адреса (согласно RFC 2397), как это сейчас дѣлается съ нѣкоторыми другими малоразмѣрными заглушками, показываемыми перед началом скачивания файлов (и дѣлается как раз для того, чтобы заглушка приходила прямо в HTML побыстрѣе, исключая даже то время ожидания, которое в противном случае расходуется в сáмом начале запроса файла с сервера, расходуется на сам же этот запрос ещё до начала скачивания).
Въ дѣлѣ сайтостроения эффект от появления поддержки JPEG XL во браузерах (ну или от удачных попыток «подпереть костылём» отсутствие такой поддержки, как это сейчас происходит с костылём WebPJS, вполне способным отчасти подпереть собою отсутствие поддержки WebP въ нѣкоторыхъ браузерах) окажется, скорее всего, двойным эффектом. Сперва почувствуется эффект от лучшего сжатия, а затѣмъ почувствуется эффект от поддержки неполного скачивания.
Нѣкоторые сайты начнут перекодировать накопленные архивы изображений (и GIF, и PNG, и прежние JPEG) в формат JPEG XL, что без промедления приведёт их к экономии дискового пространства (а оттого и к экономии денежных средств, уплачиваемых за хостинг).
Нѣкоторые пользователи также начнут перекодировать изображения в формат JPEG XL, что без промедления приведёт их к тому, что прежние ограничения загрузки файлов на сайты (ограничения по объёму файлов) окажутся для таких пользователей замѣтно менѣе обременительными (но только при том непремѣнномъ условии, что и сайты эти начнут поддерживать загрузку файлов в формате JPEG XL в дополнение к загрузке в прежних форматах файлов). То есть всѣ вотъ эти нынѣшніе «не болѣе 1½ мегабайтов в vn/ на Ычане», «не болѣе 3 мегабайтов в b/ на Ычане», «не болѣе 4 мегабайтов в a/ на Ычане», «не болѣе 5 мегабайтов на одну неподвижную иллюстрацию в Твиттере», «не болѣе 5 мегабайтов в a/ на 410чане», «не болѣе 10 мегабайтов при загрузке файла на Мракопедию», «не болѣе 10 мегабайтов при загрузке иллюстраций на GitHub», «не болѣе 10 мегабайтов на Fastpic (и не болѣе 400 килобайтов для прямых ссылок)», «не болѣе 20 мегабайтов в b/ на Nowere», «не болѣе 25 мегабайтов на Lostpic», «не болѣе 40 мегабайтов на Radikal», и такъ далѣе, и такъ далѣе — всѣ, всѣ они будут пропускать замѣтно больше графической информации, чѣмъ прежде, если только эти сайты начнут принимать JPEG XL (и если не начнут одновременно ещё сильнѣе снижать свои лимиты, руководясь цѣлью дальнѣйшей экономіи).
Можно понадеяться, что и нѣкоторые такие чатники (мессенджеры), которые сейчас не радуют чрезмѣрнымъ JPEGованием пересылаемых иллюстраций: Telegram, WhatsApp и другие — поищут и найдут новый баланс между экономией траффика и сохранением качества при сжатии в JPEG XL, причём качество сдѣлается чуть лучше, чем в прежнем JPEG, а траффик всё равно чуть поменьше.
Возможность же организовать информацию в файле JPEG XL таким образом, чтобы миниатюра получалась неполным скачиванием, послужит неплохою альтернативою существующему положению дѣлъ в области миниатюризации изображений на сайтах. До сих пор возможными были только два подхода к этому:
во-первых, сайт мог требовать от пользователя закачать изображение на сайт, где его миниатюра (указывающая на полноразмѣрное изображение) изготавливалася автоматически, но зато, как правило, серьёзно ограничивался объём файла (чтобы экономить на хостинге и не перетруждаться при миниатюризации);
во-вторых, сайт мог предлагать пользователю сохранить изображение на каком-либо другом (внешнем) хостинге картинок, после чего сообщить сайту адрес изображения и адрес миниатюры (созданной автоматически хостингом или вручную пользователем), но зато, как правило, необходимым оказывалося модерирование (если становилось необходимо провѣрять, не указал ли злоумышляющий пользователь подложную миниатюру, не соотвѣтствующую настоящему содержанию изображения).
Теперь же сайт сможет позволить пользователю (по его желанию или же для обхода ограничений объёма) выложить файл JPEG XL внѣ сайта, что не помешает миниатюре быть изготовленною автоматически: сайту достаточно скачать самое начало указанного файла, убедиться в том, что это JPEG XL (причём подготовленный для постепенного просмотра по мѣрѣ скачивания), а затѣмъ просто взять миниатюру из начала файла в готовом виде (не затрачивая собственных вычислительных усилий).
Оттого всё болѣе повадным будет оказываться децентрализованное (безхостинговое) хранение файлов JPEG XL силами самих зрителей (если их достаточно много), совершаемое в P2P-распределённой файловой системе IPFS или посредством сидирования файлов по технологии WebTorrent.
Нѣкоторые сайты начнут перекодировать накопленные архивы изображений (и GIF, и PNG, и прежние JPEG) в формат JPEG XL, что без промедления приведёт их к экономии дискового пространства (а оттого и к экономии денежных средств, уплачиваемых за хостинг).
Нѣкоторые пользователи также начнут перекодировать изображения в формат JPEG XL, что без промедления приведёт их к тому, что прежние ограничения загрузки файлов на сайты (ограничения по объёму файлов) окажутся для таких пользователей замѣтно менѣе обременительными (но только при том непремѣнномъ условии, что и сайты эти начнут поддерживать загрузку файлов в формате JPEG XL в дополнение к загрузке в прежних форматах файлов). То есть всѣ вотъ эти нынѣшніе «не болѣе 1½ мегабайтов в vn/ на Ычане», «не болѣе 3 мегабайтов в b/ на Ычане», «не болѣе 4 мегабайтов в a/ на Ычане», «не болѣе 5 мегабайтов на одну неподвижную иллюстрацию в Твиттере», «не болѣе 5 мегабайтов в a/ на 410чане», «не болѣе 10 мегабайтов при загрузке файла на Мракопедию», «не болѣе 10 мегабайтов при загрузке иллюстраций на GitHub», «не болѣе 10 мегабайтов на Fastpic (и не болѣе 400 килобайтов для прямых ссылок)», «не болѣе 20 мегабайтов в b/ на Nowere», «не болѣе 25 мегабайтов на Lostpic», «не болѣе 40 мегабайтов на Radikal», и такъ далѣе, и такъ далѣе — всѣ, всѣ они будут пропускать замѣтно больше графической информации, чѣмъ прежде, если только эти сайты начнут принимать JPEG XL (и если не начнут одновременно ещё сильнѣе снижать свои лимиты, руководясь цѣлью дальнѣйшей экономіи).
Можно понадеяться, что и нѣкоторые такие чатники (мессенджеры), которые сейчас не радуют чрезмѣрнымъ JPEGованием пересылаемых иллюстраций: Telegram, WhatsApp и другие — поищут и найдут новый баланс между экономией траффика и сохранением качества при сжатии в JPEG XL, причём качество сдѣлается чуть лучше, чем в прежнем JPEG, а траффик всё равно чуть поменьше.
Возможность же организовать информацию в файле JPEG XL таким образом, чтобы миниатюра получалась неполным скачиванием, послужит неплохою альтернативою существующему положению дѣлъ в области миниатюризации изображений на сайтах. До сих пор возможными были только два подхода к этому:
во-первых, сайт мог требовать от пользователя закачать изображение на сайт, где его миниатюра (указывающая на полноразмѣрное изображение) изготавливалася автоматически, но зато, как правило, серьёзно ограничивался объём файла (чтобы экономить на хостинге и не перетруждаться при миниатюризации);
во-вторых, сайт мог предлагать пользователю сохранить изображение на каком-либо другом (внешнем) хостинге картинок, после чего сообщить сайту адрес изображения и адрес миниатюры (созданной автоматически хостингом или вручную пользователем), но зато, как правило, необходимым оказывалося модерирование (если становилось необходимо провѣрять, не указал ли злоумышляющий пользователь подложную миниатюру, не соотвѣтствующую настоящему содержанию изображения).
Теперь же сайт сможет позволить пользователю (по его желанию или же для обхода ограничений объёма) выложить файл JPEG XL внѣ сайта, что не помешает миниатюре быть изготовленною автоматически: сайту достаточно скачать самое начало указанного файла, убедиться в том, что это JPEG XL (причём подготовленный для постепенного просмотра по мѣрѣ скачивания), а затѣмъ просто взять миниатюру из начала файла в готовом виде (не затрачивая собственных вычислительных усилий).
Оттого всё болѣе повадным будет оказываться децентрализованное (безхостинговое) хранение файлов JPEG XL силами самих зрителей (если их достаточно много), совершаемое в P2P-распределённой файловой системе IPFS или посредством сидирования файлов по технологии WebTorrent.
🐦 Опубликован очередной сборник моих твиттеровских микроблогозаписей.
Талантливый воин начинает своё странствие в глубинах подземнаго міра, преодолевая громадные лабиринты и пещеры и вступая в опасные сражения с невиданными чудовищами подземелий. В конце концов воину удаётся навсегда покинуть подземные пространства и выйти на поверхность, но в изрядной степени он обречён и там на одиночество, так как его расовая продолжительность жизни существенно превосходит людскую и так как одно упоминание о его расе вызывает ужас и деятельную ненависть у большинства жителей поверхности. Если не считать кратких эпизодов дружбы или любви, побеждающей межрасовые предрассудки, то вѣчною спутницею этого воина остаётся только волшебная чёрная кошка, которая обычно имѣетъ размѣры простой домашней кошки, когда воин носит её с собою, но которая приобретает размѣры и ярость пантеры, когда сопутствует этому воину в битве. Для читателей западных фэнтэзи всё это звучит как пересказ начала сюжета книг Сальваторе про Дриззта. Но это ещё и пересказ начала сюжета японского #ранобэ «Yaritsukai to, Kuroneko».
PANO_20191230_160314~2.jpg
1.9 MB
Поздравляю с наступлением нового (2020) года, желаю всего наилучшего в наступившие двадцатые годы XXI вѣка! 🥂
Мой новогодний подарок вам — вот эта фотопанорама бесснежной (да почти и безлюдной) набережной в Геленджике #вчера (30 декабря) и яркой «бороды» на вершинах горного хребта #Маркотх.
Я намѣренъ подводить и нѣкоторые итоги прошедшего (2019) года, но только не прямо сейчас, а существенно позже, поскольку в новогоднюю ночь читатели и авторы не бывают готовыми к тому, чтобы сочинять и читать сообщения (кроме самых кратких и самых позитивных), хотя бы и приготовленные загодя к полуночной отправке; притом алкоголь влияет и на память, и на рассудок, и даже на настроение.
Анонсирую поэтому, что упомянутые итоги года я задумываю неторопливо подводить въ нѣсколькихъ сообщениях (одно — с видеороликом об аниме для любителей аниме, другое — с гиперссылками для фэнов VR, третье — с суждениями про Сѣть да Telegram) и управиться с ними за нѣсколько первых дней января в наступившем 2020 году; посмотрим, удастся ли.
Мой новогодний подарок вам — вот эта фотопанорама бесснежной (да почти и безлюдной) набережной в Геленджике #вчера (30 декабря) и яркой «бороды» на вершинах горного хребта #Маркотх.
Я намѣренъ подводить и нѣкоторые итоги прошедшего (2019) года, но только не прямо сейчас, а существенно позже, поскольку в новогоднюю ночь читатели и авторы не бывают готовыми к тому, чтобы сочинять и читать сообщения (кроме самых кратких и самых позитивных), хотя бы и приготовленные загодя к полуночной отправке; притом алкоголь влияет и на память, и на рассудок, и даже на настроение.
Анонсирую поэтому, что упомянутые итоги года я задумываю неторопливо подводить въ нѣсколькихъ сообщениях (одно — с видеороликом об аниме для любителей аниме, другое — с гиперссылками для фэнов VR, третье — с суждениями про Сѣть да Telegram) и управиться с ними за нѣсколько первых дней января в наступившем 2020 году; посмотрим, удастся ли.
🐦 Опубликован очередной сборник моих твиттеровских микроблогозаписей.
ipfs.io
Twitter: @FidonetRunes
velonation (@Romasheda) 2019-12-27 08:34:23 (UTC) https://twitter.com/Romasheda/status/1210479022930575361 Издержки хранения велосипеда на улице Sergey Turulin (@STurulin) 2019-12-27 08:58:00 (UTC) h➡
Media is too big
VIEW IN TELEGRAM
Первая часть ранее обещанного подведения мною итогов года выглядит так: #вчера я изложил мои впечатления об #аниме осени 2019 года и (априорно) об аниме, ожидающемся зимою и весною в 2020 году.
Видеозапись этого устного изложения моих впечатлений длится пять часов с половиною.
Вот основные метки времени:
1:18 ⏩ окончание вступления, начало впечатлений об осеннем сезоне
9:12 ⏩ цитата мнения Ферапонта Соусова об исэкаях осени 2019 года
20:40 ⏩ моё мнение про исэкай как движитель сюжета
34:13 ⏩ достоинства аниме Shinchou Yuusha и «повисшая в воздухе» (не подкреплённая дальнейшим сюжетом) постельная сцена в девятой серии
1:19:51 ⏩ Val × Love доводит до абсурда сюжетный ход с отталкивающей внешностью центрального персонажа
2:55:35 ⏩ начало априорных рассуждений о зимнем сезоне
2:55:59 ⏩ Koisuru Asteroid
3:45:48 ⏩ Toaru Kagaku no Railgun T, ожидаемое «Исчезновение Мисаки Микото»
4:34:17 ⏩ начало априорных рассуждений о весеннем сезоне
5:06:29 ⏩ Hamefura, аниме о перерождении в антагонистку из otome game
Видеозапись этого устного изложения моих впечатлений длится пять часов с половиною.
Вот основные метки времени:
1:18 ⏩ окончание вступления, начало впечатлений об осеннем сезоне
9:12 ⏩ цитата мнения Ферапонта Соусова об исэкаях осени 2019 года
20:40 ⏩ моё мнение про исэкай как движитель сюжета
34:13 ⏩ достоинства аниме Shinchou Yuusha и «повисшая в воздухе» (не подкреплённая дальнейшим сюжетом) постельная сцена в девятой серии
1:19:51 ⏩ Val × Love доводит до абсурда сюжетный ход с отталкивающей внешностью центрального персонажа
2:55:35 ⏩ начало априорных рассуждений о зимнем сезоне
2:55:59 ⏩ Koisuru Asteroid
3:45:48 ⏩ Toaru Kagaku no Railgun T, ожидаемое «Исчезновение Мисаки Микото»
4:34:17 ⏩ начало априорных рассуждений о весеннем сезоне
5:06:29 ⏩ Hamefura, аниме о перерождении в антагонистку из otome game