vector graphics - vecteezy - Representación subpixel RGB para gráficos?

free vector

Question

Me pregunto si hay alguna biblioteca de gráficos que admita la representación de subpíxeles RGB (como ClearType) para gráficos en general, no solo para texto . Esto permitiría prácticamente triplicar la resolución horizontal y colocar gráficos en las posiciones x del tercer píxel.

Si bien creo que esto sería muy útil, no pude encontrar mucho en Internet al respecto, excepto lo siguiente:

• Cómo funciona la representación de fuentes de subpíxeles (hay algunas imágenes de línea en el centro)
• Representación de subpíxeles y cambio de tamaño de la imagen (algunas ideas interesantes sobre la aplicación de la representación de subpíxeles para cambiar el tamaño de los mapas de bits)

¿Hay alguna biblioteca que implemente esto, o hay esfuerzos para llevar algo como esto a la biblioteca de El Cairo, por ejemplo?

Actualizar:

Me refiero específicamente a las técnicas de representación que tienen en cuenta que las pantallas LCD actuales utilizan subpíxeles de diferentes colores. Para hacer un punto blanco, establezca todos los subpíxeles en ''on'' o 255. Una línea blanca sería varios subpíxeles uno encima del otro:

...RGB...
...RGB...
...RGB...
...RGB...
...RGB...
...111...

(donde . es un subpíxel completamente negro, y R , G o B son subpíxeles rojos, verdes o azules completamente iluminados). Como nuestros ojos no pueden resolver los subpíxeles, se mezclan para formar una línea blanca. Sin embargo, también podría hacer una línea blanca de lo siguiente:

....GBR..
....GBR..
....GBR..
....GBR..
....GBR..
....111..

Tenga en cuenta que es perfectamente nítido, pero colocado en x = 1 1/3 píxeles. Esto no es posible con las técnicas de renderización tradicionales que dibujan una línea blanca ligeramente borrosa. Aquí, por ejemplo, R = 70% encendido, r = 30% encendido. No resolví las matemáticas, esto es solo para que tengas la idea:

...RGBrgb...
...RGBrgb...
...RGBrgb...
...RGBrgb...
...RGBrgb...
...777333...

Otro ejemplo es una pendiente, que puede hacer a) con píxeles completos, b) suavizado, oc) con representación de subpíxel:

a)  RGB......  b)  RGB......  c)  RGB......
    RGB......      RGBrgb...      .GBR.....
    ...RGB...      rgbRGB...      ..BRG....
    ...RGB...      ...RGB...      ...RGB...
    ...RGB...      ...RGBrgb      ....GBR..
    ......RGB      ...rgbRGB      .....BRG.
    ......RGB      ......RGB      ......RGB

Nuevamente, tenga en cuenta que esto es solo un ejemplo simple para darle una idea general, pero verá que a) es irregular o con alias, b) es borrosa yc) es tan nítida como puede verla en una pantalla LCD.

Las implementaciones reales de esto, para la visualización de fuentes (ClearType en Windows y la representación de subpíxeles en FreeType) tienen un algoritmo más sofisticado. Tienen en cuenta que los subpíxeles individuales sangran o brillan unos en otros, conservan la intensidad o energía total del color. También tienen en cuenta que el espaciado de subpíxeles no es uniforme (el espaciado entre R y G, o G y B (en el píxel) puede ser más pequeño que entre B y R), y finalmente, algunas pantallas tienen diseños de píxeles completamente diferentes.

Answer 1

Alguien logró obtener algunos resultados interesantes usando ImageMagick. El método y los resultados, así como una discusión interesante, se exponen aquí: https://www.imagemagick.org/discourse-server/viewtopic.php?t=19120

Tema interesante, por cierto. Pero el punto sigue siendo: ¿qué tan útil puede ser la técnica, ya que tal proceso solo beneficiaría las imágenes sin escala en un tipo específico de pantalla?

Answer 2

Parece que es posible con AGG en antigrain.com definiendo su propio canal de conversión para asignar la salida a los píxeles del dispositivo. Consulte https://sourceforge.net/p/vector-agg/mailman/search/?q=LCD

Answer 3

Por lo que sé, no existe una biblioteca gráfica con subpixel RGB rendering.

Aquí hay algunas razones posibles por las que:

• Microsoft tiene algunas patentes sobre la tecnología de representación de subpíxeles RGB. No sé si esas patentes se aplican solo a la rasterización de fuentes, pero si no, es probablemente una muy buena razón por la que otras bibliotecas gráficas no la usan.
• Como se señaló en la pregunta, la representación de subpíxeles se basa en una implementación de hardware. Funciona bien con pantallas que componen el color al colocar 3 celdas de color de lado a lado (por ejemplo, un monitor LCD). Para todos los demás tipos de pantallas (plasma, proyectores, CRT antiguo), no funciona.
• La representación de subpíxeles agrega solo resolución horizontal. Esta limitación no es un problema para la rasterización de la fuente, ya que a menudo es la fuente la que necesita más resolución (ver caracteres en negrita y cursiva y kerning). Con el gráfico "personalizado" sería extraño tener una resolución diferente en cada eje.
• La representación de subpíxeles no funciona con la visualización rotativa. Por ejemplo, los dispositivos móviles tienen que usar tanto el procesamiento de subpíxeles RGB como el antialiasing.
• La representación de subpíxeles solo funciona con la resolución nativa de una pantalla.
• Parece que las personas ciegas del color tienen problemas con la representación de subpíxeles. Vea este paper para más información.
• La representación de subpíxeles funciona muy bien con negro sobre blanco o blanco sobre fondos negros. Con otros fondos, el "renderizador" debe conocer el color de fondo para ajustar el efecto de subpíxel. Por esta misma razón, Office 2013 dejó de usar ClearType.
• Esto es más subjetivo, pero la diferencia entre el procesamiento de subpíxeles y el antialias es muy sutil. Las desventajas y la complejidad agregada de la representación de subpíxeles pueden no valer la pena.

En mi humilde opinión, el futuro de mejores gráficos es con una mayor densidad de píxeles, como la pantalla retina de Apple.