= Сообщение: 2652 из 2655 ================================== RU.BLOG.MITHGOL =
От : Mithgol the Webmaster 2:50/88 30 Aug 18 03:50:32
Кому : All 30 Aug 18 03:50:32
Тема : Знакомство с FLIR и знакомство с OptiPNG
FGHI : area://RU.BLOG.MITHGOL?msgid=2:50/88+5b87d727
= Кодировка сообщения определена как: CP866 ==================================
==============================================================================
Я узнал на этой неделе о том, что понимание того, как работает сжатие изображений в файлах PNG, продвинулось достаточно далеко для того, чтоб оказаться способным породить программу http://optipng.sourceforge.net
Основываясь на понимании того, что сжатие PNG может оказываться случайно чуть больше или чуть меньше, эта программа (в зависимости от указанного ей уровня оптимизации) начинает перебирать сперва дельта-фильтры, затем стратегии сжатия zlib, затем уровни употребляемой zlib памяти, затем ещё больше дельта-фильтров (включая те, которые обычно не приводят к более сильному сжатию изображений, но случайно могут привести). Если наращивать указанный OptiPNG уровень оптимизации, то можно начать перебирать ещё и уровни сжатия, и ещё большее количество уровней употребляемой zlib памяти ── до тех пор, пока количество перебираемых вариантов не перевалит сперва за две сотни, затем за тысячу, чтобы вообще не полагаться на случай. Но в подавляющем большинстве случаев достаточно нескольких десятков переборов вариантов, а по умолчанию OptiPNG вообще ограничивается восемью, и что же? ── этого достаточно для того, чтобы от вполне реальных PNG-файлов, годами у меня хранившихся (будь то сделанные некогда скриншоты, или обрезки фотографий, или кадры из аниме и кино, или результаты из графических редакторов), с уверенностью отщипывать то по нескольку процентов, то по нескольку десятков процентов, а то и вообще в несколько раз ужимать их.
В тех случаях, когда речь идёт о нескольких процентах, ещё можно полагать, что OptiPNG перебором вариантов случайно отыскивает такой, в котором сжатие оказывается чуть-чуть получше (за счёт более подходящего дельта-фильтра, например). В тех же случаях, когда речь идёт о десятках процентов, нетрудно подозревать, что программа, пишущая в PNG, с самого начала по каким-либо соображениям (например, для скорейшего завершения работы или же вообще для удобства программиста) занималась менее сложною задачею, чем следовало бы (например, выбрала меньшую степень сжатия в zlib, или использовала другую библиотеку сжатия вместо zlib, или использовала примитивный разностный дельта-фильтр вместо чуть более сложного адаптивного, или что-либо другое подобное).
Сама идея того, что можно просто &+AKs-;в уме&+ALs-; (в памяти компьютера) перебрать восемь способов (или шестнадцать, или двадцать четыре, или сорок восемь...) сжатия PNG и полным перебором выбрать среди них наилучший, выглядит поразительно: во-первых, идея выглядит простою до очевидности, а во-вторых, волшебством кажется то, что она работает. (Причём, если вдуматься, то это скорее чёрная магия, мешающая состояться тому более простому миру, в котором адаптивный фильтр всегда работал бы лучше, чем любой из пяти более примитивных, а девятый уровень сжатия в zlib всегда работал лучше, чем восьмой, а девятый уровень памяти ── опять же лучше, чем восьмой, и так далее).
Кроме знакомства с OptiPNG я также узнал о том, что развивающийся с сентября 2015 года (скоро три года как) проект ещё одного формата сжатия без потерь, известного под названием FLIF (тотчас отмечу ещё, что есть в Википедии статья https://en.wikipedia.org/wiki/Free_Lossless_Image_Format о нём) достиг немалых успехов, не только превзойдя PNG (и безпотерьные варианты форматов WebP и JPEG 2000 и BPG) по степени сжатия, но и позволяя такое постепенное отображение файла по мере поступления, которое (в отличие от алгоритма https://en.wikipedia.org/wiki/Adam7_algorithm в PNG) к тому же не приводит к резкому росту объёма файла.
И более того: в то время, как используемый постепенно отображаемыми вариантами PNG алгоритм https://en.wikipedia.org/wiki/Adam7_algorithm для отображения первоначальной сильно размытой версии изображения нуждается в поступлении одной шестидесятичетвёртой части данных (то есть всё-таки больше полутора процентов, что для многосоткилобайтовых файлов PNG равняется всё же нескольким килобайтам), постепенно отображаемые варианты FLIF начинают показ некой версии изображения (ещё более размытой, но всё же дающей самое-самое начальное представление), когда из Интернета пришла едва осьмушка процента ── первые 200 байтов, например.
Я посмотрел демонстрационный видеофайл https://youtu.be/ByH7RMsMxBY и пришёл в восторг, а затем скачал его и просматривал, так сказать, покадрово (с постановкою на паузу), а не то в мельтешении и не увидеть в точности, как развивается ситуация по мере поступления байтов из Сети.
Первые 200 байтов: PNG не показывает вообще ничего, FLIF показывает несколько (не менее полудесятка) цветовых пятен: снизу красноватое, слева синеватое, справа отдающее фиолетовым, по центру и по диагонали ── вспышки белого.
Первые 400 байтов: PNG показывает одну строку размытых пикселов, FLIF прибавил светотеневые пятна внутри цветовых.
Первые 600 байтов: PNG показывает три строки размытых пикселов, позволяющих судить о том, что перед нами ── верхняя часть каких-то углов или округлостей. FLIF позволяет уверенно видеть, что вышеупомянутые цветовые пятна имеют форму, для нижнего пятна близкую к квадрату, для верхних ── к ромбу, и что поверх их располагаются более яркие и белые пятна поменьше.
Первые 800 байтов: PNG показывает четыре строки размытых пикселов, почти ничего не прибавляющие, кроме понимания того, что на углах (или округлостях) вроде как есть более светлые отблески. FLIF позволяет видеть, что у цветных пятен вроде как есть какая-то внутренняя светотеневая структура.
Первая тысяча байтов: PNG показывает пятую строку размытых пикселов, позволяя угадывать на правой (зелёной) округлости светлое пятно. FLIF постепенно придаёт цветовым пятнам какой-то пространственный объём и глубину.
Вторая тысяча байтов: PNG показывает чуть более десятка строк размытых пикселов и позволяет видеть, что синий объект слева и зелёный справа ── это вроде как треугольники, снаружи покрытые пятнами, а внутри ── более тёмною тенью, так что они, возможно, являются проекциями каких-то объёмных полупрозрачных фигур. FLIF позволяет уверенно видеть, что три цветовых пятна являются какими-то объёмными геометрическими фигурами, форма которых, впрочем, далеко не ясна (центральное красное пятно напоминает нечто вроде старого кинескопа), и что ниже красного есть ещё четвёртое (жёлтое) цветовое пятно ещё не ясной формы и предназначения (отдельная ли фигура или просто цветная тень от красной).
Первые 5000 байтов: PNG целиком показал левую верхнюю (синюю) и правую верхнюю (зелёную) фигуру, светотеневая картина которых позволяет уверенно опознать куб, а диагональное расположение светлых пятен позволяет угадывать игральные кости. Ясно видны, впрочем, только расположенные под меньшим углом к зрителю грани (тройка на синей игральной кости, пятёрка на зелёной). Под ними видно самое начало угла красного куба, но только по аналогии зритель может угадывать, что это также будет игральная кость (и даже что это будет куб; при такой размытости и при такой неполной видимости фигура могла бы легко оказаться, скажем, икосаэдром). FLIF позволяет ясно видеть четыре куба (синий и зелёный наверху, красный в центре, жёлтый снизу), но точки (делающие их игровыми костями) ясно видны только на гранях алого куба (шестёрка) и синего (тройка), а пятёрка на зелёном выглядит размытою, её боковые точки легко могли бы оказаться и простыми бликами света.
Первые 6600 байтов: PNG показал три верхние игральные кости, FLIF показал все четыре, да притом более чётко передаёт круглую форму точек на боковых гранях.
Вот как выглядит этот стоп-кадр:
После него можно переставать смотреть видеофильм https://youtu.be/ByH7RMsMxBY как не способный ничего более прибавить к тому, что показано в нём до этого: налицо появление нового формата, который много лучше ведёт себя на экране в то время, когда из Сети поступают ещё только самые первые килобайты файла.
Судьба, как говорил Морфеус, не лишена иронии: формат FLIF был бы очень полезен десятилетиями ранее, когда нам нескольких килобайт и дожидаться приходилось по нескольку секунд, но сейчас это его качество может оказаться полезным только в тех местностях, где скорость Интернета остаётся очень скверною (например, в центральных частях Африки или в приполярной России), для остального же мира килобайты пролетят в мгновение ока, а единственно полезным качеством FLIF останется более высокая степень сжатия графических файлов без потерь.
Конечно, если высокоскоростной Интернет будет до крайности зароскомнадзорен и закошмарен, так что для зрителей (не желающих раз за разом созерцать заглушки про блокировки) и для авторов (не желающих отправляться на нары одновременно с подпаданием своих произведений под блокировки) останутся только какие-нибудь нелепые и низкоскоростные каналы (например, акустическая стеганография поверх имитации телефонного разговора), то тогда вдругорядь на поведение первых сотен байтов и первых килобайтов будут пристально смотреть по нескольку секунд или даже десятков секунд, и смотреть неизбежнейше ── от нечего делать ── и тогда, конечно же, и это достижение FLIF заиграет яркими красками. А на стомегабитном ростелекомовском канале ── н&+BGM-;тъ, не заиграет. И если закошмаривание приведёт не к резкому падению скоростей и объёмов передачи информации, а только к росту задержек (например, во время тайного рукопожатия участники тайного общества станут обмениваться двухтерабайтовыми флэшками, но раз в сутки ── что составляет в среднем семь килобайтов в секунду, но ждать постепенной загрузки файла не приходится, так как он передаётся в одно мгновение), то и в этом постапокалиптическом варианте поведение первых сотен и тысяч байтов файла не окажется важным делом.
Так кажется.
Однако это не так.
У плавного нарастания качества файла по мере его поступления (у нарастания, насчитывающего десятки постепенных шагов вместо всего семи резких, алгоритму https://en.wikipedia.org/wiki/Adam7_algorithm свойственных) есть и ещё одна полезная сторона. Можно отрезать небольшой начальный кусок файла и использовать в качестве предпросмотра (миниатюры) меньшего размера. Можно отрезать небольшой начальный кусок файла и использовать в качестве версии файла для малопиксельных экранов. Можно отрезать небольшой начальный кусок файла в качестве простейшего способа превратить сжатие без потерь в сжатие с потерями (причём размер потерь очень просто определяется размером отсечённого хвоста файла).
Вот ведь какою полезною штукою этот FLIF получился.
Возьмём в качестве примера имиджборды: чаще всего, чтобы иллюстрация не умерла отд&+BGM-;льно от текста, её хранят на том же хостинге (а если разрешено употребление видеозаписей, то и видеозапись хранят так же), а в текст вставляют не саму её, а миниатюру, по которой читатель может жмякнуть, когда пожелает посмотреть полную версию. Естественно, размер файла при этом ограничивают, чтоб не чрезмерно перетруждался хостинг. Рано или поздно некоторые имиджборды понимают, что крупные видеофайлы им не потянуть, но что участники общения нуждаются в такой возможности. Обычно при этом приходят к поддержке довольно ограниченного количества внешних видеохостингов ── например, только YouTube и Coub ── потому что те предоставляют API (программный интерфейс), позволяющий отобразить миниатюру, а другие не предоставляют. А что же делать, если не только видеофайлы, но и обыкновенные графические файлы случаются столь крупными, что их хочется поместить где-нибудь в другом месте? Вероятно (хотя мн&+BGM-; не известны прим&+BGM-;ры этого) пришлось бы также составлять список таких внешних хостингов, которые предоставляли бы программные средства (API) для получения миниатюр. Однако появление FLIF м&+BGM-;няетъ правила игры, раз для получения миниатюры достаточно скачать тот же файл, в котором содержится и полноразмерное изображение ── просто скачать не весь.
(Понятно, что не одни только имиджборды затронуты приведённой в этом примере проблемою: она актуальна для некоторых форумов, и блогохостингов, и социальных сетей, и торрентовых трекеров, и даже для СМИ.)
Фидонет будет великим и гипертекстовым! [Ru.Mozilla] http://Mithgol.Ru/
Mithgol the Webmaster. [Братство Нод] [Team А я меняю subj]
... Люди перестают развиваться, как только начинают размножаться. (Паркинсон)
--- Знаешь ли ты, что "рублёвка" пишется через "ё"?
* Origin: Край родной долготерпенья, // Край ты русского народа! (2:50/88)
|
