А существуют ли в природе библиотеки под Windows в виде dll, которые имеют в экспорте процедуры для быстрого DCT и IDCT. Мне нужно работать с jpeg-ами, всю работу по парсингу сегментов, разбору хафмана и т.д. я делаю сам, но DCT и IDCT у меня очень медленные, хочется заменить их на что-то внешнее, быстрое и оптимизированное под современные процессоры.
Здравствуйте, Aniskin, Вы писали:
A>А существуют ли в природе библиотеки под Windows в виде dll, которые имеют в экспорте процедуры для быстрого DCT и IDCT. Мне нужно работать с jpeg-ами, всю работу по парсингу сегментов, разбору хафмана и т.д. я делаю сам, но DCT и IDCT у меня очень медленные, хочется заменить их на что-то внешнее, быстрое и оптимизированное под современные процессоры.
Intel Performance Primitives? Не знаю, правда, насколько подойдет под ваши требования.
Здравствуйте, CyberDemon, Вы писали:
CD>Intel Performance Primitives?
Выглядит обнадеживающе. Нашел в документации семейство функций DCTFwdGetSize, DCTFwdInit, DCTFwd, DCTInvInit, DCTInvGetSize, DCTInv. Но как их использовать на практике, из какой конкретно dll их брать, не понятно. Буду пытаться изучать, спасибо.
Здравствуйте, Aniskin, Вы писали:
A>Здравствуйте, CyberDemon, Вы писали:
CD>>Intel Performance Primitives?
A>Выглядит обнадеживающе. Нашел в документации семейство функций DCTFwdGetSize, DCTFwdInit, DCTFwd, DCTInvInit, DCTInvGetSize, DCTInv. Но как их использовать на практике, из какой конкретно dll их брать, не понятно. Буду пытаться изучать, спасибо.
Ну там как бы все есть в доках. Можно статически линковать, можно и в DLL, все работает (ну или раньше работало , сейчас не использую).
Здравствуйте, CyberDemon, Вы писали:
CD>Ну там как бы все есть в доках.
Ну, пока вопросов больше, чем ответов.
CD>Можно статически линковать, можно и в DLL, все работает.
Я пишу на паскалях, и доступный для меня вариант только динамическая линковка через dll. В ippi.dll есть интересная функция ippiDCT8x8Inv_16s_C1, которая по документации делает то, что мне нужно. На вход подается 1) указатель на буфер из двухбайтовых знаковых DC/AC коэффициентов и 2) указатель на буфер из двухбайтовых чисел куда будет записан результат. Но документация не пишет, к каком диапазоне должны быть DC/AC коэффициенты, нужно ли мне расширять их до 16 бит. Аналогично не указан диапазон выходных значений, нужно ли мне сужать его до нужных мне 8 бит? Должны ли буферы быть выровнены по какой-то конкретной границе? И не понятно, является ли библиотека потокобезопасной.
В данное время я использую паскалевскую версию jpeg_idct_ifast из jidctfst.c из libjpeg. Ее прототип выглядит так:
И мне нужно вызов этой функции преобразовать в вызов ippiDCT8x8Inv_16s_C1(const Ipp<datatype>* pSrc, Ipp<datatype>* pDst).
И так жаба душит тянуть 100 Мб (ippcore.dll + ippi.dll + ippie9.dll + ippik0.dll + ippil9.dll + ippim7.dll + ippin8.dll + ippiy8.dll) ради пары функций
A>И так жаба душит тянуть 100 Мб (ippcore.dll + ippi.dll + ippie9.dll + ippik0.dll + ippil9.dll + ippim7.dll + ippin8.dll + ippiy8.dll) ради пары функций
вряд ли кто-то будет класть DCT/IDCT в отдельную либу. Как вариант: вытащить несколько файликов из, например, libx264 (начать с https://github.com/mirror/x264/blob/master/common/dct.h) в отдельную либу только с нужными функциями, и собрать в свою либу, которую потом линковать. Если с лицензиями все устроит — может быть рабочий вариант. И не забыть симдовые реализации функций.
A>И так жаба душит тянуть 100 Мб (ippcore.dll + ippi.dll + ippie9.dll + ippik0.dll + ippil9.dll + ippim7.dll + ippin8.dll + ippiy8.dll) ради пары функций
fftw еще есть. Это опернсурсное и его долго с собой даже матлаб таскал, пока окончательно на интеловские либы не перешел. Еще есть npp, если на нвидиях гонять собираешься.
Но таки у интеловских лучшая оптимизация.