Как понимаю у тебя LORnix дома стоит?
Тот что после загрузки, сразу лор на фуллскрин, и никакой дополнительной информации из системы? :)
Ну а по сабжу - скрипт пока спит, я проспорил месяц своего фото на лоре..

Я не могу понять, почему lossy вы называете «фишкой jpeg2k». А позиция относительно оверкила jpeg2000 в общем мне ясна.

где?)

да каким образом он заменит то из чего собсно и состоит? И левых либ никто никому не впаривает, а предлагают патч к уже существующим

Такая стратегия оказалась неэффективной, надо чтобы после патча либы и расшитрения картинок назывались иначе, с добавкой «а», тогда будет легче впарить всё это в дистрибутивы - хотели и фич добавить и не увеличивать размер системных либ, не получилось.

несовместима со старыми декодерами

На DVD-проигрывателе не посмотришь, на плеере не посмотришь, на мобиле не посмотришь. Что да здравствует?

Я не могу понять, почему lossy вы называете «фишкой jpeg2k»

Это вы назвали его фишкой, а не я.

Это вы назвали его фишкой, а не я.

Я перечислял то, чего не умеет png.

В PNG lossy не нужно.

Я перечислял то, чего не умеет png.

А я сказал, что все перечисленное не помешало умереть jpeg2k.

Что «где» ?

При чем тут прореживание?

Спор за аватарку?

Путаница с понятиями. Прореживанием именуется не выброс пикселей. Цветоразностные компоненты обрабатываются блочно. В блоке, допустим, 4х4 происходит усреднение цвета: все пиксели получают усредненное значение. Вот и думайте где выплывают артефакты: на фото где блоки однородны и внутри блока цвета мало отличаются и соотвественно среднее значение не уплывет или в блоке где часть пикселей темные(текст), а часть светлые(фон).

С знакомым спорил, кон был фоточка на лоре. Я не думал что я проиграю.

В PNG lossy не нужно.

Никто и не спорит. Просто один товарищ заметил, что

жпэг2k потому и не взлетел - ту нишу в которую он метил уже занял PNG

И мне стало интересно, как же это png затмил собой всё-умею-всё-могу jpeg2000.

Точнее при раскодировании блоки пикселей будут получать среднее посчитаное при кодировании.

Проявление «мыла» также поддается логике. Почитайте вики и все статьи-ссылки про YCbCr и ДКП ради интереса.

Тем, что уже был и не имел проблем с законным использованием, вероятно.

+++ Кстати, «всё умею» геморройно поддерживать.

jpeg также поддерживает 4:4:4, так что смотрите настройка вашего кодера

В блоке, допустим, 4х4 происходит усреднение цвета:

Я изучал сжатие YUV(YCbCr)-слоёв в кодеке Theora.
Что могу сказать ... там усреднение «цветности», скорее.
А «яркость» не усредняется.
Это я изучал 4:2:2-субдискретизацию.

См. википедию: http://en.wikipedia.org/wiki/Chroma_subsampling :

"Chroma subsampling is the practice of encoding images by
 implementing less resolution for chroma information than for
 luma information, taking advantage of the human visual system's
 lower acuity for color differences than for luminance."

Но есть 4:4:4-субдискретизация, как Вам уже отметили в этом треде.
Она может быть выполнена в разных цветовых пространствах:

4:4:4 Y'CbCr
4:4:4 R'G'B' (no subsampling)

Нахрен не нужна там анимация.

как же это png затмил собой всё-умею-всё-могу jpeg2000.

да очень просто - универсальное всегда будет проигрывать специальному

Читайте источник цитаты. В начале разработчики Mozilla прямо утверждали, что не будут поддерживать WebP, пока не будут добавлены некоторые возможности. И обещали пересмотреть решение как только они появятся. Возможности появились, но результатом пересмотра был тот же WONTFIX (если кто‐то вообще заморачивался: новая отмазка отличалась невнятностью). Никаких чётких заявлений вроде «мы добавим (не пересмотрим!) WebP, когда …» не было. Более того, чётких заявлений вроде «результат пересмотра обусловлен …», где … — существующая на данный момент проблема, я тоже не увидел.

Мозилловцы в конце концов сказали, что этот WONTFIX - флаг не окончательный, и что ситуация может и измениться. Хотя они там прямо признают, что здорово обожглись на WebM и теперь к инициативам гугла насчет новых форматов относятся с большим недоверием.

фотки на зеркалке сохраняются в jpeg

Зачем тебе зеркалка, если ты не осилил RAW? Купи мыльницу за два рубля.

К сожалению, новая версия обратно несовместима со старыми декодерами формата, так что придётся обновить и их.

срочно переводить на новый формат. кто не обновился тот ссзб.

Я в курсе. Не понимаю как это соотносится с постом на который вы отвечали.

А «яркость» не усредняется.

Я про яркость и не писал. Как это работает все я в курсе. Год назад в магистратуре в качестве НИРС давали JPEG частично переизобретать. Там и с влиянием отсева после ДКП ознакомился и с эффектами прореживания компонент Cb и Cr.

А я кажется понял. Пост на который вы ответили ввел вас в заблуждение, прочитайте все мои комменты.

Кстати, официальный JPEG тоже собираются расширять до JPEG-HDR, но только обязательно хотят сохранить обратную совместимость. И подход Independent JPEG Group они явно не одобряют:

http://encode.ru/threads/1629-Quo-Vadis-JPEG-ISO-Work-Starts

http://encode.ru/threads/1598-Quo-Vadis-JPEG-Another-update

I should also say that Guido Vollbeding (one and only member of IJG) seems to follow a different route and tries to establish a not-backwards compatible codec for HDR or lossless compression. Why that is a good idea (that is, to loose backwards compatibility, and *not* picking one of the existing standards in this area, e.g. JPEG LS or so) is beyond me. After all, there are already more than enough lossless/HDR image formats to pick from, and I don't see the need for another (non-compatible) one. But judge yourself...

Мне понравилось, что ты сравнивал png с lossy режимом jpeg2000, очень показательно.

Как тебе такие результаты?

[dunkaist@ddesk spitfire]$ ls -o
total 1020
-rw-r--r-- 1 dunkaist 177702 Jan 16 13:06 out1.webp
-rw-r--r-- 1 dunkaist 313238 Jan 16 12:58 out3.tiff
-rw------- 1 dunkaist 548114 Jan  5 16:51 spitfire_by_cryshl-d4q8czb.png

Причём,

[dunkaist@ddesk spitfire]$ dwebp out1.webp -pam -o a.pam
Decoded out1.webp. Dimensions: 4966 x 5615 (with alpha). Now saving...
Saved file a.pam
[dunkaist@ddesk spitfire]$ gm convert out3.tiff b.pam
[dunkaist@ddesk spitfire]$ gm convert sp*.png c.pam
[dunkaist@ddesk spitfire]$ cmp a.pam b.pam
[dunkaist@ddesk spitfire]$ cmp b.pam c.pam
[dunkaist@ddesk spitfire]$

Мне понравилось, что ты сравнивал png с lossy режимом jpeg2000, очень показательно.

а в lossless кстате даже немножко меньше весит чем с 80% потерей качества

хотя похоже на >50% lossy алгоритмы JPEG2000 просто не катят на таких картинках

Как тебе такие результаты?

Sorry could not be opened (тифка в одном только гимпе открывается)

/А вообще то я нашел в чем JPEG2000 силен - растровые изображения с альфой и без (типа таких), даже в фотках и рисованных пикчах - разница с jpeg мизерная, а при одинаковом качестве у jpeg размер меньше + поддержка в приложениях лучше

Даже не знаю как они собираются совместимость сохранять. У кодера/декодера один набор операций. Если вводить какую-либо операцию в кодер появится либо новая сущность которая при декодировании будет приводить все к виду необходимому декодеру jpeg существующему, либо расширять набор операций декодера.

яблочный TIFF, который впринципе мог бы вообще заменить PNG, но выходной размер у него намного больше

TIFF сжатый алгоритмом Lempel-Ziv & Welch меньше несжатого PNG и ненамного больше сжатого.

Даже не знаю как они собираются совместимость сохранять.

Типичный JPEG сейчас - это 24 бита в формате R8:G8:B8. Они хотят добиться лучшей точности, допустим R10:G10:B10 и говорят, давайте закодируем его в виде двух частей - R8:G8:B8 в старом формате, а оставшиеся R2:G2:B2 сохраним в дополнительном блоке. То есть старые программы хотя бы увидят R8:G8:B8, это и будет обратная совместимость.

Чем-то напоминает подход APNG, только в данном случае инициатива исходит от самого Joint Photographic Experts Group, поэтому шансы на признание гораздо выше. Не исключено что производителям фотокамер эта идея может понравиться.

Ну и что? Старый плеер ни flac не прочитает, ни png. Он устарелый.

Модеры не поняли иронии, заложенной в изначальную версию заголовка и переименовали новость

Двухлетний Cowon читает FLAC. Насчёт поддержки PNG не уверен, но вроде тоже. Будет ли производитель выпускать новые прошивки под такие — хз.

К сожалению, новая версия обратно несовместима со старыми декодерами формата, так что придётся обновить и их.

Оригинал

Add cjpeg -rgb1 option to create an RGB JPEG file, and insert a simple reversible color transform into the processing which significantly improves the compression.
The recommended command for lossless coding of RGB images is now cjpeg -rgb1 -block 1 -arithmetic.
As said, this option improves the compression significantly, but the files are not compatible with JPEG decoders prior to IJG v9 due to the included color transform.

Так бы сразу и написали, что «несовместимость» касается только Lossless-JPEG-файлов, полученных при использовании опции "-rgb1", нововведенной в libjpeg 9.

JPEG рассчитан для эффективного сжатия градиентов (читай, фотографий реального мира, где резкие переходы между тонами происходят редко). PNG рассчитан для сжатия штучной графики (где есть чёткая граница перехода — *этот пиксель чёрный, а следующий уже сразу белый*). Именно поэтому PNG используется для графики, в web, где JPEG даёт сильный шум (артефакты) именно на резких переходах цветов. А для фотографий JPEG наоборот, более эффективный, а PNG сравнительно очень слабо сжимает.

Чушь. Эти артефакты появляются при DCT

Так бы сразу и написали, что «несовместимость» касается только Lossless-JPEG-файлов, полученных при использовании опции "-rgb1", нововведенной в libjpeg 9.

Если допустим браузер наткнется на такой «новый» JPEG, он его покажет?

Попробуй разложи картинку в Y Cb Cr, прореди и собери обратно. Без DCT. При DCT еще и замыливание вылезет из-за обрезания спектра, это схоже с воздействием НЧ фильтра на обычный временной сигнал. Извините, вы вопросом занимались или так начитались?

Интересная информация, благодарю за разъяснения. Как я понял подвижек в области качество/степень сжатия не получится существенных.

webp не нужен

К сожалению, новая версия обратно несовместима со старыми декодерами формата

Мир праху твоему