Comments 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.
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-м году:
Если интересно, вот полное изображение. Это из Playboy, так что смотрите на свой страх и риск — http://www.ee.cityu.edu.hk/~lmpo/lenna/len_full.jpg.
А вот так Лена выглядела в 1997-м году:
Интересные картинки на образовательных ресурсах Гонконга лежат :)
Вот история на русском web.archive.org/web/20101210175120/http://www.homepc.ru/offline/print/2002/77/22117/
Тогда уже и хайрез с «офсайта» Лены.
Использовать будем классический Bitmap (System.Drawing.Bitmap). Данный класс удобен тем, что скрывает от нас детали кодирования растровых форматов – как правило, они нас и не интересуют. При этом поддерживаются все распространенные форматы, типа BMP, GIF, JPEG, PNG.
Оффтоп, конечно, но вот сравнение производительности кодирования jpeg разными способами в .NET. По оси абсцисс — качество, по оси ординат — время
В описанном в статье случае, использование GDI может быть оправдано, однако, обрезка и масштабирование(как и кодирование изображения) с помощью WPF и WIC получается в разы быстрее
>>Запускаем код несколько раз, добиваясь типичных результатов – необходимо убедиться, что на нем не сказывается какой-то неожиданный процесс.
Я недавно столкнулся с проблемой замеров производительности .NET-программ, неожиданные вещи могут сказываться на результатах очень сильно. Поэтому я сделал несложное решение для автоматизации процесса: BenchmarkDotNet (можно поставить через NuGet). Прогрев процессора, выборка результатов и оценка погрешностей будут происходить сами, нужно лишь написать целевые методы. Плюс обеспечивается чистота эксперимента: выставляется высокий приоритет для процесса и потока, между отдельными запусками чистится мусор, выставляется фиксированая ProcessorAffinity (чтобы процесс не скакал между ядрами) и т.д. Возможно, данный проект может быть вам полезен для обеспечения высокой точности замеров времени.
Я недавно столкнулся с проблемой замеров производительности .NET-программ, неожиданные вещи могут сказываться на результатах очень сильно. Поэтому я сделал несложное решение для автоматизации процесса: BenchmarkDotNet (можно поставить через NuGet). Прогрев процессора, выборка результатов и оценка погрешностей будут происходить сами, нужно лишь написать целевые методы. Плюс обеспечивается чистота эксперимента: выставляется высокий приоритет для процесса и потока, между отдельными запусками чистится мусор, выставляется фиксированая ProcessorAffinity (чтобы процесс не скакал между ядрами) и т.д. Возможно, данный проект может быть вам полезен для обеспечения высокой точности замеров времени.
Я сейчас могу ошибаться, давно это было, как-то копался с GDI графикой на compact framework, как раз на предмет ускорения, и заметил следующую вещь, если использовать 32-х битный формат вместо 24-х битного, происходит увеличение быстродействия примерно на 25-30 процентов.
Опять статья о совершенно очевидных вещах. Понятное дело, что указатели будут быстрее двухмерных массивов, которые в свою очередь будут быстрее попиксельных операций.
Из названия и начала статьи показалось, что автор хочет рассказать о каких-то более интересных алгоритмах работы с изображениями, думал, что бенчмарки и чтение — это только начало. Удивился, когда на этом все и закончилось.
Хотя может быть это только первая статья.:)
Хотя может быть это только первая статья.:)
Насчет многомерных массивов — мне в самом начале это было не столь очевидно. Ведь все-таки выполняется не код, скомпилированный в команды процессора, а есть еще промежуточный уровень (MSIL). То, что идет значительная прибавка производительности, также говорит о достаточно высокой эффективности среды исполнения .net. Только в этом случае накладные расходы на проверку выхода за границы размерности и операции вычисления позиции в массиве, будут так сильно сказываться.
Про очевидные вещи — согласен. При накоплении некоторого опыта, это становится очевидно. Собственно, потому в названии статьи и указал «для начинающих». Но пока не пощупаешь сам, что какую выгоду дает, бывает сложно оценить, стоит ли в каком-то случае усложнять код ради этой прибавки. В данном случае хотелось показать как раз не качественно («вот, так быстрее»), а количественно («так быстрее в N раз»).
Про очевидные вещи — согласен. При накоплении некоторого опыта, это становится очевидно. Собственно, потому в названии статьи и указал «для начинающих». Но пока не пощупаешь сам, что какую выгоду дает, бывает сложно оценить, стоит ли в каком-то случае усложнять код ради этой прибавки. В данном случае хотелось показать как раз не качественно («вот, так быстрее»), а количественно («так быстрее в N раз»).
Мне кажется тема быстрой обработки изображений на C# было неплохо раскрыта в AForge.net.
А зачем вам unsafe там, где Marshal.Copy хватает за глаза?
Да, по этому поводу прошу автора статьи добавить в сравнение.
Не совсем. Marshal.Copy просто перенесет данные в другое место в том же порядке. Если мне хочется обрабатывать компоненты отдельно (каждую в своем массиве), то необходимо переставлять. Конечно, не всегда такое нужно, тогда действительно, Marshal.Copy хватит. Более того, в некоторых случаях можно вообще работать с данными Bitmap, никуда их не перенося. Все зависит от того, какая обработка нужна. Например, если нужна обработка с плавающей запятой (как указано в последнем случае), то простым копированием не обойтись.
Only those users with full accounts are able to leave comments. Log in, please.
Работа с растром на низком уровне для начинающих