¿Hay alguna razón por la que el logo de Hillary Clinton tiene muescas ocultas?

¡Esta pregunta no es política en lo más mínimo!

ingrese la descripción de la imagen aquí

Mientras miraba la versión SVG del logotipo de Hillary que se encuentra aquí , noté que había muescas en las dos barras verticales de la H. La barra transversal de la flecha cubre las muescas para que no se vean al ver el logotipo. Pero tengo mucha curiosidad de por qué el diseñador podría haber puesto estas muescas. ¿Alguien sabe?

ingrese la descripción de la imagen aquí

Técnicamente, este es un esquema de elusión de errores. Es un poco sorprendente e inquietante pensar que todas las universidades y los principales proveedores de motores de renderizado 2D cometen el mismo error una y otra vez, aunque sabemos la causa, sabemos cómo solucionarlo y no es un gran impacto en el rendimiento. en una computadora moderna. Y ninguna gente de gráficos 3D rara vez comete este error y lo han sabido durante más de 30 años.
@joojaa, ¿cómo se aplica esto en 3D? Pensé en Z-fighting, pero eso todavía no es terriblemente raro en los videojuegos (es cierto que las permutaciones de grados de libertad, polígonos, sombreadores, posiciones de modelos, etc. son prácticamente infinitas en comparación con la creación de un gráfico 3D específico)
@NickT No es un problema de lucha az, es un problema de mezclar opacidad y cobertura, pero 3D es mucho más que juegos. En 3D hemos utilizado durante años el multimuestreo para resolver el problema de aa. El multimuestreo (por lo general, incluso si lo hiciera, los resultados no serían tan pronunciados) no calcula la cobertura y, por lo tanto, no comete el error de pensar que una cobertura del 50% es visible en un 25% a través de otra cobertura del 50%. Si bien esto puede ser cierto, la respuesta también puede ser 50% visible o ninguno visible. En este caso, para evitar confusiones, el otro 50 % se elimina manualmente. Podemos arreglar 3 casos, pero no todos. No debería ser necesario.
Es triste que lo reconocí claramente para evitar un error de representación de bordes superpuestos. Pero SVG todavía tiene 14 años, así que espero que esto se arregle algún día.
@FranciscoPresencia no es un problema con SVG, es solo un problema con la forma en que elegimos implementar erróneamente los renders. Diferentes renderizadores SVG tienen diferente gravedad de este problema
@joojaa pero aún podría agregarse a la especificación de cómo representarlo correctamente
@joojaa Sin embargo, no creo que sea una simple 'solución'. El 'error' tiene sentido si piensas en que cada elemento del SVG se rasteriza individualmente... que es exactamente cómo funciona un SVG. Si un vector se encuentra en un píxel, tiene que haber ese píxel de suavizado. En un SVG puramente estático, veo que se podría agregar algo de lógica para enmascarar elementos debajo de otros, pero dado que puedes hacer cosas como animar SVG, veo que sería una IA mucho más compleja que tendría que escribirse.
@ DA01 no, la solución ingenua es increíblemente simple, es menos código que el algoritmo actual. En lugar de hacer un cálculo basado en la cobertura, simplemente renderice como si no tuviera suavizado en absoluto en una resolución más alta y luego filtre la imagen a una resolución real. Esto nunca se derramará de abajo hacia arriba ya que no puede cometer un error, el elemento más frontal lo oscurece por completo. Las tarjetas gráficas hacen esto todo el tiempo de lo que se trata la configuración x4 x8 x16 aa en la configuración de la tarjeta gfx.
@joojaa ah, sí... esa es una solución interesante.
@joojaa Incluso al usar los motores 3D habituales, debe evitar las juntas en T, ya que de lo contrario los errores de redondeo de la posición del vértice pueden generar agujeros o superposiciones. En este caso, esto equivale a agregar vértices a la barra azul donde la izquierda de la barra azul izquierda se cruza con la flecha. (Mientras no gire el logotipo, es posible que no afecte este caso debido a la alineación de la figura con los puntos cardinales, por lo que probablemente estaría bien sin ellos)
@codesInChaos soy consciente de esto.
es simplemente una buena práctica para evitar problemas de impresión, no es gran cosa.
@joojaa el problema con esto es que necesitas saber cuándo reducir la muestra. Y si tiene tanto la versión aumentada como la reducida al mismo tiempo, terminará con desarrolladores que desean acceso de píxeles a ese búfer aumentado. Un segundo problema es mantener esta cantidad de datos en la memoria. (Ya puede hacer esto en Javascript, por cierto: solo tenga el ráster del lienzo dos veces más grande que el espacio en el que se representa)
@JanDvorak Entonces, ¿prefiere los errores porque es más fácil? Su banco también podría evitar el redondeo y simplemente truncar los números porque es conveniente (muchacho, estarían encantados de hacerlo). Pero no, no necesita almacenar el búfer más de lo que le lleva filtrarlo. Sé que se puede hacer, es solo que no se hace de forma predeterminada, lo que significa que todos los diseñadores gráficos del mundo pasan horas todos los años depurando estos problemas. No es como si tuviera acceso ahora tampoco.

Respuestas (4)

Para evitar posibles artefactos de renderizado.

Sin las muescas, es probable que vea los bordes de las formas inferiores donde se encuentran con los bordes de las formas superpuestas (en la pantalla, de todos modos, no es realmente un problema al imprimir).

Puede ver ejemplos y explicaciones de los posibles artefactos aquí:

Rara vez hay alguna razón para tener bordes perfectamente alineados que causen artefactos como ese, por lo que usar "muescas" como en el logotipo de Hillary es un buen hábito.

En realidad, esto puede ser un problema igual de grande con la impresión. En la impresión digital, al menos el svg normalmente se rasterizará antes de enviarse a la impresora, y pueden aparecer los mismos tipos de artefactos. (El último proyecto en mi último empleador (una gran imprenta comercial) involucró la creación de software para ayudar a identificar este tipo de cosas antes de que se hiciera el costoso trabajo de poner tinta en el papel).
Ya que estamos hablando de la política estadounidense, ¿te refieres a "artefactos"?
Según english.se me refiero a artefactos, no artefactos. (Pero como soy británico, me refiero a artefactos independientemente)
Rara vez hay alguna razón... solo curiosidad: ¿alguna vez hay alguna razón?
@AloisMahdal Lo dudo mucho.
@AloisMahdal Sí, cuando se trata de transparencia. De manera óptima, utiliza un software/formato que puede hacer esto bien, pero no siempre es así.

Comprender la rasterización y el algoritmo del pintor podría ayudar.

Una forma de representar gráficos vectoriales (gráficos definidos por polígonos, en lugar de píxeles) en píxeles es rasterizar los polígonos mientras se ejecuta el algoritmo del pintor.

El algoritmo del pintor es un proceso de abajo hacia arriba en el que primero colocas el fondo, luego dibujas encima de ese fondo con cada capa de color hasta llegar a la capa superior.

Cuando deposita una capa, presta atención a su cobertura (generalmente almacenada en un canal adicional, el canal alfa) y la usa para mezclar el color agregado con lo que ya está allí.

Si su nueva capa cubre un píxel en un 50% y es azul, promedia el color actual de ese píxel con azul y lo dibuja allí.

Las cosas se vuelven un poco más complejas si está creando una imagen con transparencia, pero no fundamentalmente.

La rasterización es el proceso de convertir un polígono en píxeles. Aquí, calculamos cuánto cubre el polígono un píxel dado usando algo de álgebra, luego calculamos la cantidad de cobertura.

Si tiene dos bordes de un polígono que son coincidentes, exactamente uno encima del otro, pero ambos cubren la mitad de un píxel determinado, lo que sucede es un problema.

Supongamos que el polígono inferior es rojo y el superior azul y el fondo es blanco.

Primero pintamos el rojo. Esto se mezcla con el blanco, dando lugar a 50% blanco y 50% rojo.

Luego pintamos el azul. Esto se mezcla con el 50% blanco 50% rojo y obtenemos 25% blanco 25% rojo 50% azul. Lo mismo sucede si el rojo y el azul se encuentran en el medio, o si el azul cubre completamente al rojo.

Pero "en realidad" el polígono azul cubrió completamente al rojo, entonces ¿por qué lo estamos viendo? Porque el algoritmo olvida los detalles de posicionamiento de subpíxeles.

Siempre que haya una cobertura del 100% de un polígono, esto no es un problema.

Ahora bien, este problema no es fundamental. Puede hacer renderizado de polígonos con un enfoque similar al trazado de rayos (donde sobre-renderiza por un factor de N ^ 2 en los puntos), o incluso un enfoque de vector puro (donde resta formas de bloqueo de la geometría de las formas debajo ellos, recortándolos). En ninguno de los casos, los colores "ocultos" se filtran a la imagen de salida.

El algoritmo del pintor no es el único caso en el que la geometría "oculta" puede filtrarse. Si está imprimiendo con medios opacos, a veces las capas de color no están perfectamente alineadas. Por lo tanto, las capas inferiores se filtran cuando la capa superior debería cubrirlas por completo.

Como no sabe cómo se generará su imagen vectorial, muescas como esa le permiten crear imágenes que son más sólidas frente a técnicas de impresión/visualización imperfectas.

Su descripción se aplica en el caso de gráficos que contienen canales alfa, o en el caso de dibujo de subpíxeles cuando se aplica suavizado. El ejemplo de OP mostrará los artefactos de muesca para capas combinadas en contra de lo que se pretende. Sugeriría que el problema está más relacionado con los errores de registro en la impresión.
@pekka sí, pero hoy en día la mayoría de las renderizaciones tienen suavizado.
Si la capa superior tiene alguna transparencia, la muesca dará como resultado un retroceso gradual de la capa inferior desde el borde, lo que afectará tanto al suavizado como al color del nivel superior. Una respuesta más apropiada sería tener un rebaje rectangular (de un tamaño difícil de estimar) en el área donde no se desea mezclar. ¿Cómo cuantificas esto?
@pekka Si la capa superior tiene cantidades medias de transparencia, este problema es mucho menos problemático (como puede ver el rojo debajo del azul de todos modos). A medida que la transparencia de la parte superior se acerca a la opacidad, acérquese a la solución anterior. A medida que se aleja de la opacidad, acérquese a la composición previa. El problema general es complicado dados los errores de registro, los problemas de acumulación (¡demasiadas capas!), el suavizado y todo lo demás: en algún momento, desea escribir vectores personalizados para cada formato de salida, o modificar los vectores de alguna manera. Simplemente traté de responder la causa técnica exacta del problema que resuelve la muesca.
@Pekka, un rectángulo es más difícil de dibujar y luego terminas con el problema opuesto del mismo problema en el que el fondo se muestra a través. La muesca es una especie de compromiso entre un error y varios otros (la muesca es para la representación en pantalla, mientras que al no tener una cavidad cuadrada, se pueden hacer placas de sobreimpresión si es necesario con errores mínimos). Pero realmente no hay razón para que sea necesario hacer esto, es solo que nuestros renderizadores funcionan mal, eso es todo. Podríamos solucionar los 3 problemas fácilmente cambiando la forma en que rasterizamos.

Cai tiene razón. Pensé en agregar una respuesta visual también.

La razón por la que esto sucede es que es un SVG. A diferencia de una imagen rasterizada en la que controlas cada píxel renderizado, la rasterización del SVG ocurre en el navegador... por lo que el navegador toma estas decisiones.

Una de las decisiones que debe tomar el navegador es cuándo hacer el suavizado. Por lo general, hará esto cuando un punto a lo largo de una línea caiga en un píxel. Entonces eliminará el alias de ese píxel. Dado que representará todas las capas del SVG, lo hará con cada capa y ahí es donde puede comenzar a obtener el artefacto de borde. Esto es especialmente cierto cuando juegas con el zoom del SVG, ya que hará que se superpongan diferentes píxeles de la pantalla.

Aquí hay una captura de pantalla de un cuadro verde superpuesto a un cuadro rojo en Chrome. La parte superior está al 100% del zoom de la página, la parte inferior está ampliada. Observe la diferencia al representar ese borde:

ingrese la descripción de la imagen aquí

Si tomo una captura de pantalla y hago zoom para mostrar la rasterización, puede obtener una imagen más clara de lo que está sucediendo:

ingrese la descripción de la imagen aquí

La solución ideal aquí sería que el rasterizador SVG en el navegador sea "más inteligente" y no represente las cosas que están apiladas, pero dado que los elementos SVG se pueden manipular externamente y en vivo (ya que es solo un archivo XML), no es una solución práctica para el navegador.

Entonces, en cambio, el diseñador toma esa decisión usando las muescas que ves.

Por cierto, esto es similar en concepto a cómo lidiar con el registro en la impresión mediante el reventado .

La impresión en varios colores requiere un registro preciso para evitar espacios antiestéticos y es una preocupación cuando los artefactos se componen de múltiples fuentes. Problemas similares pueden ocurrir incluso en productos digitales donde la aritmética de precisión limitada necesariamente introduce errores.

El problema que se evita es el reventado inverso , donde la desviación del gráfico previsto puede dar como resultado una línea delgada del color de fondo que se muestra a la izquierda de los bordes coincidentes verticales. Como los colores contrastan mucho, el impacto será notable (intente mover la línea discontinua incluso 1 píxel a la izquierda de la vertical).

El enfoque no pretende impactar en la mezcla de tintas. Las coordenadas coherentes en pantalla evitan el problema, mientras que los medios tonos se utilizan para gestionar el color.

¿Hay alguna razón por la que el logo de Hillary Clinton tiene muescas ocultas?
RespuestasAquíPolítica de privacidad1y, 0v