Monster Musume no Oishasan EP01.7z
51 MB
Сшил (в Overmix) некоторые кадры первой серии #аниме Monster Musume no Oishasan.
Сшивки прилагаю в формате PNG внутри архива 7-Zip.
Предпросмотр сшивок — в Твиттере. (Там они сжаты в формате JPEG с внесением потерь, поскольку таковы твиттеровские правила.)
Сшивки прилагаю в формате PNG внутри архива 7-Zip.
Предпросмотр сшивок — в Твиттере. (Там они сжаты в формате JPEG с внесением потерь, поскольку таковы твиттеровские правила.)
🐦 Опубликован очередной сборник моих твиттеровских микроблогозаписей.
Он содержит, в частности, ретвит видеозаписи новой московской велополосы (и ретвиты обсуждений её) и ретвит видеозаписи прискорбного отсутствия велополосы на том мосту, который ведёт в Крым.
Он содержит, в частности, ретвит видеозаписи новой московской велополосы (и ретвиты обсуждений её) и ретвит видеозаписи прискорбного отсутствия велополосы на том мосту, который ведёт в Крым.
ipfs.io
Twitter: @FidonetRunes
Space Snaps (@AstronomyHD) 2020-07-07 16:08:42 (UTC) https://twitter.com/AstronomyHD/status/1280534214241386496 Comet over Lebanon. TJ (@tjournal) 2020-07-08 15:25:14 (UTC) https://twitter.com/tjourn➡
🐦 Опубликован очередной сборник моих твиттеровских микроблогозаписей.
Он содержит, в частности, ретвиты видеозаписей краснодарского наводнения и ретвит рецепта создания информационного блока в гитхабовском профиле.
Он содержит, в частности, ретвиты видеозаписей краснодарского наводнения и ретвит рецепта создания информационного блока в гитхабовском профиле.
ipfs.io
Twitter: @FidonetRunes
Альфина (@alphyna) 2020-07-08 21:55:04 (UTC) https://twitter.com/alphyna/status/1280983768304582656 рациональный человек: Россия — довольно ординарная страна, в которой множество обыденных явлений, в➡
Ѿправилъ Телеграму через Twitter одиннадцатипунктный мегафичреквест (в качестве дополнения к предшествующему), состоящий из слѣдующихъ пожеланий:
🅰️0⃣ Телеграму неплохо бы подготовиться к результатам недавнего решения Apple о запуске поддержки формата WebP в Safari 14 (а также в iOS и в macOS) ранѣе конца 2020 года. Надо ждать появления многих изображений WebP, не предназначаемых пользователями к отсылке в качестве стикеров, и разработать для них интерфейс «Послать как изображение».
🅰️1️⃣ Многие изображения в формате PNG (скажем, скриншоты с крупными областями, заполненными текстом) лучше сжимаются в WebP без потерь, чѣмъ в JPEG с потерями (для любого разумного качества JPEG). Telegram мог бы сохранять их именно как WebP без потерь, а для браузеров, не имѣющихъ поддержки WebP, использовать полифилл.
🅰️2️⃣ Телеграму слѣдовало бы послѣдовать примѣру Твиттера и реализовать нѣкоторыя правила, подобныя вон тѣмъ, предотвращающим сжатие файлов PNG в формат JPEG с потерями въ тѣхъ случаях, когда исходный файл достаточно мал (900×900 или меньше) или, в особенности, когда такое сжатие порождает большѣе число байтов.
🅰️3️⃣ Частичная комбинация двух предшествующих предложений: «не переужимать файл из PNG в JPEG, если получающийся объём JPEG больше, чѣмъ объёмъ результата сжатия того же PNG в формат WebP без потерь» (WebP без потерь слѣдуетъ предпочитать, а употребление JPEG бессмысленно в таких случаях).
🅰️4️⃣ Телеграму слѣдовало бы послѣдовать примѣру Твиттера и реализовать нѣкоторыя правила, подобныя вон тѣмъ, предотвращающим переужатие файлов из JPEG в JPEG (с внесением дополнительных потерь) въ тѣхъ случаях, когда исходный JPEG ужé достаточно мал (меньше 8 битов на пиксел, меньше 5 мегабайтов всего, меньше 4096×4096 пикселов по размѣру).
🅰️5️⃣ Когда сжатие в формат JPEG (совершаемое с внесением потерь) неизбѣжно, то тогда хотя бы устраните различия его результатов в различных клиентах Телеграма (напримѣръ, в Telegram Desktop по сравнению с Telegram под Android) употреблением одного и того же современного кодировщика (MozJPEG) с одними и теми же настройками и качества, и оптимизаций, и чёрно-бѣлаго сверхконтраста «с запасом».
🅰️6️⃣ Telegram мог бы передавать изображения JPEG быстрѣе и хранить их болѣе эффективно, кабы выбрал гугловский формат Brunsli (см. демонстрацию) в качестве формата для хранения и передачи JPEGов без потерь. Впрочем, декодирование его потребует дополнительной работы процессора и затрат электричества из аккумулятора.
🅰️7️⃣ Поддержка анимаций Телеграмом означает либо формат анимированных GIF (передаваемых «как есть» при превышении десятимегабайтового объёма, но конвертируемых с потерями в видео AVC в контейнере MP4 в противном случае), либо беззвучное зацикленное повторение видео MP4. Эту поддержку можно было бы также распространить на форматы анимированных PNG и анимированных WebP: оба формата существуют достаточно долго и поддерживаются широко.
🅰️8️⃣ Гугловский FAQ про WebP заканчивается примѣромъ такой анимированной GIFки, которая гораздо лучше сжимается в формате анимированного WebP без потерь, чѣмъ при сжатии в видеоформат с внесением потерь. Telegram также мог бы пробовать анимированный WebP без потерь для каждой анимации (использовать AVC с потерями только тогда, когда это реально лучше).
🅰️9️⃣ Нѣкоторые комплекты стикеров (вон тот, напримѣръ) свидетельствуют, что пользователям нужны и растровые анимации в стикерах — и что для этой цѣли извращён формат векторных анимаций, прямоугольниками которого представлены линии пикселов. Telegram мог бы дозволить отсылку нѣкоторыхъ анимированных WebP в качестве анимированных стикеров.
🅰️🔟 Телеграму слѣдовало бы дозволить снабжение видеопроигрывателей подписями гораздо большей длины ещё тогда, когда в 2019 году объявлена была поддержка таймкодов. В нынешний предѣлъ (1024 сѵмволовъ) еле-еле влезает дюжина болѣе-менѣе информативных таймкодов. В подписях под новыми, болѣе длинными (двухгигабайтовыми) видеозаписями это сдѣлается ещё очевиднѣе.
Ведущий телеграмного микроблога в Твиттере принял эти пожелания и пообѣщалъ передать их на разсмотрѣніе.
🅰️0⃣ Телеграму неплохо бы подготовиться к результатам недавнего решения Apple о запуске поддержки формата WebP в Safari 14 (а также в iOS и в macOS) ранѣе конца 2020 года. Надо ждать появления многих изображений WebP, не предназначаемых пользователями к отсылке в качестве стикеров, и разработать для них интерфейс «Послать как изображение».
🅰️1️⃣ Многие изображения в формате PNG (скажем, скриншоты с крупными областями, заполненными текстом) лучше сжимаются в WebP без потерь, чѣмъ в JPEG с потерями (для любого разумного качества JPEG). Telegram мог бы сохранять их именно как WebP без потерь, а для браузеров, не имѣющихъ поддержки WebP, использовать полифилл.
🅰️2️⃣ Телеграму слѣдовало бы послѣдовать примѣру Твиттера и реализовать нѣкоторыя правила, подобныя вон тѣмъ, предотвращающим сжатие файлов PNG в формат JPEG с потерями въ тѣхъ случаях, когда исходный файл достаточно мал (900×900 или меньше) или, в особенности, когда такое сжатие порождает большѣе число байтов.
🅰️3️⃣ Частичная комбинация двух предшествующих предложений: «не переужимать файл из PNG в JPEG, если получающийся объём JPEG больше, чѣмъ объёмъ результата сжатия того же PNG в формат WebP без потерь» (WebP без потерь слѣдуетъ предпочитать, а употребление JPEG бессмысленно в таких случаях).
🅰️4️⃣ Телеграму слѣдовало бы послѣдовать примѣру Твиттера и реализовать нѣкоторыя правила, подобныя вон тѣмъ, предотвращающим переужатие файлов из JPEG в JPEG (с внесением дополнительных потерь) въ тѣхъ случаях, когда исходный JPEG ужé достаточно мал (меньше 8 битов на пиксел, меньше 5 мегабайтов всего, меньше 4096×4096 пикселов по размѣру).
🅰️5️⃣ Когда сжатие в формат JPEG (совершаемое с внесением потерь) неизбѣжно, то тогда хотя бы устраните различия его результатов в различных клиентах Телеграма (напримѣръ, в Telegram Desktop по сравнению с Telegram под Android) употреблением одного и того же современного кодировщика (MozJPEG) с одними и теми же настройками и качества, и оптимизаций, и чёрно-бѣлаго сверхконтраста «с запасом».
🅰️6️⃣ Telegram мог бы передавать изображения JPEG быстрѣе и хранить их болѣе эффективно, кабы выбрал гугловский формат Brunsli (см. демонстрацию) в качестве формата для хранения и передачи JPEGов без потерь. Впрочем, декодирование его потребует дополнительной работы процессора и затрат электричества из аккумулятора.
🅰️7️⃣ Поддержка анимаций Телеграмом означает либо формат анимированных GIF (передаваемых «как есть» при превышении десятимегабайтового объёма, но конвертируемых с потерями в видео AVC в контейнере MP4 в противном случае), либо беззвучное зацикленное повторение видео MP4. Эту поддержку можно было бы также распространить на форматы анимированных PNG и анимированных WebP: оба формата существуют достаточно долго и поддерживаются широко.
🅰️8️⃣ Гугловский FAQ про WebP заканчивается примѣромъ такой анимированной GIFки, которая гораздо лучше сжимается в формате анимированного WebP без потерь, чѣмъ при сжатии в видеоформат с внесением потерь. Telegram также мог бы пробовать анимированный WebP без потерь для каждой анимации (использовать AVC с потерями только тогда, когда это реально лучше).
🅰️9️⃣ Нѣкоторые комплекты стикеров (вон тот, напримѣръ) свидетельствуют, что пользователям нужны и растровые анимации в стикерах — и что для этой цѣли извращён формат векторных анимаций, прямоугольниками которого представлены линии пикселов. Telegram мог бы дозволить отсылку нѣкоторыхъ анимированных WebP в качестве анимированных стикеров.
🅰️🔟 Телеграму слѣдовало бы дозволить снабжение видеопроигрывателей подписями гораздо большей длины ещё тогда, когда в 2019 году объявлена была поддержка таймкодов. В нынешний предѣлъ (1024 сѵмволовъ) еле-еле влезает дюжина болѣе-менѣе информативных таймкодов. В подписях под новыми, болѣе длинными (двухгигабайтовыми) видеозаписями это сдѣлается ещё очевиднѣе.
Ведущий телеграмного микроблога в Твиттере принял эти пожелания и пообѣщалъ передать их на разсмотрѣніе.
🐦 Опубликован очередной сборник моих твиттеровских микроблогозаписей.
Он содержит, в частности, ретвиты сообщений об угоне учётных записей твиттеровских знаменитостей криптовалютчиками и официальных объяснений произошедшего.
Он содержит, в частности, ретвиты сообщений об угоне учётных записей твиттеровских знаменитостей криптовалютчиками и официальных объяснений произошедшего.
ipfs.io
Twitter: @FidonetRunes
Extinct Animals 🦖🦕 (@Extinct_AnimaIs) 2020-07-13 13:33:00 (UTC) https://twitter.com/Extinct_AnimaIs/status/1282669357311688705 Wiwaxia was a prehistoric bottom feeder that lived during the early Ca➡
Code Geass S01EP01.7z
20.8 MB
Сшил (в Overmix) некоторые кадры первой серии #аниме Code Geass.
Сшивки прилагаю в формате PNG внутри архива 7-Zip.
Предпросмотр сшивок — в Твиттере. (Там они сжаты в формате JPEG с внесением потерь, поскольку таковы твиттеровские правила.)
Сшивки прилагаю в формате PNG внутри архива 7-Zip.
Предпросмотр сшивок — в Твиттере. (Там они сжаты в формате JPEG с внесением потерь, поскольку таковы твиттеровские правила.)
🐦 Опубликован очередной сборник моих твиттеровских микроблогозаписей.
Он содержит, в частности, ретвиты фотографий котов и кошек, которые спят, уложив свой подбородок на возвышение.
Он содержит, в частности, ретвиты фотографий котов и кошек, которые спят, уложив свой подбородок на возвышение.
ipfs.io
Twitter: @FidonetRunes
Марина (@EmsVladimirova) 2020-07-12 18:41:34 (UTC) https://twitter.com/EmsVladimirova/status/1282384621695574021 #Геленджик 🖤 ДТП-Бот (@dtp_stat) 2020-07-17 09:00:01 (UTC) https://twitter.com/dtp_st➡
Uzaki-chan wa Asobitai! EP01 EP02.7z
31.6 MB
Сшил (в Overmix) некоторые кадры первой и второй серии #аниме «Uzaki-chan wa Asobitai!».
Сшивки прилагаю в формате PNG внутри архива 7-Zip.
Предпросмотр сшивок — в Твиттере. (Там они сжаты в формате JPEG с внесением потерь, поскольку таковы твиттеровские правила.)
Сшивки прилагаю в формате PNG внутри архива 7-Zip.
Предпросмотр сшивок — в Твиттере. (Там они сжаты в формате JPEG с внесением потерь, поскольку таковы твиттеровские правила.)
Code Geass S01EP02.7z
25.4 MB
Сшил (в Overmix) некоторые кадры второй серии #аниме Code Geass.
Сшивки прилагаю в формате PNG внутри архива 7-Zip.
Предпросмотр сшивок — в Твиттере. (Там они сжаты в формате JPEG с внесением потерь, поскольку таковы твиттеровские правила.)
Сшивки прилагаю в формате PNG внутри архива 7-Zip.
Предпросмотр сшивок — в Твиттере. (Там они сжаты в формате JPEG с внесением потерь, поскольку таковы твиттеровские правила.)
Познакомившись в конце августа позапрошлого (2018) года с утилитою OptiPNG, способною уменьшать объём графических файлов в формате PNG без внесения потерь в них (а только за счёт прямого перебора настроек сжатия графических данных для поиска наиболее подходящей для конкретного файла комбинации настроек), я без промедления упомянул о ней тремя абзацами в Фидонете и затѣмъ ещё в Твиттере — и начал ею в дальнейшем пользоваться. Подобная оптимизация файлов полезна и в сайтостроении (чтобы быстрѣе доставлять иллюстрации читателям), и в Твиттере (вѣдь въ послѣдніе годы Twitter ввёл такие правила, согласно которым любой публикуемый файл PNG, превосходящий размѣры 900×900 пикселов, будет на стороне сервера принудительно сжат в формат JPEG с качеством, равным 85 пунктам — то есть с внесением потерь — если только не был заранее оптимизирован до такой степени, что упомянутое переужатие в JPEG привело бы к росту его объёма), и на имиджбордах (особенно тѣхъ, которые ограничивают объём файла всего-навсего нѣсколькими мегабайтами) — всюду, всюду полезна.
Однако по опыту употребления OptiPNG нельзя не замѣтить два крупных недостатка OptiPNG.
Первый недостаток — однопоточная конструкция: даже работая в том режиме, которым предполагается перебор болѣе тысячи комбинаций настроек («-o7 -zm1-9»), утилита OptiPNG перебирает их послѣдовательно, не пытаясь распараллелить своё занятие и получить выгоду от многоядерности современных процессоров.
Второй недостаток — происхождение: нельзя не видѣть, что большинство перебираемых настроек имѣетъ отношение к работе библиотеки zlib: какой у ней используется уровень сжатия, какая стратегия сжатия, сколько употребляется памяти. В общем-то, таковы вообще всѣ перебираемые OptiPNG настройки, за исключением одного только выбора из шести вариантов настройки фильтрации PNG (пять вариантов «один фильтр на весь файл», шестой — эвристический метод Крокера для выбора фильтра отдѣльно для каждой строки пикселов). Это значит, что само по себе появление OptiPNG (и других аналогичных оптимизаторов) вызвано прежде всего тѣмъ, что zlib ведёт себя не логично и предсказуемо («задай максимальный уровень сжатия и количество памяти — получи наилучшее сжатие»), а слишком случайно — достаточно случайно для того, чтобы побуждать к тому, чтобы попробовать настройки похуже и поглядеть, не получится ли результат получше.
Получается, что для решения именно этой задачи — для оптимизации файлов PNG — была бы в среднем куда полезнѣе не такая реализация алгоритма DEFLATE, которая побуждает попробовать десятки вариантов настройки и иногда получить оттого неожиданно хороший результат (как zlib), а такая реализация, которая всегда работает въ нѣсколько десятков раз медленнѣе, но зато всегда же (а не время от времени) получает болѣе сжатые графические данные, получает меньший объём файла.
И что же, есть ли такая реализация с открытым исходным кодом? — оказывается, есть: Zopfli. Статья в Википедии сообщает, что появление Zopfli относится к 2013 году. Того же года статья в австралийском «Лайфхакере» свидетельствует, что работа Zopfli на реальных текстовых данных (взятых из статей Википедии) была раз в восемьдесят медленнее аналога (gzip), но зато и объём получающегося архива был на 1½% меньше.
Но это на текстовых данных, не на графических — а пытались ли примѣнить Zopfli к сжатию файлов PNG? Оказывается, в том же году (в 2013 году) появилась утилита ZopfliPNG (от создателей Zopfli), которая как раз и должна была примѣняться для оптимизации файлов PNG; но мнѣ достаточно было одного взгляда на её файл README, чтоб разочаровать себя пониманием того, что утилита ZopfliPNG не удобна для реального использования. Слишком уж она, как это называется? — opinionated: стремится навязать пользователю своё мнение.
Напримѣръ, ZopfliPNG по умолчанию убирает из файла метаданные и не имѣетъ такой простой настройки, которая позволила бы не убирать (а имѣетъ сложную: прочтите документацию по формату PNG, составьте список идентификаторов сохраняемых метаданных). Нѣтъ и настроек (для OptiPNG привычных) для пересохранения файла в чересстрочном виде (Adam7).
Однако по опыту употребления OptiPNG нельзя не замѣтить два крупных недостатка OptiPNG.
Первый недостаток — однопоточная конструкция: даже работая в том режиме, которым предполагается перебор болѣе тысячи комбинаций настроек («-o7 -zm1-9»), утилита OptiPNG перебирает их послѣдовательно, не пытаясь распараллелить своё занятие и получить выгоду от многоядерности современных процессоров.
Второй недостаток — происхождение: нельзя не видѣть, что большинство перебираемых настроек имѣетъ отношение к работе библиотеки zlib: какой у ней используется уровень сжатия, какая стратегия сжатия, сколько употребляется памяти. В общем-то, таковы вообще всѣ перебираемые OptiPNG настройки, за исключением одного только выбора из шести вариантов настройки фильтрации PNG (пять вариантов «один фильтр на весь файл», шестой — эвристический метод Крокера для выбора фильтра отдѣльно для каждой строки пикселов). Это значит, что само по себе появление OptiPNG (и других аналогичных оптимизаторов) вызвано прежде всего тѣмъ, что zlib ведёт себя не логично и предсказуемо («задай максимальный уровень сжатия и количество памяти — получи наилучшее сжатие»), а слишком случайно — достаточно случайно для того, чтобы побуждать к тому, чтобы попробовать настройки похуже и поглядеть, не получится ли результат получше.
Получается, что для решения именно этой задачи — для оптимизации файлов PNG — была бы в среднем куда полезнѣе не такая реализация алгоритма DEFLATE, которая побуждает попробовать десятки вариантов настройки и иногда получить оттого неожиданно хороший результат (как zlib), а такая реализация, которая всегда работает въ нѣсколько десятков раз медленнѣе, но зато всегда же (а не время от времени) получает болѣе сжатые графические данные, получает меньший объём файла.
И что же, есть ли такая реализация с открытым исходным кодом? — оказывается, есть: Zopfli. Статья в Википедии сообщает, что появление Zopfli относится к 2013 году. Того же года статья в австралийском «Лайфхакере» свидетельствует, что работа Zopfli на реальных текстовых данных (взятых из статей Википедии) была раз в восемьдесят медленнее аналога (gzip), но зато и объём получающегося архива был на 1½% меньше.
Но это на текстовых данных, не на графических — а пытались ли примѣнить Zopfli к сжатию файлов PNG? Оказывается, в том же году (в 2013 году) появилась утилита ZopfliPNG (от создателей Zopfli), которая как раз и должна была примѣняться для оптимизации файлов PNG; но мнѣ достаточно было одного взгляда на её файл README, чтоб разочаровать себя пониманием того, что утилита ZopfliPNG не удобна для реального использования. Слишком уж она, как это называется? — opinionated: стремится навязать пользователю своё мнение.
Напримѣръ, ZopfliPNG по умолчанию убирает из файла метаданные и не имѣетъ такой простой настройки, которая позволила бы не убирать (а имѣетъ сложную: прочтите документацию по формату PNG, составьте список идентификаторов сохраняемых метаданных). Нѣтъ и настроек (для OptiPNG привычных) для пересохранения файла в чересстрочном виде (Adam7).
👍1
Между двумя крайностями, упомянутыми в предшествующем сообщении: OptiPNG и ZopfliPNG — существует и нѣкая золотая середина. Вчера (23 июля) я натолкнулся на её упоминание, когда читал обсуждение правил пересжатия изображений Твиттером (и правил отказа от такого пересжатия тогда, когда сам микроблоггер достаточно оптимизировал файл перед публикацией): оказалось, что Нолан О'Брайен (представитель Твиттера в этом обсуждении) 30 января прошлого (2019) года, рассуждая о возможностях сжатия PNG без потерь (об алгоритмах, доступных микроблоггерам, но работающих слишком долго для употребления самим Твиттером на стороне сервера), упомянул («через запятую», как говорится) не только OptiPNG, но и oxipng — выпускаемую много лѣтъ утилиту (её версия 0.1.0 появилась в марте 2016 г.), в которую на первом же году её жизни (в декабре 2016 г.) была добавлена поддержка Zopfli.
Ѿдѣльно ѿмѣчу, что я мог бы, навѣрное, натолкнуться на упоминание oxipng и в том случае, если бы перечитывал статью англоязычной Википедии о Zopfli после 5 августа прошлого (2019) года (когда такое упоминание было туда добавлено).
Кроме ужé упомянутой поддержки Zopfli, оптимизатор oxipng также радует и признанием автора в том, что oxipng создавался съ цѣлью повторить и улучшить успѣхъ OptiPNG (а значит, можно ожидать всѣ возможности, по OptiPNG привычныя), и что oxipng работает многопоточно (так что различные варианты фильтрации PNG перебираются не последовательно, а параллельно).
Там, гдѣ OptiPNG, если работает в режиме предѣльнаго сжатия, послѣдовательно перебирает для каждого из шести вариантов фильтрации PNG ещё по 180 вариантов работы zlib — там oxipng в режиме Zopfli параллельно пробует всѣ шесть вариантов, и притом для каждого из них просто запускает сжатие Zopfli (которое работает медленнѣе, чѣмъ zlib, но всё же не в 180 же раз медленнѣе!). Нетрудно сосчитать, что этим обеспечивается выигрыш по времени примѣрно на порядок в многопоточном режиме, и даже при необходимости отключения многопоточности (напримѣръ, при параллельной обработке многих файлов на немногих ядрах процессора) можно ожидать выигрыш болѣе чѣмъ в два раза.
По правде сказать, у oxipng всё же есть одно неприятное отличие от OptiPNG по возможностям (то же сáмое, за которое я был недоволен и ZopfliPNG, о чём упоминал в Твиттере в ноябре прошлого года): нѣтъ такого параметра в настройках, который позволил бы сохранять неизмѣнными дату и время модификации файла, оптимизируемого oxipng. (Однако же явный выигрыш в скорости работы стóит того, чтобы потрудиться и соорудить вокруг oxipng пакетный файл, запускающий команду clonefiletime утилиты NirCmd перед удалением исходного PNG.)
Натравив oxipng (в режиме Zopfli) на мою многотысячефайловую коллекцию PNG, въ извѣстной мѣрѣ ужé преизрядно обработанную OptiPNG за послѣдніе годы, я обнаружил, что объёмы файлов с художественною информациею: кадры из аниме, страницы манги, скриншоты визуальных романов — сжимаются oxipng на нѣсколько процентов сильнѣе, чѣмъ въ OptiPNG, и в среднем даже сильнѣе по сравнению с теми полутора процентами, которые австралийский «Лайфхакер» наблюдал при работе с текстовыми данными, а не графическими. То есть и 2%, и 3%, и 4%, и 5%, и 6%, и 7%, и даже 8% время от времени (в зависимости от содержимого) я увидал достигаемыми, а меньше 2% также получалось — но рѣже, чѣмъ больше 2%. Сжатие же файлов PNG, содержащих фрагменты текстовых страниц: страниц книг, страниц сайтов, словесных реплик на имиджбордах или в иных обсуждениях или блогозаписях (в социальных сетях, напримѣръ) — оказалось ещё болѣе впечатляющим: при работе над ними экономия объёма файла, приносимая oxipng, систематически превосходит 10% (и это, напоминаю, при оптимизации файлов, до этого ужé обработанных в OptiPNG). По-видимому, достоинства Zopfli особенно эффективны по отношению к графическим файлам, состоящим прежде всего из крупных однотонных областей (областей фона страницы), и менее крупных однотонных же контуров (букв страницы), и небольших узких областей промежуточных цвѣтовъ, порождаемых сглаживанием.
Я рад видѣть это. Впредь я буду использовать именно oxipng.
Ѿдѣльно ѿмѣчу, что я мог бы, навѣрное, натолкнуться на упоминание oxipng и в том случае, если бы перечитывал статью англоязычной Википедии о Zopfli после 5 августа прошлого (2019) года (когда такое упоминание было туда добавлено).
Кроме ужé упомянутой поддержки Zopfli, оптимизатор oxipng также радует и признанием автора в том, что oxipng создавался съ цѣлью повторить и улучшить успѣхъ OptiPNG (а значит, можно ожидать всѣ возможности, по OptiPNG привычныя), и что oxipng работает многопоточно (так что различные варианты фильтрации PNG перебираются не последовательно, а параллельно).
Там, гдѣ OptiPNG, если работает в режиме предѣльнаго сжатия, послѣдовательно перебирает для каждого из шести вариантов фильтрации PNG ещё по 180 вариантов работы zlib — там oxipng в режиме Zopfli параллельно пробует всѣ шесть вариантов, и притом для каждого из них просто запускает сжатие Zopfli (которое работает медленнѣе, чѣмъ zlib, но всё же не в 180 же раз медленнѣе!). Нетрудно сосчитать, что этим обеспечивается выигрыш по времени примѣрно на порядок в многопоточном режиме, и даже при необходимости отключения многопоточности (напримѣръ, при параллельной обработке многих файлов на немногих ядрах процессора) можно ожидать выигрыш болѣе чѣмъ в два раза.
По правде сказать, у oxipng всё же есть одно неприятное отличие от OptiPNG по возможностям (то же сáмое, за которое я был недоволен и ZopfliPNG, о чём упоминал в Твиттере в ноябре прошлого года): нѣтъ такого параметра в настройках, который позволил бы сохранять неизмѣнными дату и время модификации файла, оптимизируемого oxipng. (Однако же явный выигрыш в скорости работы стóит того, чтобы потрудиться и соорудить вокруг oxipng пакетный файл, запускающий команду clonefiletime утилиты NirCmd перед удалением исходного PNG.)
Натравив oxipng (в режиме Zopfli) на мою многотысячефайловую коллекцию PNG, въ извѣстной мѣрѣ ужé преизрядно обработанную OptiPNG за послѣдніе годы, я обнаружил, что объёмы файлов с художественною информациею: кадры из аниме, страницы манги, скриншоты визуальных романов — сжимаются oxipng на нѣсколько процентов сильнѣе, чѣмъ въ OptiPNG, и в среднем даже сильнѣе по сравнению с теми полутора процентами, которые австралийский «Лайфхакер» наблюдал при работе с текстовыми данными, а не графическими. То есть и 2%, и 3%, и 4%, и 5%, и 6%, и 7%, и даже 8% время от времени (в зависимости от содержимого) я увидал достигаемыми, а меньше 2% также получалось — но рѣже, чѣмъ больше 2%. Сжатие же файлов PNG, содержащих фрагменты текстовых страниц: страниц книг, страниц сайтов, словесных реплик на имиджбордах или в иных обсуждениях или блогозаписях (в социальных сетях, напримѣръ) — оказалось ещё болѣе впечатляющим: при работе над ними экономия объёма файла, приносимая oxipng, систематически превосходит 10% (и это, напоминаю, при оптимизации файлов, до этого ужé обработанных в OptiPNG). По-видимому, достоинства Zopfli особенно эффективны по отношению к графическим файлам, состоящим прежде всего из крупных однотонных областей (областей фона страницы), и менее крупных однотонных же контуров (букв страницы), и небольших узких областей промежуточных цвѣтовъ, порождаемых сглаживанием.
Я рад видѣть это. Впредь я буду использовать именно oxipng.
👍1
Намѣреваясь в дальнейшем использовать oxipng (по причинам, изложенным в предшествующем сообщении) для сжатия файлов PNG без внесения потерь, я полностью отдаю себе отчёт в том, что утилита ZopfliPNG (отвергнутая мною за неудобное отсутствие настройки Adam7), возможно, была бы способна обеспечивать ещё меньший объём файлов, так как скриншот её настроек демонстрирует возможность перепробовать большѣе количество стратегий выбора фильтров, чѣмъ в OptiPNG или в oxipng, да притом в README можно прочесть, что и алгоритм сжатия также используется современный, вдохновлённый используемым в WebP. Однако же думаю, может быть наивно, что закон убывающей отдачи работает в этом случае, то есть что напрягать себя употреблением ZopfliPNG большого смысла нѣтъ, а достаточно употребления Zopfli в oxipng.
Раз уж зашла рѣчь о WebP, то надо сказать и о том, что всякий сколько-нибудь впечатлительный (а особенно — увлекающийся новинками) человѣкъ на моёмъ мѣстѣ имѣлъ бы повод опустить руки, приговаривая: «Ну какой смысл тратить время, провѣряя преимущество того или другого оптимизатора файлов PNG над остальными оптимизаторами: всё равно формат PNG доживает послѣдніе мѣсяцы, так как компания Apple ужé объявила о готовности начать поддержку формата WebP во браузере Safari, начиная со слѣдующей же (четырнадцатой) версии. Стало быть, ужé к концу нынѣшняго (2020) года можно (да и нужно, нужно!) ждать того только, что на свѣтѣ не останется ни одного сколько-нибудь популярного браузера Интернета, не умеющего открывать картинки WebP с той же лёгкостью, что и картинки болѣе ранних графических форматов: GIF, JPEG, PNG — а так как WebP превосходит PNG по силе сжатия изображений, совершаемого без внесения потерь, то тогда формат WebP убьёт PNG, то есть необратимо и навсегда недосягаемо превзойдёт его собою. Можно ли в этих обстоятельствах удѣлять много часов знакомству с ранее не опробованным оптимизатором PNG и притом надеяться, что за оставшиеся немногие мѣсяцы употребления PNG всѣ достоинства этого оптимизатора принесут достаточно выгоды для того, чтобы оправдались затраты времени? — надеяться на это никоим образом нельзя!».
Я же смотрю в ближайшее будущее нѣсколько болѣе трезво, и у меня есть повод надеяться на то, что употребление формата PNG сохранится (в определённой нише) даже послѣ того, как формат WebP достигнет сияющих вершин заслуживаемой им популярности. И это тот же повод, которым я руководился, отказываясь от ZopfliPNG. Этот повод — алгоритм Adam7.
В формат PNG заложена возможность перетасовать пикселы графического файла по алгоритму Adam7, который звѣрски ухудшает их сжимаемость (и оттого увеличивает объём файла — нерѣдко болѣе чѣмъ на 20%), но этой цѣною онъ подмѣняетъ «медленное» (построчное) отображение файла болѣе быстрым (но и менѣе детальным) заполнением всего пространства изображения, и заполнение это впервые происходит во много десятков раз быстрѣе, чѣмъ при построчности — оно происходит ужé тогда, когда едва одна только шестьдесят четвёртая часть всѣхъ пикселов оказалась принятою изъ Сѣти! — и поступление всѣхъ остальных пикселов всего лишь наращивает детализацию картинки, а размѣры и основные очертания её ужé понятны для зрителя.
Во всѣхъ тѣхъ случаях, когда нѣкоторый графический файл доставляется къ нѣкоторымъ его зрителям по невысокоскоростным (напримѣръ, мобильным) каналам связи замѣтно долго — по нынешним временам таков едва ли не каждый многомегабайтный файл — хочется имѣть возможность отказаться от построчного отображения. Формат PNG даёт такую возможность, а в формат WebP она не заложена. (А для ещё болѣе крупных файлов формат WebP не подойдёт ещё и потому, что размѣръ изображения ограничен: не болѣе
Раз уж зашла рѣчь о WebP, то надо сказать и о том, что всякий сколько-нибудь впечатлительный (а особенно — увлекающийся новинками) человѣкъ на моёмъ мѣстѣ имѣлъ бы повод опустить руки, приговаривая: «Ну какой смысл тратить время, провѣряя преимущество того или другого оптимизатора файлов PNG над остальными оптимизаторами: всё равно формат PNG доживает послѣдніе мѣсяцы, так как компания Apple ужé объявила о готовности начать поддержку формата WebP во браузере Safari, начиная со слѣдующей же (четырнадцатой) версии. Стало быть, ужé к концу нынѣшняго (2020) года можно (да и нужно, нужно!) ждать того только, что на свѣтѣ не останется ни одного сколько-нибудь популярного браузера Интернета, не умеющего открывать картинки WebP с той же лёгкостью, что и картинки болѣе ранних графических форматов: GIF, JPEG, PNG — а так как WebP превосходит PNG по силе сжатия изображений, совершаемого без внесения потерь, то тогда формат WebP убьёт PNG, то есть необратимо и навсегда недосягаемо превзойдёт его собою. Можно ли в этих обстоятельствах удѣлять много часов знакомству с ранее не опробованным оптимизатором PNG и притом надеяться, что за оставшиеся немногие мѣсяцы употребления PNG всѣ достоинства этого оптимизатора принесут достаточно выгоды для того, чтобы оправдались затраты времени? — надеяться на это никоим образом нельзя!».
Я же смотрю в ближайшее будущее нѣсколько болѣе трезво, и у меня есть повод надеяться на то, что употребление формата PNG сохранится (в определённой нише) даже послѣ того, как формат WebP достигнет сияющих вершин заслуживаемой им популярности. И это тот же повод, которым я руководился, отказываясь от ZopfliPNG. Этот повод — алгоритм Adam7.
В формат PNG заложена возможность перетасовать пикселы графического файла по алгоритму Adam7, который звѣрски ухудшает их сжимаемость (и оттого увеличивает объём файла — нерѣдко болѣе чѣмъ на 20%), но этой цѣною онъ подмѣняетъ «медленное» (построчное) отображение файла болѣе быстрым (но и менѣе детальным) заполнением всего пространства изображения, и заполнение это впервые происходит во много десятков раз быстрѣе, чѣмъ при построчности — оно происходит ужé тогда, когда едва одна только шестьдесят четвёртая часть всѣхъ пикселов оказалась принятою изъ Сѣти! — и поступление всѣхъ остальных пикселов всего лишь наращивает детализацию картинки, а размѣры и основные очертания её ужé понятны для зрителя.
Во всѣхъ тѣхъ случаях, когда нѣкоторый графический файл доставляется къ нѣкоторымъ его зрителям по невысокоскоростным (напримѣръ, мобильным) каналам связи замѣтно долго — по нынешним временам таков едва ли не каждый многомегабайтный файл — хочется имѣть возможность отказаться от построчного отображения. Формат PNG даёт такую возможность, а в формат WebP она не заложена. (А для ещё болѣе крупных файлов формат WebP не подойдёт ещё и потому, что размѣръ изображения ограничен: не болѣе
16383×16383 пикселов.) Стало быть, популярность формата PNG при доставке крупных файлов не поколеблется до тѣхъ поръ, пока не обретёт популярность формат JPEG XL и не принесёт болѣе совершенный аналог алгоритма Adam7 — двумерное вейвлетное преобразование Альфреда Хаара. Однако до стандартизации и популярности JPEG XL остаётся ещё явно больше года, и даже о величине влияния этого преобразования на объём файла рано ещё судить.🐦 Опубликован очередной сборник моих твиттеровских микроблогозаписей.
Zopfli antagonists.7z
21.7 MB
Мои первоначальные впечатления о величине превосходства утилиты oxipng (работающей в режиме Zopfli) над OptiPNG оказались преувеличенными. Продолжая примѣнять oxipng для сжатия моего многотысячефайлового хранилища файлов PNG, я замѣтилъ через пару дней, что Zopfli не всегда безусловно превосходит zlib (как я думал): на сотню изображений всё же может попасться (и попадается) примѣрно 2 или 3 таких, которые в OptiPNG сжимаются лучше, хотя и ненамного (от полупроцента до 2% разницы). Пять таких изображений я даже сохранил (в прилагаемом архиве) для дальнейших экспериментов (напримѣръ, очень интересно, сработает ли ZopfliPNG лучше, чѣмъ oxipng).
Ещё оказалось, что оцѣнка скорости Zopfli (раз в 80 медленнѣе конкурентов) ≈справедлива насчёт работы zlib в режиме максимальных усилий по сжатию, но при переборе других настроек zlib чаще всего zlib работает быстрѣе. Потому и oxipng опережает OptiPNG по скорости не на порядок, а лишь в несколько раз — и, главным образом, за счёт распараллеливания (а не скорости Zopfli).
Ещё оказалось, что оцѣнка скорости Zopfli (раз в 80 медленнѣе конкурентов) ≈справедлива насчёт работы zlib в режиме максимальных усилий по сжатию, но при переборе других настроек zlib чаще всего zlib работает быстрѣе. Потому и oxipng опережает OptiPNG по скорости не на порядок, а лишь в несколько раз — и, главным образом, за счёт распараллеливания (а не скорости Zopfli).
Uzaki-chan wa Asobitai! EP03.7z
12.1 MB
Сшил (в Overmix) некоторые кадры третьей серии #аниме «Uzaki-chan wa Asobitai!».
Сшивки прилагаю в формате PNG внутри архива 7-Zip.
Предпросмотр сшивок — в Твиттере. (Там они сжаты в формате JPEG с внесением потерь, поскольку таковы твиттеровские правила.)
Сшивки прилагаю в формате PNG внутри архива 7-Zip.
Предпросмотр сшивок — в Твиттере. (Там они сжаты в формате JPEG с внесением потерь, поскольку таковы твиттеровские правила.)
Maou Gakuin no Futekigousha EP02 EP03 EP04.7z
172.9 MB
Сшил (в Overmix) некоторые кадры второй, третьей и четвёртой серии #аниме Maou Gakuin no Futekigousha.
Сшивки прилагаю в формате PNG внутри архива 7-Zip.
Предпросмотр сшивок — в Твиттере. (Там они сжаты в формате JPEG с внесением потерь, поскольку таковы твиттеровские правила.)
Сшивки прилагаю в формате PNG внутри архива 7-Zip.
Предпросмотр сшивок — в Твиттере. (Там они сжаты в формате JPEG с внесением потерь, поскольку таковы твиттеровские правила.)
🐦 Опубликован очередной сборник моих твиттеровских микроблогозаписей.
🐦 Опубликован очередной сборник моих твиттеровских микроблогозаписей.
Он содержит, в частности, ретвиты азиатских фотографий с книгами на русском языке и ретвиты видеозаписей, сдѣланных очевидцами бейрутских взрывов.
Он содержит, в частности, ретвиты азиатских фотографий с книгами на русском языке и ретвиты видеозаписей, сдѣланных очевидцами бейрутских взрывов.
ipfs.io
Twitter: @FidonetRunes
Ан (@AnnSherror) 2020-07-23 10:42:39 (UTC) https://twitter.com/AnnSherror/status/1286250366917582848 Представляю вашему вниманию два озера - голубичное и благодатное Population and Demography (@popde➡
🐦 Опубликован очередной сборник моих твиттеровских микроблогозаписей.
Он содержит, в частности, ретвиты сообщений о том, что Twitter начал поисковую пессимизацию государственных СМИ и чиновников (причём их определение составлено так хитроумно, что, напримѣръ, Би-Би-Си эта мѣра не затронет, да и «Голоса Америки» не коснётся, вѣроятно; то есть мѣра эта — исключительно противороссийская, да ещё, может быть, противокитайская, и то только на первое время, пока Китаю не позволят как-нибудь вывернуться), а упоминания видеохостинга BitChute вообще начал блокировать.
Он содержит, в частности, ретвиты сообщений о том, что Twitter начал поисковую пессимизацию государственных СМИ и чиновников (причём их определение составлено так хитроумно, что, напримѣръ, Би-Би-Си эта мѣра не затронет, да и «Голоса Америки» не коснётся, вѣроятно; то есть мѣра эта — исключительно противороссийская, да ещё, может быть, противокитайская, и то только на первое время, пока Китаю не позволят как-нибудь вывернуться), а упоминания видеохостинга BitChute вообще начал блокировать.
Zopfli antagonists.7z
74.2 MB
Я наконец закончил засовывание моей коллекции файлов PNG в утилиту oxipng. Команда «
for %p in (*.png) do call имяОбработчика "%p"» проработала 2½ недѣли без перерыва — хорошо ещё, что никто не вздумал отключить электричество в городе (или в конкретном его районе) во всё это время, несмотря на явно сильное электроупотребление, вызванное лѣтнею жарою. Моё первоначальное (восторженное) мнение о возможностях реализации Zopfli алгоритма DEFLATE сперва перемѣнилось к худшему (о чём я упоминал 27 июля), но сейчас я успѣлъ вдругорядь перемѣнить его нѣсколько к лучшему: хотя скорость oxipng по-прежнему не слишком больше, чѣмъ у OptiPNG (так что за час автоматически обрабатывается не болѣе четырёх или шести — в зависимости от размѣра — таких сшивок кадров из аниме, которые я тут приводил), но всё же на сотню изображений не всегда попадается 2 или 3 таких, которые в OptiPNG сжимаются лучше: бывают и такие сотни, в которых ни одного такого изображения. Я собрал 19 примѣровъ таких изображений, архив с которыми и прилагаю.🐦 Опубликован очередной сборник моих твиттеровских микроблогозаписей.
Он содержит, в частности, ретвиты видеозаписей волгоградского взрыва, нѣcколькихъ новостей и мнений о белорусских массовых протестах, планов зеленоградского микрорайона, фэнфиков-кроссоверов по мотивам «Волшебной скрипки» Гумилёва, объявлений о новом твиттеровском API.
Он содержит, в частности, ретвиты видеозаписей волгоградского взрыва, нѣcколькихъ новостей и мнений о белорусских массовых протестах, планов зеленоградского микрорайона, фэнфиков-кроссоверов по мотивам «Волшебной скрипки» Гумилёва, объявлений о новом твиттеровском API.