Y a-t-il une raison pour laquelle le logo d'Hillary Clinton a des entailles cachées?

226

Cette question n'est pas du tout politique!

En regardant la version SVG du logo d'Hillary trouvée ici , j'ai remarqué qu'il y avait des encoches dans les deux barres verticales du H. La barre transversale en forme de flèche recouvre les encoches afin qu'elles ne soient pas visibles lors de l'affichage du logo. Mais je suis très curieux de savoir pourquoi le designer aurait pu mettre ces encoches. Est-ce que quelqu'un sait?

logo svg best-practice

— IJ Kennedy
source

53

Techniquement, il s'agit d'un système de contournement de bogues. C'est un peu surprenant et troublant de penser que toutes les universités et les principaux constructeurs de moteurs de rendu 2D font la même erreur encore et encore, même si nous en connaissons la cause, nous savons comment le réparer, ce qui n'est pas un énorme succès en termes de performances. sur un ordinateur moderne. Et personne n’a rarement cette erreur et le sait depuis plus de 30 ans.

— joojaa

6

@NickT Ce n'est pas un problème de combat mais un problème de mélange d'opacité et de couverture, mais la 3D est bien plus que des jeux. En 3D, nous utilisons depuis longtemps le multi-échantillonnage pour résoudre le problème aa. Le multi-échantillonnage (même si les résultats ne sont pas aussi prononcés) ne calcule pas la couverture et ne commet donc pas l'erreur de penser qu'une couverture à 50% correspond à 25% visible à travers une couverture supplémentaire à 50%. Bien que cela puisse être vrai, la réponse peut également être 50% visible ou aucun visible. Dans ce cas, pour éviter toute confusion, les 50% restants étant supprimés manuellement, nous pouvons corriger 3 cas mais pas tous. Ne devrait pas être nécessaire.

— Joojaa

5

Il est regrettable que j’ai clairement reconnu que cela évitait un problème de rendu des frontières qui se chevauchaient. Mais SVG a toujours 14 ans et j'espère que cela sera corrigé un jour.

— Francisco Presencia

5

@FranciscoPresencia ce n'est pas un problème avec SVG, c'est juste un problème avec la façon dont nous choisissons de mettre en œuvre par erreur les rendus. Différents moteurs de rendu SVG ont une gravité différente de ce problème

— joojaa

12

@ DA01 no le correctif naïf est incroyablement simple, son moins de code que l'algorithme actuel. Au lieu d'effectuer un calcul basé sur la couverture, effectuez un rendu comme si vous n'aviez pas d'antialias sur une résolution supérieure, puis filtrez l'image à la résolution réelle. Cela ne se répercutera jamais de bas en haut car il ne peut pas se tromper, l'élément le plus en face le masque complètement. Les cartes graphiques font tout ce temps ce que les paramètres x4 x8 x16 aa sont dans les paramètres de la carte gfx.

— Joojaa

233

Pour éviter les artefacts de rendu possibles.

Sans les encoches, vous risquez de voir les bords des formes du bas là où ils se rencontrent (si cela reste visible à l'écran, ce n'est pas vraiment un problème lors de l'impression).

Vous pouvez voir des exemples et des explications sur les artefacts possibles ici:

Il y a rarement une raison d'avoir des bords parfaitement alignés qui pourraient causer de tels artefacts, aussi utiliser des "encoches" comme dans le logo d'Hillary est une bonne habitude.

— Cai
source

6

Cela peut en fait être un gros problème d’impression. En impression numérique, au moins svg sera rastérisé avant d’être envoyé à l’imprimante et les mêmes types d’artefacts peuvent apparaître. (Le dernier projet de mon dernier employeur (grand imprimeur commercial) impliquait la création d'un logiciel permettant d'identifier ce genre de choses avant que le travail coûteux consistant à mettre de l'encre sur du papier ne soit effectué.)

— Mr.Mindor

1

Puisque nous parlons de politique américaine, vous voulez dire "artefacts"?

— Andrew Rasmussen

5

Selon english.se, je veux dire des artefacts, pas des artefacts. (Mais depuis que je suis britannique, je veux dire des artefacts malgré tout)

— Cai

Il y a rarement une raison ... juste curieuse: y a- t- il jamais une raison?

— Alois Mahdal

@AloisMahdal J'en doute fort.

— Cai

61

Comprendre la rastérisation et l'algorithme du peintre peut aider.

Une façon de rendre des graphiques vectoriels (graphiques définis par des polygones au lieu de pixels) consiste à pixelliser les polygones lors de l'exécution de l'algorithme du peintre.

L'algorithme du peintre est un processus de bas en haut dans lequel vous commencez par placer l'arrière-plan, puis vous dessinez par-dessus cet arrière-plan avec chaque calque de couleur jusqu'à atteindre le calque supérieur.

Lorsque vous déposez un calque, vous portez une attention particulière à sa couverture (généralement stockée dans un canal supplémentaire, le canal alpha), et vous l'utilisez pour mélanger la couleur ajoutée à ce qui existe déjà.

Si votre nouveau calque recouvre un pixel à 50% et qu'il est bleu, vous faites la moyenne de la couleur actuelle de ce pixel avec du bleu et vous y tracez à la place.

Les choses deviennent un peu plus complexes si vous créez une image avec transparence, mais pas fondamentalement.

La rastérisation est le processus de transformation d'un polygone en pixels. Ici, nous calculons combien de polygones recouvre un pixel donné en utilisant une algèbre, puis calculons un montant de couverture.

Si vous avez deux bords d'un polygone qui coïncident - exactement l'un sur l'autre - mais que les deux couvrent à moitié un pixel donné, il se produit un problème.

Supposons que le polygone inférieur soit rouge et que le haut bleu et l'arrière-plan soient blancs.

Nous peignons d'abord le rouge. Cela se mélange avec le blanc, conduisant à 50% de blanc, 50% de rouge.

Nous peignons ensuite le bleu. Cela se mélange avec le 50% blanc 50% rouge et nous obtenons 25% blanc 25% rouge 50% bleu. La même chose se produit si le rouge et le bleu se rencontrent au milieu ou si le bleu recouvre complètement le rouge.

Mais "en réalité" le polygone bleu recouvrait complètement le polygone rouge, alors pourquoi le voyons-nous? Parce que l'algorithme oublie les détails de positionnement sous-pixel.

Tant qu'il y a une couverture à 100% d'un polygone, cela ne pose pas de problème.

Maintenant, ce problème n'est pas fondamental. Vous pouvez effectuer le rendu des polygones avec une approche du type tracé de rayons (où vous effectuez un sur-rendu du facteur N ^ 2 par points), ou même une approche du type pur vecteur (où vous soustrayez des formes bloquantes de la géométrie des formes sous-jacente). eux, en les découpant). Dans aucun cas, les couleurs "cachées" ne traversent l'image de sortie.

L'algorithme du peintre n'est pas le seul cas où une géométrie "cachée" peut s'infiltrer. Si vous imprimez avec un support opaque, les couches de couleurs ne sont parfois pas parfaitement alignées. Les sous-couches traversent donc lorsque la couche supérieure devrait la recouvrir complètement.

Comme vous ne savez pas comment votre image vectorielle sera imprimée, de tels encoches vous permettent de créer des images plus robustes face aux techniques d'impression / d'affichage imparfaites.

— Yakk
source

1

Votre description s’applique dans le cas de graphiques contenant des canaux alpha, ou dans le cas d’un dessin sous-pixel lors d’un anti-crénelage. L'exemple de PO affichera les artefacts d'entaille pour les couches mélangées contrairement à ce qui était prévu. Je dirais que le problème est davantage lié aux erreurs d'enregistrement lors de l'impression.

— Pekka

2

@pekka oui, mais la plupart des rendus rendent l'anti-aliasing aujourd'hui.

— Yakk

Si la couche supérieure présente une transparence, l'encoche entraînera un retrait progressif de la couche inférieure à partir du bord, ce qui aura un impact sur l'anti-aliasing et la couleur de niveau supérieur. Une solution plus appropriée consisterait à créer un rabais rectangulaire (d’une taille difficile à estimer) dans la zone où le mélange n’est pas souhaité. Comment quantifiez-vous cela?

— Pekka

@pekka Si la couche supérieure a une transparence moyenne, ce problème est beaucoup moins problématique (vous pouvez voir le rouge sous le bleu de toute façon). À mesure que la transparence du sommet s'approche de l'opacité, approchez-vous de la solution ci-dessus. Quand il s’éloigne de l’opacité, approchez-le avant de le composer. Le problème général est délicat, compte tenu des erreurs d’inscription, des problèmes de construction (trop de couches!), De l’anti-aliasing et de tout le reste: à un moment donné, vous souhaitez écrire des vecteurs personnalisés pour chaque format de sortie ou les modifier. J'ai simplement essayé de répondre à la cause technique exacte du problème résolu par l'entaille.

— Yakk

1

@Pekka un rectangle est plus difficile à dessiner et vous terminez avec le problème opposé du même problème en ce sens que l'arrière-plan montre un creux. L'encoche est en quelque sorte un compromis entre un bogue et plusieurs autres (l'encoche est destinée au rendu à l'écran car elle ne présente pas de cavité carrée, de sorte que les surimpressions peuvent être réalisées au besoin avec un minimum d'erreurs). Mais il n'y a vraiment aucune raison pour qu'il y ait un besoin de le faire, c'est juste que nos moteurs de rendu fonctionnent mal et que tout y est. Nous pourrions tous les 3 problèmes facilement en changeant la façon dont nous rastérisons.

— Joojaa

48

Cai a raison. Je pensais ajouter une réponse visuelle également.

La raison en est que c'est un SVG. Contrairement à une image raster dans laquelle vous contrôlez chaque pixel rendu, la pixellisation du fichier SVG a lieu dans le navigateur ... afin que le navigateur prenne ces décisions.

Une des décisions que doit prendre le navigateur est le moment opportun pour l’anti-aliasing. Cela se produit généralement lorsqu'un point le long d'une ligne tombe sur un pixel. Il sera alors anti alias de ce pixel. Puisqu'il rendra toutes les couches du fichier SVG, il le fera pour chaque couche et c'est là que vous pouvez commencer à obtenir l'artefact de bord. Cela est particulièrement vrai lorsque vous jouez avec le zoom du SVG, car cela entraînerait le chevauchement de différents pixels de l'écran.

Voici une capture d'écran d'une boîte verte chevauchant une boîte rouge dans Chrome. Le haut est au zoom de 100%, le bas est agrandi. Notez la différence de rendu de ce bord:

Si je fais une capture d'écran et que je fais un zoom avant pour afficher la pixellisation, vous pouvez obtenir une image plus claire de ce qui se passe:

La solution idéale ici serait que le rastériseur SVG dans le navigateur soit "plus intelligent" et ne rende pas les éléments empilés, mais étant donné que les éléments SVG peuvent être manipulés en externe et utilisés (ce n'est qu'un fichier XML), ce n'est pas une solution pratique. pour le navigateur.

Le concepteur prend donc cette décision en utilisant les encoches que vous voyez.

Soit dit en passant, le concept est similaire à la manière de traiter un enregistrement dans l’impression en utilisant le recouvrement .

— DA01
source

16

L'impression dans plusieurs couleurs nécessite un enregistrement précis pour éviter les espaces disgracieux et constitue un problème lorsque les artefacts proviennent de plusieurs sources. Des problèmes similaires peuvent survenir même dans les produits numériques où l'arithmétique de précision limitée introduit nécessairement une erreur.

Le problème à éviter est celui du recouvrement inverse - dans lequel une déviation par rapport au graphique souhaité peut entraîner une fine ligne de la couleur d'arrière-plan sur la gauche des bords coïncidents verticaux. Les couleurs étant très contrastées, l’impact sera perceptible (essayez de déplacer la ligne brisée de 1 pixel à gauche de la verticale).

L'approche n'est pas destinée à avoir un impact sur le mélange des encres. Les coordonnées cohérentes à l'écran évitent le problème, tandis que la demi-teinte est utilisée pour gérer les couleurs.

— Pekka
source