Быстрый декод JPEGа и biCompression=BI_JPEG - WIN API

Нужно быстро загрузить и показать Ne количество JPEG файлов. Приемлемым резултатом (для меня) это 4-5 файлов по 4MB/10Mpx в секунду на Core2 Duo E2140 ...

опробовал — стандартный GDI+ Bitmap::FromFile(), весьма тормознуто

— 50 сек на 100 циклов
libjpeg и cximage — около 30 сек на 100 циклов
Acdsee показывает в status bar'е не более 0.20 сек на файл, т.е. максимум 20 сек на 100 циклов — не знаю на сколько это правда, но субъективно и в самом деле весьма шустро

хотелось бы получить результат как в Acdsee

И на тему biCompression=BI_JPEG (про который MSDN пишут что вроде как работает в XP). Хотел проверить на каком же этапе так жутко тормозит родной виндовый GDI. Хотел сам загрузить JPG content из файлы и скормить в CreateDIBSection(biCompression = BI_RGB)->SetBitmapBits() но для этого нужно как-то добыть из файла JPG заголовок чтобы вызвать CreateDIBSection() а затем и сам JPG stream для SetBitmapBits() ... ничего из примеров как это сделать не нашёл ни в MSDN ни в гугле ни здесь

Да и вообще интересно будет ли выводиться на экран DIB с BI_JPEG вот таким способом или нет

    void CChildView::OnPaint() 
    {
        CPaintDC dc(this);
        CDC      bmDC;
        
        bmDC.CreateCompatibleDC(&dc);
        SelectObject(bmDC.m_hDC, m_hbm); // <-- где m_hbm это DIB c biCompression=BI_JPEG

        dc.StretchBlt(100, 100, 800, 600, &m_bmDC, 500, 500, 400, 300, SRCCOPY);
    }

ЗЫ:

    Bitmap* bmp = Bitmap::FromFile(L"C:\\My.jpg");
    HBITMAP  hbm;
    DIBSECTION  dib;

    bmp->GetHBITMAP(c, &hbm);
    ::GetObject(hbm, sizeof(DIBSECTION), &dib);

и вот здесь в dib.dsBmih.biCompression уже лежит 0 (он же BI_RGB) а не BI_JPEG.

Здравствуйте, SergV6, Вы писали:

SV>Нужно быстро загрузить и показать Ne количество JPEG файлов. Приемлемым резултатом (для меня) это 4-5 файлов по 4MB/10Mpx в секунду на Core2 Duo E2140 ...

SV>опробовал — стандартный GDI+ Bitmap::FromFile(), весьма тормознуто

— 50 сек на 100 циклов
SV>libjpeg и cximage — около 30 сек на 100 циклов
SV>Acdsee показывает в status bar'е не более 0.20 сек на файл, т.е. максимум 20 сек на 100 циклов — не знаю на сколько это правда, но субъективно и в самом деле весьма шустро
Любой современный просмотрщик вначале загружает внедренные превьюшки, а в фоне идет обработка полноразмерных файлов (да и то не всегда)

C>Любой современный просмотрщик вначале загружает внедренные превьюшки, а в фоне идет обработка полноразмерных файлов (да и то не всегда)

Пожалуй не соглашусь с этим. Во-первых не бывает превьюшек 1280х1024, во-вторых если написано 'load time=' то это всё таки не время отображения картинки из кэша, ну и в третьих — в Acdsee спокойно можно листать картинки без тормозов, чего не скажешь при виндовый вьювер

. Так что не в фоновой обработке счастье.

В общем я пока ещё в поисках ....

Наверно написать свой, а не использовать GDI =)

Здравствуйте, SergV6, Вы писали:

C>>Любой современный просмотрщик вначале загружает внедренные превьюшки, а в фоне идет обработка полноразмерных файлов (да и то не всегда)

SV>Пожалуй не соглашусь с этим. Во-первых не бывает превьюшек 1280х1024, во-вторых если написано 'load time=' то это всё таки не время отображения картинки из кэша, ну и в третьих — в Acdsee спокойно можно листать картинки без тормозов, чего не скажешь при виндовый вьювер

. Так что не в фоновой обработке счастье.

Превьюшки, естественно, используются только для первоначальго показа в Browser (когда все скопом), одновременно начинается обработка тех изображений, превью которых есть в этом Browser, так как больше вероятность того, что из захотят посмотреть в полном размере.
Да и при просмотре в полнйы размер в Acdsee кеш картинок и вперед, и назад, в отличи от

SV>В общем я пока ещё в поисках ....
libjpeg показывает очень неплохую скорость, на самом деле, только не в том случае, когда поверх него cximage сидит

Если надо быстрее, то могу только IPP (Intel® Integrated Performance Primitives) предложить. Еще более быстрый способ для настоящих джедаев доступен если в системе видеокарта на чипе NVIDIA — берем http://developer.nvidia.com/object/cuda.html и пишем — благодаря своей структуре JPEGочень хорошо поверх этого API ложится, у меня всего две недели на порт libjpeg 6.0 ушло

С тем же PNG такой финт ушами уже не пройдет.

Здравствуйте, Conr, Вы писали:

C>Если надо быстрее, то могу только IPP (Intel® Integrated Performance Primitives) предложить.

На Pentium III (т.е. с использованием SSE) давало прирост производительности в разы по сравнению с libjpeg, если работать с файлами на диске. И на порядок, если учитывать только распакову JPEG в памяти. Сейчас должно быть еще лучше

Здравствуйте, Michael Chelnokov, Вы писали:

C>>Если надо быстрее, то могу только IPP (Intel® Integrated Performance Primitives) предложить.

MC>На Pentium III (т.е. с использованием SSE) давало прирост производительности в разы по сравнению с libjpeg, если работать с файлами на диске. И на порядок, если учитывать только распакову JPEG в памяти. Сейчас должно быть еще лучше

У меня на Core2 Quad Q6600 + 2 гига оеративки IPP 5.3 шустрее libjpeg примерно в 15 раз (отображение на экране с кешем на RAM-DRIVE). Правда решение на NVIDIA CUDA в тех же условиях быстрее в 27-30 раз

Сейчас по просьбе пользователей разбираюсь с ATI CTM — пока кроме матов ничего сказать не могу

SV>В общем я пока ещё в поисках ....

... пока дожидался ответа и сам с помощью великого и могучго inet'а пришёл к тому же IPP (Intel® Integrated Performance Primitives) что рекомендует Conr.

Результаты по сравнению производительности вполне впечатляют (хоть и не в 15 раз), особенно если компилировать интелловским компилятором:

Тестовый .jpg — 4M, 3648х2736 = 10Mpx

СxImage (он же libjpeg)

MS Compiler = 0.327 — 1 x

ipp-samples\image-codecs\jpegview\

MS Compiler = 0.136 — 2.74 x
Intel Compiler 10.1 = 0.079 sec — 4.13 x <- с такой скоростью мне нафиг предзагрузка не нужна, 12 10Mpx картинок в секунду

Вопрос теперь в легальности использования IPP. Покупать чё-то не хочется

, а использовать хочется ...

Здравствуйте, SergV6, Вы писали:

SV>ipp-samples\image-codecs\jpegview\

SV> MS Compiler = 0.136 — 2.74 x
SV> Intel Compiler 10.1 = 0.079 sec — 4.13 x <- с такой скоростью мне нафиг предзагрузка не нужна, 12 10Mpx картинок в секунду
От потому и не в 15

SV>Вопрос теперь в легальности использования IPP. Покупать чё-то не хочется

, а использовать хочется ...
Ну елки-палки, она стоит 200, а экономит куда как больше.

C>Ну елки-палки, она стоит 200, а экономит куда как больше.

Взялся встроить JPEG decoder от IPP в свою прогу, и в обшем уже начал сомневаться в самом ли деле с его помощью можно много сэкономить ...

1. sample'ы в которых идёт JPEG декодер наверное индийские студенты писали потому что
а) про поддержку UNICODE там не слышали (хотя бы для имён файлов)
b) класса который можно было бы взять и вставить в свою прогу нету, весь decode/encode сделан внутри CJPGViewDoc соответственно с привязкой к остальноый части 'их' приложения которое мне нафиг не нужно
c) про структуру исходников для jpeg2000 я вообще молчу — 32 папки, причём если включать это всё с свой проект — все нужно прореференсить в "additional include directories"

2. исходники откомпилированы и слинкованы похоже что из-под 2005й студии, и соответственно это всё не поднимается в VC6 из-за ошибок типа

    error LNK2001: unresolved external symbol ___security_cookie

3. ну и собственно производительность ... на самом деле оказалась не такая уж и супер хорошая ...
Среднее время по 10 разным JPEG'ам

    MyApp/libjpeg            - 0.263 sec
    MyApp/IPP intel compiler - 0.238 sec = 1.1 раза <- тут хотелось бы получить те же 0.108 что и ниже
    IppSample/vc compiler    - 0.150 sec = 1.75 раза
    IppSample/intel compiler - 0.108 sec = 2.45 раза

во-первых — для IPP раньше я просто взял время что выдавал их sample, но оказалось что они там считали только время на decode (без зачитывания header'а и прочих операций) а реально на открытие картинки из файла уходит на много больше
во-вторых — после переноса их исходников в свой проект, производительность оказалась на уровне libjpeg даже при
... компилировании через intel compiler
... всеми включёнными оптимизациями
... статической линковке на IPP библиотеку

уж и не знаю в чём могут быть грабли ...

Здравствуйте, SergV6, Вы писали:

SV>1. sample'ы в которых идёт JPEG декодер наверное индийские студенты писали потому что
SV> а) про поддержку UNICODE там не слышали (хотя бы для имён файлов)
Зачем UNICODE надо в кодеке JPEG??? А имена файлов — так это на то и пример, а не готовое решение. Вообще IPP, кажется, у нас в Новгороде разрабатывается, тех ребят, которых я оттуда знаю, индийскими студентами ну никак не назвать

SV> b) класса который можно было бы взять и вставить в свою прогу нету, весь decode/encode сделан внутри CJPGViewDoc соответственно с привязкой к остальноый части 'их' приложения которое мне нафиг не нужно
Хм, собственно кодек JPEG лежит в ipp-samples\image-codecs\jpegview\jpeg\. Декодер CJPEGDecoder определен в jpegdec.h — бери и вставляй, что еще надо? Единственное, что я еще дополнительно сделал — заменил все их стримы на свои, заточенные под мои нужды.

SV> c) про структуру исходников для jpeg2000 я вообще молчу — 32 папки, причём если включать это всё с свой проект — все нужно прореференсить в "additional include directories"
не пользовал, ничего сказать не могу

SV>2. исходники откомпилированы и слинкованы похоже что из-под 2005й студии, и соответственно это всё не поднимается в VC6 из-за ошибок типа
SV>

SV>    error LNK2001: unresolved external symbol ___security_cookie
SV>

Хм, а случаем debug-release версии не намешаны вместе? Да и вообще, какие причины для использования VC6?

SV>3. ну и собственно производительность ... на самом деле оказалась не такая уж и супер хорошая ...
IPP дает прирост производительности на DCT-tranfsorms, Huffman decoding и преобразовании цветовых пространств, причем очень существенный (на моей тестовой конфигурации x15, как я уже писал). А вот все остальное (предзагрузка данных, кеши) надо делать ручками — чудес на свете не бывает

Если не хочется со всем этим возиться, то у Intel'а раньше была библиотечка специально для JPEG — IJL(Intel Jpeg Library), из беты она так и не вышла (последняя версия кажется 1.5) и в ней нет поддержки новейших процессоров (p8), но работает она все-таки пошустрее libjpeg + она бесплатная и ее можно использовать в коммерческих приложениях. Если погуглить, то, наверное, можно найти дистрибутив.

Похоже таки со всем разобрался ...

SV>>1. sample'ы в которых идёт JPEG декодер наверное индийские студенты писали потому что
SV>> а) про поддержку UNICODE там не слышали (хотя бы для имён файлов)
C>Зачем UNICODE надо в кодеке JPEG???
Да, в самом кодеке он не нужен, но чтобы прочитать из файла одного кодека недостаточно ... см. ниже

SV>> b) класса который можно было бы взять и вставить в свою прогу нету, весь decode/encode сделан внутри CJPGViewDoc соответственно с привязкой к остальноый части 'их' приложения которое мне нафиг не нужно
C>Хм, собственно кодек JPEG лежит в ipp-samples\image-codecs\jpegview\jpeg\...
Это я конечно же нашёл, но чтобы добраться от чтения файла до кодека в sample лежит CJPGViewDoc->CIppImage->ReadImageJPEG(из jpeg.cpp который не самой папке с кодеком). Вот так вот всё у них не так просто ...

Короче чтобы всунуть это в свой проект нужно ещё порядком покопаться ... а могли бы весь нужный интерфейс вынести в CIppImage.

SV>>2. исходники откомпилированы и слинкованы похоже что из-под 2005й студии, и соответственно это всё не поднимается в VC6 из-за ошибок типа
SV>>

SV>>    error LNK2001: unresolved external symbol ___security_cookie
SV>>

C>Хм, а случаем debug-release версии не намешаны вместе? Да и вообще, какие причины для использования VC6?
Эта проблема похоже возникает из-за опции компилятора /GS — Buffer Security Check о которой в VC6 ещё не слышали.
А студия 2005я не нравится мне из-за своей тормознутость (даже на нормальном железе), и пары удобных фич что я постоянно пользуюсь из тех что есть в VC6 нету в 2005й. Да и бинарники линкуются на vc80 runtime которого на голой WinXP по-моему нету ...

SV>>3. ну и собственно производительность ... на самом деле оказалась не такая уж и супер хорошая ...
C>IPP дает прирост производительности на DCT-tranfsorms, Huffman decoding и преобразовании цветовых пространств, причем очень существенный (на моей тестовой конфигурации x15, как я уже писал). А вот все остальное (предзагрузка данных, кеши) надо делать ручками — чудес на свете не бывает

с производительностью мой косяк оказался (в чём я в общем-то и не сомневался), дело окащалось в одной маленькой строче

  ippStaticInit();

которую я sample'е просмотрел и нашёл только через очень (мля

) долгое время сравнивя проекты построчно

итого ippStaticInit() + опции Intel компилятора /Qopenmp /Qwd9,171,181,383,444,593,810,858,981,1418 дают результат в среднем
0.1 sec на средний 10Mpx файл на моём Core2 Quo E2140 разогнанном до 2,8Ghz

C>Если не хочется со всем этим возиться, то у Intel'а раньше была библиотечка специально для JPEG — IJL(Intel Jpeg Library), из беты она так и не вышла (последняя версия кажется 1.5) и в ней нет поддержки новейших процессоров (p8), но работает она все-таки пошустрее libjpeg + она бесплатная и ее можно использовать в коммерческих приложениях. Если погуглить, то, наверное, можно найти дистрибутив.

А она в исходниках лежит в том же IPP — ipp-samples\image-codecs\jpeg-ijl

— 50 сек на 100 циклов
SV>libjpeg и cximage — около 30 сек на 100 циклов
SV>Acdsee показывает в status bar'е не более 0.20 сек на файл, т.е. максимум 20 сек на 100 циклов — не знаю на сколько это правда, но субъективно и в самом деле весьма шустро

SV>хотелось бы получить результат как в Acdsee

Нда — уже почти год прошёл с моих последних экспериментов на эту тему

... тем временем результами полученными при использовании Ipp я не очень рад.
1) По произодительности всё равно не сравнится с Acdsee (откомилировани Intel комилятором с OMP). На отдельных файлах время загрузки около 0,4сек (Acdsee — на том же файле около 0.1sec) — хотя в среднем где-то 0.1 .. 0.2 сек.
2) Какой-то косяк с GrayScale картинками — после декодера получается какая-то цианисто-смешаная ерунда
... в общем впечатление что над JPEG декодер'ом там работали индусские (ну или как говорят здесь нижегородские) студенты остаётся в силе

Надумал ещё раз погуглить на эту тему, зашёл на sourceforge и попалась мне библиотека jpegdec — http://sourceforge.net/projects/jpegdec. Вкратце — JPEG декодер с использованием SSSE2 на чистом .asm'е. Мои впечатления

Положительные
1) Производительность чуть лучше Ipp со всеми оптимизациями — при том что библиотека однопоточная а Ipp типа 2+ процессора использует если есть
2) Прост в использовании как грабли
3) Нету косяка с GrayScale картинками

Отрицательные
1) Не поддерживат Progressive
2) Не поддерживат многопоточность
3) Выдаёт битмап в 32х битах а не в 24х — а зажать 32ный битмап через Ipp у меня что-то не получилось

4) Хоть написано и аккуратно — но чистый .asm. Чтобы чего-то доправить нужно быть не меньшим монстром чем авторы этой библиотеки (к примеру сделать поддержку многопоточности + Progressive формат). В общем — шаг влево/шаг вправо — захочешь а сделать проблематично

5) Посколько SSE2 — быстро, но будет работать только на P4+

PS: И что за монстры работают в Acdsee — вот бы их библиотечку прикрутить

Здравствуйте, SergV6, Вы писали:

C>>Зачем UNICODE надо в кодеке JPEG???
SV>Да, в самом кодеке он не нужен, но чтобы прочитать из файла одного кодека недостаточно ... см. ниже
Это уж ты самостоятельно...

SV>Это я конечно же нашёл, но чтобы добраться от чтения файла до кодека в sample лежит CJPGViewDoc->CIppImage->ReadImageJPEG(из jpeg.cpp который не самой папке с кодеком). Вот так вот всё у них не так просто ...

Короче чтобы всунуть это в свой проект нужно ещё порядком покопаться ... а могли бы весь нужный интерфейс вынести в CIppImage.

Это Performance Primitives. Примитивы, а не классы-на-все-случаи-жизни.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, SergV6, Вы писали:

SV>1) По произодительности всё равно не сравнится с Acdsee (откомилировани Intel комилятором с OMP). На отдельных файлах время загрузки около 0,4сек (Acdsee — на том же файле около 0.1sec) — хотя в среднем где-то 0.1 .. 0.2 сек.
Забей на файловые стримы. Читай в память через MMF и стримай уже из памяти.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, CreatorCray, Вы писали:

CC>

Это Performance Primitives. Примитивы, а не классы-на-все-случаи-жизни.
С одной стороны согласен что Jpeg кодек не в самой библиотеке лежит в самплах к ней, с другой — не переписывать же мне их Jpeg кодек (а это вещь которая нужна очень многим). Да и не один я его попользовать взялся. С кривым самплом туче людей работы по переделке хватит.

Здравствуйте, CreatorCray, Вы писали:

SV>>1) По произодительности всё равно не сравнится с Acdsee (откомилировани Intel комилятором с OMP). На отдельных файлах время загрузки около 0,4сек (Acdsee — на том же файле около 0.1sec) — хотя в среднем где-то 0.1 .. 0.2 сек.
CC>Забей на файловые стримы. Читай в память через MMF и стримай уже из памяти.
А кто такой MMF? Что-то эта аббривиатура ничего подходящего мне не говорит ...

Здравствуйте, SergV6, Вы писали:

SV>А кто такой MMF? Что-то эта аббривиатура ничего подходящего мне не говорит ...

Memory Mapped Files

Здравствуйте, SergV6, Вы писали:

CC>>

Это Performance Primitives. Примитивы, а не классы-на-все-случаи-жизни.
SV>С одной стороны согласен что Jpeg кодек не в самой библиотеке лежит в самплах к ней, с другой — не переписывать же мне их Jpeg кодек (а это вещь которая нужна очень многим). Да и не один я его попользовать взялся. С кривым самплом туче людей работы по переделке хватит.
А нафига самому? Есть turbojpeg — кодек на основе ipp, совместимый с libjpeg.

Результаты последних экспериментов — время загрузки в ms.

Условия — всё тот же Core2 Duo. Откомпилированно мелкософтовским компилятором + Whole Program Optimization. Как недано узнал, компилятор от MS тоже понимает OPENMP и код из-под него работает быстрее чем от интеловского (что странно

) — соответственно OPENMP включено.

                            JpegIpp JpegDec Jpeg6bx JpegWic
------------------------------------------------------------
            Canon A610.JPG       36     112      54     129
             Canon A70.JPG       20      55      26      44
           Canon EOS5D.JPG       84     187      96     246
           Canon SD900.JPG       61     161      81     206
Casio EX-Z1050 (Progr).jpg       90      36      36      46
             GrayScale.JPG       16      44      18      34
          Minolta F100.JPG       26      84      38      68
            Nicon D200.JPG       72     233     104     265
     Panasonic DMC-FX9.JPG       50     153      70     170
      Pentax Optio S5z.jpg       29      87      42      70
  Samsung Digimax A400.jpg       24      71      34      56
            Sony PC350.JPG       19      52      24      41

Notes:

IPP — по исходникам от версии 5.3. Нынешняя 6.0 и работает медлеенее и глюки с многопоточностью имеются (как результат — полосы в декодирванном битмаp'е)

JpegWic (для WinXP) — про WIC интересный комментарий от MS insider'а тут — http://sim0nsays.livejournal.com/19954.html — "По скорости — будет также или лучше. Там субоптимальная реализация, большинство трюков и low-level optimizations какие можно было сделать, сделали."
Судя по всему не так уж и всё сделали раз в среднем скорость раза в 3 меньше чем IPP

(Prоgressive не в счёт — это явно какой-то косяк в IPP, причём по исходникам от 6.0 отрабатывает быстрее чем Jpeg6bx)

	От:	SergV6
	Дата:	23.12.07 23:14
	Оценка:

	От:	Conr
	Дата:	24.12.07 01:17
	Оценка:

	От:	SergV6
	Дата:	27.12.07 22:02
	Оценка:

	От:	Uzumaki Naruto
	Дата:	28.12.07 06:21
	Оценка:

	От:	Conr
	Дата:	28.12.07 13:45
	Оценка:

	От:	Michael Chelnokov
	Дата:	28.12.07 14:58
	Оценка:

	От:	CreatorCray
	Дата:	05.12.08 11:01
	Оценка:

	От:	CreatorCray
	Дата:	05.12.08 11:01
	Оценка:

	От:	Аноним
	Дата:	05.12.08 18:58
	Оценка: