Брезенхем и У на страже диагоналей

[@RiffKazan]

Странно. Последнее изображение противоречит тексту. Написано, что чем ближе линия к середине пикселя, но при этом 2 пикселя ровно посередине (координаты 2:1 и 3:1) явно светлее своих «пар» (2:0 и 3:2 соответственно), хотя их центры и находятся гораздо ближе к линии

[@JustLuckyGuy]

Простите за занудство. Но мне потребовалось 4 раза перечитать предложение, чтобы понять о чем вы. Так правильнее:

Написано, что чем ближе линия к середине пикселя, тем темнее, но при этом 2 пикселя ровно посередине (координаты 2:1 и 3:1) явно светлее своих «пар» (2:0 и 3:2 соответственно), хотя их центры и находятся гораздо ближе к линии

[@RiffKazan]

да-да, извиняюсь, заметил уже тогда, когда редактировать поздно было…

[@BasmanovDaniil]

Опечатка в тексте, сейчас исправлю.

[@homm]

Это не опечатка, нужно переделывать картинку.

[@BasmanovDaniil]

А, разобрался в чём дело. Я в графическом редакторе вырезал не тот кусок линии.

[@BasmanovDaniil]

Переделал иллюстрации. Морока с этим фотошопом пиксели увеличивать, всё норовит сгладить.

[@kyrie]

Я обычно это принтскрином делаю, не всегда подходит, но в целом быстро и просто.

[@Ogi]

Увеличивайте с интерполяцией по соседним пикселям (Nearest neighbor).

[@Arilas]

Линия пересекает боковые центры этих пикселей (нижний и верхний), а не центр пикселя (геометрический).

[@TheShock]

раньше там было другое, неправильное, изображение

[@bsideup]

В прекрасном университете ИТМО лабораторная по компьютерной графике писалась на ASM, а задание было нарисовать свою фамилию начертанием «от руки». Все, кто хотят вызубрить эти алгоритмы — Welcome to IFMO!:)

Не для слабонервных

[@Arrest]

По-моему, тут нет сглаживания.

[@Rast1234]

Так монохромная картинка же. Раз на ASM-е делалось, явно проще в двух цветах работать, чем загружать свою палитру, например.

[@hannimed]

Про самую первую картинку: мне на 100% нравится вариант слева — глаза не устают.

[@BasmanovDaniil]

Ничего удивительного, алгоритм У Сяолиня для рисования гладких линий за двадцать с лишним лет успел устареть. На замену ему напридумывали множество других алгоритмов, в том же фотошопе линии рисуются иначе, зато он по-прежнему остаётся очень простым в реализации.

[@Arilas]

Сейчас происходит дополнительно утяжеление линии, для того, чтобы она не выглядела резаной. Утяжеление расширяет количество смежных пикселей на некоторое значение, которое сглаживает линию.

[@AxisPod]

Жуть, Брезенхем с плавающей точкой, извращение. Это целочисленный алгоритм, на кой черт там float. В той же вики есть пример на C++, целочисленный.

[@BasmanovDaniil]

Разумеется, но приведённый выше читается легче. Во время подготовки статьи я нашёл море разных оптимизаций, но не могу же я их все привести?

[@fyga]

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

[@homm]

Это все еще актуально. см мою недавнюю историю.

[@fyga]

Всегда можно найти задачу где применение целочисленной арифметики оправданно. Просто раньше их и искать не надо было.

[@dr_brain]

В статье не указанно, в чём преимущество алгороитма Брезенхема. А именно: в цикле рисования не используется умножение и деление, что было очень актуально, когда процессоры были большие и медленые.

[@qehgt]

Оно и сейчас актуально.

[@CENTUR10N]

Спасибо за алгоритм сглаженной линии. Брезенхем для сеток давно использовал уже. Не хватает примеров в 100% масштабе. По увеличенным понятно, как оно должно выглядеть, но, иногда, в 100% масштабе выглядит все не так, как представляется.

[@BasmanovDaniil]

Посмотрите на новые картинки, надеюсь, стало понятнее.

[@cdkrot]

(y1 — у0)/(x1 — x0)

А если x1=x0?

[@BasmanovDaniil]

Тогда деление на ноль. Кроме вертикальной линии, есть ещё три других особых ситуаций: горизонтальная линия, диагональ под 45 градусов и точка. Их можно обрабатывать в начале и рисовать другими способами.

[@Triang3l]

Тогда memset или цикл с присваиванием, что к тому же быстрее.

[@Triang3l]

Ошибся, memset — для горизонтальной. Для вертикальной — только цикл.

[@Triang3l]

А для диагональной — тот же цикл, но со сдвигом на 1 в обоих измерениях, а не в одном.
А потом можно прогнать тот же цикл около линии с каждой стороны и на 2 пикселя короче с прозрачностью, скажем, 1-sqrt(2), для сглаживания.

[@Triang3l]

(1-sqrt(2))/2 даже, наверно, потому что с двух сторон.

[@Triang3l]

То есть (1-sqrt(2)/2)/2, забыл поделить корень на 2.

[@cdkrot]

(y1 — у0)/(x1 — x0)

А если x1=x0?
Извините

[@cdkrot]

(y1 — у0)/(x1 — x0)

А если x1=x0?

[@jakobz]

Нужно наверное еще гамму учитывать — код цвета пикселя вроде как нелинейно связан с его яркостью. Линии будут менять визуально толщину в зависимости от наклона.

Кроме того, по этому алгоритму концы отрезка получаются неправильные — скошенные по вертикали. Через это непонятно что будет на стыках двух отрезков.

Короче я бы все-таки взял какую-нибудь готовую библиотеку для рисования вектора, нетривиальная это задача.

[@spacediver]

Если вы не из параллельной вселенной, где все сидят за векторными мониторами

Я из параллельной вселенной, где на векторные гипертекстовые мониторы выводятся (исключительно ради обратной совместимости!) эти ваши растровые изображения — в виде совокупности закрашенных квадратных фигур со сторонами, параллельными краям монитора.

Бррр. Расточительный расход экранной площади.

[@TheShock]

в виде совокупности закрашенных квадратных фигур со сторонами, параллельными краям монитора

Это и есть растр.

[@spacediver]

вот-вот. И больше ничего из него не извлечешь.

Хоть векторизуй, в самом деле.

[@Theo_from_Sed]

Да вы, батенька, весельчак!

[@muradali]

Поглядите на эту полоску: /. Если придвинуться поближе к монитору, то можно увидеть пиксельные ступеньки, которые пытаются притвориться векторной линией.

Те у кого ретина, разглядеть не смогут как ни придвигайся. ))