Me pregunto si hay alguna biblioteca de gráficos que admita la reproducción de subpíxeles RGB (como ClearType) para gráficos generales, , no solo para el texto. Esto permitiría prácticamente triplicar la resolución horizontal y colocar los gráficos en posiciones de tercer píxel x.RGB de procesamiento de subpíxeles para gráficos?
Aunque creo que esto sería muy útil, no pude encontrar mucho en internet sobre ella, excepto los siguientes:
- How Sub-Pixel Font Rendering Works (hay algunas imágenes de líneas alrededor de la mitad)
- Subpixel rendering and image resizing (algunas ideas interesantes sobre la aplicación de la representación de subpíxeles para cambiar el tamaño de mapas de bits)
¿Hay alguna biblioteca que implemente esto, o hay esfuerzos para traer algo como esto a la biblioteca de El Cairo, por ejemplo?
Actualización:
Me refiero específicamente a las técnicas que tengan en cuenta que las pantallas LCD actuales de uso de sub-píxeles de diferentes colores renderizado. Para hacer un punto blanco, se establece todos los subpíxeles en 'ON' o 255. Una línea blanca sería varios subpíxeles una encima de la otra:
...RGB...
...RGB...
...RGB...
...RGB...
...RGB...
...111...
(donde . es un sub-píxel totalmente negro, y R, G o B son subpíxeles rojos, verdes o azules completamente iluminados). Debido a que nuestros ojos no pueden resolver los subpíxeles, se combinan para formar una línea blanca. Que podría sin embargo también hacen una línea blanca entre los siguientes:
....GBR..
....GBR..
....GBR..
....GBR..
....GBR..
....111..
Nota que es perfectamente afilada, pero colocado en x = 1 1/3 píxeles. Esto no es posible con las técnicas tradicionales de renderizado que dibujan una línea blanca ligeramente borrosa. Aquí, por ejemplo, R = 70% iluminado, r = 30% iluminado. No trabajé a cabo los cálculos, esto es sólo para que pueda obtener la idea:
...RGBrgb...
...RGBrgb...
...RGBrgb...
...RGBrgb...
...RGBrgb...
...777333...
Otro ejemplo es una pendiente, lo que se puede hacer a) con píxeles completos, b) filtros antialiasing, o c) con los subpíxeles renderizado:
a) RGB...... b) RGB...... c) RGB......
RGB...... RGBrgb... .GBR.....
...RGB... rgbRGB... ..BRG....
...RGB... ...RGB... ...RGB...
...RGB... ...RGBrgb ....GBR..
......RGB ...rgbRGB .....BRG.
......RGB ......RGB ......RGB
una vez más, tenga en cuenta que esto es sólo un ejemplo crudo para darle la idea general, pero se ve que a) es dentada o alias, b) es borrosa, y c) es tan agudo como usted puede obtenerlo en una pantalla LCD.
Las implementaciones reales de esto, para la visualización de fuentes (ClearType en Windows y la representación subpixel en FreeType) tienen un algoritmo más sofisticado. Toman en cuenta que los subpíxeles individuales sangran o brillan entre sí, conservan la intensidad de color total o la energía. También tienen en cuenta que el espacio entre píxeles no es uniforme (el espacio 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 que algunas pantallas tienen diseños de píxeles completamente diferentes.
Cairo admite posicionamiento subpíxel. Todas las coordenadas son de doble precisión. Ver [cairo_line_to] (http://www.cairographics.org/manual/cairo-Paths.html#cairo-line-to) para un ejemplo – mbonnin
Soy consciente de que puedes usar coordenadas no enteras, pero me refiero a la representación RGB subpixel, no solo renderizado antialias. La representación de subpíxeles RGB tiene en cuenta que cada píxel en una pantalla LCD está compuesto por un subpíxel rojo, verde y azul. Actualizaré la pregunta con un poco más de detalle. – jdm
bien, entendido. de hecho, no sabía que algunos motores de fuente podrían hacer esto (dudo que Freetype 'divida' píxeles en sus valores RGB, ¿o sí?). También esto dependería de la configuración real de la matriz rgb, por lo que podría terminar haciendo más daño que bien en pantallas como la [nexus one] (http://arstechnica.com/gadgets/2010/03/secrets-of-the-nexus -ones-screen-science-color-and-hacks /) – mbonnin