Как стать автором
Обновить

Комментарии 22

Где-то я уже видел эту девушку…
en.wikipedia.org/wiki/Lenna

Lenna or Lena is the name given to a standard test image which has been in use since 1973.
Да, это просто легенда в обработке изображений. Нужно ей было бы дать почетную степень за вклад в развитие компьютерных технологий…

Если интересно, вот полное изображение. Это из Playboy, так что смотрите на свой страх и риск — http://www.ee.cityu.edu.hk/~lmpo/lenna/len_full.jpg.

А вот так Лена выглядела в 1997-м году:
image
Интересные картинки на образовательных ресурсах Гонконга лежат :)
Тогда уже и хайрез с «офсайта» Лены.
Использовать будем классический Bitmap (System.Drawing.Bitmap). Данный класс удобен тем, что скрывает от нас детали кодирования растровых форматов – как правило, они нас и не интересуют. При этом поддерживаются все распространенные форматы, типа BMP, GIF, JPEG, PNG.


Оффтоп, конечно, но вот сравнение производительности кодирования jpeg разными способами в .NET. По оси абсцисс — качество, по оси ординат — время



В описанном в статье случае, использование GDI может быть оправдано, однако, обрезка и масштабирование(как и кодирование изображения) с помощью WPF и WIC получается в разы быстрее
>>Запускаем код несколько раз, добиваясь типичных результатов – необходимо убедиться, что на нем не сказывается какой-то неожиданный процесс.

Я недавно столкнулся с проблемой замеров производительности .NET-программ, неожиданные вещи могут сказываться на результатах очень сильно. Поэтому я сделал несложное решение для автоматизации процесса: BenchmarkDotNet (можно поставить через NuGet). Прогрев процессора, выборка результатов и оценка погрешностей будут происходить сами, нужно лишь написать целевые методы. Плюс обеспечивается чистота эксперимента: выставляется высокий приоритет для процесса и потока, между отдельными запусками чистится мусор, выставляется фиксированая ProcessorAffinity (чтобы процесс не скакал между ядрами) и т.д. Возможно, данный проект может быть вам полезен для обеспечения высокой точности замеров времени.
Я сейчас могу ошибаться, давно это было, как-то копался с GDI графикой на compact framework, как раз на предмет ускорения, и заметил следующую вещь, если использовать 32-х битный формат вместо 24-х битного, происходит увеличение быстродействия примерно на 25-30 процентов.
Интересно. Я попробую на днях.
Возможно использовался BGRA и из-за этого происходило преобразование BGR -> BGRA.
Опять статья о совершенно очевидных вещах. Понятное дело, что указатели будут быстрее двухмерных массивов, которые в свою очередь будут быстрее попиксельных операций.
Из названия и начала статьи показалось, что автор хочет рассказать о каких-то более интересных алгоритмах работы с изображениями, думал, что бенчмарки и чтение — это только начало. Удивился, когда на этом все и закончилось.

Хотя может быть это только первая статья.:)
Да, есть планы продолжить. Но не хотелось смешивать разные вопросы, как, например, алгоритмика и оптимизация отдельного подготовительного шага.
Насчет многомерных массивов — мне в самом начале это было не столь очевидно. Ведь все-таки выполняется не код, скомпилированный в команды процессора, а есть еще промежуточный уровень (MSIL). То, что идет значительная прибавка производительности, также говорит о достаточно высокой эффективности среды исполнения .net. Только в этом случае накладные расходы на проверку выхода за границы размерности и операции вычисления позиции в массиве, будут так сильно сказываться.

Про очевидные вещи — согласен. При накоплении некоторого опыта, это становится очевидно. Собственно, потому в названии статьи и указал «для начинающих». Но пока не пощупаешь сам, что какую выгоду дает, бывает сложно оценить, стоит ли в каком-то случае усложнять код ради этой прибавки. В данном случае хотелось показать как раз не качественно («вот, так быстрее»), а количественно («так быстрее в N раз»).
Мне кажется тема быстрой обработки изображений на C# было неплохо раскрыта в AForge.net.
А зачем вам unsafe там, где Marshal.Copy хватает за глаза?
Добавил сравнение с Marshal.Copy() вариантом в конец статьи. Обновил код в репозитории.
Спасибо!
Не совсем. Marshal.Copy просто перенесет данные в другое место в том же порядке. Если мне хочется обрабатывать компоненты отдельно (каждую в своем массиве), то необходимо переставлять. Конечно, не всегда такое нужно, тогда действительно, Marshal.Copy хватит. Более того, в некоторых случаях можно вообще работать с данными Bitmap, никуда их не перенося. Все зависит от того, какая обработка нужна. Например, если нужна обработка с плавающей запятой (как указано в последнем случае), то простым копированием не обойтись.
Ну можно было сначала перегнать в managed-массив, и уже его перемалывать. Всяко лучше чем работать с указателями, ведь пара неверных движений — и потом придётся неделями отлавливать ExecutionEngineException и Access Violation во время сборки мусора.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории