LINUX.ORG.RU

Релиз libjpeg-turbo 1.0.0

 ,


0

1

libjpeg-turbo - альтернативная IJG библиотека для чтения, записи и обработки изображений стандарта JPEG, использующая MMX и SIMD для оптимизации скорости на платформах x86 и x86-64; библиотека совместима по API и ABI с стандартной libjpeg 6b и может быть установлена вместо обычной дистрибутивной libjpeg для получения 50% и более выигрыша в производительности обработки JPEG изображений.

Библиотека поставляется под GPL-совместимой лицензией wxwidgets и была адаптирована Fedora для включения в Fedora 14 в качестве системной библиотеки libjpeg

Для желающих попробовать доступны как исходники, так и бинарные пакеты для linux x86 и x86-64 в .deb , .rpm , а также версии для MacOSX и MS Windows, скачать можно тут

>>> сайт проекта

★★★★★

Проверено: JB ()

мои тесты производительности jpeg-turbo 0.0.93 тут - http://www.linux.org.ru/jump-message.jsp?msgid=5003577&cid=5005471

библиотека как замена libjpeg6b полностью стабильна и работает без глюков, проблемы со стабильностью могут быть на системах где jpeg6b уже не является стандартом и будет смешиваться jpeg8 и jpeg6

Sylvia ★★★★★
() автор топика

Да, в Slackware-current с ней не поработаешь.

Тот же gwenview сегфолтится с

gwenview(11979) Gwenview::JPEGErrorManager::errorExitCallBack: Wrong JPEG library version: library is 62, caller expects 80 
Segmentation fault

some-body ★★
()
Ответ на: комментарий от boo32

вот в арче я не понимаю зачем оно, bleeding edge, давно перешел на jpeg8 , даже если и поставить 6b, это все равно нужно пересобирать системные пакеты, хоть и libjpeg реже используется напрямую в отличие от libpng, но как минимум нужно пересобирать gtk loader и qt imageloader, Firefox использует обычно свой набор библиотек для графики (называется, как бы вы думали? libpr0n ) и хоть ему и можно указать --with-system-jpeg при сборке, он не очень счастлив получить заголовки от jpeg6, исправляется тривиально, но все равно требует вмешательства

Sylvia ★★★★★
() автор топика

хорошая новость. Я уже думал что оптимизация окончательно вышла из моды

irq
()
Ответ на: комментарий от irq

оптимизация никогда не выходила из моды. а вы, видимо, про антипаттерн проектирования «преждевременная оптимизация».

boo32
()

Ждём ебилдов. Кстати, а под Гентой это работает?

Lighting ★★★★★
()
Ответ на: комментарий от Sylvia

>Firefox использует обычно свой набор библиотек для графики

ага, а новый «флагман» «реактивный гуглохром ©» тянет за собой жпег6

registrant ★★★★★
()

Актуально для просмотра 10-ти мегапиксельных фоток с цифромыльниц :)

Evtomax
()
Ответ на: комментарий от avol

А как предполагается подменять? Просто скопировать файлы (или сделать линки) из /opt/libjpeg-turbo в /usr ? Или есть более цивильный способ?

ifred
()
Ответ на: комментарий от ifred

можно сделать пакет для вашего дистра.

uju ★★
()
Ответ на: комментарий от zenden

наверно из-за лицензий или из-за совместимости с GCC

wingrime
()

поглядим в новой федорке, ждем веселостей

mikhalich ★★
()
Ответ на: комментарий от ifred

В readme пишут:

If a Unix application is dynamically linked with libjpeg, then you can replace libjpeg with libjpeg-turbo at run time by manipulating the LD_LIBRARY_PATH.

export LD_LIBRARY_PATH=/opt/libjpeg-turbo/{lib}:$LD_LIBRARY_PATH

NOTE: {lib} can be lib, lib32, lib64, or lib/64, depending on the O/S and architecture.

System administrators can also replace the libjpeg sym links in /usr/{lib} with links to the libjpeg dynamic library located in /opt/libjpeg-turbo/{lib}. This will effectively accelerate every dynamically linked libjpeg application on the system.

avol
()
Ответ на: комментарий от ifred

проще всего кинуть
libjpeg.so.62.0.0 в /usr/local/lib (или lib64)
и сделать ldconfig

/usr/local/lib(64) обычно имеет приоритет над /usr/lib(64)

Sylvia ★★★★★
() автор топика

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

timur_dav ☆☆☆☆☆
()

Кокраз ковырял вчера libjpeg на предмет внедрения OpenCL. ^_^ теперь будет больше понимание какой API реализовывать т.к. libjpeg достаточно ужасен в плане кода.

stalkerg ★★★★★
()
Ответ на: комментарий от stalkerg

DCT 8x8, куча LUT, ага не сломать кеш достойная задача для русского программиста ;)

nikitos ★★★
()

Спасибо, поставил rpm-ку из Rawhide вместо libjpeg.

kmike ★★
()

libjpeg-turbo generally achieves 80-120% of the performance of TurboJPEG/IPP. It is faster in some areas but slower in others.

anonymous
()

Стараюсь не юзать жопег - формат без альфы - не айс.

helios ★★★★★
()

>Стараюсь не юзать жопег - формат без альфы - не айс.

Png смотрится всяко круче, одно плохо максимальное сжатие не слишком большое.

Napilnik ★★★★★
()

ну как всегда федорка впереди планеты всей. ждем появления в OpenSuSE 11.4

mono ★★★★★
()
Ответ на: комментарий от mono

впереди - слишком громко сказано,
с одной стороны у IJG «unresponsive upstream», что предрасполагает к форку, с другой стороны jpeg6b фактически жил без изменений в течении аж 11 лет, это за последний год его немного расширили 7, 8 , расширили очень незначительно, но ABI не сохранили
Хочется чтобы jpeg-turbo доработали (там реально немного) до поддержки jpeg8 , и вот тогда можно считать что libjpeg от IJG на x86/x86-64 будет вытеснена. по крайней мере в тех дистрибутивах, которые посчитают что производительность один из наиболее важных факторов.

Sylvia ★★★★★
() автор топика

Название какое-то пионерское.

dm1024 ★★★
()

Что куда линковать, я что-то не догнал?

System administrators can also replace the libjpeg sym links in /usr/{lib} with ==> links to the libjpeg dynamic library located in /opt/libjpeg-turbo/{lib}. This ==> will effectively accelerate every dynamically linked libjpeg application on the ==> system.

Желательно в виде готовой команды, а то в этих библиотеках голову сломишь

leonder
()

> так и бинарные пакеты для linux x86 и x86-64 в .deb , .rpm
А почему нет txz? По-моему как-то неправильно, что пользователей самого лучшего дистрибутива обделили пакетами

Xenius ★★★★★
()

скоро на лоре будут писать про обновление каждой либы,докатились .

Ubuntu1004
()
Ответ на: комментарий от Xenius

Недоверяю я сборку пакетов под мою слаку никому, кроме Патрика и его команды. Лучше уж сам пакет изготовлю.

some-body ★★
()
Ответ на: комментарий от slyjoeh

Для MacOsX есть, славненько, надо бы заюзать.

slyjoeh (04.07.2010 16:22:30)

Купил медленный мак ?

anonymous
()

>для включения в Fedora 14 в качестве системной библиотеки libjpeg

Т.е. в новой федоре будет древний jpeg?

madcore ★★★★★
()

ls /usr/share/doc/libjpeg-turbo-1.0.0$ ls |grep doc libjpeg.doc usage.doc

для документации формата лучше не нашли?

bohm ★★★★★
()
Ответ на: комментарий от devl547

нежелательно, там собираются 2 библиотеки
лучше для замены использовать libjpeg.so.62.0.0
libjpeg-turbo.so это для явной замены при сборке

Sylvia ★★★★★
() автор топика
Ответ на: комментарий от anonymous

~/tmp$ tar -xf ~/NAS/sources/libjpeg-turbo-1.0.0.tar.gz
~/tmp$ ls -l libjpeg-turbo-1.0.0/simd/Makefile.*
-rw-r--r-- 1 sylvia sylvia 1779 Jul 2 13:22 libjpeg-turbo-1.0.0/simd/Makefile.am
-rw-r--r-- 1 sylvia sylvia 18248 Jul 2 13:22 libjpeg-turbo-1.0.0/simd/Makefile.in


это что-то у вас... в tarball все на месте.
скачайте заново

Sylvia ★★★★★
() автор топика
Ответ на: комментарий от schakal

> Жду поддержки libjpeg8 и тогда попробую.

А этот libjpeg8 кому-небудь нужен? Что в нем есть хорошего кроме сломанной бинарной совместимости и сомнительных новых фич: http://hardwarebug.org/2010/02/01/ijg-swings-again-and-misses/

Если интересно, вот мнение Tom Lane, оригинального автора libjpeg: http://lists.fedoraproject.org/pipermail/devel/2010-May/136976.html

В общем, похоже, этот Guido Vollbeding (теперешний автор libjpeg7 и libjpeg8) решил присвоить то, что плохо лежит :)

Кстати, для тех, кто гоняет бенчмарки, в утилиты cjpeg и djpeg написаны не самым оптимальным образом и активно используют getc/putc, поэтому заметная часть времени уходит на io (особенно в cjpeg). При этом улучшения в части самого энкодера/декодера менее заметны.

ssvb
()
Ответ на: комментарий от Sylvia

> Хочется чтобы jpeg-turbo доработали (там реально немного) до поддержки jpeg8

Новая SmartScale фича из jpeg8 является SIMD-unfriendly по дизайну. К тому же дает худшее качество изображения.

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

ssvb
()
Ответ на: комментарий от ssvb

спасибо за информацию, так вот что значило «unresponsive upstream»

на libjpeg8 пока повязан только новый transcode, все остальное успешно работает с libjpeg-turbo и соответственно 6b

11 лет ждал чтобы присвоить? )

Sylvia ★★★★★
() автор топика
Ответ на: комментарий от ssvb

>При этом улучшения в части самого энкодера/декодера менее заметны.

все равно заметны) +50% примерно

Sylvia ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.