jpeg-turbo теперь поддерживает ABI jpeg7 и jpeg8

> что это и зачем это нужно можно прочитать тут

Вот интересно, неужели на декодирование jpeg на современных декстопах действительно тратится сколько-нибудь ощутимое время? Чтобы нужно было это декодирование оптимизировать...

Вот интересно, неужели на декодирование jpeg на современных декстопах действительно тратится сколько-нибудь ощутимое время?

Ну если учесть, сколько этих жипегов рисуется, может оно и имеет смысл.

во-первых не только декодирование
во-вторых если брать обработку больших изображений, например фотографий, то тратится и весьма ощутимое, при их массовой обработке, создании превьюшек и т д

Любители делать фото на цифромыльницы 12Mpx и выше уже могут заставить задуматься о сабже. А про фото, сделанные Hasselblad 40-60Mpx или HiRES снимки NASA я вообще молчу... А двухкратный boost лишним не бывает.

Как с этим SVN соотносится порт graphics/libjpeg-turbo? Нужно подождать последнюю версию или уже можно им заменять стандартный jpeg 8_3?

http://upload.wikimedia.org/wikipedia/commons/4/45/ESO_-_The_Carina_Nebula_%2...

только стоило написать , что открывать это нужно с осторожностью ) особенно если ОЗУ немного, если это конечно тот самый файлик на 95 Мб )

хотя нет, там 39 Mb

у меня побольше есть 95681874 Eta_Carinae_Nebula_1.jpg )

Тот самый. Кстати, на нём очень показателен boost. BTW, а «ускоренной» версии zlib нет часом? А то PNG бы тоже чуток поскорее окрывать.

Не, не тот и вправду. У меня 95681874 bytes 29566х14321

для zlib нет, и навряд ли будет, там во-первых итак match.S есть оптимизированый,
во-вторых там все же больше целочисленная обработка данных, а не FloatingPoint, от SSE больше выигрывает второе.

>а «ускоренной» версии zlib нет часом?

Естественно нет) И PNG нет.

//а еще lame бы подкрутить..

Пересобирать нужно будет весь софт зависюший от jpeg?

в том то и дело , что НЕТ! :)
можно только заменить библиотеку и получить все бонусы


оно полностью совместимо по ABI с IJG версией libjpeg, причем версия с транка с jpeg7 и jpeg8 тоже теперь

Ок, убедили

Поставил в арч svn-версию. Всё работает. Пакет chromium-browser-bin тащит за собой libjpeg-6b поэтому он сам по себе, остальные проги норм подцепили сабж.

для 6b можно отдельно собрать jpeg-turbo
поддержка 6b там давно уже есть

PS: а я еще помню когда с turbo версией половина jpeg'ов грузились с зелеными полосами или другими артефактами, сейчас хорошо сделали все

Ага, но я уже хромиум выпилил. Всё равно до браузера не дотягивает :D

> Пакет chromium-browser-bin тащит за собой libjpeg-6b поэтому он сам по себе

Ну, это у кого как. :)

ldd /usr/lib64/chromium-browser/chrome | grep jpeg
   libjpeg.so.8 => /usr/local/lib/libjpeg.so.8 (0x00007f545c3ad000)

-bin ? :)
наверняка ведь не -bin ? )

Спасибо за новость. В прошлый раз я уже успел с 6b слезть. Сейчас как раз весьма кстати. :)

а я пересобирала все на libjpeg.so.62 :)
но другим например так просто это не сделать, поэтому... вот.. дождались пока сделали поддержку других ABI :)

> наверняка ведь не -bin ? )
Наверняка не -bin. :) Да и путь не такой, как у гугловской сборки.
Кстати, по результатам разборок в толксах с подделкой DCE для тестов в IE9, самосбор работает быстрее, чем -bin.

Стандартная установка autoconf на Ubuntu 10.10: (Версия 2.67)

autoreconf --install --force
Can't exec "libtoolize": Нет такого файла или каталога at /usr/bin/autoreconf line 196.
Use of uninitialized value in pattern match (m//) at /usr/bin/autoreconf line 196.
configure.ac:21: error: possibly undefined macro: AC_PROG_LIBTOOL
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1

> а я пересобирала все на libjpeg.so.62 :)
У меня тоже была такая мысль, но я её старательно отогнал. :)
Надо для локального оверлея сейчас сделать ebuild, чтобы турбо-версия ставилась в систему без коллизий, полностью заменяя обычную.

Может, сразу напишете список зависимостей для сборки?

пакет libtool

qfile /usr/bin/libtoolize
sys-devel/libtool (/usr/bin/libtoolize)

libtool

Проверь, все ли установлено, что нужно для сборки.

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

1 ) сборка из trunk
2 ) у меня система собрана с libjpeg.so.62 , и хоть я достаточно давно пользуюсь jpeg-turbo и проблем давно никаких не замечала, тем не менее я не проверяла jpeg7/jpeg8 у себя
3) если вы собираетесь заменять стандартную системную библиотеку, нужно хотя бы понимать что вы делаете и зачем...

поэтому руководство минимальное, для энтузиастов так сказать :)

насчет ebuild
в генте кажется тоже планируют переход
во всяком случае там есть в портеже

media-libs/libjpeg-turbo
Available versions: **1.0.1 **1.0.90-r1 {static-libs}
Homepage: http://sourceforge.net/projects/libjpeg-turbo/
Description: MMX, SSE, and SSE2 SIMD accellerated jpeg library


и virtual/jpeg , т.е. можно будет выбирать скорее всего какую версию ставить

1.0.90-r1 оказывается с jpeg8, проворонил я счастье... Всё-равно -9999 хочу. :)

http://sourceforge.net/projects/libjpeg-turbo/files/

тут не было 1.0.90

~/repo/libjpeg-turbo/tags $ ls -l
total 20
drwxr-xr-x 6 sylvia users 4096 Jun 18 15:19 0.0.90
drwxr-xr-x 6 sylvia users 4096 Jun 18 15:19 0.0.91
drwxr-xr-x 6 sylvia users 4096 Jun 18 15:19 0.0.93
drwxr-xr-x 6 sylvia users 4096 Jul 26 08:03 1.0.0
drwxr-xr-x 6 sylvia sylvia 4096 Oct 3 18:09 1.0.1


и в svn jpeg-turbo тоже, это что-то гентушники наснапшотили сами из trunk'a

так этот 1.0.90-r1 уже можно размаскировать и заюзать?

> так этот 1.0.90-r1 уже можно размаскировать и заюзать?
Да. Сейчас почистил /usr/local/lib64, удалил libjpeg, собрал -turbo. Работает замечательно. Единственно, не дружит со своей же версией 1.0.1 (которая только 6). Надо перекрыть, развести по разным слотам и чуть подредактировать ебилд для 1.0.1.

пусть доводят до ума значит, я потом почищу package.provided и мусор в /usr/local :)

У меня не на чем протестировать работоспособность для jpeg6.
Это с libjpeg-turbo-1.0.90-r1 уже дружит. Можно потестировать.

cat /usr/local/portage/media-libs/libjpeg-turbo/libjpeg-turbo-1.0.1.ebuild
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/media-libs/libjpeg-turbo/libjpeg-turbo-1.0.1.ebuild,v 1.1 2010/09/20 17:57:09 ssuominen Exp $

EAPI=2
inherit libtool

DESCRIPTION=«MMX, SSE, and SSE2 SIMD accellerated jpeg library»
HOMEPAGE="http://sourceforge.net/projects/libjpeg-turbo/"
SRC_URI=«mirror://sourceforge/${PN}/${P}.tar.gz»

LICENSE=«as-is LGPL-2.1 wxWinLL-3.1»
SLOT=«62»
KEYWORDS=«»
IUSE=«static-libs»

RDEPEND="!media-libs/jpeg:0
   !media-libs/jpeg:62"
DEPEND=«${RDEPEND}
   dev-lang/nasm»

src_prepare() {
   elibtoolize
}

src_configure() {
   econf \
      --disable-dependency-tracking \
      $(use_enable static-libs static)
}

src_install() {
   exeinto /usr/$(get_libdir)
   doexe .libs/libjpeg.so.62 || die
}

http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo/trunk/README-tu...

\Ъ{

Not supported:

-- libjpeg: DCT scaling in compressor cinfo.scale_num and cinfo.scale_denom are silently ignored.

-- libjpeg: IDCT scaling extensions in decompressor libjpeg-turbo still supports IDCT scaling with scaling factors of 1/2, 1/4, and 1/8 (same as libjpeg v6b.)

-- libjpeg: Fancy downsampling in compressor cinfo.do_fancy_downsampling is silently ignored.

-- jpegtran: Scaling Seems to depend on the DCT scaling feature, which isn't supported.

}

Что-то может сломаться. AUR за начало месяца на это намекает.

Поставил, вроде жив пока, все работает все открывается.

Ебилды уже есть? Придётся ли пересобирать бинарный Fx, чтобы задействовать поддержку этой библиотеки?

как выяснилось - ебилды уже есть
см выше

пересобирать ничего не нужно.

впрочем для фаерфокса есть момент, что он по умолчанию собран с bundled libjpeg, лучше посмотреть в about:buildconfig чтобы там было --with-system-jpeg

Вот интересно, неужели на декодирование jpeg на современных декстопах действительно тратится сколько-нибудь ощутимое время? Чтобы нужно было это декодирование оптимизировать...

Как-то в 6-м году понадобилось жать кадры камер в джпег, чтобы слать их потом по сети. libjpeg оказался раз в 5 тормознее libavcodec. Т.е. с libjpeg вообще получалось срамное непотребство. Если они ускорили его в пару раз, то... То всё равно нафиг не надо, ибо закрутить код, как в ffmpeg делают, они не смогут.

А как установить эту либу вместо системной в quirky?

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

libjpeg оказался раз в 5 тормознее libavcodec

Какого из кодеков?

закрутить код, как в ffmpeg делают

Не понял.

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

Жалось в jpeg. По протоколу видеопоток должен был быть в MJPEG.

Какого из кодеков?

jpeg

Хех, не знал этого. В одной из своих поделок как раз использую libjpeg для декодирования приходящего с веб-камеры mjpeg. Впрочем, в у меня на совсем другие вещи весь cpu time расходуется.

Подменил родные сусешные x86 и x86-64 либы, особой разницы на 400+ мегапиксельном жипеге незаметил.

А, пардон, в suse уже на libjpeg8 переехали, а я 6-ю заменил.

фааак
поставил сабж - теперь на фоне него пнг такооооой тормоз! о_О