Работа с растром на низком уровне для начинающих

[@xEzhik]

Где-то я уже видел эту девушку…

[@freextraz]

en.wikipedia.org/wiki/Lenna

Lenna or Lena is the name given to a standard test image which has been in use since 1973.

[@atepeq]

Да, это просто легенда в обработке изображений. Нужно ей было бы дать почетную степень за вклад в развитие компьютерных технологий…

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

А вот так Лена выглядела в 1997-м году:

[@BlackSwan]

Интересные картинки на образовательных ресурсах Гонконга лежат :)

[@kAIST]

Вот история на русском web.archive.org/web/20101210175120/http://www.homepc.ru/offline/print/2002/77/22117/

[@Sergey40a]

Тогда уже и хайрез с «офсайта» Лены.

[@Dima_Sharihin]

Использовать будем классический Bitmap (System.Drawing.Bitmap). Данный класс удобен тем, что скрывает от нас детали кодирования растровых форматов – как правило, они нас и не интересуют. При этом поддерживаются все распространенные форматы, типа BMP, GIF, JPEG, PNG.

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



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

[@DreamWalker]

>>Запускаем код несколько раз, добиваясь типичных результатов – необходимо убедиться, что на нем не сказывается какой-то неожиданный процесс.

Я недавно столкнулся с проблемой замеров производительности .NET-программ, неожиданные вещи могут сказываться на результатах очень сильно. Поэтому я сделал несложное решение для автоматизации процесса: BenchmarkDotNet (можно поставить через NuGet). Прогрев процессора, выборка результатов и оценка погрешностей будут происходить сами, нужно лишь написать целевые методы. Плюс обеспечивается чистота эксперимента: выставляется высокий приоритет для процесса и потока, между отдельными запусками чистится мусор, выставляется фиксированая ProcessorAffinity (чтобы процесс не скакал между ядрами) и т.д. Возможно, данный проект может быть вам полезен для обеспечения высокой точности замеров времени.

[@SergeyVoyteshonok]

Я сейчас могу ошибаться, давно это было, как-то копался с GDI графикой на compact framework, как раз на предмет ускорения, и заметил следующую вещь, если использовать 32-х битный формат вместо 24-х битного, происходит увеличение быстродействия примерно на 25-30 процентов.

[@atepeq]

Интересно. Я попробую на днях.

[@dordzhiev]

Возможно использовался BGRA и из-за этого происходило преобразование BGR -> BGRA.

[@KvanTTT]

Опять статья о совершенно очевидных вещах. Понятное дело, что указатели будут быстрее двухмерных массивов, которые в свою очередь будут быстрее попиксельных операций.

[@AlexP11223]

Из названия и начала статьи показалось, что автор хочет рассказать о каких-то более интересных алгоритмах работы с изображениями, думал, что бенчмарки и чтение — это только начало. Удивился, когда на этом все и закончилось.

Хотя может быть это только первая статья.:)

[@atepeq]

Да, есть планы продолжить. Но не хотелось смешивать разные вопросы, как, например, алгоритмика и оптимизация отдельного подготовительного шага.

[@atepeq]

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

Про очевидные вещи — согласен. При накоплении некоторого опыта, это становится очевидно. Собственно, потому в названии статьи и указал «для начинающих». Но пока не пощупаешь сам, что какую выгоду дает, бывает сложно оценить, стоит ли в каком-то случае усложнять код ради этой прибавки. В данном случае хотелось показать как раз не качественно («вот, так быстрее»), а количественно («так быстрее в N раз»).

[@ondister]

Мне кажется тема быстрой обработки изображений на C# было неплохо раскрыта в AForge.net.

[@kekekeks]

А зачем вам unsafe там, где Marshal.Copy хватает за глаза?

[@Weageoo]

Да, по этому поводу прошу автора статьи добавить в сравнение.

[@atepeq]

Добавил сравнение с Marshal.Copy() вариантом в конец статьи. Обновил код в репозитории.

[@Weageoo]

Спасибо!

[@atepeq]

Не совсем. Marshal.Copy просто перенесет данные в другое место в том же порядке. Если мне хочется обрабатывать компоненты отдельно (каждую в своем массиве), то необходимо переставлять. Конечно, не всегда такое нужно, тогда действительно, Marshal.Copy хватит. Более того, в некоторых случаях можно вообще работать с данными Bitmap, никуда их не перенося. Все зависит от того, какая обработка нужна. Например, если нужна обработка с плавающей запятой (как указано в последнем случае), то простым копированием не обойтись.

[@kekekeks]

Ну можно было сначала перегнать в managed-массив, и уже его перемалывать. Всяко лучше чем работать с указателями, ведь пара неверных движений — и потом придётся неделями отлавливать ExecutionEngineException и Access Violation во время сборки мусора.