Некоторе время занимаясь реализацией различных алгоритмов обработки изображений, я не мог не узнать о пакете Intel Integrated Performance Primitives (Intel IPP). Это набор высокопроизводительных функций обработки одно-, двух- и трехмерных данных, использующих возможности современных процессоров на полную. Это такие кирпичики с универсальными интерфейсами, из которых можно строить свои приложения и библиотеки. Продукт этот, безусловно, коммерческий, поскольку входит в поставку других средств разработки и отдельно не распространяется.
И с тех пор, как я узнал об этом пакете, меня не покидало желание узнать, насколько быстро в нем реализован ресайз изображений. Каких-то официальных бенчмарков или данных о производительности в документации нет, как нет и бенчмарков от сторонних разработчиков. Самое близкое, что мне удавалось найти — бенчмарки кодека JPEG от проекта libjpeg-turbo.
И вот позавчера, в процессе подготовки статьи методы ресайза изображений (прочтение которой очень желательно для понимания дальнейшего изложения) я в очередной раз наткнулся на статью, о которой и пойдет речь:
Статья находится в гугле по запросу «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) (совсем фантастика) Разослать пользователям продукта письмо с извинениями за введение в заблуждение.
Автор: homm
