внѣшній_двухтерабайтник_SSD_AGI_ED138,_он_же_AGI2T0GIMED138,_в_DNS.png
317.3 KB
Въ послѣдніе нѣсколько лѣтъ почти каждый, кто обдумывал покупку в DNS внѣшняго SSD (по USB подключаемого) объёмомъ 2 терабайта, почти неизбѣжно обнаруживал среди наиболѣе дешёвых вариантов ту модель, под брэндом AGI выпускаемую, которая называется ED138 — или, слегка подлиннѣе, AGI2T0GIMED138.
(Я всё же пишу «почти каждый» и «почти неизбѣжно», потому что дешевизна товаров перемѣняется со временем — напримѣръ, прямо сейчас нѣкоторые двухтерабайтные SSD Kingston распродаются со скидкою 11% или 12% и оттого будут ещё дешевле до тѣхъ поръ, пока эта распродажа не завершится.)
Но дешевизна — не единственное свойство AGI2T0GIMED138, и если кто зайдёт на страницу этого товара (скриншот которой я приложил чуть выше) и затѣмъ вздумает прочитать там отзывы (приводимые там в обратном хронологическом порядке), то тогда постепенно начнёт среди отзывов обнаруживать негативные; правда, каждый из таковых относится не к двухтерабайтовой, а к терабайтовой или к полутерабайтовой модели SSD той же фирмы (отзывы на SSD разного объёма приводятся там вперемѣшку).
29 ноября прошлого (2025) года там появился отзыв от покупщика терабайтового SSD, сообщающий про смерть SSD на втором году использования — про «битые» секторы и невозможность переразмѣтки раздѣловъ диска:
(Я всё же пишу «почти каждый» и «почти неизбѣжно», потому что дешевизна товаров перемѣняется со временем — напримѣръ, прямо сейчас нѣкоторые двухтерабайтные SSD Kingston распродаются со скидкою 11% или 12% и оттого будут ещё дешевле до тѣхъ поръ, пока эта распродажа не завершится.)
Но дешевизна — не единственное свойство AGI2T0GIMED138, и если кто зайдёт на страницу этого товара (скриншот которой я приложил чуть выше) и затѣмъ вздумает прочитать там отзывы (приводимые там в обратном хронологическом порядке), то тогда постепенно начнёт среди отзывов обнаруживать негативные; правда, каждый из таковых относится не к двухтерабайтовой, а к терабайтовой или к полутерабайтовой модели SSD той же фирмы (отзывы на SSD разного объёма приводятся там вперемѣшку).
29 ноября прошлого (2025) года там появился отзыв от покупщика терабайтового SSD, сообщающий про смерть SSD на втором году использования — про «битые» секторы и невозможность переразмѣтки раздѣловъ диска:
отзыв 2025-11-29 на внѣшній SSD AGI.png
94.3 KB
12 ноября позапрошлого (2024) года там же появился отзыв от покупщика полутерабайтового SSD, сообщающий про смерть диска через 13 мѣсяцев эксплуатации и приводящий фото его начинки (выглядит как NVMe въ гнѣздѣ M.2 с подключением к USB через переходник):
отзыв 2024-11-12 на внѣшній SSD AGI.png
108.1 KB
13 ноября позапозапрошлого (2023) года там же появился отзыв от покупщика терабайтового SSD, дополненный 30 декабря того же года сообщением о том, что SSD помер опять же через 13 мѣсяцев эксплуатации и приводящий фото его начинки:
отзыв 2023-11-13 на внѣшній SSD AGI.png
157.1 KB
Причём автор этого позапозапрошлогодняго отзыва умозаключает, что из строя вышел переходник, а сам SSD в порядке. Руководясь этим умозаключением, он купил новый переходник (ужé не на USB, а на SATA), подходящий под измѣренную им длину устройства NVMe (под 2242), и тѣмъ возстановилъ работоспособность.
Понятно, что это умозаключение не годилось бы в случае, упоминаемом первым из вышеприведённых отзывов, так как появление «битых» секторов указывает, вернѣе всего, на проблемы с самим носителем данных (то есть с чипами SSD), а не с переходником.
4 октября позапозапрошлого (2023) года там же появился отзыв от покупщика двух терабайтников, дополненный 31 октября того же года сообщением о том, что скорость работы каждого из двух SSD неприятно сократилася:
Понятно, что это умозаключение не годилось бы в случае, упоминаемом первым из вышеприведённых отзывов, так как появление «битых» секторов указывает, вернѣе всего, на проблемы с самим носителем данных (то есть с чипами SSD), а не с переходником.
4 октября позапозапрошлого (2023) года там же появился отзыв от покупщика двух терабайтников, дополненный 31 октября того же года сообщением о том, что скорость работы каждого из двух SSD неприятно сократилася:
отзыв 2023-10-04 на внѣшній SSD AGI.png
115.6 KB
Такой же SSD (но двухтерабайтовой величины) приобрёл в 2023 году и я, причём ещё до появления каждого из этих негативных отзывов (в чём могу быть увѣреннымъ благодаря тому, что одним из первых видеофайлов, на SSD сохранённых, была четырнадцатая серия римэйка «Rurouni Kenshin» 2023 года, вышедшая во вторую недѣлю октября того года — пятого или шестого числа октября в зависимости от часового пояса). Я предполагал, что использование именно SSD (а не традиционных вращающихся HDD) сильно ускорит и видеоцитирование, и сшивки видеокадров, и другие задачи, нѣкоторые этапы которых упираются в скорость записи или прочтения видеофайлов.
Года два это предположение выглядѣло совершенно оправданным, но осенью 2025 года я замѣтилъ начавшееся замедление работы SSD, причём скорость доходила не только до двух мегабайтов в секунду (как у автора послѣдняго из вышеприведённых отзывов, также испытавшаго аналогичное явление), но и ещё менѣе того. Под конец 2025 года пришлось прекратить использовать этот SSD и эвакуировать с него всѣ файлы, потому что становилось понятно, что возникли нѣкія проблемы с носителем данных (то есть с чипами SSD), которыя контроллер пытается компенсировать многократностью попыток чтения или записи до тѣхъ поръ, пока не достигнет (по его мнѣнію) успѣшнаго результата — и оттого всё замедление.
При копировании я обнаружил около двадцати видеофайлов «явно битых» (то есть таких, при попытке считывания которых наблюдалися ошибки чтения) и ещё около двадцати видеофайлов «скрыто битых» (то есть таких, при попытке считывания которых не наблюдалися явныя ошибки чтения, однако содержимое считываемого файла переставало соѿвѣтствовать извѣстному хэшу его). К счастью, всё это были не уникальныя видеоданныя, а серии аниме (причём недавния — именно за тот 2025 год, когда диск SSD начал обнаруживать замедление работы), и оттого всѣ утраченныя куски видеофайлов удалось невозбранно возстановить посредством торрентоваго файлообмѣна.
Но ориентироваться, уж конечно, надо на то одно, что в другой раз так не посчастливится.
Никому не нравится слишком частая смерть дисков, но о ней ещё можно думать как об обратной стороне дешевизны — дескать, малая цѣна оборачивается необходимостью чаще уплачивать эту цѣну, разсматривая дешёвый SSD в качестве своего рода «расходника».
Но ещё менѣе способна нравиться неожиданная утрата данных или неявное повреждение их.
Конечно, постепенное нарастание ошибок и постепенное уменьшение скорости — это всё равно гораздо лучше, чѣмъ неожиданное «превращение в кирпич» (полный отказ) всего SSD.
Но всё же от нормальных чипов SSD хочется ждать дольшей безотказности — хотя бы до достижения заявленной величины TBW. От нормальных контроллеров SSD хочется ждать понимания происходящего отказа чипов — такого понимания, которое проявляется готовностью помѣчать сбойные секторы как сбойные (а не противоположною ей готовностью «грубою силою» упорно повторять операцию раз за разом до наступления успѣха, особенно если способнаго оказаться кажущимся и порождать скрытыя потери данных), проявляется готовностью видѣть признаки грядущей сбойности секторов ещё до наступления реальной потери данных (то есть судить по уровням энергии, физически достигаемым при сохранении информации, и по скоростям утечки энергии) и эвакуировать данные из угрожаемых секторов, проявляется способностью перевести SSD в состояние read only («только для чтения») опосля исчерпания «живых» секторов.
Поэтому твердотѣльной продукции AGI (какъ внѣшнихъ SSD, так и внутренних устройств NVMe) я планирую впредь избѣгать — да и вам то же сáмое совѣтую.
Для примѣра можно подмѣтить, что самый дешёвый четырёхтерабайтник NVMe (для втыкания в M.2) в DNS в настоящее время — это AGI AI828, о котором самый залайканный отзыв сообщает, что контроллер в том NVMe — невѣсть какóй:
Года два это предположение выглядѣло совершенно оправданным, но осенью 2025 года я замѣтилъ начавшееся замедление работы SSD, причём скорость доходила не только до двух мегабайтов в секунду (как у автора послѣдняго из вышеприведённых отзывов, также испытавшаго аналогичное явление), но и ещё менѣе того. Под конец 2025 года пришлось прекратить использовать этот SSD и эвакуировать с него всѣ файлы, потому что становилось понятно, что возникли нѣкія проблемы с носителем данных (то есть с чипами SSD), которыя контроллер пытается компенсировать многократностью попыток чтения или записи до тѣхъ поръ, пока не достигнет (по его мнѣнію) успѣшнаго результата — и оттого всё замедление.
При копировании я обнаружил около двадцати видеофайлов «явно битых» (то есть таких, при попытке считывания которых наблюдалися ошибки чтения) и ещё около двадцати видеофайлов «скрыто битых» (то есть таких, при попытке считывания которых не наблюдалися явныя ошибки чтения, однако содержимое считываемого файла переставало соѿвѣтствовать извѣстному хэшу его). К счастью, всё это были не уникальныя видеоданныя, а серии аниме (причём недавния — именно за тот 2025 год, когда диск SSD начал обнаруживать замедление работы), и оттого всѣ утраченныя куски видеофайлов удалось невозбранно возстановить посредством торрентоваго файлообмѣна.
Но ориентироваться, уж конечно, надо на то одно, что в другой раз так не посчастливится.
Никому не нравится слишком частая смерть дисков, но о ней ещё можно думать как об обратной стороне дешевизны — дескать, малая цѣна оборачивается необходимостью чаще уплачивать эту цѣну, разсматривая дешёвый SSD в качестве своего рода «расходника».
Но ещё менѣе способна нравиться неожиданная утрата данных или неявное повреждение их.
Конечно, постепенное нарастание ошибок и постепенное уменьшение скорости — это всё равно гораздо лучше, чѣмъ неожиданное «превращение в кирпич» (полный отказ) всего SSD.
Но всё же от нормальных чипов SSD хочется ждать дольшей безотказности — хотя бы до достижения заявленной величины TBW. От нормальных контроллеров SSD хочется ждать понимания происходящего отказа чипов — такого понимания, которое проявляется готовностью помѣчать сбойные секторы как сбойные (а не противоположною ей готовностью «грубою силою» упорно повторять операцию раз за разом до наступления успѣха, особенно если способнаго оказаться кажущимся и порождать скрытыя потери данных), проявляется готовностью видѣть признаки грядущей сбойности секторов ещё до наступления реальной потери данных (то есть судить по уровням энергии, физически достигаемым при сохранении информации, и по скоростям утечки энергии) и эвакуировать данные из угрожаемых секторов, проявляется способностью перевести SSD в состояние read only («только для чтения») опосля исчерпания «живых» секторов.
Поэтому твердотѣльной продукции AGI (какъ внѣшнихъ SSD, так и внутренних устройств NVMe) я планирую впредь избѣгать — да и вам то же сáмое совѣтую.
Для примѣра можно подмѣтить, что самый дешёвый четырёхтерабайтник NVMe (для втыкания в M.2) в DNS в настоящее время — это AGI AI828, о котором самый залайканный отзыв сообщает, что контроллер в том NVMe — невѣсть какóй:
отзыв 2025-08-03 на NVMe AGI.png
99.7 KB
Я сейчас не собираюсь приобретать четырёхтерабайтник NVMe, но вот если бы собирался, то тогда непремѣнно обошёл бы этот конкретный девайс стороною, предполагая в нём вѣроятность близких аналогов всѣхъ вышеозначенных проблем с контроллером и с чипами.
❤9👌2
Сразу нѣсколько бандитов, руководясь приказом своей красивой и люто безжалостной атаманши (или, если угодно, своей анэго, потому что всё это происходит в аниме), с обнажённым оружием бросаются на центральнаго персонажа #аниме съ намѣреніемъ убить его на мѣстѣ. А он не выхватывает своё собственное оружие, но и голыми руками не пытается отбить или перехватить оружие противников, вообще не контратакует и даже не уклоняется от наносимых ударов — вмѣсто этого он позволяет всѣмъ ударамъ быть нанесёнными и тѣмъ самымъ тотчас же наглядно продемонстрировать ихъ безсмысленность: настолько высокоуровневый персонаж просто-напросто не может погибнуть от такого оружия, которым располагают обыкновенные бандиты.
Такую сцену можно было увидать въ іюлѣ 2012 года в четвёртой серіи превосходного аниме «Sword Art Online» о смертоносной игре в виртуальной реальности, причиняющей смерть игрокам в так называемом реальномъ мірѣ одновременно с гибелью игрового персонажа их. Высокоуровневый персонаж, сознательно ставшій цѣлью разбойнаго нападения, обладал настолько значительным количеством хитпойнтов здоровья и притом настолько быстрою регенераціею ихъ, что удары сразу нѣсколькихъ бандитов не могли причинить ему существеннаго урона, а весь нанесённый урон исчезал безслѣдно за нѣсколько секунд.
Такую сцену можно было увидать и въ апрѣлѣ прошлаго (2025) года ужé во второй серіи того аниме, которое извѣстно прежде всего под сокращённым названием «Yami Healer» (потому что полное название его «Isshun de Chiryou Shiteita no ni Yakutatazu to Tsuihou Sareta Tensai Chiyushi, Yami Healer to Shite Tanoshiku Ikiru» запомнить, сами понимаете, трудновато). Весьма одарённый цѣлитель, невольно ставший жертвою нападения обозлённых конкурентов той преступной группировки человѣкоящерицъ, участников которой он успѣшно лечил в своей нелегальной клинике, оказался притом давним обладателем тайнаго знанія о том, что защитная магия сродни цѣлительской, так что ни топоры, ни лапы, ни даже острые зубы человѣковолковъ не могли вообще ничего подѣлать с его защитою.
Малѣйшее усиліе сравненія видеоцитат, мною здѣсь прилагаемых, позволяет увѣренно констатировать, что тринадцать лѣтъ не прошли безслѣдно для идеи такой сцены и что мы видим плоды дальнѣйшаго художественнаго развитія ея. Если банда разбойников «Длань Титана» в «Sword Art Online» оказалася совершенно деморализована неудачею совершённаго ими нападения, то няшная звѣродѣвочка из «Yami Healer» демонстрирует способность быстро мыслить в критических обстоятельствах и находить альтернативное рѣшеніе: коль скоро цѣлитель неуязвим, но с его бизнесом всё же хочется непремѣнно покончить, то тогда достаточно разгромить нелегальную клинику его, раздолбать его мебель и вообще жилище.
(Да, и это направленіе дѣйствій также заканчивается для неё неблагополучно — но по такой причине, о которой звѣродѣвочка никак не могла догадываться заранѣе, так что мыслила она правильно.)
📔 ОГЛАВЛЕНИЕ
Такую сцену можно было увидать въ іюлѣ 2012 года в четвёртой серіи превосходного аниме «Sword Art Online» о смертоносной игре в виртуальной реальности, причиняющей смерть игрокам в так называемом реальномъ мірѣ одновременно с гибелью игрового персонажа их. Высокоуровневый персонаж, сознательно ставшій цѣлью разбойнаго нападения, обладал настолько значительным количеством хитпойнтов здоровья и притом настолько быстрою регенераціею ихъ, что удары сразу нѣсколькихъ бандитов не могли причинить ему существеннаго урона, а весь нанесённый урон исчезал безслѣдно за нѣсколько секунд.
Такую сцену можно было увидать и въ апрѣлѣ прошлаго (2025) года ужé во второй серіи того аниме, которое извѣстно прежде всего под сокращённым названием «Yami Healer» (потому что полное название его «Isshun de Chiryou Shiteita no ni Yakutatazu to Tsuihou Sareta Tensai Chiyushi, Yami Healer to Shite Tanoshiku Ikiru» запомнить, сами понимаете, трудновато). Весьма одарённый цѣлитель, невольно ставший жертвою нападения обозлённых конкурентов той преступной группировки человѣкоящерицъ, участников которой он успѣшно лечил в своей нелегальной клинике, оказался притом давним обладателем тайнаго знанія о том, что защитная магия сродни цѣлительской, так что ни топоры, ни лапы, ни даже острые зубы человѣковолковъ не могли вообще ничего подѣлать с его защитою.
Малѣйшее усиліе сравненія видеоцитат, мною здѣсь прилагаемых, позволяет увѣренно констатировать, что тринадцать лѣтъ не прошли безслѣдно для идеи такой сцены и что мы видим плоды дальнѣйшаго художественнаго развитія ея. Если банда разбойников «Длань Титана» в «Sword Art Online» оказалася совершенно деморализована неудачею совершённаго ими нападения, то няшная звѣродѣвочка из «Yami Healer» демонстрирует способность быстро мыслить в критических обстоятельствах и находить альтернативное рѣшеніе: коль скоро цѣлитель неуязвим, но с его бизнесом всё же хочется непремѣнно покончить, то тогда достаточно разгромить нелегальную клинику его, раздолбать его мебель и вообще жилище.
(Да, и это направленіе дѣйствій также заканчивается для неё неблагополучно — но по такой причине, о которой звѣродѣвочка никак не могла догадываться заранѣе, так что мыслила она правильно.)
📔 ОГЛАВЛЕНИЕ
❤2
Егор Холмогоров
попытка сформулировать незападные ценности ничуть не плоха, особенно если не ведет к запретунству и синдрому вахтера, а также к мигрантофилии и исламофилии
Но она очень часто ведёт именно к запретунству и синдрому вахтёра, а также к мигрантофилии и исламофилии.
Причём от исламофилии и мигрантофилия.
От синдрома вахтёра и запретунство.
Причём запретунство всегда в одну и ту же сторону.
Когда эти люди говорят о незападных цѣнностяхъ, то никогда не имѣютъ въ виду, напримѣръ, цѣнности восточной страны Японіи, в которой и императора не разстрѣливали въ подвалѣ, и миграція тщательно ограничивается (пусть и не до нуля ограничивается, но всё же достигнуто было то состояние единства общества, которым порождён мем «есть два типа цивилизаций»), и Хинамидзава не Матёра, и проч.
Никогда, никогда!
Как раз наоборот: у каждого запретуна (или хотя бы у каждого второго) рука тянется запрещать просмотр какого-нибудь аниме, нерѣдко под предлогом демонстративно надуманным.
Притом вдобавок они почти всегда тянуться запретить вам покупать и продавать (ощущая себя, может быть, в высшем смысле слугами апокалиптическаго Звѣря), или вослѣдъ Интернету запретить ещё сотовую связь, и электричество, и книгопечатание (ощущая себя, может быть, в высшем смысле слугами султана Баязида II, по нѣкоторымъ небезспорнымъ свѣдѣніямъ считающегося запретившим книгопечатание), а под конец запретить и крайнюю плоть, напримѣръ. Или ещё чего похуже, что даже и выговорить страшно («не подсказывайте им!»), хотя я в них вѣрю: этакие и без подсказки непремѣнно, непремѣнно додумаются самостоятельно — просто не так скоро, может быть.
Ждите того, что додумаются.
Причём от исламофилии и мигрантофилия.
От синдрома вахтёра и запретунство.
Причём запретунство всегда в одну и ту же сторону.
Когда эти люди говорят о незападных цѣнностяхъ, то никогда не имѣютъ въ виду, напримѣръ, цѣнности восточной страны Японіи, в которой и императора не разстрѣливали въ подвалѣ, и миграція тщательно ограничивается (пусть и не до нуля ограничивается, но всё же достигнуто было то состояние единства общества, которым порождён мем «есть два типа цивилизаций»), и Хинамидзава не Матёра, и проч.
Никогда, никогда!
Как раз наоборот: у каждого запретуна (или хотя бы у каждого второго) рука тянется запрещать просмотр какого-нибудь аниме, нерѣдко под предлогом демонстративно надуманным.
Притом вдобавок они почти всегда тянуться запретить вам покупать и продавать (ощущая себя, может быть, в высшем смысле слугами апокалиптическаго Звѣря), или вослѣдъ Интернету запретить ещё сотовую связь, и электричество, и книгопечатание (ощущая себя, может быть, в высшем смысле слугами султана Баязида II, по нѣкоторымъ небезспорнымъ свѣдѣніямъ считающегося запретившим книгопечатание), а под конец запретить и крайнюю плоть, напримѣръ. Или ещё чего похуже, что даже и выговорить страшно («не подсказывайте им!»), хотя я в них вѣрю: этакие и без подсказки непремѣнно, непремѣнно додумаются самостоятельно — просто не так скоро, может быть.
Ждите того, что додумаются.
www.ageofinvention.xyz
Age of Invention: Did the Ottomans Ban Print?
I’ve become interested in the question of when, and why, some countries don’t adopt the technologies of their near-neighbours — especially when they have significant diplomatic and commercial ties.
👏5❤🔥2
«Прощание_с_Матёрой»_и_«Higurashi_no_Naku_Koro_ni».png
27.6 KB
Чтобы значение моего краткого высказывания «Хинамидзава не Матёра» в предшествующем сообщении было чуть болѣе понятным, я прилагаю здѣсь скриншот моего стародавняго сообщенія, сравнивающаго «Прощание с Матёрой» В. Г. Распутина с сюжетною канвою #аниме «Higurashi no Naku Koro ni» и впервые опубликованнаго в Фидонете в марте 2013 г.
👍2
Пятнадцать дней назад (14 января) я упоминал о том, что исходный код Chromium (то есть та часть движка браузера Chrome, код которой открыт) днём ранѣе (13 января) пополнили поддержкою формата графических файлов JPEG XL — причём пока что по умолчанию поддержка эта выключена, однако её можно включить в настройках (а для того сперва хотя бы узнать о ней, потому что просто так в этот подраздѣлъ в настройках никто не полезет).
Сегодня я могу совершенно такую же новость изложить и про браузер Mozilla Firefox:
• и его исходный код также пополнили поддержкою формата графических файлов JPEG XL,
• и эта поддержка также по умолчанию выключена, но её можно включить в настройках (а для того сперва хотя бы узнать о ней, потому что просто так в этот подраздѣлъ в настройках никто не полезет),
• и опять же это произошло днём ранѣе, чѣмъ я сообщаю (28 января в 19:50, если судить по времени вон того комментария в Багзилле — время, однако же, тихоокеанское).
Если эта поддержка дойдёт до стадии бета-версии и затѣмъ до стадии официальнаго выпуска браузера без задержки, то тогда она появится в версии Firefox 149, выпуск которой в настоящее время намѣчается на 24 марта.
Однако в прошлом ужé были такие версии Файерфокса, в которых возможность включить поддержку формата графических файлов JPEG XL ограничивалася экспериментальными сборками, а до стадии бета-версии и затѣмъ до стадии официальнаго выпуска браузера не доходила. (Единственное существенное различие состоит в том только, что прежде реализация поддержки формата графических файлов JPEG XL была сочинённою на языке Си++, тогда как теперь — на языке Rust.)
По аналогии можно предположить, что и теперича возможность включить поддержку формата графических файлов JPEG XL может дойти до стадии бета-версии и затѣмъ до стадии официальнаго выпуска браузера не без задержек, если разработчики придут к мысли о необходимости дольшего тестирования, нежели до 24 марта.
Посмотрим.
Для сравнения сообщаю напослѣдокъ, что в Telegram Desktop поддержка просмотра графических файлов JPEG XL ужé есть.
И во браузере Safari поддержка просмотра графических файлов JPEG XL ужé есть.
Сегодня я могу совершенно такую же новость изложить и про браузер Mozilla Firefox:
• и его исходный код также пополнили поддержкою формата графических файлов JPEG XL,
• и эта поддержка также по умолчанию выключена, но её можно включить в настройках (а для того сперва хотя бы узнать о ней, потому что просто так в этот подраздѣлъ в настройках никто не полезет),
• и опять же это произошло днём ранѣе, чѣмъ я сообщаю (28 января в 19:50, если судить по времени вон того комментария в Багзилле — время, однако же, тихоокеанское).
Если эта поддержка дойдёт до стадии бета-версии и затѣмъ до стадии официальнаго выпуска браузера без задержки, то тогда она появится в версии Firefox 149, выпуск которой в настоящее время намѣчается на 24 марта.
Однако в прошлом ужé были такие версии Файерфокса, в которых возможность включить поддержку формата графических файлов JPEG XL ограничивалася экспериментальными сборками, а до стадии бета-версии и затѣмъ до стадии официальнаго выпуска браузера не доходила. (Единственное существенное различие состоит в том только, что прежде реализация поддержки формата графических файлов JPEG XL была сочинённою на языке Си++, тогда как теперь — на языке Rust.)
По аналогии можно предположить, что и теперича возможность включить поддержку формата графических файлов JPEG XL может дойти до стадии бета-версии и затѣмъ до стадии официальнаго выпуска браузера не без задержек, если разработчики придут к мысли о необходимости дольшего тестирования, нежели до 24 марта.
Посмотрим.
Для сравнения сообщаю напослѣдокъ, что в Telegram Desktop поддержка просмотра графических файлов JPEG XL ужé есть.
И во браузере Safari поддержка просмотра графических файлов JPEG XL ужé есть.
bugzilla.mozilla.org
1986393 - land initial jpegxl rust code pref disabled
RESOLVED (zondolfin) in Core - Graphics: ImageLib. Last updated 2026-01-28.
❤🔥1🎉1👀1
НТВ
Центральное телевидение / Выпуски программы / Выпуск от 21 июня 2025 года / Передачи НТВ
Главный форум России: что и как решают на кулуарных сделках? И о чем главные спикеры форума говорят в коридорах, когда не попадают в объективы камер?Первая околоядерная война: кто и зачем запустил на Ближнем Востоке стратегию апокалипсиса? Сможет ли Трамп…
У телеканала «НТВ» в том выпуске программы «Центральное телевидение», который вышел 21 июня прошлого (2025) года, через ¾ часа от начала телепередачи был прелюбопытный разсказъ о мрачных пророчествах японской мангаки Рё Тацуки.
(Видеоцитату я для удобства прилагаю гиперссылкою, но удобство это оказывается неполным: Telegram отказывается создавать предпросмотр этой гиперссылки, содержащий работоспособный видеопроигрыватель.)
К настоящему времени можно увѣренно констатировать, что предсказанная в этой передаче природная катастрофа не состоялася ни 5 июля, ни вообще в 2025 году.
По слѣдамъ этой передачи я также прочитал болѣе раннюю (2024 года) замѣтку об этих же пророчествах на сайте «Epoch Times Russia» и тотчас же обратил внимание на то, что обсуждаемая манга (упоминающая о том, что мангаке заблаговременно показана была во сне и смерть Фредди Меркьюри, и смерть принцессы Дианы, и землетрясение в Кобе) впервые опубликована была только в 1999 году, то есть опосля всѣхъ этих трёх значительных событий, так что о заблаговременности мы можем только вѣрить авторкѣ ея на слово — ну или не вѣрить.
А если кто желает подробнѣе ознакомиться с этой мангою, то тогда обратите внимание на канале @pohodu на комментарии вон к тому сообщению (как раз 5 июля выложенному).
(Видеоцитату я для удобства прилагаю гиперссылкою, но удобство это оказывается неполным: Telegram отказывается создавать предпросмотр этой гиперссылки, содержащий работоспособный видеопроигрыватель.)
К настоящему времени можно увѣренно констатировать, что предсказанная в этой передаче природная катастрофа не состоялася ни 5 июля, ни вообще в 2025 году.
По слѣдамъ этой передачи я также прочитал болѣе раннюю (2024 года) замѣтку об этих же пророчествах на сайте «Epoch Times Russia» и тотчас же обратил внимание на то, что обсуждаемая манга (упоминающая о том, что мангаке заблаговременно показана была во сне и смерть Фредди Меркьюри, и смерть принцессы Дианы, и землетрясение в Кобе) впервые опубликована была только в 1999 году, то есть опосля всѣхъ этих трёх значительных событий, так что о заблаговременности мы можем только вѣрить авторкѣ ея на слово — ну или не вѣрить.
А если кто желает подробнѣе ознакомиться с этой мангою, то тогда обратите внимание на канале @pohodu на комментарии вон к тому сообщению (как раз 5 июля выложенному).
👍1😁1
Егор Холмогоров
в учебниках будущего "Наши" будут описываться как этническое еврейское движение, успешно встроенное в политсистему РФ
Да здѣсь и вся политсистема-то — —
💯12🌚5🥴2
Артемий & Сыч
Да, это фото из файлов Эпштейна
Близокъ побѣды торжественный часъ
Иногда я обдумываю полное имя итальянскаго живописца Джорджоне (а звали его Джорджо Барбарелли да Кастельфранко, как нетрудно прочесть хотя бы в Википедии) и обнаруживаю в нём стихотворный ритм.
Во-первых, имена собственныя «Барбарелли» и «Кастельфранко» — это сочетания четырёх слогов, из которых третий является ударным, так что могли бы быть стихотворною стопою пэона третьего.
Во-вторых, если нарочно использовать не сочетание имени «Джорджо» с прозвищем «Барбарелли» черезъ пробѣлъ, а использовать союз «и»: «звали его и Джорджо и Барбарелли, он из Кастельфранко» — то тогда в итальянской фразе «Джорджо эт Барбарелли да Кастельфранко» в сочетаниях слов «эт Барбарелли» и «да Кастельфранко» мы видим ужé по пять слогов, из которых четвёртый является ударным, так что сочетания эти могли бы быть стихотворною стопою гиперпэона четвёртого.
Возможно ли такое перечисление? — честно говоря, я не очень увѣренъ. Обычно имена одного и того же человѣка не перечисляют через союз «и», чтобы не создать ненароком ложного представления о перечислении нѣсколькихъ людей. Но когда очень ясно, что рѣчь идёт об одном человѣкѣ (скажем, когда полное имя идёт в скобках опосля извѣстнаго краткаго), тогда такое перечисление возможно, хотя и прозвучит нѣсколько коряво.
Возможно ли называть такую стихотворную стопу «гиперпэоном четвёртым»? — честно говоря, я опять же не очень увѣренъ. С одной стороны, пэоны (то есть стопы из четырёх слогов) с ударным первым, вторым, третьим и четвёртым слогом называют соѿвѣтственно «пэон первый», «пэон второй», «пэон третий» и «пэон четвёртый», так что отчего бы не распространить этот принцип нумерации и на гиперпэоны. С другой стороны, нельзя же обойти молчанием, что Даніилъ Андреевъ въ замѣткѣ «Новыя метро-строфы» называл стопу из пяти слогов с третьим ударным просто-напросто «гипер-пэон», а с четвёртым ударным слогом — «гипер-пэон второй» (а не «четвёртый»). Но я не готов прибѣгнуть к андреевской терминологии, потому что предвижу, что тогда возникла бы трудная проблема при первой же необходимости как-нибудь назвать такую стопу из пяти слогов, в которой ударение падает на второй слог. Предпочитаю думать, что эта работа Андреева (созданная им въ совѣтской тюрьмѣ и затѣмъ ни разу не опубликованная при жизни автора ея) осталась навсегда недозаписанною и что он сам непремѣнно перемѣнилъ бы нумерацию, кабы дошёл до возможности перечислить всѣ пять возможных типов гиперпэонов послѣдовательно.
Наблюдение же моё о Джорджоне означает, что перечисление имён его встало бы «как родное» во всякое такое стихотворное произведение, которое сочинено было с употреблением той именно стихотворной стопы, которую я назвал здѣсь «гиперпэоном четвёртым». Возьмём для примѣра «Пѣсню о Соколѣ» Максима Горького и насытим настойчивыми отсылками к живописи Джорджоне:
Получается тот творческий приём, который был в строчке «в одном из неснятых фильмов Федерико Феллини» извѣстной пѣсни Васильева (лидера группы «Сплин»): нарочно натянутая отсылка к художественным образам чужого итальянскаго творчества.
Во-первых, имена собственныя «Барбарелли» и «Кастельфранко» — это сочетания четырёх слогов, из которых третий является ударным, так что могли бы быть стихотворною стопою пэона третьего.
Во-вторых, если нарочно использовать не сочетание имени «Джорджо» с прозвищем «Барбарелли» черезъ пробѣлъ, а использовать союз «и»: «звали его и Джорджо и Барбарелли, он из Кастельфранко» — то тогда в итальянской фразе «Джорджо эт Барбарелли да Кастельфранко» в сочетаниях слов «эт Барбарелли» и «да Кастельфранко» мы видим ужé по пять слогов, из которых четвёртый является ударным, так что сочетания эти могли бы быть стихотворною стопою гиперпэона четвёртого.
Возможно ли такое перечисление? — честно говоря, я не очень увѣренъ. Обычно имена одного и того же человѣка не перечисляют через союз «и», чтобы не создать ненароком ложного представления о перечислении нѣсколькихъ людей. Но когда очень ясно, что рѣчь идёт об одном человѣкѣ (скажем, когда полное имя идёт в скобках опосля извѣстнаго краткаго), тогда такое перечисление возможно, хотя и прозвучит нѣсколько коряво.
Возможно ли называть такую стихотворную стопу «гиперпэоном четвёртым»? — честно говоря, я опять же не очень увѣренъ. С одной стороны, пэоны (то есть стопы из четырёх слогов) с ударным первым, вторым, третьим и четвёртым слогом называют соѿвѣтственно «пэон первый», «пэон второй», «пэон третий» и «пэон четвёртый», так что отчего бы не распространить этот принцип нумерации и на гиперпэоны. С другой стороны, нельзя же обойти молчанием, что Даніилъ Андреевъ въ замѣткѣ «Новыя метро-строфы» называл стопу из пяти слогов с третьим ударным просто-напросто «гипер-пэон», а с четвёртым ударным слогом — «гипер-пэон второй» (а не «четвёртый»). Но я не готов прибѣгнуть к андреевской терминологии, потому что предвижу, что тогда возникла бы трудная проблема при первой же необходимости как-нибудь назвать такую стопу из пяти слогов, в которой ударение падает на второй слог. Предпочитаю думать, что эта работа Андреева (созданная им въ совѣтской тюрьмѣ и затѣмъ ни разу не опубликованная при жизни автора ея) осталась навсегда недозаписанною и что он сам непремѣнно перемѣнилъ бы нумерацию, кабы дошёл до возможности перечислить всѣ пять возможных типов гиперпэонов послѣдовательно.
Наблюдение же моё о Джорджоне означает, что перечисление имён его встало бы «как родное» во всякое такое стихотворное произведение, которое сочинено было с употреблением той именно стихотворной стопы, которую я назвал здѣсь «гиперпэоном четвёртым». Возьмём для примѣра «Пѣсню о Соколѣ» Максима Горького и насытим настойчивыми отсылками к живописи Джорджоне:
Высоко в горы вполз Уж и лёг там в сыром ущелье, свернувшись в узел и глядя в море, как на картине Джорджоне (Джорджо эт Барбарелли да Кастельфранко).
Высоко в небе сияло солнце, а горы зноем дышали в небо, и бились волны внизу о камень, как на картине Джорджоне (Джорджо эт Барбарелли да Кастельфранко).
А по ущелью, во тьме и брызгах, поток стремился навстречу морю, гремя камнями, как на картине Джорджоне (Джорджо эт Барбарелли да Кастельфранко).
Весь в белой пене, седой и сильный, он резал гору и падал в море, сердито воя, как на картине Джорджоне (Джорджо эт Барбарелли да Кастельфранко).
Вдруг в то ущелье, где Уж свернулся, пал с неба Сокол с разбитой грудью, в крови на перьях, как на картине Джорджоне (Джорджо эт Барбарелли да Кастельфранко).
С коротким криком он пал на землю и бился грудью в бессильном гневе о твёрдый камень, как на картине Джорджоне (Джорджо эт Барбарелли да Кастельфранко).
Уж испугался, отполз проворно, но скоро понял, что жизни птицы — две-три минуты, как на картине Джорджоне (Джорджо эт Барбарелли да Кастельфранко).
Получается тот творческий приём, который был в строчке «в одном из неснятых фильмов Федерико Феллини» извѣстной пѣсни Васильева (лидера группы «Сплин»): нарочно натянутая отсылка к художественным образам чужого итальянскаго творчества.
🤔2
Стихотворная стопа, состоящая из пяти слогов (четвёртый из которых — ударный), складывающихся в словá «и Адольф Гитлер», может считаться не только гиперпэоном, но и гитлерпэоном.
🗿5😁3🌚2
скриншотъ_побѣды_въ_игрѣ_«Сапёръ»_на_полѣ_50×50_клѣтокъ.png
152.3 KB
Вот графический файл в формате PNG, содержащий скриншот совершенно той же побѣды въ игрѣ «Сапёръ» на полѣ 50×50 клѣтокъ, которую я вчера приводил в предшествующем сообщении в виде стикера, для чего мнѣ достаточно было перевести изображение из формата PNG в формат WebP, который Телеграмом почти всегда отображается именно в виде стикера — исключением из этого правила являются только изображенія, по объёму превосходящія два мегабайта (как я о том упоминал в марте 2021 г.) или хотя бы содержащія болѣе 6 553 600 пикселов.
Даже опосля обработки самым дѣйственнымъ изъ извѣстныхъ мнѣ средств сжатия файлов PNG, совершаемаго без внесения потерь (а средством этим является утилита ECT версии 0.9.5), приведённый здѣсь файл PNG занимает 155 936 байтов. Это достаточно неплохо (напримѣръ, файл содержит меньше двоичных битов, чѣмъ пикселовъ), но формат WebP (будучи болѣе современным, чѣмъ PNG) всё же способен обеспечивать ещё болѣе эффективное сжатие данных, так что только что упомянутый стикер в предыдущем сообщении обходится всего-навсего 52 450 байтами. Можно сосчитать, что кодировщик cwebp из пакета libwebp сжал изображение примѣрно в три раза эффективнѣе (а если хотите знать не примѣрно, то файл WebP на 66,36% меньше файла PNG).
За счёт какого превосходства формата WebP над форматом PNG достигается как раз такой (≈трёхкратный) рост оптимизации данных? — за счёт учёта взаимной зависимости компонентов цвѣта пиксела, которых как раз три и есть: это красный, зелёный и синий компоненты его. В девяностые годы при создании формата PNG в его фильтры пикселов была заложена возможность учитывать только пространственную структуру изображения (что ужé придаёт этому формату высокую эффективность при сжатии прямых горизонтальных и вертикальных линий и одноцвѣтныхъ квадратов, из которых состоит поле «Сапёра»), тогда как кодировщик WebP способен учесть ещё и цвѣтностную структуру его: так как значительная часть поля «Сапёра» безцвѣтна (то есть состоит изъ свѣтло-сѣрыхъ клѣтокъ и тёмно-сѣрыхъ линий), то простое вычитание зелёнаго цвѣтового канала из краснаго и из синяго убирает из этихъ двухъ послѣднихъ всю пространственную структуру линий и клѣтокъ и оставляет на ея мѣстѣ пустоту, сжимаемую ещё болѣе эффективно.
Вослѣдъ появлению формата PNG (в 1996 году) и затѣмъ появлению libwebp версии 0.2 с поддержкою сжатия изображений, совершаемаго без внесения потерь (в августе 2012 года), очередным многообѣщающимъ средством такого сжатия становится формат графических файлов JPEG XL, добравшийся до стандартизации в 2021 и 2022 году (ISO/IEC 18181), получивший поддержку во браузере Safari в 2023 году, а въ нынѣшнемъ году постепенно обзаводящійся поддержкою в Chrome и затѣмъ ещё в Firefox.
И как же кодировщик этого формата справится со сжатием того же скриншота без внесения потерь? — а вот так:
Даже опосля обработки самым дѣйственнымъ изъ извѣстныхъ мнѣ средств сжатия файлов PNG, совершаемаго без внесения потерь (а средством этим является утилита ECT версии 0.9.5), приведённый здѣсь файл PNG занимает 155 936 байтов. Это достаточно неплохо (напримѣръ, файл содержит меньше двоичных битов, чѣмъ пикселовъ), но формат WebP (будучи болѣе современным, чѣмъ PNG) всё же способен обеспечивать ещё болѣе эффективное сжатие данных, так что только что упомянутый стикер в предыдущем сообщении обходится всего-навсего 52 450 байтами. Можно сосчитать, что кодировщик cwebp из пакета libwebp сжал изображение примѣрно в три раза эффективнѣе (а если хотите знать не примѣрно, то файл WebP на 66,36% меньше файла PNG).
За счёт какого превосходства формата WebP над форматом PNG достигается как раз такой (≈трёхкратный) рост оптимизации данных? — за счёт учёта взаимной зависимости компонентов цвѣта пиксела, которых как раз три и есть: это красный, зелёный и синий компоненты его. В девяностые годы при создании формата PNG в его фильтры пикселов была заложена возможность учитывать только пространственную структуру изображения (что ужé придаёт этому формату высокую эффективность при сжатии прямых горизонтальных и вертикальных линий и одноцвѣтныхъ квадратов, из которых состоит поле «Сапёра»), тогда как кодировщик WebP способен учесть ещё и цвѣтностную структуру его: так как значительная часть поля «Сапёра» безцвѣтна (то есть состоит изъ свѣтло-сѣрыхъ клѣтокъ и тёмно-сѣрыхъ линий), то простое вычитание зелёнаго цвѣтового канала из краснаго и из синяго убирает из этихъ двухъ послѣднихъ всю пространственную структуру линий и клѣтокъ и оставляет на ея мѣстѣ пустоту, сжимаемую ещё болѣе эффективно.
Вослѣдъ появлению формата PNG (в 1996 году) и затѣмъ появлению libwebp версии 0.2 с поддержкою сжатия изображений, совершаемаго без внесения потерь (в августе 2012 года), очередным многообѣщающимъ средством такого сжатия становится формат графических файлов JPEG XL, добравшийся до стандартизации в 2021 и 2022 году (ISO/IEC 18181), получивший поддержку во браузере Safari в 2023 году, а въ нынѣшнемъ году постепенно обзаводящійся поддержкою в Chrome и затѣмъ ещё в Firefox.
И как же кодировщик этого формата справится со сжатием того же скриншота без внесения потерь? — а вот так:
скриншотъ_побѣды_въ_игрѣ_«Сапёръ»_на_полѣ_50×50_клѣтокъ.jxl
60.8 KB
Сравнивая этот файл с двумя предыдущими, нетрудно сосчитать, что положение его промежуточно, то есть что он (занимая 62 284 байта) оказывается хотя и меньше файла PNG (на 60,06% при принятии объёма PNG за сотню процентов), но всё же файл WebP ещё меньше файла JXL (на 15,79% при принятии объёма JXL за сотню процентов).
На этом основании можно увѣренно прийти к выводу, что скриншот побѣды въ игрѣ «Сапёръ» на полѣ 50×50 клѣтокъ — это ещё один примѣръ такого рода изображеній, которыя в настоящее время замѣтно лучше сжимаются без потерь в WebP, нежели в JPEG XL. Нѣсколько других подобных примѣровъ я ужé приводил в Твиттере (нынѣ 𝕏) в 2021—2023 гг.
Существованию такихъ примѣровъ может и должно быть тотчас же противопоставлено то мнѣніе, согласно которому достигаемое в частных случаях превосходство кодировщика WebP над кодировщиком JPEG XL объясняется не несовершенством формата JPEG XL (который, как раз наоборот, должен считаться предоставляющим при сжатии изображений без потерь всѣ тѣ же возможности, что и WebP), а единственно несовершенством его кодировщика, который можно ещё далѣе совершенствовать год за годом (и код за кодом) и наконец довести до недосягаемого превосходства над кодировщиком WebP. (Этого мнѣнія придерживается, в частности, Jyrki Alakuijala, роль которого в разработке того и другого кодировщика весьма значительна.)
Однако такое совершенствование пока ещё остаётся дѣломъ будущаго — и даже весьма отдалённаго, потому что в ближайшем-то будущем команда разработчиков будет занята совершенствованием отнюдь не кодировщика в libjxl, а декодировщика в jxl-rs (такое совершенствование совершенно необходимо для того, чтобы впредь Chrome и Firefox не слишком притормаживали при декодировании изображений, хранимых в формате JPEG XL).
Поэтому, если вам придётся столкнуться с такого рода энтузиастами, которые при появлении любого нового формата файлов начинают считать его готовым замѣнить каждого из предшественников, то тогда знайте, что для JPEG XL такого рода энтузиазм остаётся въ нѣкоторыхъ случаях беспочвенным.
В области сжатия изображений, совершаемого без внесения потерь в них, до сих пор сохраняются случаи превосходства WebP. Поэтому в ближайшие годы чаще всего придётся сравнивать объёмы файлов, достигаемые при таком сжатии в WebP и в JPEG XL. Исключением могут быть только такие случаи, в которых и без сравнения превосходство формата JPEG XL оказывается всегда безспорным: напримѣръ, если без потерь приходится сжать длинный скриншот длинной страницы, по высоте превосходящей семнадцать тыщщ пикселов, то тогда формат WebP не подойдёт, потому что в нём изображение не может превосходить 16383 пикселов ни по высоте, ни по ширине.
В области сжатия изображений, совершаемого c внесением потерь в них, кодировщику формата JPEG XL «дышит в спину» кодировщик формата AVIF, который был серьёзно усовершенствован прошлой зимою (к февралю 2025 года) и обзавёлся бóльшим вниманием ко сбережению мелких деталей изображения. В том случае, когда эти изображения являются притом анимированными, превосходство формата AVIF оказывается недосягаемым благодаря возможности формирования «пирамиды» междукадровых предсказаний (о ней я упоминал в январе 2024 г.), позволяющей сильно сократить междукадровую избыточность графической информации. Но даже для статических изображений превосходство формата JPEG XL над форматом AVIF теперича перестаёт сказываться даже при среднем сжатии изображения (меньше трёх-четырёх битов на пиксел).
Понятно, что в будущем такому совершенствованию кодировщика формата AVIF может быть противопоставлено совершенствование кодировщика формата JPEG XL.
Однако в этом же будущем усовершенствованному кодировщику формата JPEG XL придётся, может быть, в качестве конкурента столкнуться с новой версией формата AVIF, основанной на AV2 вмѣсто AV1 и оттого наращивающей силу сжатия изображений примѣрно на 17%—20% (о чём я упоминал въ послѣднемъ абзацѣ вон того сообщения 16 сентября 2025 года) и предотвращающей рассыпание изображений на квадратики при сильном сжатии (а это в Мадриде показывал Норкин, которого я ужé цитировал 14 января):
На этом основании можно увѣренно прийти к выводу, что скриншот побѣды въ игрѣ «Сапёръ» на полѣ 50×50 клѣтокъ — это ещё один примѣръ такого рода изображеній, которыя в настоящее время замѣтно лучше сжимаются без потерь в WebP, нежели в JPEG XL. Нѣсколько других подобных примѣровъ я ужé приводил в Твиттере (нынѣ 𝕏) в 2021—2023 гг.
Существованию такихъ примѣровъ может и должно быть тотчас же противопоставлено то мнѣніе, согласно которому достигаемое в частных случаях превосходство кодировщика WebP над кодировщиком JPEG XL объясняется не несовершенством формата JPEG XL (который, как раз наоборот, должен считаться предоставляющим при сжатии изображений без потерь всѣ тѣ же возможности, что и WebP), а единственно несовершенством его кодировщика, который можно ещё далѣе совершенствовать год за годом (и код за кодом) и наконец довести до недосягаемого превосходства над кодировщиком WebP. (Этого мнѣнія придерживается, в частности, Jyrki Alakuijala, роль которого в разработке того и другого кодировщика весьма значительна.)
Однако такое совершенствование пока ещё остаётся дѣломъ будущаго — и даже весьма отдалённаго, потому что в ближайшем-то будущем команда разработчиков будет занята совершенствованием отнюдь не кодировщика в libjxl, а декодировщика в jxl-rs (такое совершенствование совершенно необходимо для того, чтобы впредь Chrome и Firefox не слишком притормаживали при декодировании изображений, хранимых в формате JPEG XL).
Поэтому, если вам придётся столкнуться с такого рода энтузиастами, которые при появлении любого нового формата файлов начинают считать его готовым замѣнить каждого из предшественников, то тогда знайте, что для JPEG XL такого рода энтузиазм остаётся въ нѣкоторыхъ случаях беспочвенным.
В области сжатия изображений, совершаемого без внесения потерь в них, до сих пор сохраняются случаи превосходства WebP. Поэтому в ближайшие годы чаще всего придётся сравнивать объёмы файлов, достигаемые при таком сжатии в WebP и в JPEG XL. Исключением могут быть только такие случаи, в которых и без сравнения превосходство формата JPEG XL оказывается всегда безспорным: напримѣръ, если без потерь приходится сжать длинный скриншот длинной страницы, по высоте превосходящей семнадцать тыщщ пикселов, то тогда формат WebP не подойдёт, потому что в нём изображение не может превосходить 16383 пикселов ни по высоте, ни по ширине.
В области сжатия изображений, совершаемого c внесением потерь в них, кодировщику формата JPEG XL «дышит в спину» кодировщик формата AVIF, который был серьёзно усовершенствован прошлой зимою (к февралю 2025 года) и обзавёлся бóльшим вниманием ко сбережению мелких деталей изображения. В том случае, когда эти изображения являются притом анимированными, превосходство формата AVIF оказывается недосягаемым благодаря возможности формирования «пирамиды» междукадровых предсказаний (о ней я упоминал в январе 2024 г.), позволяющей сильно сократить междукадровую избыточность графической информации. Но даже для статических изображений превосходство формата JPEG XL над форматом AVIF теперича перестаёт сказываться даже при среднем сжатии изображения (меньше трёх-четырёх битов на пиксел).
Понятно, что в будущем такому совершенствованию кодировщика формата AVIF может быть противопоставлено совершенствование кодировщика формата JPEG XL.
Однако в этом же будущем усовершенствованному кодировщику формата JPEG XL придётся, может быть, в качестве конкурента столкнуться с новой версией формата AVIF, основанной на AV2 вмѣсто AV1 и оттого наращивающей силу сжатия изображений примѣрно на 17%—20% (о чём я упоминал въ послѣднемъ абзацѣ вон того сообщения 16 сентября 2025 года) и предотвращающей рассыпание изображений на квадратики при сильном сжатии (а это в Мадриде показывал Норкин, которого я ужé цитировал 14 января):
generalized deblocking filter results.png
798.3 KB
Правда, чтобы этакое будущее и впрямь реализовалося, необходимо наперёд появиться такому новому варианту формата AVIF, который будет основываться на возможностях формата AV2 вмѣсто AV1 — а я ужé упоминал (16 сентября 2025 года), что этот вариант пока ещё никто не обѣщалъ сколько-нибудь твёрдо. Сейчас могу прибавить к этому, что даже появление такой новинки ещё не будет автоматически означать появление поддержки ея во браузерах (а также на сёрверной стороне — напримѣръ, в GD в PHP), так что до широкого употребленія ея в Интернете ещё далеко. Пройдут годы.
Больше того: даже сам видеоформат AV2, появление которого запланировано было на конец 2025 года (согласно пресс-релизу AOMedia), всё ещё не появился даже к началу февраля нынѣшняго (2026) года — а вѣдь без AV2 нечего и думать о появлении какой-либо основанной на AV2 новой версии формата AVIF.
Да и про формат JPEG XL надо сказать ещё, что он — даже не достигшій ещё полнаго превосходства над WebP в области сжатия изображений без внесения потерь, даже оттесняемый форматом AVIF в область одного только несильнаго сжатия изображений с внесением потерь в них — всё же сохраняет два таких преимущества, которыми формат WebP или формат AVIF не обладают.
Во-первых, любой старый JPEG может быть преобразован в формат JPEG XL, причём и без внесения новых потерь в изображение, и с доужатием его (для экономии мѣста и траффика), и с обратимостью (то есть из такого JPEG XL можно будет при желании получить прежний JPEG «как есть»). Формат WebP на такое не способен, а формат AVIF только в будущем (на основе AV2) способен будет прийти к возможности доужатия JPEG без внесения новых потерь, но об обеспéчении обратимости такого переужатия пока ещё никто не помышляет.
Во-вторых, хранение изображений с внесением потерь в них (в том числе и переужатых старых JPEG) порождает такой файл JPEG XL, который оказывается способным к быстрому размытому отображению во время скачивания его изъ Сѣти: сперва хранится (и оттого сперва скачивается) список усреднённых цвѣтовъ каждого изъ тѣхъ квадратных блоков, на которые изображение было раздѣлено при кодировании. Формат WebP на такое не способен в принципе (изображение всегда отображается сверху вниз по мѣрѣ скачивания файла изъ Сѣти), а формат AVIF на такое не способен по умолчанию (изображение отображается только опосля скачивания файла изъ Сѣти), если нарочно не засовывать в AVIF миниатюру изображения — однако это «не бесплатно» в AVIF (потому что увеличивает объём файла AVIF приблизительно на объём миниатюры), тогда как в JPEG XL это обеспечивается самим форматом хранения свѣдѣній о пикселах.
Однако второе из этих двух преимуществ выглядит не слишком значительным:
➊ Ни в одном из браузеров (даже в Safari, имѣвшемъ с 2023 года фору) не была ещё реализована постепенность отображения файлов JPEG XL.
➋ Значимость постепенности умаляется нынѣшнею неравномѣрностью поступления файлов изъ Сѣти (мысли Арчибальда на эту тему я пересказывал 14 января).
➌ Рѣшающаго значенія постепенность не имѣетъ: если нѣкій сайт принимает изображенія во всѣхъ современных форматах, однако только не превосходящія опредѣлённаго небольшого объёма файла (и тѣмъ понуждает к сильному сжатию файла), то тогда я предпочту достичь большего качества файла, а не постепенности отображения его — и оттого выберу не JPEG XL, а AVIF.
Поэтому насчёт будущности формата JPEG XL прогнозирую вот чего:
① Суффикс «XL» (сокращение слов «extra life») слѣдуетъ считать заслуженным: поддержка формата JPEG XL продлит жизнь старым JPEG за счёт обратимого преобразования их в JPEG XL, совершаемого без внесения новых потерь в изображения, однако доужатием экономящего и траффик, и дисковое пространство.
② В области сжатия изображений, совершаемого без внесения потерь, формат JPEG XL будет превосходить формат WebP сперва не всегда, а затѣмъ всё чаще — по мѣрѣ совершенствования кодировщика, когда и если оно произойдёт.
③ В области сжатия изображений, совершаемого почти без внесения потерь, формат JPEG XL не будет имѣть равныхъ себѣ, однако при любом сколько-нибудь сильном сжатии обрѣчёнъ уступать формату AVIF.
Больше того: даже сам видеоформат AV2, появление которого запланировано было на конец 2025 года (согласно пресс-релизу AOMedia), всё ещё не появился даже к началу февраля нынѣшняго (2026) года — а вѣдь без AV2 нечего и думать о появлении какой-либо основанной на AV2 новой версии формата AVIF.
Да и про формат JPEG XL надо сказать ещё, что он — даже не достигшій ещё полнаго превосходства над WebP в области сжатия изображений без внесения потерь, даже оттесняемый форматом AVIF в область одного только несильнаго сжатия изображений с внесением потерь в них — всё же сохраняет два таких преимущества, которыми формат WebP или формат AVIF не обладают.
Во-первых, любой старый JPEG может быть преобразован в формат JPEG XL, причём и без внесения новых потерь в изображение, и с доужатием его (для экономии мѣста и траффика), и с обратимостью (то есть из такого JPEG XL можно будет при желании получить прежний JPEG «как есть»). Формат WebP на такое не способен, а формат AVIF только в будущем (на основе AV2) способен будет прийти к возможности доужатия JPEG без внесения новых потерь, но об обеспéчении обратимости такого переужатия пока ещё никто не помышляет.
Во-вторых, хранение изображений с внесением потерь в них (в том числе и переужатых старых JPEG) порождает такой файл JPEG XL, который оказывается способным к быстрому размытому отображению во время скачивания его изъ Сѣти: сперва хранится (и оттого сперва скачивается) список усреднённых цвѣтовъ каждого изъ тѣхъ квадратных блоков, на которые изображение было раздѣлено при кодировании. Формат WebP на такое не способен в принципе (изображение всегда отображается сверху вниз по мѣрѣ скачивания файла изъ Сѣти), а формат AVIF на такое не способен по умолчанию (изображение отображается только опосля скачивания файла изъ Сѣти), если нарочно не засовывать в AVIF миниатюру изображения — однако это «не бесплатно» в AVIF (потому что увеличивает объём файла AVIF приблизительно на объём миниатюры), тогда как в JPEG XL это обеспечивается самим форматом хранения свѣдѣній о пикселах.
Однако второе из этих двух преимуществ выглядит не слишком значительным:
➊ Ни в одном из браузеров (даже в Safari, имѣвшемъ с 2023 года фору) не была ещё реализована постепенность отображения файлов JPEG XL.
➋ Значимость постепенности умаляется нынѣшнею неравномѣрностью поступления файлов изъ Сѣти (мысли Арчибальда на эту тему я пересказывал 14 января).
➌ Рѣшающаго значенія постепенность не имѣетъ: если нѣкій сайт принимает изображенія во всѣхъ современных форматах, однако только не превосходящія опредѣлённаго небольшого объёма файла (и тѣмъ понуждает к сильному сжатию файла), то тогда я предпочту достичь большего качества файла, а не постепенности отображения его — и оттого выберу не JPEG XL, а AVIF.
Поэтому насчёт будущности формата JPEG XL прогнозирую вот чего:
① Суффикс «XL» (сокращение слов «extra life») слѣдуетъ считать заслуженным: поддержка формата JPEG XL продлит жизнь старым JPEG за счёт обратимого преобразования их в JPEG XL, совершаемого без внесения новых потерь в изображения, однако доужатием экономящего и траффик, и дисковое пространство.
② В области сжатия изображений, совершаемого без внесения потерь, формат JPEG XL будет превосходить формат WebP сперва не всегда, а затѣмъ всё чаще — по мѣрѣ совершенствования кодировщика, когда и если оно произойдёт.
③ В области сжатия изображений, совершаемого почти без внесения потерь, формат JPEG XL не будет имѣть равныхъ себѣ, однако при любом сколько-нибудь сильном сжатии обрѣчёнъ уступать формату AVIF.
👍7👏5🔥4👀3❤2🎉1