The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

В Safari 17 и WebKit включена поддержка формата изображений JPEG XL

10.06.2023 13:21

Компания Apple включила по умолчанию в бета-версии браузера Safari 17 и движке WebKit поддержку формата изображений JPEG XL, от поддержки которого в Chrome в прошлом году отказалась компания Google. В Firefox поддержка формата JPEG XL доступна в ночных сборках (включается через image.jxl.enabled = true в about:config), но Mozilla пока сохраняет нейтральную позицию в вопросе продвижения этого формата.

В качестве аргумента удаления экспериментальной поддержки JPEG XL из кодовой базы Chromium упоминалось отсутствие достаточного интереса к формату со стороны экосистемы. С тех пор ситуация изменилась и кроме положительных отзывов от web-разработчиков и сообщества (за поддержку JPEG XL в Chrome высказались представители Facebook, Adobe, Intel and VESA, Krita, The Guardian, libvips, Cloudinary, Shopify и Free Software Foundation), формат теперь будет поддерживаться в Safari. В Google продолжают поступать запросы, связанные с возвращением кода для работы JPEG XL в Chromium.

В числе аргументов Google против включения JPEG XL также упоминалось отсутствие достаточных дополнительных преимуществ по сравнению с существующими форматами. При этом на странице с заявкой добавления поддержки JPEG XL в движок Blink упоминаются такие преимущества, как снижение размера до 60% по сравнению с изображениями JPEG идентичного качества и наличие расширенных возможностей, таких как HDR, анимация, прозрачность, режим прогрессивной загрузки, плавное ухудшение качества при уменьшении битрейта, сжатие JPEG без потерь (уменьшение размера JPEG до 21% c возможностью восстановления исходного состояния), поддержка до 4099 каналов и большой диапазон глубин цвета.

Кодек JPEG XL не требует отчислений и предлагает открытую эталонную реализацию под лицензией BSD. Применяемые в JPEG XL технологии не пересекаются с запатентованными технологиями, за исключением принадлежащего Microsoft патента на метод rANS (range Asymmetric Number System), но для данного патента выявлен факт более раннего использования ("prior art").

Дополнение: Опубликованы результаты сравнение форматов JPEG XL, WebP и AVIF, проведённого c использованием сервиса ImageEngine. Кодирование в формате JPEG XL по сравнению с AVIF позволило снизить размер файлов на 11%, а при оценке уровня качества (dssim) JPEG XL опередил AVIF на 13%. Что касается формата WebP, то его показатели в средних значениях близки к AVIF, т.е. JPEG XL также примерно на 10% опережает его по степени сжатия и уровню видимых отличий от оригинала.



  1. Главная ссылка к новости (https://www.theregister.com/20...)
  2. OpenNews: Доступен браузер Thorium 110, более быстрый форк Chromium
  3. OpenNews: Google упраздняет поддержку JPEG XL в Chrome
  4. OpenNews: Firefox, Chrome, Edge и Safari прекратят поддержку TLS 1.0 и TLS 1.1
  5. OpenNews: Chrome и Safari убрали возможность отключения атрибута отслеживания кликов
  6. OpenNews: Компания Apple добавила поддержку кодека AV1 в браузер Safari
Лицензия: CC BY 3.0
Наводку на новость прислал Artem S. Tashkinov
Короткая ссылка: https://opennet.ru/59276-jpegxl
Ключевые слова: jpegxl, webkit, safari
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (138) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, Аноним (2), 13:47, 10/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +13 +/
    У Гулага просто есть своя карманная вебп. Она получше авиф и прочей дряни, но тоже уг. А у JXL конкурентов не существует, это Гулаг думает, что евоный шлак способен конкурировать, но он просто выставляет себя на посмешище в очередной раз.
     
     
     
    Часть нити удалена модератором

  • 3.11, Аноним (11), 14:16, 10/06/2023 [ответить]  
  • +6 +/
    1) По пункту webp vs jpegxl анон полностью прав. JXL технологичней кодирования ключевых кадров из VP8.
    2) По пункту очередного обсёра гугла. Непонятно упорство гугла, когда формат royalty-free, это да, с этим не поспоришь. А по поводу "очередности" обсёра. Это доля (участь) корпораций делать всякие волны и плюсы, и тащить их до полных похорон, сохраняя хорошую мину при плохой игре и итогах этой игры.
     
     
  • 4.38, Гогольмоголь (?), 18:19, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >2) По пункту очередного обсёра гугла. Непонятно упорство гугла, когда формат royalty-free, это да, с этим не поспоришь.

    И чо?
    Вот жупег изначально тоже типа халявный, а потом выяснилось, что там запатентованные алогритмы
    Ты штоли будешь плотить, если патентный тралл на подет на Гугл?)))

     
  • 4.73, Аноним (73), 22:47, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Во время JPEG были более технолоничные форматы сжатия с потерями.
    Про убогий GIF я вообще молчу.
    Да и PNG недалеко ушёл — о божечки, мы придумали жать изображение в ZIP!
    Но. Ведь аноним всё сделал для поддержки более лучших форматов?
     
     
  • 5.87, iZEN (ok), 12:22, 11/06/2023 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Да и PNG недалеко ушёл — о божечки, мы придумали жать изображение в ZIP!

    Формат PNG не только имеет поддержку сжатия без потерь, но и неограниченноую палитру цветов, прозрачность (альфа-канал), гамма-коррекцию, цветовую коррекцию (ICC). Это растровый формат, в котором можно сохранять промежуточные файлы двумерной растровой графики для последующего редактирования.

     
     
  • 6.102, Аноним (73), 12:07, 12/06/2023 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Клёво, а в анимацию умеет?
    Как промежуточный формат — вы шутите? Или его реально так кто-то использует?
     
     
  • 7.112, Аноним (112), 18:45, 13/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Клёво, а в анимацию умеет?

    Да, через формат на его основе известный как APNG. Интересно тем что даже декодеры не понимающие именно APNG видят сие как валидный PNG из первого кадра в файле. В основном мозилла продвигала но хром APNG тоже умеет уже много лет.

    > Как промежуточный формат — вы шутите? Или его реально так кто-то использует?

    Вполне вариант - а что, lossless же и сжатие умеет. Меньше места чем цатимегабайтные простыни без сжатия занимает. И хотя это обычный zlib, за счет префильтров не так уж и плохо жмет многие виды картинок. Но, конечно, не фоточки - это больше для lineart/computer generated/etc.

     
  • 2.40, Аноним (40), 19:34, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Гулаг думает, что евоный шлак

    Большинство разработчиков формата JXL из Google.

     
     
  • 3.46, Аноним (2), 20:02, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не знаю как там насчёт формата, но как минимум половина (и вроде даже лучшая лосслесс половина) это кодер целиком взятый с гулаговского кладбища мёртвых проектов, поэтому отношение сотрудников отчасти можно понять.
     
  • 2.48, совсем не аноним (?), 20:13, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    скоро выходит Jpeg ai, опять все переписывать
     
  • 2.85, Аноним (85), 10:38, 11/06/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    посмотрел несколько тестов кодирования. интересовали результаты jpeg xl и wepb. Да, jpeg xl оказался эффективней (около 6% преимущество), но вот скорость кодирования webp оказался существенно лучше -- примерно в 8 раз быстрее. Думаю, в некоторых случаях это довольно существенно.
     
     
  • 3.92, Аноним (2), 19:47, 11/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Вебп очень плох в плане сохранения качества в пересчёте на размер. И вебп2 не намного лучше. Но главная беда это ограничения формата и кодера. На практике, там далеко не 6%. Насчёт скорости не скажу, png тоже медленный.
     
  • 3.103, VladSh (?), 13:33, 12/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    В некоторых случая да. Но браузер предназначен для отображения, т.е. для декодирования. И если скорость декодирования не отличается в худшую сторону, то не вижу причин, чтобы не включить поддержку.
     
  • 2.111, Аноним (112), 18:41, 13/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > У Гулага просто есть своя карманная вебп. Она получше авиф и прочей > дряни,

    Yolo!!! WebP это по сути I-фреймы из кодека VP8 в упрощенном формате файла. На память об этом умеет только YUV и только с субсэмплингом. High-bitdepth, RGB цветовые пространства и прочие глупости не умеет принципиально. Так что даже для фоточек не предел мечтаний. Ну да, поэффективнее жыпега.

    Но с тех пор был VP9. А потом - на его основе (точнее, на основе прототипа VP10) - в смеси с Thor и Daala - появился AV1. Чьи I-фреймы стали - только подумайте - AVIF. То-есть AVIF чисто технически является дальним потомком WebP. Улучшенным по всем мыслимым параметрам. И как раз специально сделан менее карманным - чтобы и остальные внедрили поддержку охотнее. Что они и сделали.

     

  • 1.3, Аноним (3), 13:50, 10/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Вдруг webp станет никому не нужен? Подскажите, а webp придумали не потому, что его сделать можно просто выдернув кусок из webm-потока и подправив заголовок?
     
     
  • 2.8, Аноним (11), 14:07, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    webp - это контейнер RIFF (некоторая обвязка) над алго сжатия, которые применяются для кодирования ключевых кадров (I-frame, keyframe), для декодирования которых не нужны другие кадры (Intra-coded) кодека VP8.
     
     
  • 3.12, Аноним (12), 14:24, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так это выдернутый ключевой кадр из VP8, засунутый в webp контейнер, или нет? Я имею в виду, не могли ли этот формат придумать и внедрить для оптимизации формирования миниатюр на YouTube? Знаю, что YT всё видео перекодирует, но у них такие объёмы, что даже маленькое улучшение, вроде экономии на формировании миниатюр, может дать сколько-то денег.
     
     
  • 4.25, Аноним (25), 15:12, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >Так это выдернутый ключевой кадр из VP8, засунутый в webp контейнер, или нет?

    Я не специалист, но судя по тому, что я видел, что говорят про WebP/HEIF/AVIF - это именно выдернутые ключевые кадры.

    Придумали их всё же не ради миниатюр, а ради вторичного использования имеющегося кода и аппаратного ускорения видео. Отсюда проистекают ограничения этих форматов (маленькое разрешение, ограниченный выбор сабсэмплинга, ограниченная битность каналов и т.д.). Зато очень дешёвое good enough решение.

     
     
  • 5.113, Аноним (112), 18:49, 13/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > про WebP/HEIF/AVIF - это именно выдернутые ключевые кадры.

    Ну да. И к тому же AV1 (AVIF ключевой кадр AV1) сильно эффективнее чем VP8 (WebP - ключевой кадp VP8) и как он может быть хуже чем предок решительно не понятно. К тому же умеет сильно больше форматов.

     
     
  • 6.114, Аноним (2), 19:24, 13/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Непонятно только теоретикам. Он дефективный и артефачит на пустом месте, больше искажает цвета. Собственно, я жду, когда av1 уже окончательно загнётся, большей мерзости я ещё не встречал (он превзошёл в свой мерзости и никчёмности vp9). Есть слабые надежды, что av2 исправит ситуацию, но это не в ближайшие годы. Так что vp9 в вебе с нами надолго. Ну а jxl вообще первый реальный кандидат заменить jpeg за 30 лет. И png с webp заодно полностью заменить способен.
     
     
  • 7.115, Аноним (112), 22:32, 13/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Больше чем YUV с субсэмплингом то С RGB-скрина десктопа какого Ну да, кон... большой текст свёрнут, показать
     
     
  • 8.121, Аноним (2), 23:34, 13/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Именно так, обычный cwebp sharp_yuv на пару порядков лучше обычного libaom в пла... текст свёрнут, показать
     
     
  • 9.124, Аноним (112), 22:10, 14/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Кривая цветопередача в основном заслуга subsampling самого по себе И в этом пла... большой текст свёрнут, показать
     
  • 4.27, Анонус (?), 15:16, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Так это выдернутый ключевой кадр из VP8, засунутый в webp контейнер

    Если совсем точно, то в AVI-контейнер (хотя RIFF применяется в довольно многих форматах медиафайлов).

     
     
  • 5.116, Аноним (112), 22:44, 13/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Если совсем точно, то в AVI-контейнер (хотя RIFF применяется в довольно многих
    > форматах медиафайлов).

    Вообще-то этот контейнер называется как раз RIFF. AVI файлы является частным случаем оного контейнера. Есть и другие. Скажем, WAV - тоже частный случай RIFF контейнера. Но другого, по набору чанков с AVI имеет мало общего. Есть и некоторые иные RIFF-based контейнеры а также несколько иных форматов в этом стиле, когда идет FOURCC-идентификатор, длина, и данные такого размера, возможно, с вложенными аналогичными структурами.

    Более того - PNG также следует этому паттерну, он не RIFF (его первый тэг как раз PNG) но идея остается.

    И кстати ISO BMFF (известный многим как "mp4") использует весьма похожие идеи, хотя там конкретное представление чанков немного отличается в деталях.

     
  • 4.45, Аноним (45), 19:56, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Так это выдернутый ключевой кадр из VP8, засунутый в webp контейнер

    Так точно.

     

  • 1.5, Аноним (5), 13:58, 10/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Лучше бы они вместо того чтобы высказываться высылали бабулесы в Гугл. Вот это был бы совсем другой разговор.
     
     
  • 2.10, Тот_Самый_Анонимус__ (?), 14:14, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Лучше бы ты вместо своего высказывания денег перевёл нуждающимся.
     
     
  • 3.19, Аноним (5), 14:59, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Перевёл твоя очередь.
     
     
  • 4.72, Тот_Самый_Анонимус__ (?), 22:46, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Перевёл твоя очередь.

    Пфф, без пруфов не катит.

     
  • 2.95, Аноним (95), 23:14, 11/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Отправил бабулю в гугл, с ней все будет в порядке?
     
     
  • 3.106, Абрахимн Ибо Гуглин (?), 09:13, 13/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Хапроий бабушка, научим golang, обучим играть go, наймем разрабатывать alphago
     
  • 3.107, Аноним (107), 15:20, 13/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Еще бы, иначе сможешь неплохо поднять баб(осов) за эйджизм и сикхизм
     

  • 1.6, Аноним (5), 13:59, 10/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    И вообще анимированный jpeg сразу в гарбедж без раздумий.
     
     
  • 2.7, Аноним (2), 14:07, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Там с анимациями не очень пока емнип. Но вот типичная гифка 100 кадров 5-10 гигабайт, с этим вполне может конкурировать уже сейчас. Одна из киллер фич сабжа это быстрое лосслесс перекодирование уже существующих жпегов с потерями (чтобы получить хороший результат, исходник должен быть без потерь), на моём опыте 20-40% экономии в среднем (до ~99%) и этот тот же жпег остаётся.
     
     
  • 3.9, Аноним (2), 14:10, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Но кстати повторное лосси кодирование не уменьшает размер (некуда уменьшать), но способно спрятать жпег артефакты получше альтернатив.
     
  • 2.13, Аноним (12), 14:25, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Абсолютно. Есть же видеокодеки для такого.
     
     
  • 3.14, Аноним (2), 14:31, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    MJPEG хороший кодек, но всё же подустарел.
     
     
  • 4.21, Аноним (25), 15:02, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Он хорош двумя вещами:
    1) низкая вычислительная сложность
    2) отсутствие межкадрового сжатия, что полезно, когда недопустимо "додумывание" кодеком деталей изменений в кадре.

    Что делает его идеальным для, например, автомобильных видеорегистраторов.

    В остальном он, прямо скажем, лучше только полного отсутствия сжатия и сжатия видео без потерь универсальными компрессорами типа Deflate и ко.

     
  • 4.82, Бывалый смузихлёб (?), 09:46, 11/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Попробуй-ка на мелком маломощном устройстве с мизером памяти организовать видеотрансляцию
    С MJPEG это вполне получается
    Разве что звука нет. Но и частота кадров получается неплохой
     
     
  • 5.96, Аноним (95), 23:19, 11/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Проблема Mjpeg в том что аппаратного ускорения нет, хотя раньше софт умел, не знаю что изменилось, но теперь просмотр потока с ip камеры что под linux что под windows жрет процессор как не в себя.
     
     
  • 6.100, Бывалый смузихлёб (?), 05:07, 12/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Там в чём-то другом может быть проблема
    По крайней мере, уж если какой-нибудь есп-32 тянет получение кадров с камеры, их обработку и отправку, то для ПК сложностей вообще быть не должно. Разве что камер много или на компе происходит перекодирование в другой формат
     
     
  • 7.104, Аноним (95), 15:32, 12/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, проблема именно в том что теперь аппаратного ускорения видео mjpeg нет, ни в браузерах ни в приложениях, даже если например использовать ip камеру в качестве камеры для Скайпа декодирование идёт на процессоре, это началось когда в windows 10 внедрили frame server, а в linux не знаю когда и по какой причине.
     
  • 5.117, Аноним (112), 22:47, 13/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Попробуй-ка на мелком маломощном устройстве с мизером памяти организовать видеотрансляцию
    > С MJPEG это вполне получается > Разве что звука нет. Но и частота кадров получается неплохой

    Частота кадров получается неплохой только если битрейта завались. Поскольку inter-frame сжатия нет как класса, вместо того чтобы слать дельту между кадрами оно весь кадр заново шлет. По поводу чего приличный FPS требует дочерта бандвиза сети. Мягко говоря.

     
  • 3.20, Аноним (5), 15:01, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Даже сам эпл у себя на сайте делает анимации плавных переходов или разворотов простыми видеофайлами и у них нормально получается.
     
     
  • 4.34, Аноним (34), 16:35, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >By today (Oct 2022), we still can only use <img src=".mp4"> on Safari. If you want to make MP4 files work like GIFs on other browsers, you might wanna use <video autoplay muted loop>.

    https://stackoverflow.com/questions/60114243/using-videos-in-img-html

     
  • 4.118, Аноним (112), 22:51, 13/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Даже сам эпл у себя на сайте делает анимации плавных переходов или
    > разворотов простыми видеофайлами и у них нормально получается.

    Кроме того момента что реклама делающая это же самое но нагло и бесяще всех достала, так что не любой браузер вообще разрешает автовоспроизведение видео и на этом направлении можно хлебнуть горя и глюков.

     

  • 1.16, Аноним (25), 14:47, 10/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Всё-таки есть что-то подозрительное в том, что JPEG XL использует в качестве целевой метрики Butteraugli производства тех же самых разработчиков и большую часть своего преимущества в качестве обосновывает именно на превосходстве в этой метрике, а при сравнении с помощью простого и понятного PSNR, которому сто лет в обед, сливает конкурентам, в том числе очень старым типа JP2.
     
     
  • 2.24, Аноним (2), 15:09, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Что подозрительного? Имеет значение только визуальное качество и PSNR это очень плохая метрика для оценки потерь. Если сравнивать качество, то Peak Absolute Error чуть получше, но тоже не идеал. На зуме лосси выглядит плоховато, когда меньше q96, но зависит от источника тоже. Могут быть небольшие артефакты на краях, у конкурентов артефакты намного хуже. q97 очень близко к pixel-perfect. При этом, размер этого q97 аналогичен jpeg q93 который с кучей атрефактов идёт без вариантов. Кое-что не жалко и в q94 пожать, разница будет не видна, если не включать 800-кратный зум. К лосслесс претензий быть не может.
     
     
  • 3.28, Аноним (25), 15:18, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Подозрительное оно тем, что Butteraugli сложный (и их собственный — конфликт интересов же), а PSNR — простой.

    Согласен, что PSNR — не лучшая метрика, но сложные метрики демонстрируют большую хрупкость на нестандартных (не предусмотренных разработчиками) изображениях, ИМХО. На r/jpegxl периодически появляются темы про то, что их visually lossless не такой уж и visually lossless на изображениях.

     
     
  • 4.66, Cucumber (?), 21:37, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Можно просто своими глазами сравнить, jpegxl явно лучше гугловского webp, соревнуясь только с avif
    https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2022_10_04/index
     
     
  • 5.69, Аноним (69), 21:53, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Быть лучше webp не так уж и трудно, так как это довольно старый формат с ограничениями типа "только 4:2:0 сабсэмплинг". Как он в сравнении с JP2? В моём ограниченном исследовании WebP проигрывал ещё более старому JP2.

    Avif, кстати, в PSNR превосходен и в вышеупомянутом исследовании обходил JP2. Я не удивлюсь, если одной из причин, почему гугл выбрал его — это то, что он очень хорош в классической метрике и ему не нужны новоиспечённые метрики, придуманные разработчиками самого формата.

     
     
  • 6.123, Аноним (123), 20:27, 14/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Jpeg XL однозначно лучше Jpeg 2000 в любых пресетах: https://twitter.com/jonsneyers/status/1532771586381688833

    С точки зрения Jpeg Group, он заменяет 2000 и нет смысла больше смотреть на него, после появления XL.

     
     
  • 7.132, Аноним (25), 14:27, 15/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Снейерс и Клаудинари, проводившие это исследование 8212 одни из разработчиков... большой текст свёрнут, показать
     
     
  • 8.133, Аноним (25), 14:31, 15/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    частей стандарта, конечно... текст свёрнут, показать
     
  • 8.134, Аноним (134), 15:08, 15/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Даже если вот просто с этим согласиться закрыв глаза на всё, то всё равно пол... большой текст свёрнут, показать
     
     
  • 9.136, Аноним (25), 21:08, 15/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Мне кажется, что JXL силён в том, что в интернете особо и не нужно Для векторно... большой текст свёрнут, показать
     
     
  • 10.137, Аноним (25), 21:15, 15/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Я хочу добавить, что экономия места, которую даёт пережатие JPG в JXL, тоже акту... текст свёрнут, показать
     
     
  • 11.144, Аноним (134), 15:56, 16/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А тут прикиньте - транскодить не надо будет каждому клиенту умножайте на количе... большой текст свёрнут, показать
     
     
  • 12.147, Аноним (25), 17:34, 16/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Оно и сейчас так происходит 8212 перекодированные изображения кэшируются, кон... большой текст свёрнут, показать
     
  • 10.143, Аноним (134), 15:39, 16/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Вы пытаетесь сказать, что в интернете не особо-то и нужен формат изображений, ко... текст свёрнут, показать
     
     
  • 11.146, Аноним (25), 17:21, 16/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Давайте остановимся на том, что из моей аргументации в ответ будет только ха-х... большой текст свёрнут, показать
     
  • 2.125, Аноним (112), 22:27, 14/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Да просто капец как подозрительно те разработчики заметили чуть быстрее чем Зо... большой текст свёрнут, показать
     
     
  • 3.140, Аноним (25), 00:05, 16/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >Как метрика он достаточно паршивый.

    Вопрос немного не об этом. Непонятно почему я должен принимать то, что Butteraugli непаршивый. Этих метрик полным полно было, что мешало взять какую-то готовую от сторонних авторов, а не придумывать свою? Откуда я могу быть уверен, что оптимизация на эту метрику, чьи свойства (в отличие от имеющегося PSNR, по которому куча peer-reviewed статей написано) не особенно хорошо изучены и описаны — это правильно? Почему в Гугле посмотрели на этот Butteraugli и решили, что на выбор того, какие кодеки оставить, а какие выкинуть, он влиять не должен, а должен влиять PSNR, который использовался в том самом отчёте, на основании которого было принято решение выкинуть JXL из хрома?

     
     
  • 4.141, Аноним (25), 00:28, 16/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Пардон, нашёл это сравнение и там речь про MS-SSIM, а не PSNR. Это не так уж и важно, так как MS-SSIM — тоже старая метрика, хорошо исследованная в академических источниках.
     
  • 2.131, uis (??), 11:41, 15/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > а при сравнении с помощью простого и понятного PSNR

    Лол, PSNR самая худшая метрика. Настолько плохая, что даже простой SSIM лучше.

     

  • 1.17, Chromium (ok), 14:51, 10/06/2023 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • +/
     

     ....ответы скрыты (3)

  • 1.23, ИмяХ (?), 15:06, 10/06/2023 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • –3 +/
     

     ....ответы скрыты (2)

  • 1.31, grayich (ok), 15:26, 10/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    почему бы подобное не выносить в модули, зачем тащить в базовый код
     
     
  • 2.98, Разработчики браузеров (?), 00:48, 12/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А что, так можно было???
     

  • 1.36, Всем Анонимам Аноним (?), 17:09, 10/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Прикольно, в гугловском багрепорте (который начал один из команды Chromium, кстати), вместо объективный доводов куча просто срача, типа какой гугл плохой, а аппл хороший. Могу поспорить, только 1% идет от людей, которые занимаются web разработкой, если они там вообще есть. Иначе бы обосновали почему вдруг в задницу клюнуло в 2023 году и им всем срочно понадобился именно этот формат только из-за того, что в его названии слово JPEG присутствует.
     
     
  • 2.37, Аноним (37), 17:22, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > вместо объективный доводов куча просто срача

    Врать-то зачем?

     
  • 2.41, Аноним (69), 19:38, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Вообще, я согласен, какой-то просто неприличный хайп трейн везёт этот JPEG XL ... большой текст свёрнут, показать
     
     
  • 3.43, Аноним (5), 19:39, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Уже есть нейросети кому интересный эти форматы?
     
  • 3.47, Аноним (2), 20:08, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Я перепаковал 300гб png в 120гб jxl без потерь. TIFF так может? Может быть TGA может? Что, нет?
     
     
  • 4.49, Аноним (2), 20:16, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Там ещё кучка лосси жпг файлов, в среднем экономия 20% при лосслесс перекодировании (заодно почистил мусор в тегах). Это 200гб просто так. Но это просто маленький набор данных, до которого я добрался и на котором мог проверить.

    А что касается лосси кодирования, то там то же самое -- настолько эффективного и качественного лосси кодирования до сих пор ещё не показывал ни один кодек. Теперь не надо кодировать в убитый jpeg-60 чтобы иметь адекватный размер файла.

     
     
  • 5.50, Аноним (69), 20:18, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >Там ещё кучка лосси жпг файлов, в среднем экономия 20% при лосслесс перекодировании (заодно почистил мусор в тегах). Это 200гб просто так. Но это просто маленький набор данных, до которого я добрался и на котором мог проверить.

    Есть арифметик JPEG, man jpegtran

     
     
  • 6.54, Аноним (2), 20:41, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Уменьшает малоцветный файл на 3%. JPEG reconstruction на 13%. 2 рисованный файл на 9% и jpegxl на 23%. Это jpeg q100 и q99, файлы огромные. Если бы кодировали в полноценный jpegxl, они были бы куда лучше и без артефактов. Это кажется ерундой, но когда у тебя каждый жпег под сотни мегабайт это имеет значение.
     
     
  • 7.60, Аноним (69), 21:08, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >когда у тебя каждый жпег под сотни мегабайт

    Серьёзно, что это за джипеги, в которых сотни мегабайт?

    Если это карты, спутниковые снимки или ещё что-то, что выводится тайлами, то это идеальный кандидат для J2K.

    Если это фотки какие-то, то возникает закономерный вопрос — какие фотки требуют так много, да ещё и со смехотворной джипеговой 24-битовой цветностью?

     
     
  • 8.61, Аноним (2), 21:19, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Обычные жпеги, каждый второй такой сегодня CGI в основном 16к разрешение PSD ... текст свёрнут, показать
     
     
  • 9.64, Аноним (69), 21:26, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Да там поди постеризация дичайшая с 24 битами-то при таком разрешении А вы как ... текст свёрнут, показать
     
     
  • 10.74, Аноним (2), 22:57, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А там много вариантов Не так много софта на линуксе поддерживает экспорт Ну во... большой текст свёрнут, показать
     
     
  • 11.75, Аноним (25), 23:09, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Файл не битый, в исходнике просто есть альфа канал и он был сохранён в JP2 Друг... текст свёрнут, показать
     
     
  • 12.76, Аноним (25), 23:36, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ещё такой эксперимент вероятно, более интересный могу предложить cjxl -d 1 fi... текст свёрнут, показать
     
     
  • 13.77, Аноним (25), 23:48, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Если второе число покажется вам слишком маленьким, попробуйте немного увеличить ... текст свёрнут, показать
     
  • 12.91, Аноним (2), 19:31, 11/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Файл битый, даже точнее сказать безвозвратно запоротый без вариантов, потому чт... большой текст свёрнут, показать
     
     
  • 13.93, Аноним (25), 23:01, 11/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Так, давайте по порядку Для JP2 действительно есть хорошие имплементации и не о... большой текст свёрнут, показать
     
     
  • 14.94, Аноним (25), 23:12, 11/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Конечно, имелось в виду наоборот r размер файла в формате pnm сойдёт и bmp д... текст свёрнут, показать
     
  • 14.97, Аноним (25), 23:34, 11/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Имелась в виду просто сложность, хотя вычислительная, конечно, тоже выше, чем та... текст свёрнут, показать
     
  • 14.135, Аноним (134), 15:52, 15/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Потому, что это сейчас почти никому не надо Времена надо уложиться в 1,44 мега... большой текст свёрнут, показать
     
     
  • 15.138, Аноним (25), 22:52, 15/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Я не соглашусь, интернет всё ещё с нами 8212 размеры изображений и других заг... большой текст свёрнут, показать
     
     
  • 16.142, Аноним (134), 15:31, 16/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    И много вы знаете рельаных сценариев в инете, где картинки жмут специально под ... большой текст свёрнут, показать
     
     
  • 17.145, Аноним (25), 17:15, 16/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, не играет 8212 пожалуйста, не сводите разговор к обсуждении моей объекти... большой текст свёрнут, показать
     
  • 4.51, Аноним (69), 20:20, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >Я перепаковал 300гб png в 120гб jxl без потерь. TIFF так может? Может быть TGA может? Что, нет?

    J2K может лосслесс паковать и может это делать лучше TIF.

     
     
  • 5.52, Аноним (2), 20:24, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    В том и дело что ни один из лосслесс кодеров не может даже близко сравниться с jxl. Его может побить только png упакованный проприетарью на оффтопе, но это только когда мало цветов и менее универсально.
     
     
  • 6.53, Аноним (69), 20:33, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >В том и дело что ни один из лосслесс кодеров не может даже близко сравниться с jxl.

    Во-первых, тут нужны источники.

    Во-вторых, cjxl на стандартном эффорте 7 очень-очень медленно жмёт, а на более низких он ничем не лучше J2K, а то и хуже. Я бы сказал, что это как архиватор PAQ — да, жмёт сильнее всех, но скорость убивает любые преимущества. Из той же категории pigz -11, который жмёт лучше, чем -9, но до конца сжатия мало-мальски крупного файла можно и не дожить :)

     
     
  • 7.63, Аноним (2), 21:24, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    На 4 пне? И каким боком тут потоковые компрессоры deflate? Я кодирую 9 файлы с разрешением 4-16к и мне норм, фактически бесплатно по хранилищу выходит. Кодирует только в 1 поток (1 из этапов вроде 2 потока) поэтому можно спокойно загружать по числу ядер.
     
     
  • 8.65, Аноним (69), 21:34, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Да если бы Так можно любые форматы ускорить с помощью xargs, тут ничего нового... текст свёрнут, показать
     
     
  • 9.68, Аноним (2), 21:41, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ток независимо от числа тредов загружает 1 ядро, а так да Других параметров код... текст свёрнут, показать
     
  • 7.83, Аноним (83), 10:18, 11/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >Из той же категории pigz -11, который жмёт лучше, чем -9, но до конца сжатия мало-мальски крупного файла можно и не дожить :)

    Для png есть zopflipng, для zip в zopfli умеет zipalign.

     
     
  • 8.89, Аноним (25), 17:58, 11/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    pigz -11 8212 это и есть zopfli, только для gzip Он чудовищно медленный, но ... текст свёрнут, показать
     
     
  • 9.127, Аноним (112), 22:50, 14/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А эта штука тоже пытается подобрать оптимальный вариант кодирования Есть много ... текст свёрнут, показать
     
  • 4.57, Аноним (5), 20:53, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем хранить png где ты их взял, сканы? Качества обычного джипега тебе вы хватило за глаза.
     
  • 4.119, Аноним (112), 23:01, 13/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >  TIFF так может?

    Который из? TIFF так то КОНТЕЙНЕР а не КОДЕК. А внутрях абсолютно разное барахло может быть. В принципе даже вот JXL тоже можно в TIFF врапнуть. Как отдельный, собссно, вариант "тега". Это тоже TIFF будет (не знаю есть ли уже стандартный тег для такого субформата).

    Извините, даже DNG (RAW фоты с некоторых камер) - формально как бы TIFF файл. А JXL может, извините, байеровский формат пикселей вообще? Ну вот такое с матрицы фотика на самом деле идет :)

     
     
  • 5.122, Аноним (2), 00:31, 14/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ни о чём.
     
     
  • 6.126, Аноним (112), 22:44, 14/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Ни о чём.

    Пойнт в том что в TIFF может быть что угодно, он лишь контейнер. Поэтому сравниваться с ним - полное ололо. С тем же успехом можно туда и сабжевое сжатие засунуть. И получится что сравнили JXL vs JXL тогда? :). Другое дело что такой диалект (пока еще?) может и не быть устаканившимся и стандартнам.

    А так поугарать, взятая наобум равка в DNG была TIFF содержащим в себе...
    1) JPEG как превьюху. Жпег может быть встроен в формат контейнера TIFF.
    2) Байеровсие данные в том чудесатом формате. После жпега уже. На то и теги что их может быть более 1.

    Что так уж запрещает в TIFF засунуть не просто JPEG а JPEG XL - кто б его знает. Ну а что конкретная программа работающая с TIFF умеет - другой вопрос уже.

     
     
  • 7.129, Аноним (2), 00:11, 15/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну и чё, кто-нибудь уже засунул наверно, да? Неужели нет, а почему? У каждого вендора свой форк этой дряни, а сжатия не завезли. Ещё внезапно окажется, что это раздутый контейнер. А у jxl очень грамотный контейнер с прицелом на минимум оверхеда. И вообще ему контейнер не обязательно. Так вот и вопрос, получается, где же конкуренция?
     
     
  • 8.139, Аноним (-), 23:59, 15/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Может кто и засунули Основная трабла с TIFF - это поддержка софтом ВСЕХ фич Эт... большой текст свёрнут, показать
     
  • 2.55, Kuromi (ok), 20:42, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Абсолютно такие же срачи бывают и в Мозилловской Багзилле, правда с некоторых пор они оперативно лочат комменты в таком случае.
     
     
  • 3.59, Аноним (69), 21:01, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    О чём и речь, JPEG XL пушится толпой хомячков, которые ничего не понимают в области и по этой причине вынуждены обращаться к срачам чтобы хоть как-то обосновать своё мнение.

    При этом формат, вероятно, и вправду интересный, но методы его продвижения мне не очень нравятся. Похоже на астротурфинг, если честно.

     

  • 1.39, Аноним (39), 19:18, 10/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Эппля как всегда ОПОМНИЛАСЬ! :)) Люди уже AVIF продвигают (т.е. даже WebP уже вчерашний день)
     
     
  • 2.42, Аноним (5), 19:38, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Опять решили сделать не как все со своими клавиатурами бабочки и очередной раз облажались.
     
  • 2.88, 0_0 (?), 16:59, 11/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    В Safari уже давно есть поддержка WebP и AVIF, а теперь добавили еще один. Опомнись.
     
     
  • 3.108, Kuromi (ok), 17:57, 13/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > В Safari уже давно есть поддержка WebP и AVIF, а теперь добавили
    > еще один. Опомнись.

    Сафари начал пддерживать WebP когда они поняли что Мозилла с Гуглем пришли к соглашению - Хром включает APNG, Файрфокс включает WebP. В этот момент отказываться от WebP стало просто неактуально.

     
  • 2.105, DEF (?), 17:39, 12/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    JPEG XL более новый, чем AVIF.
     

  • 1.44, timur.davletshin (ok), 19:55, 10/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    https://addons.mozilla.org/en-US/firefox/addon/jxl/ - для нетерпеливых.
    https://jpegxl.info/art/2021-04_jon.html - для тестирования (да, оно тормозное).
     
     
  • 2.56, Kuromi (ok), 20:44, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А не проще Nightly поставить тогда? Так хоть нативная поддержка, а не полифилы на JS.
     
     
  • 3.58, Аноним (5), 20:54, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не надо ставить эту падучку.
     
     
  • 4.67, Аноним (67), 21:38, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    а эти падения они сейчас с нами? в этой комнате?
     
     
  • 5.70, Аноним (5), 22:36, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    У тебя глюки?
     
  • 4.110, Kuromi (ok), 18:01, 13/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Не надо ставить эту падучку.

    Да хосспади, ставите Nightly, проверяете что все работает, вырубаете обновление (известно как, политиками). Потом при релизе свежего стабильного релиза аккуратно создаете резервную копию и обновляетесь. Такая схема почти ничем от сидения на стабильно релизе не отличается.
    Это если вам Jpeg XL реально нужен.

     
  • 2.81, AleksK (ok), 08:30, 11/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Поставил аддон и зашёл на тестовую страничку ноутбук кулерами завыл как будто на нём 4K без хардварного ускорения включил. Это как надо упоротся чтобы просто показать статичных картинок так ресурсы жрал?
     
     
  • 3.109, Kuromi (ok), 17:59, 13/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Поставил аддон и зашёл на тестовую страничку ноутбук кулерами завыл как будто
    > на нём 4K без хардварного ускорения включил. Это как надо упоротся
    > чтобы просто показать статичных картинок так ресурсы жрал?

    А там в аддоне WASM потому что, целая библиотека в него перегнана. Поэтому Nightly - вот путь.

     

  • 1.62, Аноним (62), 21:23, 10/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Если хотите, чтобы ваш новый передовой формат изображений все ненавидели и никуда не принимали - назовите его JPEG [что-нибудь].
     
     
  • 2.71, Аноним (5), 22:37, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    100% работает.
     
  • 2.99, Аноним (99), 01:00, 12/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    JPEG-RUST
     

  • 1.78, penetrator (?), 00:09, 11/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Реально отличный результат, ни WebP ни AVIF не нужно, они хуже даже, чем JPG, особенно там где много деталей
     
  • 1.80, Аноним (73), 08:20, 11/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    На самом деле истина проста: всем нужен быстрый, более-менее качественно жмущий, стандартизированный формат. Как он там называется, запамятовал?..
     
     
  • 2.84, Аноним (84), 10:27, 11/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, всем нужен формат, устраивающий всех. Для вендоров бесплатного софта самое главное требование - отсутствие патентов, так как от уплаты отчислений с каждой загруженной копии только Гугл защищён - у него свои патенты, и если MPEG LA начнёт с ним судиться, то все члены патентного пула огребут.
     
  • 2.90, Аноним (25), 17:59, 11/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    JPEG XL, только без XL

    (шутка, состоящая лишь из доли шутки)

     

  • 1.86, Аноним (86), 10:57, 11/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Где-то плачет микрософт со своим jpeg xr.
     
     
  • 2.128, Аноним (112), 22:52, 14/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Где-то плачет микрософт со своим jpeg xr.

    Учитывая что экс-ишак стал всего лишь проприетарной шкуркой для хрома у них есть и другие поводы поплакать.

     

  • 1.130, uis (??), 11:29, 15/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Mozilla пока сохраняет нейтральную позицию в вопросе продвижения этого формата.
    > В Firefox поддержка формата JPEG XL доступна в ночных сборках

    Не такая уж и нейтральная, раз есть только в найтбилдах и только за флагом. Хром раньше прятал только за флагом.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру