Разоблачение рекламной статьи Intel

    Некоторе время занимаясь реализацией различных алгоритмов обработки изображений, я не мог не узнать о пакете Intel Integrated Performance Primitives (Intel IPP). Это набор высокопроизводительных функций обработки одно-, двух- и трехмерных данных, использующих возможности современных процессоров на полную. Это такие кирпичики с универсальными интерфейсами, из которых можно строить свои приложения и библиотеки. Продукт этот, безусловно, коммерческий, поскольку входит в поставку других средств разработки и отдельно не распространяется.

    С тех пор, как я узнал об этом пакете, меня не покидало желание узнать, насколько быстро в нем реализован ресайз изображений. Каких-то официальных бенчмарков или данных о производительности в документации нет, как нет и бенчмарков от сторонних разработчиков. Самое близкое, что мне удавалось найти — бенчмарки кодека JPEG от проекта libjpeg-turbo.

    И вот, позавчера, в процессе подготовки статьи «Методы ресайза изображений» (прочтение которой очень желательно для понимания дальнейшего изложения) в очередной раз наткнулся на статью, о которой и пойдет речь:

    libNthumb, The NHN* Performance Primitive for Real-Time Creation of Thumbnail Image with Intel IPP Library

    Статья находится в гугле по запросу «intel ipp image resize benchmarks» на первой или второй строке и размещена на сайте Intel, среди авторов значатся двое сотрудников Intel.

    В статье описывается нагрузочное тестирование некой библиотеки libNthumb в сравнении со всем известным ImageMagick. Подчеркивается, что libNthumb создана на основе Intel IPP и использует её преимущества. Обе библиотеки читают 12-мегапиксельный JPEG файл разрешением 4000×3000, ресайзят его в разрешение 400×300, после чего сохраняют обратно в JPEG. Библиотека libNthumb тестируется в двух режимах:

    libNthumb — изображение JPEG открывается не в нативном разрешении, а уменьшенное в 8 раз (т.е. в разрешении 500×375). Формат JPEG позволяет это делать без полного декодирования исходного изображения. После этого изображение масштабируется до требуемого разрешения 400×300.

    libNthumbIppOnly — изображение открывается в своем исходном разрешении, после чего масштабируется до требуемого разрешения 400×300 за один проход. Этот режим призван, как утверждается в статье, подчеркнуть разницу в производительности именно от использования Intel IPP, без дополнительных технических ухищрений. Вот поясняющая схема из самой статьи:



    После этого приводятся результаты замеров производительности для всех трех вариантов (ImageMagick, libNthumb, libNthumbIppOnly) по следующим параметрам: время декодирования, время ресайза, время сжатия и общее время работы. Меня заинтересовали результаты именно ресайза. Цитата:

    Тhe figure below shows average elapsed time for resizing process.



    Regardless of the number of worker threads, libNthumb shows about 400X performance gain over ImageMagick. It is because libNthumb has smaller data set through IDCT scale factor during decoding process.

    Как видно из графика, libNthumb в обоих вариантах оказывается в 400 раз быстрее ImageMagick. Авторы статьи объясняют это тем, что libNthumb обрабатывает намного меньше входных данных (в 64 раза, если быть точным) из-за уменьшения изображения в 8 раз сразу при открытии. Это действительно объясняет результат libNthumb, но это никак не объясняет результаты libNthumbIppOnly, которая должна использовать тот же набор входных данных, что и ImageMagick, т.е. полноразмерное изображение. О выдающихся результатах libNthumbIppOnly авторы умалчивают.

    Мне кажется (на самом деле я уверен, но формат повествования вынуждает писать объективно), что в libNthumb (а следовательно и в Intel IPP) и ImageMagick для ресайза изображений используются совершенно разные методы. Мне кажется, что в Intel IPP используется метод аффинных преобразований (тут я снова отсылаю вас прочесть методы ресайза изображений), метод, работающий за постоянное время относительно размеров исходного изображения, метод, совершенно не пригодный для уменьшения размеров больше чем в 2 раза, метод, дающий не очень качественный результат при уменьшении до двух раз. В то время как в ImageMagick используется метод сверток (тут я уже абсолютно уверен), дающий значительно более качественный результат, но и требующий намного больше вычислений.

    Если мои предположения верны, это можно было бы легко понять по получившемуся изображению: результат libNthumbIppOnly должен быть сильно пикселизированным. И в исходной статье действительно есть секция со сравнением качества получившихся картинок. Приведу её полностью:

    The thumbnail image should have a certain level of quality. When it comes to the quality of thumbnail image from libNthumb, the quality difference from ImageMagick is invisible to the naked eye. The below pictures are thumbnail images generated by ImageMagick and libNthumb, respectively.

    Thumbnail Image by ImageMagick


    Thumbnail Image by libNthumb


    There are various methods of resizing. Image quality will differ depending on the filter used. libNthumb improves image quality through multi-level resizing and sharpening filters, each having a different look and feel.

    Чудесным образом, результата работы libNthumbIppOnly тут нет. Более того, приведенные изображения разного разрешения и оба меньше заявленных 400×300 пикселей.

    Как я уже говорил, я считаю, что метод аффинных преобразований совершенно не пригоден для произвольного изменения размера изображений, и если он где-то используется, то это явный баг. Но это только мое мнение и я не могу никак помешать компании Intel продавать библиотеку, реализующую именно этот метод. Вот чему я могу помешать — так это введению других разработчиков в заблуждение и выдаванию разницы в работе двух принципиально разных алгоритмов за разницу в реализации. Если в статье утверждается, что что-то работает быстрее в 400 раз, то нужно убедиться, что результат работы один и тот же.

    Я ничего не имею против Intel и не ставлю цель как-то ей навредить. И с моей точки зрения, она должна сделать следующее:

    1) Исправить статью. Написать, почему производительность ImageMagick и IPP нельзя сравнивать напрямую.
    2) Исправить документацию. Сейчас догадаться о том, что линейная, кубическая и интерполяция функцией Ланцоша используют аффинные преобразования, не пригодные для уменьшения более чем в 2 раза, можно только по косвенным признакам: в приложении документации приводится точный алгоритм работы фильтров.
    3) (совсем фантастика) Разослать пользователям продукта письмо с извинениями за введение в заблуждение.
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 20

      +8
      Интересно, кто-нибудь вообще берет в расчет бенчмарки от компаний-производителей? А уж тем более когда в них приводятся фразы типа «мы в 400 раз быстрее ближайших конкурентов»?
        +4
        У того же самого Intel-а в примерах декодера видео, построенного на Intel Media SDK, инкремент декодированных фреймов происходил в двух местах, в результате чего показывался в два раза больший fps. Несколько часов я потратил чтобы понять почему мой собственный пример на их компонентах выдает меньший fps чем их пример. Конечно, я думаю, что это была непреднамеренная ошибка.
        +35
        Хочу обратиться к НЛО, которое без спроса добавляет кавычки (причем криво) и убирает переносы строк: я благодарен за желание помочь, но впредь лучше писать свои предложения в личку.
          0
          Столь строгое совпадение времени ресайза libNthumbIppOnly и libNthumb даже афинными преобразованиями не объяснить. Я бы вообще предположил, что они и там и там использовали предварительное 8-кратное уменьшение. Ну а что, всё равно никто не проверит…
            +1
            Ну почему же, аффинные преобразования действительно имеют линейное время относительно исходного разрешения, потому что изображение строится по одинаковому набору точек.

            In [1]: import cv2
            
            In [2]: i = cv2.imread('ex1_.jpg')
            In [3]: i.shape
            Out[3]: (1280, 1920, 3)
            In [4]: %timeit -n 50 r = cv2.resize(i, (400, 300), interpolation=cv2.INTER_LINEAR)
            "50 loops, best of 3: 2.75 ms per loop"
            
            In [5]: i = cv2.imread('5k.jpg')
            In [6]: i.shape
            Out[6]: (2880, 5120, 3)
            In [7]: %timeit -n 50 r = cv2.resize(i, (400, 300), interpolation=cv2.INTER_LINEAR)
            "50 loops, best of 3: 2.88 ms per loop"
            
              0
              Да, Вы правы. Это я ступил что-то.
                +1
                Линейное → постоянное. В статье тоже исправил.
              +1
              Но это только мое мнение и я не могу никак помешать компании Intel продавать библиотеку, реализующую именно этот метод.

              Методов ресайза в библиотеке несколько. Не примите за нравоучение или грубость, но лучше Вы сами не вводите разработчиков в заблуждение выдавая свои догадки
              Мне кажется, что в Intel IPP используется метод аффинных преобразований (тут я снова отсылаю вас прочесть методы ресайза изображений),

              за чистую монету. Документация на каждую функцию доступна.

              Более того, я так же не хочу им помогать/рекламировать, как и Вы не хотите навредить Intel. Но 5 лет использования библиотеки (а теперь и компилятора), благо наши системы привязаны на процессоры, дают понять, что аналогов не так уж и много. Я сейчас говорю про наличие в ней не только таких "примитивных" функций, как ресайз, а более сложных статистических функций и прочих. Поэтому, я думаю, не стоит заострятся на какой-то одной функции, т.к. пускают пыль в глаза ВСЕ производители.
                +1
                Методов ресайза в библиотеке несколько.

                Да, помимо аффинных преобразований есть суперсемплинг. Но именно реализация ресайза аффинными преобразованиями с моей точки зрения является багом.

                Не понял, при чем тут аналоги, «примитивность» ресайза (если так примитивно, что же правильно не реализовали) и другие функции, если речь о недобросовестном сравнении.

                пускают пыль в глаза ВСЕ производители

                Во-первых, вы сейчас совершенно бездоказательно оклеветали других производителей. Во-вторых, пыль в глаза можно пускать по разному. Можно поставить сравниваемые продукты в одинаковые условия, не благоприятные для одного из них. А можно в совершенно разные и выдавать это за сравнение.
                  0
                  Не понял, при чем тут аналоги, «примитивность» ресайза

                  "Примитивность" по сравнению с операциями взаимной кросс-корреляции/преобразование Фурье и т.д. Аналоги, в смысле другие пакеты (тот же OpenCV), не обладают таким богатством «элементарных» функций (кирпичиков), заточенных на быстродействие. Кстати, OpenCV можно таки собрать с использованием IPP. И прирост производительности действительно заметен.
                  Во-первых, вы сейчас совершенно бездоказательно оклеветали других производителей

                  Согласен, каюсь. Скажу иначе. Весь мой опыт работы и решения (программные), с которыми я сталкивался/знакомился, а так же решения, которые сам продвигал всегда напоминают (если уж совсем утрировано) сказку «Как старик корову продавал». В смысле, кто будет говорить о недостатках своего решения или делать сравнения в невыгодных для себя условиях. Ну глупо же -). Поэтому Вам в первом комментарии вполне резонно и написали, мол «это давно известный факт».
                +3
                При всём при этом, не могу не заметить, что IPP действительно крутая штука, позволяющая выжать из железа максимум. Жаль только, что платная. Что, вообще говоря, удивительно, так как на процах конкурирующего производителя она все равно бесполезна…
                  0
                  Бесполезна по сравнению с чем? Сможете показать на примере? Например, сравните прирост/падение производительности на процессоре Intel при переходе от FFTW к IPP FFT с приростом/падением производительности того же примера на аналогичном по набору инструкций процессоре AMD. Только проконтролируйте использование именно той же библиотеки IPPS в обоих случаях, чтобы автоматический диспетчер не мешал… Можно даже на статью на хабре набрать материала, если получится интересный результат… У меня, к сожалению, нет таких процессоров в шаговой доступности.
                    +1
                    Товарищ vanxant хотел сказать, что программа скомпилированная с использованием IPP, вполне может быть, не будет работать на машине с процессором AMD, о чем сам Intel и пишет в своих доках, но завуалированно. Ни о каком падении в сравнении с чем то речи не идет-)
                      +1
                      Пока достоверно не известно, что он хотел сказать, но на официальном сайте указано именно об уровне оптимизации, и не слова о том, что IPP вообще не будет работать на процессорах других производителей. Если бы это было так, то мало кто решился бы выпускать продукт для широкого круга пользователей используя IPP и/или компилятор Intel. Привязав IPP к своим процессорам Intel потеряла бы большую часть пользователей. Вы бы купили такой программный продукт? Рекомендовали бы его коллегам?..
                  0
                  Заинтересовало быстрое уменьшение jpeg. Насколько я понимаю, ссылка www.libjpeg-turbo.org/About/SmartScale, к примеру, именно к этому относится?
                    0
                    а уменьшенное в 8 раз
                    Только это в 64 раза уменьшено.
                      –1
                      Статья немного улыбнула, ее смысл можно свеcти к «closed-source библиотеки едят ваши данные бенчмарки!!!11». Но ведь это и так все знают, не так ли? Кто хочет качество, использует библиотеку с открытой реализацией известного алгоритма, которую можно проверить (и даже оптимизировать). Кто хочет дописать строчку с аббревиатурами и buzzword'ами в прес-релиз, тоже имеет свой вариант. Для всех есть место под солнцем, и никому ни перед кем извиняться не надо.
                        +2
                        Добрый день, уважаемые коллеги.
                        Вы совершенно правы – обсуждаемая здесь статья была опубликована без рецензии со стороны разработчиков библиотеки IPP ( Intel® Integrative Primitives ) и статья действительно содержит явные ошибки допущенные авторами.
                        Мы работаем над исправлением и обновлением данной публикации и сообщим здесь на форуме когда это обновление произойдет.
                        Мы также подумаем как обновить соответствующие части документации и сделаем это в одном из будущих обновлений.

                        С Уважением, Intel® IPP Team.
                          0
                          Первые комментарии за почти два месяца, но все равно, спасибо.
                          0
                          чего-то стерли её

                          Only users with full accounts can post comments. Log in, please.