Есть ли причина, по которой на логотипе Хиллари Клинтон есть скрытые выемки?

Этот вопрос ни в малейшей степени не политический!

введите описание изображения здесь

Глядя на SVG-версию логотипа Хиллари, найденную здесь , я заметил, что в двух вертикальных полосах буквы H есть выемки. Перекладина со стрелками закрывает выемки, поэтому их не видно при просмотре логотипа. Но мне очень любопытно, почему дизайнер сделал эти выемки. Кто-нибудь знает?

введите описание изображения здесь

Технически это схема обхода ошибок. Немного удивительно и тревожно думать, что все университеты и основные поставщики движков 2D-рендеринга повторяют одну и ту же ошибку снова и снова, даже если мы знаем причину, мы знаем, как ее исправить, и это не так уж сильно влияет на производительность. на современном компьютере. И люди без 3D-графики редко совершают эту ошибку и знают об этом уже 30+ лет.
@joojaa как это применимо в 3D? Я думал о Z-файтинге, но это все еще не так уж редко встречается в видеоиграх (по общему признанию, перестановки степеней свободы, полигонов, шейдеров, позиций моделей и т. д. практически бесконечны по сравнению с созданием конкретной 3D-графики).
@NickT Это не проблема боя, а проблема смешивания непрозрачности и покрытия, но 3D - это гораздо больше, чем игры. В 3D мы веками использовали мультисэмплинг для решения проблемы аа. Мультисэмплинг (обычно, даже если бы результаты были не столь выраженными) не рассчитывает покрытие и, таким образом, не совершает ошибку, полагая, что 50%-е покрытие — это 25%-е покрытие через другие 50%-е покрытие. Хотя это может быть правдой, ответ также может быть виден на 50% или ничего не видно. В этом случае, чтобы избежать путаницы, остальные 50% удаляются вручную, мы можем исправить 3 случая, но не все. Не должен быть нужен.
Печально, что я четко распознал это, чтобы избежать ошибки рендеринга перекрывающихся границ. Но SVG все еще 14 лет, поэтому я надеюсь, что когда-нибудь это исправят.
@FranciscoPresencia это не проблема с SVG, это просто проблема с тем, как мы ошибочно реализуем рендеринг. Различные средства визуализации SVG имеют разную серьезность этой проблемы.
@joojaa, но его все еще можно добавить в спецификацию, как правильно отображать
@joojaa Я не думаю, что это простое «исправление». «Ошибка» имеет смысл, если вы думаете о том, что каждый элемент SVG растеризуется индивидуально... именно так работает SVG. Если вектор лежит в пикселе, должен быть один пиксель сглаживания. Я вижу, что в чисто статическом SVG можно добавить некоторую логику, чтобы маскировать элементы под другими, но поскольку вы можете делать такие вещи, как анимация SVG, я вижу, что это гораздо более сложная часть ИИ, которую нужно было бы написать.
@ DA01 нет, наивное исправление невероятно простое, в нем меньше кода, чем в текущем алгоритме. Вместо того, чтобы выполнять расчет на основе покрытия, просто визуализируйте, как если бы вы вообще не применяли сглаживание на более высоком разрешении, а затем отфильтруйте изображение до реального разрешения. Это никогда не будет проливаться снизу вверх, так как он не может ошибиться, поскольку самый передний элемент полностью его закрывает. Видеокарты делают это все время, что и настройки x4 x8 x16 aa в настройках карты gfx.
@joojaa ах, да ... это интересное решение.
@joojaa Даже при использовании обычных 3D-движков вам нужно избегать Т-образных соединений, поскольку в противном случае ошибки округления положения вершин могут привести к дырам или перекрытиям. В данном случае это означает добавление вершин к синей полосе, где левая часть левой синей полосы пересекает стрелку. (Пока вы не поворачиваете логотип, это может не повлиять на этот случай из-за выравнивания фигуры по сторонам света, поэтому, вероятно , вам будет хорошо без них)
@codesInChaos я знаю об этом.
это просто хорошая практика, чтобы избежать проблем с печатью - ничего страшного.
@joojaa проблема в том, что вам нужно знать, когда уменьшать частоту дискретизации. И если вы одновременно храните версию с повышенной и пониженной частотой дискретизации, вы получите разработчиков, которым нужен доступ к пикселям этого буфера с повышенной частотой дискретизации. Вторая проблема заключается в хранении такого большого объема данных в памяти. (Вы уже можете сделать это в Javascript, кстати: просто сделайте растр холста в два раза больше, чем пространство, в котором он отображается)
@JanDvorak Итак, вы предпочитаете ошибки, потому что это проще? Ваш банк также может избежать округления и просто обрезать числа, потому что это удобно (боже, они были бы рады это сделать). Но нет, вам не нужно хранить буфер дольше, чем вам нужно, чтобы отфильтровать его. Я знаю, что это можно сделать, просто это не делается по умолчанию, а это означает, что каждый графический дизайнер в мире каждый год тратит часы на отладку этих проблем. Сейчас у меня тоже нет доступа.

Ответы (4)

Для предотвращения возможных артефактов рендеринга.

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

Вы можете увидеть примеры и объяснение возможных артефактов здесь:

Редко есть какая-либо причина иметь идеально выровненные края, которые могут вызвать подобные артефакты, поэтому использование «выемок», как в логотипе Хиллари, является хорошей привычкой.

На самом деле это может быть такой же большой проблемой при печати. При цифровой печати, по крайней мере, svg обычно растрируется перед отправкой на принтер, и могут появляться те же типы артефактов. (последний проект у моего последнего работодателя (крупная коммерческая типография) включал в себя написание программного обеспечения, помогающего идентифицировать подобные вещи до того, как была сделана дорогостоящая работа по нанесению чернил на бумагу.)
Раз уж мы говорим о политике США, вы имеете в виду «артефакты»?
Согласно english.se , я имею в виду артефакты, а не артефакты. (Но поскольку я британец, я имею в виду артефакты в любом случае)
Редко бывает какая-то причина... просто любопытно: а есть ли вообще какая-то причина?
@AloisMahdal Я очень в этом сомневаюсь.
@AloisMahdal Да, когда речь идет о прозрачности. В идеале вы должны использовать программное обеспечение/формат, которые могут сделать это хорошо, но это не всегда так.

Понимание растеризации и алгоритма художника может помочь.

Один из способов рендеринга векторной графики (графика, определяемая полигонами, а не пикселями) в пиксели состоит в растеризации полигонов во время выполнения алгоритма рисовальщика.

Алгоритм художника — это восходящий процесс, когда вы сначала кладете фон, а затем рисуете поверх этого фона каждым слоем цвета, пока не достигнете верхнего слоя.

Когда вы наносите слой, вы обращаете внимание на его покрытие (обычно хранится в дополнительном канале, альфа-канале) и используете его для смешивания добавленного цвета с тем, что уже есть.

Если ваш новый слой покрывает пиксель на 50%, и он синий, вы усредняете текущий цвет этого пикселя синим цветом и вместо этого рисуете его там.

Все становится немного сложнее, если вы создаете изображение с прозрачностью, но не принципиально.

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

Если у вас есть два ребра многоугольника, которые совпадают — точно друг над другом — но оба наполовину покрывают заданный пиксель, возникает проблема.

Предположим, что нижний полигон красный, верхний синий, а фон белый.

Сначала красим красным. Это смешивается с белым, что приводит к 50% белого и 50% красного.

Затем рисуем синим цветом. Это смешивается с 50% белого, 50% красного и мы получаем 25% белого, 25% красного, 50% синего. То же самое происходит, если красный и синий встречаются посередине или если синий полностью покрывает красный.

Но «на самом деле» синий многоугольник полностью перекрыл красный, так почему же мы его видим? Потому что алгоритм забывает детали позиционирования субпикселей.

Пока есть 100% покрытие одного полигона, это не проблема.

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

Алгоритм художника — не единственный случай, когда может просочиться «скрытая» геометрия. Если вы печатаете на непрозрачном носителе, иногда цветовые слои не совпадают идеально. Таким образом, нижние слои просачиваются, когда верхний слой должен полностью их покрывать.

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

Ваше описание применимо в случае графики, содержащей альфа-каналы, или в случае субпиксельной отрисовки при сглаживании. Пример OPs покажет артефакты надрезов для смешанных слоев вопреки тому, что предполагалось. Я бы предположил, что проблема больше связана с ошибками регистрации при печати.
@pekka да, но сегодня большая часть рендеринга использует сглаживание.
Если верхний слой имеет некоторую прозрачность, то надрез приведет к постепенному оттягиванию нижнего слоя от края, что повлияет как на сглаживание, так и на цвет верхнего уровня. Более подходящим ответом было бы наличие прямоугольного фальца (размера, который трудно оценить) в области, где смешивание нежелательно. Как вы это измеряете?
@pekka Если верхний слой имеет среднюю степень прозрачности, эта проблема гораздо менее проблематична (поскольку вы все равно можете видеть красный цвет под синим). По мере того, как прозрачность верха приближается к непрозрачности, подходите к приведенному выше решению. Когда он уходит от непрозрачности, подойдите к его предварительному композитингу. Общая проблема сложна, учитывая ошибки регистрации, проблемы с наращиванием (слишком много слоев!), сглаживание и все остальное: в какой-то момент вы хотите написать собственные векторы для каждого выходного формата или как-то смешать векторы. Я просто попытался ответить на точную техническую причину проблемы, которую решает вырез.
@Pekka, прямоугольник рисовать сложнее, и тогда вы заканчиваете противоположной проблемой той же проблемы, заключающейся в том, что фон показывает желоб. Выемка — это своего рода компромисс между одной ошибкой и рядом других (выемка предназначена для рендеринга на экране, а отсутствие квадратной полости — для того, чтобы при необходимости можно было делать пластины с надпечаткой с минимальными ошибками). Но на самом деле нет никакой необходимости делать это, просто наши рендереры работают неправильно, вот и все. Мы легко справились со всеми тремя проблемами, изменив способ растрирования.

Кай прав. Я подумал, что добавлю и визуальный ответ.

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

Одно из решений, которое должен принять браузер, — когда выполнять сглаживание. Обычно это происходит, когда точка вдоль линии попадает на пиксель. Затем он будет сглаживать этот пиксель. Поскольку он будет отображать все слои SVG, он будет делать это для каждого слоя, и именно здесь вы можете начать получать артефакты краев. Это особенно верно, когда вы играете с масштабированием SVG, так как это приведет к перекрытию разных пикселей экрана.

Вот снимок экрана с зеленым полем, перекрывающим красное поле в Chrome. Верхняя часть страницы увеличена на 100%, нижняя увеличена. Обратите внимание на разницу в отображении этого края:

введите описание изображения здесь

Если я сделаю снимок экрана и увеличу масштаб, чтобы показать растеризацию, вы сможете получить более четкое представление о том, что происходит:

введите описание изображения здесь

Идеальным решением здесь было бы, чтобы растеризатор SVG в браузере был «умнее» и не отображал вещи, которые сложены, но, учитывая, что элементами SVG можно манипулировать извне и жить (поскольку это просто файл XML), это не практичное решение. для браузера.

Вместо этого дизайнер принимает это решение, используя выемки, которые вы видите.

Кстати, по идее это похоже на то, как работать с регистрацией в печати с помощью треппинга .

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

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

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