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

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

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

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

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

http://aur.archlinux.org/packages.php?ID=38030

В Ubuntu libjpeg62 6b-15ubuntu1.
Значит можно подменить?

да

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

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

да.

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

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

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

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

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

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

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

И зачем оно нужно, когда есть Intel's JPEG Library?

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

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

В 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.

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

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

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

Асм

это очень хорошо.

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

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

А libpng будет? :)

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

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

надеюсь допилят

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

slyjoeh (04.07.2010 16:22:30)

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

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

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

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

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

Там всё внятно написано. Заменить линки с системной на турбо. Если это не ясно - не стоит пытаться.

>проще всего кинуть

LD_PRELOAD=/usr/lib/libjpeg-turbo.so
не прокатит?

не компилится, simd/Makefile.in не находит...

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

~/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 все на месте.
скачайте заново

> Жду поддержки 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). При этом улучшения в части самого энкодера/декодера менее заметны.

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

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

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

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

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

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

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

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