Спустя пять лет с момента формирования ветки 2.x представлен релиз libjpeg-turbo 3.0.0, высокопроизводительной библиотеки для кодирования и декодирования изображений в формате JPEG. Libjpeg-turbo представляет собой совместимый на уровне API/ABI форк классической библиотеки libjpeg, нацеленный на обеспечение максимальной скорости кодирования и декодирования. Кроме стандартного libjpeg API библиотека предоставляет собственный TurboJPEG API и ряд расширений с моделями представления цвета, дающих возможность сжимать изображения в 32-разрядные пиксельные буферы (RGBX, XBGR) или декодировать из них. Код распространяется под тремя BSD-подобными лицензиями IJG, модифицированной BSD и zlib, бинарные сборки подготовлены для Linux (rpm, deb), macOS и Windows...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=59378
Арифметическое кодирование и 12 бит никто не умеет просматривать. Даже FF, который использует оную библиотеку (она собирается статически), отбоярился от арифметического кодирования. Lossless тоже никто не умеет.Но оптимизации - это хорошо. Новые эти ваши алгоритмы ну никуда не годятся по скорости. Один JPEG XL вроде обещает пережатие старого JPEG без потери кач-ва и этим немного скрашивает общий зоопарк, который развели за последнее время.
В начале функционал появляется в библиотеке и затем имеет шанс появиться в прикладном ПО.
Откуда берутся такие мнения? Этому где-то специально учат?Когда метр был длиннее а килограмм тяжелее, из ПО выносили части кода в библиотеки, что бы была возможность их переиспользовать.
Вот сейчас и имеем "средств хватает на 8-10 часов работы в месяц и в проекте наблюдается перерасход". Потому что никакой libreoffice или firefox не сказали автору "нам надо вот такую фичу". Они ждут, пока она сама-собой появится и протестируется.
У тебя опять затяжной приступ? Или уже наклюкался с утра.
Иди собирай скорее пакетик, пока автор не сменил лицензию на проприетарь, как вон там пугают в #4.
А что не так написано? Ну да, проекты, которые активно используют сию либу должны были быть на месте автора. Это их код должен был быть вынесен в библиотеку. Но раз так сложилось, что они просто используют, могли бы профинансировать развитие. Либо просто поддерживать донатом и продолжать ждать, когда либа улучшится. Либо заказать конкретную фичу.
> А что не так написано? Ну да, проекты, которые активно используют сию
> либу должны были быть на месте автора. Это их код должен
> был быть вынесен в библиотеку. Но раз так сложилось, что они
> просто используют, могли бы профинансировать развитие. Либо просто поддерживать донатом
> и продолжать ждать, когда либа улучшится. Либо заказать конкретную фичу.Это так не работает. Сложность современного софта на таком уровне, что разрабатывать с нуля все компоненты могут позволить себе не только лишь все (и получится всё равно плохо). А вынос кода проектов в библиотеку, это всё осталось где-то в 90х, сегодня никому не интересны твои кривые ошмётки. Если чего-то нет в проверенной надёжной либе, используемой всеми, то значит, этого нет, и это никому не интересно. Тебе не больше всех надо все проблемы на свою голову привлекать.
> А вынос кода проектов в библиотеку, это всё осталось где-то в 90х,
> сегодня никому не интересны твои кривые ошмётки.Покажи хоть один свой проект, мне интересны "ошмётки". Ты же не просто так потрындеть о прочитанном на сайтике эксперта, в перерывах меж сборкой пакетиков? У тебя есть свой личный опыт, верно?
Он из секты верующих, что для написания тривиального кода требуется 100500 человеко-лет. На том основании у них строится крупный бизнес по опакечиванию написанного одним человеком за пару вечеров.
Вот именно. Разрабы софта слишком ленивы, чтобы городить малонужный функционал самим. А вот переиспользовать сделанный другими - очень любят. Поэтому тезис про появления фич в либах - очень верный. Сначала пусть кто-то реализует, а мы потом заюзаем.
Хорошо что Гугл не читает местных экспертов по халявному реюзу "малонужного" и "велосипедит" Clang, libcxx и т.д. Потом, правда, те же самые эксперты начинают плакать, что Большой Брат одаряет их не халяльной халявой, а неким зондом, и бежать некуда.
А где зонд в clang? Отличный компилятор же.
Потому и отличный, что Google делает инструмент для себя, сами же и используют в своём глобальном проекте. В Chrome полно зондов, как утверждают свидетели. Ну а такими темпами, если конкурентному браузеру наплевать на используемые библиотеки, альтернатив Хрому может и не остаться.
А как проверить? Вроде, в gwenview показывалось норм? Тема конечно странная, жпег убожество даже на максимальном качестве (это уже размер лосслесс), а тут ему какие-то расширенные цвета пихают. Оно конечно приятно, что поменьше искажений цвета с нормального исходника, но возьмите вы уже лосслесс, а от сабжа пора отучать обывателей. Тот же Jpeg2000 для лосси получше будет, ещё бы он не был таким мутным и поддерживался нормально.
> жпег убожество даже на максимальном качествеБыл у меня коллега-аудиофил, примерно так же выражался. Так заколебал, что мы ему слепой тест устроили. После этого дорогие кабеля из правильной меди и усилки-колонки не таскал на работу )))
Ну, с картинкой и кодеками можно ведь сравнить объективно, глаза всё же не уши. Когда детали исчезают из картины, или замещаются какими-то случайными глитчами, это сразу видно. С искажениями цветов посложнее, но легко видно, если переключать туда-сюда 2 кадра.
> Ну, с картинкой и кодеками можно ведь сравнить объективно, глаза всё же
> не уши. Когда детали исчезают из картины, или замещаются какими-то случайными
> глитчами, это сразу видно. С искажениями цветов посложнее, но легко видно,
> если переключать туда-сюда 2 кадра.В дикой природе у 99,99 процентов людей нет компаратора и им JPEG в кач-ве на 95 заходит безо всяких проблем.
Плохо заходит на самом деле, многие, я уверен проклинают каждого, кто придумал так закодировать. Это огромные раздутые файлы с видимыми артефактами. На качестве 100 ещё придётся порассматривать где косяки, а тут всё видно.
> Плохо заходит на самом деле, многие, я уверен проклинают каждого, кто придумал
> так закодировать. Это огромные раздутые файлы с видимыми артефактами. На качестве
> 100 ещё придётся порассматривать где косяки, а тут всё видно.Какие там видимые артефакты, что ты рассказываешь? Или ты градиенты при кач-ве в 70 жал?
Края, детали, амплификация дефектов. Всё это видно. Но зависит от контента, какой-нибудь Ипхоне уже лажу гонит и там как-то неважно.
Края, детали? О чём вы говорите? Если не пережимать JPEG по пять раз, то в дикой природе даже на чертежах зажатых в 95 и 4:4:4 ничего невооруженный глаз не заметит. Размер можно уменьшать, увеличивая время обработки, но насколько это актуально? Что 500 кБ, что 250 будут доставляться несоизмеримо меньше в сравнении со временем установки соединения, всеми этими вашими TLS-хендшейками и, возросшим на порядок временем CPU, необходимым для декомпрессии.
А если 50 мегабайт? Это типичный жпег в дикой природе. В той же дикой природе исходник рандомной рисованной картинки как правило несколько гигабайт, поэтому ресайз имеет место быть. А вот тут уже амплификация дефектов. Пойди потом принт из этого сделай и распечатай. Ну а чертежи это не тот контент, который проблемно кодировать.
> В той же дикой природе исходник рандомной рисованной картинки как правило несколько гигабайтВ raw уже рисуют?
> А вот тут уже амплификация дефектов.
Да ты русским языком поясни, что это такое.
> Пойди потом принт из этого сделай и распечатай.Судя по тому, что за плакаты я по дороге вижу, печатают их далеко не в двухгигабайтного оригинала.
> Ну а чертежи это не тот контент, который проблемно кодировать.
Уж сколько копий сломали на эту тему, а у него "не проблема". Дорогой, это как-раз и есть тот контент, под который JPEG подходит менее всего. Но и там не так проблема велика, как о ней рассказывают неосиляторы параметров кодирования.
> амплификация дефектовЧего, простите?
> Ипхоне
Ипхоне разве всё ещё в JPG снимает?
>> амплификация дефектов
> Чего, простите?Готов поспорить, что тот же самый эксперт в других местах пишет "усиление записи в BtrFS".
В .HEIC
Но если не поставишь галочку выгружать как есть ... оно перекодировать будет в .jpg причём на самом телефоне :-)
Может и уберут с каким нить апдейтом, но пока - "софт которым может пользоваться любой дурак"(С) и все до последнего яблофага :-D
И слева нас рать и справа нас рать ... что у рекламного котика ушки не такие розовые ...
Я бы вообще запретил в вебе картинки не пожатые в качестве 10 и ниже. Захотелось качества - ткни в картинку, а там картинка в raw формате на пару гигабайт.
Ты, скорее всего, художник (ну или приближённый к ним), тебя, как музыканта дисгармония, бесит мыло (или ещё что там) на картинке. А меня так нет. Так что у каждого свои требования.
> в raw формате на пару гигабайт.Это что за зверь уже снимает в raw на пару гигабайт? У Джеймса Уэбба меньше )))
То ли дело 2+мегабайтный пнг на сайте РЖД!
Зато красиво. Это искусство, понимать надо! Кстати, в плане эффективности кодирования в лосслесс, палетированный пнг ещё никто не превзошёл.
> нет компаратора и им JPEG в кач-ве на 95 заходитЗаходит до тех пока пока не надо обработать картинку и ещё раз передать. Тогда уже 0.95 превращается в 0.95 в квадрате, а то и в кубе.
> Заходит до тех пока пока не надо обработать картинку и ещё раз передать. Тогда уже 0.95 превращается в 0.95 в квадрате, а то и в кубе.Зачем вы редактируете JPEG? Редактируйте из исходного формата или, как вариант, делайте с учётом ухудшающегося кач-ва, если вам нужно получить максимального кач-ва.
В любой соцсети, в любом мессенджере приходит Jpeg, там нет исходного формата. Поэтому 0.95 подойдёт большинству, но не всем.
Насчёт любой сети не скажу, но контактик вроде как умеет отправлять непожатые файлы. Мессенджеры и подавно.
Разве инста не в webp раздаёт? На главной Wikipedia тоже webp. Ты не смотри, что расширение jpg там, по факту это webp. Чтобы убедиться в этом, открой саму картинку в отдельной вкладке. FF пишет в заголовке настоящий тип файла. Дурацкая идея, но так сейчас 90 доставляют картинки (из тех, кто поддерживает другие форматы). Для AVIF тоже отдельно костыль пришлось клепать аналогичный.
> А как проверить?GIMP открой и закодируй в нём с соответствующим арифметическим кодированием (в расширенных диалога кодирования). Расскажешь, кто из софта умеет его открывать.
Dolphin, Gwenview, Okular, Blender, ida, Chromium, GIMP, ImageMagick поддерживают. В Krita в единственной из установленных программ не открывается нормально. Ещё ffmpeg и cjxl не поддерживают. И Godot.
> Dolphin, Gwenview, Okular, Blender, ida, Chromium, GIMP, ImageMagick поддерживают. В Krita
> в единственной из установленных программ не открывается нормально. Ещё ffmpeg и
> cjxl не поддерживают. И Godot.Gnome тоже не умеет.
Gnome не нужен.
> Gnome не нужен.Это ты корпоративным расскажи. Они кеды просто терпеть не могут.
А чего ты за них шестеришь?
> А чего ты за них шестеришь?Называть козла козлом - это просто констатация факта. А вот ты впрягся за них по своему скудоумию.
12 бит — это серые изображения, их умеют просматривать буквально все.
> 12 бит — это серые изображения, их умеют просматривать буквально все.Задай себе вопрос, зачем же его запилили 30 лет спустя, если его умеют просматривать буквально все?
>Арифметическое кодирование и 12 бит никто не умеет просматривать.Алгоритм ~50 лет уже есть, но никто так и не научился его использовать, и даже общую либу никто не юзает.
Palemoon умеет jpegxl.
https://jpegxl.info/art/2021-04_jon.html - всё это классно, но тормозноватее миниму раз в два. И это ещё лайтовый вариант. Все эти AVIF вообще на порядок медленнее. Нафига козе бОян такой?
Меньше артефактов при меньшем размере, а отличия в скорости декодирования не самые фатальные на самом деле -- вполне сравнимо с пнг. Про фичи можно не вспоминать, это понятно.
> Меньше артефактов при меньшем размере, а отличия в скорости декодирования не самые
> фатальные на самом деле -- вполне сравнимо с пнг. Про фичи
> можно не вспоминать, это понятно.Порядок - это 10 раз, два порядка - 100. Если не веришь, то можешь бенчмарки посмотреть. Если тебе одинаково ехать со скоростью 90 км в час и на 900 км в час, то для многих это имеет решающее значение.
А, я про jxl, если что, avif понятное дело убожество про которое надо поскорее забыть.
> А, я про jxl, если что, avif понятное дело убожество про которое
> надо поскорее забыть.Всё это тоже классно, но AVIF уже пропихнули, куда надо. А JPEG XL, вероятно, будет игрушкой для маргинальной части населения.
Больше, чем webp, он не займёт. Такое же днище.
Хотя, не такое же, хуже, намного хуже. И у webp есть лосслесс. Но область одна.
Лосслесс webp и avif это мыльное мыльцо. Которое в движении не видно, поскольку это видео-кодеки, а в статическом кадре все артефакты прекрасно видно.
Я бы как-то остерёгся на это завязываться - в любой момент может скатиться в проприетарное лицензирование. С другой стороны, если пользовать только совместимый с libjpeg api и возможности, why not.
Автор libjpeg-turbo пишет https://libjpeg-turbo.org/About/Jpeg-9
что libjpeg api непонятно зачем сменили на 9-ю версию, и он её поддерживать не планирует.
Every version of the IJG's software from v7 onward has broken backward ABI compatibility with previous releases, and in fact, it was not necessary to do so in the case of libjpeg v9.
...
It's more that they are unproven, and thus we feel that a stable, de facto standard JPEG codec library is not the right place to introduce them.
Эм, что? Open source же. Форкните себе последнюю версию и наслаждайтесь. Последующие версии да, могут иметь какую-то другую лицензию, но та, ваша, будет всегда законна к использованию.
форкнут, как только этот крохобор всем надоест
Да не, аффтар всё правильно делает - корпорасты заплатят. Вот аффтар нгинха не даст соврать.
Но завязывать на это свои проекты я бы таки поостерёгся :)
А на кой им сразу 3 лицензии. Это когда двух оказалось мало?
> благодаря использованию инструкций SIMD (MMX, SSE2, NEON, AltiVec VMX) на архитектурах x86, x86-64, PowerPC и ARMОзначает ли это, что на есп с его экстенсой ускорения ждать не стоит и вообще не факт что в озу влезет
Турбо?
https://media.discordapp.net/attachments/1031663193489150003...
Когда в микротик добавят?
8-10 часов в месяц? влезть в долги? он там рабов покупает что ли чтобы работу вести?
Я так эту новость понимаю:1) Донатов по данному проекту хватало в среднем на то, чтоб оплатить один рабочий день в месяц с его уровнем дохода по другим проектам.
2) Проект ему был интересен настолько, что приходилось забивать на другие проекты приносящие деньги. В итоге денег в какой-то момент вдруг не стало, а кушать хочется...
3) Делает всё сам. Тем кто приходит с готовыми патчами отказывает в их приёме, мотивируя тем, что могли бы в начале за приём патчей задонатить (на их проверку ведь ему тоже нужно тратить время, даже на переписку). В итоге, в проект приходит всё меньше людей...
А те, кто мог бы реально заплатить, видимо рассуждают так: "это ж opensource, зачем платить, раз можно просто так скачать, я ж не лох какой (иначе откуда бы у меня были деньги? копейка руб бережет и т.п.); да и если скорости jpeg-а не будет хватать, то нынче рядом с аппаратными видекодеками лепят поддержку и JPEG".
3-й пункт - вряд ли. Скорее, патчи не предлагают, только требуют от него доработок.