Французский математик Фабрис Беллар (Fabrice Bellard (http://bellard.org/)), основавший в свое время проекты QEMU и FFmpeg, а также создавший самую быструю формулу вычисления числа Пи, представил (http://bellard.org/bpg/) новый свободный формат упаковки изображений BPG (http://bellard.org/bpg/bpg_spec.txt) (Better Portable Graphics), нацеленный на замену формата JPEG, обеспечивая более оптимальные характеристики качества картинки и результирующего размера файла.
Для загрузки подготовлен (http://bellard.org/bpg/libbpg-0.9.tar.gz) набор утилит для кодирования и декодирования изображений, Си-библиотека libbpg, а также реализация декодировщика на языке JavaScript, которая позволяет добавить поддержку формата BPG на сайты, без модификации кода браузеров. Библиотека декодирования, использующая модифицированную версию FFmpeg с кодеком HEVC, поставляется под лицензией LGPLv2.1. Не привязанный к FFmpeg вариант библиотеки, а также кодировщик доступны под лицензией BSD. Так как в BPG задействованы некоторые алгоритмы HEVC, формат BPG пересекается с рядом запатентованных технологий, но патентные ограничения можно обойти используя предоставляемые современным оборудованием функции аппаратного ускорения кодирования/декодирования HEVC.
Основные особенности BPG:- Высокий уровень сжатия. Итоговые файлы получаются заметно меньшего размера, по сравнению с файлами JPEG аналогичного качества;
- Поддержка в большинстве браузеров, благодаря наличию декодировщика на языке JavaScript. Размер сжатого кода JavaScript-библиотеки декодирования 76 Кб.
- Методы кодирования основаны на подмножестве стандарта сжатия видео HEVC/H.265 (https://ru.wikipedia.org/wiki/H.265);
- Использование идентичных с JPEG форматов цветовой субдискретизации: оттенки серого, YCbCr 4:2:0, 4:2:2, 4:4:4, что позволяет исключить потери при преобразовании из JPEG;
- Поддержка слоя прозрачности;
- Поддержка схем формирования цвета RGB, YCgCo и CMYK;
- Поддержка от 8 до 14 битов на цветовой канал;
- Наличие режима сжатия без потерь;
- Возможность интеграции в файл различных метаданных, включая блоки EXIF.URL: https://news.ycombinator.com/item?id=8704629
Новость: https://www.opennet.ru/opennews/art.shtml?num=41198
Анимацию забыл добавить.
А по сути сейчас не взлетит конечно. Разработчикам важно удобство а не размер файлов. С jpeg делать ничего не надо вообще и везде работает. Это самое удобное. Надо в браузеры интегрировать и пару лет ждать пока браузеры не обновятся.
Да, в этом плане оптимально поступила Mozilla, развивая mozjpeg. Даже у Google не получилось продвинуть новый формат WebP, несмотря на все его достоинства.
> Да, в этом плане оптимально поступила Mozilla, развивая mozjpeg. Даже у Google
> не получилось продвинуть новый формат WebP, несмотря на все его достоинства.А тут еще куча патентных грабель. И блеяния про то что вы можете что-то там декодировать через оборудование - это булшит. Оборудования которое это умеет - надо нынче искать с микроскопом. А остальные стало быть должны рисковать получить счет от мпеглы?
Через пару лет видно будет.
А так - годнота. Для говномыльниц, которые сразу в jpeg преобразуют, - самое то.
чего не взлетит-то?можешь уже хоть сегодня вставлять BPG-картинки на свои сайты. :-)
Asm.Js работает на всех браузерах. (на Мозилке работает в нативном режиме, на Хроме скоро тоже в новом движке будет в нативном режиме. а на остальных браузерах в режиме обратной совместимости)
хотя конечно предвижу проблемы с CSS
Вот на мобильной мозиле у меня не работает - каша вместо этих изображений
проверил на мобиле -- да -- не показывается. (показываются цветные помехи вместо картинок).думаю мозиловцы какой-то баг допустили в мобильной версии браузера.
или даже нет...
...более вероятно что говянные (бажные) видеодрайвера на мобилке.
Большинство девайсов нынче не умеет H.265. Вообще совсем никак.
У меня работает. FF33, Galaxy S2, CM
LG, KitKat, FF34, полёт нормальный.
WP 8, все оки-доки, правда грузиться заметно дольше
Google Chrome:39.0.2171.93 (Официальная сборка)
ОС : Android 4.4.2;
Lenovo A536 Build/KOT49HРаботает на этом недорогом смарте
Lenovo A369i, Firefox 34
полёт нормальный
на Sony Xperia Z Ultra в Хроме всё ок, на iPhone 4S/iOS7 в Сафари - каша.
> можешь уже хоть сегодня вставлять BPG-картинки на свои сайты. :-)И получить завтра счет от MPEG LA, если ресурс имеет хоть какое-то отношение к странам где работают патенты?
> Asm.Js работает на всех браузерах.
Только на большинстве из них не дождешься его завершения.
> на остальных браузерах в режиме обратной совместимости)
И в результате много юзерей задолбаются икотой браузера про медленный скрипт и что там еще намного раньше чем декодируется картинка.
> хотя конечно предвижу проблемы с CSS
Скорее, проблемы с тем что JS и так то не быстрый, а если тяжелый кодек да в костыльном режиме - юзер натурально столкнется с проблемами производительности. Поэтому такое решение будет использовать пара утонченных концептуалов. Остальные предпочтут выложить жпег и не париться с проблемами производительности, а то и патентных наездов.
Держи нас в курсе дальнейших аналитических выкладок, умник.
Нафига анимация в картинках, когда есть специальные форматы для видео?
Fabrice Bellard. дальше, собственно, можно было ничего и не писать, и так понятно, что годнота.
> понятно, что годнота.Да. Сферическая. В вакууме. О том как этим в реальном мире пользоваться - перец не подумал. Особенно учитывая что большинство софта разрабатывается в этих ваших америках, с их патентными акулами. И условия хостинга наилучшие именно в США.
Я конечно понимаю что Его Величество не желает париться такой низкой субстанцией как патенты. А вот те кто делает софт в америках и хостится на американских серверах будут вынуждены этот фактор учитывать.
лично мне это всё тоже совершенно неинтересно.
> лично мне это всё тоже совершенно неинтересно.не интересно обложен ли формат патентами? Обоснуй.
>> лично мне это всё тоже совершенно неинтересно.
> не интересно обложен ли формат патентами? Обоснуй.формат патентами не обложен, он свободный.
а что там с кодеками — мне ещё менее интересно. исходники под свободной лицензией есть? ну и отлично.
http://bellard.org/bpg/
>Some of the HEVC algorithms may be protected by patents in some countries (read the FFmpeg Patent Mini-FAQ for more information)
> http://bellard.org/bpg/
>>Some of the HEVC algorithms may be protected by patents in some countries (read the FFmpeg Patent Mini-FAQ for more information)и что? какое это отношение имет к формату? для особо продвинутых повторю: *формат* патентами не обложен.
всё остальное, как я уже написал, меня интересует ещё меньше в свете наличия исходников. современная патентная система — апофеоз идиотизма. пусть в это играют те, кому делать больше нечего.
>BPG (Better Portable Graphics) is a new image format.
> ...
> Based on a subset of the HEVC open video compression standard.
Нормальная такая реклама H265. А где сравнение с webp?
Все это конечно не умоляет достижений этого выдающегося человека, респект ему.
Да, Лена хороша. Спасибо, под^W^W^W Беллару за удачный выбор изображения
> Да, Лена [s]хороша. Спасибо, под[/s] Беллару за удачный выбор изображенияЧто?
Девушку, представленную на фото примеров сжатия, так зовут. Если не ошибаюсь, в какой-то старинном Плейбое была, а сейчас де факто пример для обработки изображений.
Аноним выше какбы намекал на некорректное использование ^W вместо ^H, что приводит к стиранию трёх слов вместо трёх букв.
Суровый прон раньше был.
> Суровый прон раньше был.Это в капиталистических странах. А в СССР вообще секса не было, так что я непорочно зачат походу ))
Пальцем сделан :-E
>А в СССР вообще секса не былоДа, тупого животного американского секса не было. Была любовь.
>>А в СССР вообще секса не было
> Да, тупого животного американского секса не было. Была любовь.ага. статистика по абортам не даст соврать!
ВОт так и надо работать - сделал, выложил, предлагай. А не как systemd пихается уже в существующие инфраструктуры, хотя до конца никто вообще не понимает как он должен работать.
Те, кто пихают - понимают. А неосиляторы манов и доков могут плакать дальше.
Бустер пишет, что системд не готов. И никто, включая Поттеринга, не знает каким он будет, когда будет готов. Именно отсутствие плана развития и, как следствие, отсутствие полного описания функционала делает системд незаменяемым паразитом -- нет возможности написать аналог.
Зачем нужен аналог systemd?
Очевидно, авторы аналога будут знать чего хотят, в отличие от инвалида, управляемого из микрософта.
Так чего же они хотят?
Ку они хотят
> Зачем нужен аналог systemd?Затем же, зачем и сам systemd. Очевидно же.
А вот зачем и кому нужен systemd, это вопрос.
> Зачем нужен аналог systemd?Тут Я Вас полностью поддерживаю. Аналог systemd НЕНУЖЕН! ...
sytemd - что это такое, его курить можно?...
Если нет - нафиг.
s/системд/Linux/g
s/Поттеринга/ЛинусаФерштейн?
Я не «ферштейн». Разжуйте для тупого, пожалуйста.
Я хотел сказать, что Linux как ядро — точно такой же незавершённый продукт, завершение для него наступит вместе со смертью. И Linux, и systemd отвечают реалиям сегодняшнего дня и будут другими завтра, это естественно и нормально.
> Я хотел сказать, что Linux как ядро — точно такой же незавершённый
> продукт, завершение для него наступит вместе со смертью. И Linux, и
> systemd отвечают реалиям сегодняшнего дня и будут другими завтра, это естественно
> и нормально.а с чего вы решили что они отвечают реалиям сегодняшних требований?
или вы так думаете потому-что они эти самые требования и формируют?
> а с чего вы решили что они отвечают реалиям сегодняшних требований?Ну вот я считаю что Linux и системд с их подходами хорошо подходят к моим задачам и хотелкам. И да, среди них и виртуализация, и нормальное деление ресурсов, и контейнеры, и возможность простого и быстрого рекавери при факапах, не говоря уж о возможности запускать программы как мне надо при старте системы или событиях без лишней возни.
> или вы так думаете потому-что они эти самые требования и формируют?
Они предлагают один из вариантов развития. Вот лично мне он вполне по вкусу. Потому что пересекается с моими задачами и хотелками, а не потому что кто-то что-то "формирует".
И да, в отличие от - линух нормально тянет и мой десктоп. В отличие от например бсдшных мегаразработчиков, которые то в максималке то в гейоси почему-то сидят и оттуда лицемерно вещают про какие-то там преимущества своих фетишей.
> Я хотел сказать, что Linux как ядро — точно такой же незавершённый
> продукт, завершение для него наступит вместе со смертью. И Linux, и
> systemd отвечают реалиям сегодняшнего дня и будут другими завтра, это естественно
> и нормально.зачем "не готовый" на "незавершенный" подменил?
Системд "не готов" там было написано. Если ты хотел сказать, что линукс незавершенный, так бы и написал, а не s/системд/линукс/.
> зачем "не готовый" на "незавершенный" подменил?Не передёрнешь -- не впаришь, а он пытается именно впарить.
Всё-таки когда красиво обнажённая математика воплощается в таких эффектных изменениях - это кружит голову.
> Всё-таки когда красиво обнажённая математика воплощается в таких эффектных изменениях
> - это кружит голову.Так кто то (Гаусс) же первый сказал, "Математика - царица наук!". И да, понимание того как окружающий Мир можно "положить" на Математику (или наоборот), может вскружить голову.
> Так кто то (Гаусс) же первый сказал, "Математика - царица наук!".Там продоложение есть, которое смысл немного уточняет
Mathematics is the queen of the sciences and number theory is the queen of mathematics.
[Die Mathematik ist die Königin der Wissenschaften und die Zahlentheorie ist die Königin der Mathematik.]
Только у меня Firefox при выборе "View image" вот здесь: http://bellard.org/bpg/gallery1.html браузер секунд 10-15 жуёт одно ядро процессора? Если сабж так требователен до вычислений - то это фейл.
> Только у меня Firefox при выборе "View image" вот здесь: http://bellard.org/bpg/gallery1.html
> браузер секунд 10-15 жуёт одно ядро процессора? Если сабж так требователен
> до вычислений - то это фейл.У меня секунды две-три. Дело в том, что разжимается оно пока Джаваскриптом, который да, жрет ядро. Когда перепишут на C и встроят в браузер, жрать не будет
Что у тебя за процессор? И версия FF?
У меня более, чем на минуту завис FF на мертво. Проц Core 2 Duo 2 GHz, FF 34.0.5. Правда учитывая размер картинки не вижу ничего особо криминального: если вместо одной здоровенной картинки будет рендериться несколько маленьких уже должно быть лучше, а если ещё встроят поддержку по-нормальному в браузер чтобы не мучать JavaScript-вообще, наверно, будет норм. По крайней мере 360p видео в HEVC я кодирую и смотрю нормально.
На древнем AMD Phenom 9650 и ff 33.1 рендерится за доли секунды, при этом даже одно ядро до конца не загружает.
А, на моём ещё более древнем феноме рендерится - вообще: бесконечно...
Может и потому что в IE8(послдений для XP), который ну таки не обязан Белларду ничем,
(не и Opera у меня есть и FF, но кто сказал что там JS обычно включен)
ну да мне как пользователю пофиг - мой вердикт:
- этот формат по кр.мере в JS это негоднота.
(а, в браузеры и тем более все его не встроят).А, патентные нарушения ...их либо не должно быть вовсе,
либо должно быть автору нaсрать - и максимально использовать все оптимизации.
А, так - ни то, ни сё: заведомо - *могло бы быть* лучше или в одном, или в другом.
Core i7-3770k, 16Гб памяти, Windows, Firefox 33.1
~2 секунды: P4-3GHz Prescott с HTT, DDR1 3Gb, FF 34.0.5, FreeBSD 10.1 i386.
> Что у тебя за процессор? И версия FF?core i3 1.8 Ghz, FF33. Отрисовалось так быстро, что не сразу понял, что там этот BFG ))
Так что формат - годнота. Если гугль внедрит - остальные подтянуться и переконвертят свои говноджейпеги.
javascript там на emscripten.
В целом медленнее, но не критично.
$ time for ((f=0;f<100;++f)); do bpgdec -o 0.ppm 005.bpg; donereal 0m7.473s
user 0m6.980s
sys 0m0.494s$ time for ((f=0;f<100;++f)); do pngtopnm 005.png > 0.pnm; done
real 0m6.052s
user 0m3.879s
sys 0m0.529s
Ну так png - известный тормоз
> Ну так png - известный тормозДа вообще-то zlib не такой уж и тормозной. Хотя и не чемпион по скорости.
Опера и Хром моментально декодируют.
Это одно и то же.
У меня настоящая опера 2.16, а не обёртка "опера"..
Тоже довольно резво на старом атлоне X2 посчитало.
> У меня настоящая опера 2.16, а не обёртка "опера"..
> Тоже довольно резво на старом атлоне X2 посчитало.Поправлюсь: 12.16
При плохом зрении блюр не нужен, потому и разницы нет.
> в другом случае пикселизация, (вполне привычно фильтруемая мозгом)андройды среди нас
Сравните фотки одного размера (в байтах).
Странно, у меня за полсекунды-секунду отрендерилось. linux, amd64, ff34.
FreeBSD, FF34, corei7
Даже и не заметил что что-то там грузило. Отобразилось все мгновенно.На самом деле впечатляет. Размер картинки и такое качество. Надеюсь формат сделают стандартом.
> Надеюсь формат сделают стандартом.Надейся. Будешь отстегивать MPEG LA еще больше денег.
Есть несколько проблем, нерешённых с H.265 - например, он любит мылить изображение.Возьмём пример самого Фабриса ( http://bellard.org/bpg/lena.html ):
Первые три картинки очевидно сжимаются сильно лучше, чем JPEG. Но посмотрите на последнюю - JPEG при том же размере сохраняет больше деталей, чем кодек, основанный на H.265. Плечо и спина имеют заметный градиент у JPEG, который практически не виден у H.265 (мыло полное).
Вторая проблема - не понятно насколько хорошо H.265 справляется с векторными изображениями, чистыми градиентами и текстами. JPEG худо бедно тянет всё это, а вот, например, WEBP/VP8 может напрочь убить содержимое вектора при любом уровне сжатия ( https://i.imgur.com/2IklUDz.jpg ).
Третье - насколько лучше lossless, чем у PNG?
Последнее - JS для распаковки это отлично. А скорость? Особенно если на странице сотни preview/картинок, как в online галереях?
Как со скоростью распаковки с сильным уровнем сжатия? У меня часть фоток пережата в WEBP - они декодируются нативным декодером от 0.5 до 2 секунд, в зависимости от степени сжатия и разрешения (8MP-24MP).
>>Первые три картинки очевидно сжимаются сильно лучше, чем JPEGЭто иллюзия. Одинаково они сжимаются. Одинаково паршиво. Только способ маскировки недостаточности битрейта разный: H.265 - пригламуривает блюром и векторными градиентами, а jpeg - оставляет как есть (пикселит). Мозгу всё равно приходится воссоздавать исходную картинку из этого непотребства. jpeg в данном случае "честней" - вот всё что есть, извини, больше не смогу, а H.265 фальшиво пытается "дорисовать" недостающее за меня .
> jpeg в данном случае "честней" - вот всё что есть, извини, больше не смогуЕщё один клинический гуманитарий. JPEG люто артефактит на всех степенях сжатия и не имеет никаких "честных" эффектов. артефактит ~ вносит много искуственных особенностей не свойственных исходному изображению. Ниже верно заметили
> ... Человеческий глаз желает видеть картинку не просто похожей на оригинал, но имеющей сравнимую с ним насыщенность деталями, даже если эти "детали" просто ... сильно искажённые блоки изображения.
Если вам нужно распечатать относительно небольшое изображение на большой формат, то при увеличении вы ставите фильтрацию nearest neighbor?
Если мне нужно распечатать относительно небольшое изображение на большой формат, то я знаю, что в итоге получу халтуру как не изголяйся.
Ну так хочется же красивую картинку получить. И с блуром и градиентами она всяко приятнее выглядит, чем с джипеговскими артефактами. А где нужна точная передача деталей - там в любом случае нужен больший битрейт или вообще lossless.
>>>Первые три картинки очевидно сжимаются сильно лучше, чем JPEG
> Это иллюзия. Одинаково они сжимаются. Одинаково паршиво. Только способ маскировки недостаточности
> битрейта разный: H.265 - пригламуривает блюром и векторными градиентами, а jpeg
> - оставляет как есть (пикселит). Мозгу всё равно приходится воссоздавать исходную
> картинку из этого непотребства. jpeg в данном случае "честней" - вот
> всё что есть, извини, больше не смогу, а H.265 фальшиво пытается
> "дорисовать" недостающее за меня .Мне кажется в кавычках необходимо было написать целое выражение "фальшиво пытается дорисовать".
И все таки не плохо, что мы понемногу продвигаемся в деле понимания как оно там "дорисовывает"!
Так что, респект и уважуха некоторым товарищам. Это все таки интересней и полезней чем писанина на форумах (особенно когда почитаешь некоторые комментарии). Хотя форумы тоже необходимы.
> - оставляет как есть (пикселит).Он не пикселит, он фигово воссоздает градиент, который при недостатке информации получается задpuстанным нечто, с характерным ringing по границам пикселей и нестыковкой блоков. Можно это по границам блоков пытаться подогнать лучше + затереть ringing (с потерей мелких деталей). Чем продвинутые мпеги и занимаются, да и не только они.
>Но посмотрите на последнюю - JPEG при том же размере сохраняет больше деталей, чем кодек, основанный на H.265Это иллюзия. Человеческий глаз желает видеть картинку не просто похожей на оригинал, но имеющей сравнимую с ним насыщенность деталями, даже если эти "детали" просто подмешанный шум или сильно искажённые блоки изображения. Именно для решения этой проблемы в x264 добавляли "psychovisually optimized rate-distortion optimization".
>Вторая проблема - не понятно насколько хорошо H.265 справляется с векторными изображениями, чистыми градиентами и текстами.
x264 отлично справлялся со всем этим, особенно при 10 bit.
Так что главный вопрос в том насколько текущая реализация H.265 догнала x264.
>>Остальные области чуть более отличаются на резких перепадах ахроматической составляющей, но точно так же увидеть разницу без наложения и вычисления разницы невозможно.Понятия не имею что у вас за монитор и очки, но отличия в последней паре фоток вполне видны невооруженным глазом даже на tnt-матрице. BPG ощутимо мылит по сравнению с jpeg-ом. Субъективно это выражается в том, что jpeg-фото выглядит "глубже" и "детальней", оно естественней передает натуру.
>>>Остальные области чуть более отличаются на резких перепадах ахроматической составляющей, но точно так же увидеть разницу без наложения и вычисления разницы невозможно.
> Понятия не имею что у вас за монитор и очки, но отличия
> в последней паре фоток вполне видны невооруженным глазом даже на tnt-матрице.
> BPG ощутимо мылит по сравнению с jpeg-ом. Субъективно это выражается в
> том, что jpeg-фото выглядит "глубже" и "детальней", оно естественней передает натуру.Видимо, у него жуткого качества TN матрица на которую он смотрит под большим углом. Конечно, там всё "одинаково".
// b.
посчитай попиксельную разницу и не пиши херни.[сообщение отредактировано модератором]
[Робко]: а можно, я задам вам три вопроса?
1. Вы пиксели на мониторе глазами рассматриваете или как-то по-другому?
2. Все ли матрицы современных мониторов одинаковы, или есть какие-то отличия?
3. Все ли люди видят одинаково?
Зачем задаёшь далёкие от темы вопросы теор. характера? Тебе же совсем нечем осмысливать на них ответы. Нужно только понять простой практический факт: что на ноль не умножай всё равно получится ноль и не важно чем на этот ноль смотреть. Глупо объяснять свои гуманитарнын загоны какими-то несуществующими "фактическими" различиями посыпая их техническими терминами.
> посчитай попиксельную разницу и не пиши херни.Вообще-то, попиксельная разница как таковая - не больно какая метрика восприятия качества картинки двуногими. Заметность искажений для двуногих сильно зависит от того как именно отличаются от оригинала пикселы и одно и то же в числовом различии отличие может весьма по разному восприниматься двуногими. По этому поводу есть более продвинутые метрики, как минимум PSNR и SSIM. И даже они - весьма синтетические.
> большим углом. Конечно, там всё "одинаково".Хардварный фильтр ringing'а - хреновый монитор :).
> Понятия не имею что у вас за монитор и очки, но отличия в последней паре фоток вполне видны невооруженным глазом даже на tnt-матрице. BPG ощутимо мылит по сравнению с jpeg-ом. Субъективно это выражается в том, что jpeg-фото выглядит "глубже" и "детальней", оно естественней передает натуру.Смотрю через честный восьмибитный (на канал, естественно) IPS. Видеокарта GeForce GTX 650, проприетарные дрова NVIDIA. Артефакты jpeg'а вижу, какой-то особой "глубины" и "детальности" - нет. В данном случае, при таком сжатии предпочтительнее получить некоторое "замыливание", чем "лестницу" контуров и квадраты/пятна артефактов. ИМХО.
> BPG ощутимо мылит по сравнению с jpeg-ом.Гы-гы-гы, это фотка модели, она уже отмыленная в фотожопе.
фотошоп в 1972 году? Оригинально.
у павлинушки ещё и не такие чудеса бывают.
Прикинь, ретушь это называлось! Осветляли лимонным соком, замыливали морды лица через экспозицию при печати.
> BPG ощутимо мылит по сравнению с jpeg-ом. Субъективно это выражается вДа ладно, мылит, взгляните на ресницы.
> том, что jpeg-фото выглядит "глубже" и "детальней", оно естественней передает натуру.Про натуру нечего сказать не могу ;)
>>>Остальные области чуть более отличаются на резких перепадах ахроматической составляющей, но точно так же увидеть разницу без наложения и вычисления разницы невозможно.
> ... выглядит "глубже" и "детальней", оно естественней передает натуру.Где-то я эту песенку про "кристальность и прозрачность звучания" уже слышал. Ах, это немного из другой оперы, но там тоже свои *филы примерно таким же гуманитребством меряются когда "обличают" форматы с потерями.
> Плечи на последних картинках одинаковы с точностью до артефактов jpeg'а которые обычным глазом вообще не заметны.Лупу вам дать?
> как бы запостить в сеть кучу текста в картинках пожатых совершенно неподходящим кодеком
Древний JPEG тянет, а новые супер кодеки, на разработку которых потратили миллионы баксов, вдруг стали "неподходящими".
Плюс, не надо оскорблять. Вы можете текст фотографировать даже на мыльницу (и это часто очень нужно и полезно).
Тексты в FB в виде картинок я никогда не кидал. Уймитесь с оскорблениями.
Почини свой монитор. На последней у JPEGа больше вовсе не деталей изображения, это артефакты сжатия.
В Firefox на Android на странице с Леной BPG отображается горизонтальными полосками, а на превью страницы отображается нормально.
На десктопе всё в порядке.
этот парень - гений :)
Да. Причем совершенно серьезно.
Что гениального в том, чтобы прикрутить HEVC для сжатия изображений? Это уже делали все, кому не лень.
я не про конкретный проект. я про ВСЕ его проекты.
Наконец-то пожатые фотки не корябают глаза мусором.
Хочу такой плагин к Гимпу... :)
> Хочу такой плагин к Гимпу... :)Тут есть http://developer.gimp.org/writing-a-plug-in/1/index.html
Если порнохостеры поддержат, то взлетит.
А-а-а-а-а-а, хороший вышел бенч для проца. 36 секунд декодировал JPEG :)
$ file 1.jpg
1.jpg: JPEG image data, JFIF standard 1.02, aspect ratio, density 100x100, segment length 16, baseline, precision 8, 1920x1200, frames 3$ time bpgenc 1.jpg -o 1.bpg
real 0m35.782s
user 0m35.529s
sys 0m0.234s$ ls -la 1.jpg 1.bpg
-rw-r--r-- 1 root root 200921 дек 6 13:50 1.bpg
-rw-r----- 1 pavel pavel 356036 дек 6 13:46 1.jpg
Картинка с видом Рима, ваше супер - JPG: 1.2 мега против BPG: 278K, профит 856 килобаб
[сообщение отредактировано модератором]
> $ time bpgenc 1.jpg -o 1.bpg
> $
>$ ls -la 1.jpg 1.bpg
>-rw-r--r-- 1 root root 200921 дек 6 13:50 1.bpg
> rootЕщё и систему взломал?
> А-а-а-а-а-а, хороший вышел бенч для проца. 36 секунд декодировал JPEG :)У тебя что, нет libjpeg-turbo в системе? Или ты 16384х16384 пиксела расжимал? Или это Pi был? :)
> (забавно, у меня Хром не декодирует BPG-картину, только Опера 26 и Фокс)
Еще забавнее то что у оперы и хрома по идее один и тот же движок. Вот как проприерасы так умудряются? :)
На последней у JPEG синий хвост выглядит чётче и при первом взгляде картинка кажется с более высоким разрешением на JPEG. Если затем рассматривать долго, то оба не очень. Лучше всё в PNG сжимать.Короче, смысла нет им кодировать большие изображения, а вот если превью картинки, на те же порнушные сайты, чтобы быстрее грузились, когда нужно получить общие впечатления - тогда смысл есть )
> ))))
для веба - не пойдёт. просто из-за проблем с совместимостью.
с другой стороны, свет не сошёлся клином на вебе, может где-то и найдёт применение.
> бросается в глазаДа, что за дамочка?
Лена какая-то
Лена Седерберг
Не взлетит. Фабрис предложил практически полный аналог того, что до него уже сделали Google со своим WebP. У Google больше возможностей влиять на продвижение своего формата, да и лицензионная чистота формата - это большой плюс. Однако даже у WebP пока весьма туманные перспективы.
Где он был во времена модемов на 56К и меньше?
и 486 компов?
> и 486 компов?интересно насколько быстро на таком железе картинки бы отрисовывались
Ну если декодировать жабаскриптом в ff... Мегабайтах так на 32-х оперативки... Я думаю они отрисовывались бы вечно. При условии, что места в свопе бы хватило, иначе -ENOMEM со всеми вытекающими.
> бы хватило, иначе -ENOMEM со всеми вытекающими.Оверкоммит и OOM killer появились далеко не вчера, так что мог бы быть и SIGSEGV или SIGKILL.
О! Какие вы интересные слова знаете. Расскажите ещё что-нибудь.
Насколько этот формат онально огорожен патентами? Буква "H" в названии "H.265", говорит нам, что огорожен по самые уши.
> создавший самую быструю формулу вычисления числа Пиза сколько секунд полностью вичисляет число ПИ? :-)
>> создавший самую быструю формулу вычисления числа Пи
> за сколько секунд полностью вичисляет число ПИ? :-)Ровно столько, сколько потребуется Вам для проверки правильности вычисления ;)
Хорошего настроения!
Просто любопытно: это исключительно для изображений фотографического типа? Каковы размеры рисуноных (палитры 8, 16, 64, 256 цветов) картинок? Просто любопытно сколько будет сотен байт 4-цветная блёклая картинка под фон с размерами от 2048*1536. Также интересны способности к масштаббированию, в т.ч. непропорциональному - полезут ли деформации и муары. Я не особо разбираюсь в графике, простите, если глупость спросил. Интересно применение этого формата на веб-страницах во всех привычных вариантах.
масштабирование производится до этапа кодирования, а вообще из новости: от 8 до 14 бит на канал, с альфа-каналом получаются как минимум все те же 32-битные картинки
то есть палитра состоит из 16 миллионов цветов и до 4,398046511×10¹²
нет никакого глубокого смысла делать подобные преобразования на палитровых изображениях — кодеки всё равно не оперируют палитрами.
> патентные ограничения можно обойти используя предоставляемые современным оборудованием функции аппаратного ускорения кодирования/декодирования HEVC.Обойти их так могут распространители программ для такого оборудования, а Столлман всё равно не одобрит.
>> патентные ограничения можно обойти используя предоставляемые современным оборудованием функции аппаратного ускорения кодирования/декодирования HEVC.
> Обойти их так могут распространители программ для такого оборудования, а Столлман всё
> равно не одобрит.вот разрешат выдавать патенты на API, то и эта хитрость не спасет
Жаль, что javascript-декодер сыроват. Далеко не все сконверченные картинки отображает.
>Жаль, что javascript-декодер сыроват. Далеко не все сконверченные картинки отображает.Дико извиняюсь, это у верстальщика руки из жопы.
Как обычно - чтобы сэкономить 200Кб на картинках, нужно потратить 2Мб траффика и 200Мб памяти на JS-обертку, и переждать очередные 100% времени процессорного ядра...
шозачушь?
> Как обычно - чтобы сэкономить 200Кб на картинках, нужно потратить 2Мб траффика
> и 200Мб памяти на JS-обертку, и переждать очередные 100% времени процессорного
> ядра...squid, не слышали? Под винду handycache.
Фабрис Беллар - настоящий учёный!Сделал и выложил в общий доступ для народов Земли под свободной лицензией, а не побежал корпорастам продаваться. Мужик!
P.S. И баба у него классная! )
> Фабрис Беллар - настоящий учёный!
> Сделал и выложил в общий доступ для народов Земли под свободной лицензией,
> а не побежал корпорастам продаваться. Мужик!
> P.S. И баба у него классная! )Да, красава )) У него на сайте ещё и проект 4G станции из компа есть.
А как её зовут? Не нашёл что-то. Или это про Лену?
Смысл сравнивать с JPG? Я недавно тестировал разные форматы, сейчас лидер (с большим отрывом PNG). Особенно для grayscale.Будет ли BNG лучше PNG?
> Смысл сравнивать с JPG? Я недавно тестировал разные форматы, сейчас лидер (с
> большим отрывом PNG). Особенно для grayscale.
> Будет ли BNG лучше PNG?Уроки учи!
> Смысл сравнивать с JPG? Я недавно тестировал разные форматы, сейчас лидер (с
> большим отрывом PNG).Вам вообще пофиг на принципиальную разницу между lossy и lossless?
...бла-бла-бла лууддизм, луддизм, бла...
А автор - молодец.