264 meneos
9844 clics

Imágenes en 500 bytes: el formato de imágenes vectoriales de Haiku [ENG]  

El sistema operativo Haiku usa un formato vectorial propio para almacenar iconos, lo que es sorprendente por dos motivos: la mayoría de sistemas operativos consideran los mapas de bits suficientes para representar iconos y ya hay varios formatos vectoriales para representar gráficos (p.e. SVG). La meta del formato HVIF (Haiku Vector Icon Format) es hacer los archivos tan pequeños como sea posible, pero permitiendo mostrar las imágenes sin pérdida de calidad y con un tamaño suficientemente pequeño como para caber en un inode.
etiquetas: haiku, haiku os, imagen vectorial, hvif, icono, beos
133 131 0 K 556 tecnología
Comentarios destacados:                   
#1   que no sea de google
votos: 1    karma: 16
#2   Un s.o. empeñado en ser supereficiente tiene su coste pero tambien su potencial nicho de mercado. Bien por Haiku por seguir en esa linea.
votos: 6    karma: 50
#7   ¿Usa alguien Haiku? No, es en serio, desconocía este OS. Pregunto por el comentario de #2 donde asegura que es supereficiente.
votos: 1    karma: 14
#8   #7 hay gente que lo usa, he de decir que cuando lo he probado va como un tiro, ojalá soportara mis herramientas de desarrollo... Le iban a dar al Linux...
votos: 4    karma: 30
#9   #8 Gracias amigo.
votos: 0    karma: 7
#10   #7 Yo usé BeOS en una máquina antigua y podía hacer cosas impensables en Windows.
votos: 10    karma: 84
#23   #10:

 media
votos: 3    karma: 27
#29   #23 yo tuve Beos, y en aquel momento el rendimiento gráfico daba hasta miedo. Acojonante se quedaba corto. Pero el projecto se quedó en eso, y no era practicable para la vida real.
votos: 2    karma: 22
#58   #6 Para eso también tenemos |SysDevs ;)

#29 En realidad sí era practicable en la vida real. De hecho era competencia directa de Windows 95. El problema fueron los recursos de cada compañía. A Be Inc. no le llegaron. Microsoft iba sobrada.

/cc #23
votos: 1    karma: 23
 *   mr_b mr_b
#80   #58 ¿Hayku (BeOs) competencia directa de Windows 95? Ni en sus mejores sueños.

Que existieran en la misma época no le convertía en competencia.
votos: 0    karma: 12
#55   #10 :popcorn:
votos: 0    karma: 7
#72   #10 Yo también llegué a instalar BeOS tanto en una VM como en mi antiguo PC. ¿Qué cosas impensables en Windows podías hacer?
votos: 0    karma: 10
#87   #10 ¿Por ejemplo?
votos: 0    karma: 6
#3   ¿Es tan importante que un iconito tenga mucha calidad gráfica?
votos: 4    karma: 1
#5   #3 No es que tenga mucha calidad gráfica, es que lo puedas escalar tanto como quieras sin perder la mucha o poca calidad que tenga.
votos: 14    karma: 124
#12   #5 exacto, tengo un monitor 4k y tengo que escalar todo y prefiero que se vean bien que una basura.
votos: 0    karma: 7
#14   #3 No es tanto por la calidad sino por el tamaño. Del artículo:

TL;DR: si el icono fuese tan pequeño como para embeberlo en los metadatos del fichero, te ahorras un acceso de lectura al disco por cada fichero a listar. Al reducir el acceso a disco, se optimizan los tiempos para mostrar archivos.

Why do Haiku’s developers care about the size of icon files?
[...]
If you use the standard bitmap icon formats, you’ll probably store them in their own files, separate from the files that use them. In…   » ver todo el comentario
votos: 13    karma: 77
 *   calaverax
#57   #14 Vale como divertimento, pero ni hay problemas de almacenamiento ni hay necesidad.
Hay cosas que no se van a poder hacer con un vector, como el icono de una foto con algo real, como una cara o una fotografía.
Por otro lado... ¿qué ventajas tiene poder representar el dibujo sin pérdida de calidad en tamaños grandes si un icono es por definición un dibujo pequeño?

En fin...
votos: 1    karma: 9
#59   #57 Dependiendo del dispositivo y el tiempo que pueda permitirse perder presentando unos iconos, sí hay problemas y necesidad. Que no te hayas encontrado con ninguno, no significa que no existan.

La ventaja de no perder calidad en tamaños grandes, es que "grandes" en este caso estamos hablando de 256x256 en una pantalla tamaño móvil de 1920x1080 por ejemplo, que si lo intentas guardar en bitmap te puede ocupar 100 veces más la broma.
votos: 2    karma: 21
#65   #59 ¿Ves el sinsentido? Un móvil con una pantalla de hmmmm 5.5' mostrando un icono de 256x256. Anda que si muestra uno de 128x128 escalado se va a notar. Pero bueno, aceptamos barco. Si el icono tiene 16 bits de color hablaríamos de 16KB. En un 1GB cabrían más de 65.000 iconos de ese tamaño. No son raros los móviles con 32GB. Vamos, que con una foto más o menos que hagas en el móvil vas a notar más la diferencia de almacenamiento que con esta tontería.

Pero bueno, que como ejercicio informático es curioso.

En plan abogado del diablo a lo mejor hasta gasta más batería renderizar el icono vectorial que simplemente leer un bitmap tal cual.
votos: 0    karma: 10
#66   #65 "Esta tontería" va orientada a reducir el número de operaciones de disco, no el tamaño leído que es secundario (y algo despreciable hoy día, tal como ya señala el artículo), que es una cosa en la que precisamente las memorias de móvil son bastante malas.

Pero bueno, me hace gracia como aquí la mayoría de comentarios están diciendo cosas que se leen tal cual en el artículo enlazado como queriendo llevarle la contraria y ser más listos...

Tenemos por ejemplo a quien cree que esto…   » ver todo el comentario
votos: 4    karma: 36
#67   #66 veamos... Lo que dudo es de la eficiencia de todo el conjunto. Lo de menos accesos al "disco" pues.. como que hoy en dia es más que irrelevante. A lo mejor en discos mecánicos puede que se note, pero hay un invento nuevo, el SSD, que vas a alucinar cuando lo veas.

Desventajas:
- Limitación a la hora de diseñar iconos (¡en pleno siglo XXI!)
- Nuevas herramientas respecto a las actuales.
- Más código que consume más CPU que lo que hay hasta ahora.

Ventajas:
- Iconos vintage Windows 3.1 que puedes escalarlos hasta cubrir la fachada de un edificio sin que pixele.
votos: 0    karma: 10
#70   #67 Ya lo puse en el primer párrafo, hoy en día los accesos a disco también son importantes, si me pones de ejemplo un teléfono móvil más aún.

Lo han puesto varios usuarios ya, y el artículo ya parte explicando la situación con un SSD. Hoy en día la CPU espera un poco menos por cada lectura a disco, pero sigue esperando varios miles de operaciones en los cuales ya le ha dado tiempo a renderizar 100 iconos vectoriales.

En cuanto a las limitaciones artísticas, bueno, es una preocupación…   » ver todo el comentario
votos: 3    karma: 36
#75   #65 "En un 1GB cabrían más de 65.000 iconos de ese tamaño. No son raros los móviles con 32GB"

Irrelevante.

"Si el icono tiene 16 bits de color hablaríamos de 16KB."

En un sistema de ficheros con bloques de 4KB, como suelen ser la mayoría, eso son 4 accesos a disco.
Compara eso con 0 accesos a disco de Haiku porque ya tiene el icono al haberlo leído junto con los metadatos del fichero.
votos: 1    karma: 17
 *   Lb2A3qA Lb2A3qA
#77   #75 Me has convencido, a ver si lo implementan en Windows 11 y se nota ese hmmmm 0.0000001% más de velocidad.

Por no hablar de la de espacio que nos vamos a ahorrar. Ahora que cada vez el almacenamiento está más caro y lento seguro que se aprecian esos hmmmm.. lo menos 40MB de ahorro en esos discos de 500.000MB.

Bien valdrá la pena currarse esos iconos, va a haber un antes y un después de la velocidad y el almacenamiento de los PCs.

Lástima no lo hubieran sacado cuando el spectrum, no hubiera hecho falta el modelo 128K, Linux hubiera corrido en el zx80
votos: 0    karma: 10
#78   #77 No estoy aquí para convencerte, sino para reírme de lo gilipollas y engreído que eres.

Claramente no entiendes que pueda haber un mundo fuera de tu maquinita de 2000€ modelo gamer con Windows, RAM y disco para tirar. Espero que te lo pases chachi piruli con tus LEDs a ritmo de música chumbeta mientras te fumas el porrito y haces llorar a los nenes en el CoD.

Pero tranqui, cuando el móvil te vaya lento, el display de la lavadora se te cuelgue, o tengas que esperar a reiniciar el coche, puedes estar seguro de que yo estaré aquí partiéndome el culo.
votos: 1    karma: 10
#81   #78 No das ni una. Como vidente no te ganarías la vida.

Entonces... ¿lo van a implementar en la lavadora? Joder, esto sirve hasta para centrifugar más rápido!

PD. Vendo Opel Corsa rapidísimo con iconos vectoriales.
votos: 1    karma: 19
 *   salteado3 salteado3
#83   #81 Cada un poco más, que todavía se ve el cielo.
votos: 1    karma: 10
#84   #78 #81 ¿La lavadora? El display del deco de Euskaltel es un puto engendro que va más lento que la madre que lo parió. No sé si está hecho con HTML5 + JS porque es una verdadera basura.
votos: 0    karma: 10
#85   #84 Seguro que la clave son los iconos. Que los pongan vectoriales que evitan millones de lecturas y fijo que irá todo como la seda. Y hasta necesitará menos detergente y gastará menos luz.
votos: 1    karma: 3
 *   salteado3 salteado3
#86   #84 El mío no tenía display, sería un modelo viejo o algo. Posiblemente vaya lento porque ni se molesten en meter un controlador dedicado para el display, sino que la misma CPU se encargue de controlarlo, y tengan que mandar los datos lento de cojones para reducir el jitter hasta algo "razonablemente fiable".
votos: 2    karma: 20
#4   Yo soy mas del gif...
votos: 1    karma: 5
#6   Meneo por trolear al usuario promedio. Muy buen artículo por cierto, me encantan las curiosidades de los entresijos de la informática.
votos: 1    karma: 19
#18   #11 el problema es el gasto de cpu cada vez que tengas que renderizar el gráfico, aunque si las gpus pudieran hacer ese trabajo igual van más rápidos que los bitmaps.
Otra opción seria hacer caches en memoria con el gráfico renderizado a bitmap para no tener que recalcular nada cada vez que el icono se redibuje
votos: 6    karma: 48
#26   #18 El objetivo es que pesen poco para evitar hacer peticiones adicionales. Si haces un cache de memoria en bmp, pues al final solo la primera llamada consigue el objetivo mientras que el resto no.
votos: 2    karma: 27
#30   #26 el artículo dice que es para reducir operaciones de disco, una cache en memoria siempre reduce operaciones de disco. De hecho es al revés de como dices con una cache la primera imagen se lee se calcula y se usa, en el resto solo se usa.
votos: 0    karma: 7
#33   #26 Si guardas el bitmap en memoria de video sólo procesas la primera vez y luego tiras de caché de bitmaps en memoria de video, por lo tanto no vuelves a leer de disco; aunque lo ideal sería que los iconos se almacenaran o renderizaran en un formato vectorial que entendiera la gpu y fuera esta la que hiciera todo el trabajo una vez leidos de disco.
votos: 2    karma: 33
#38   #33 Correcto. Pensaba que quwrias dejarlo en el hdd y no en la memoria rapida.
De todas formas yo siempre que leo esto de las microptimizaciones me hace sonreir. El SO preocupado por facilitar ganar unos microsegundos y los navegadores web consumiendo, por poner un ejemplo, 50 MB por pestaña que al final obliga a estar paginando memoria(probablemente el IO mas caro que existe).
votos: 2    karma: 31
#45   #38 viéndolo así... dan ganas de no hacer SO, hagas lo bueno que lo hagas llegara alguien con un programa que se coma los recursos y haga el equipo inutilizable. ;)
votos: 1    karma: 14
#34   #26 Si no entendí mal, el artículo habla de evitar hacer lecturas de disco, que son lentas, pero creo que #18 se refiere a una cache en memoria física (la RAM, para entendernos), que es rápida.

Ya sabes, con 'disco' nos referimos a cosas como el disco duro... que es no volátil y más barato por unidad de memoria, pero tiene la pega de ser más lento. Y por 'memoria' solemos hacer referencia a cosas como la RAM, que volátil y cara pero mucho más rápida.
votos: 1    karma: 19
#41   #34
Sep. Pero por alguna razon me imaginaba generando bmps del svg en el hdd. Probablemente sea por el proyecto en el que estoy metido ahora que generamos imagenes combinando otras y demas y me he hecho un "biasing" a mi mismo.
votos: 0    karma: 10
#39   #18 Estoy de acuerdo contigo. El principal problema puede ser el tiempo de renderizado, el gasto de CPU. Si el tiempo que ahorras en lectura de disco lo gastas en renderizado pues mal negocio ¿no? Aparte, un BMP no tiene por qué ir en un fichero aparte ¿o me equivoco? (esa parte no la entendí muy bien... por ejemplo, creo que los ejecutables tienen un icono ¿BMP? codificado en el propio fichero ¿o no?)

Creo que decir que un formato es "el óptimo" o que es "el mejor", como…   » ver todo el comentario
votos: 0    karma: 8
 *   Acido Acido
 *   --286739--
#68   #39 Aparte, un BMP no tiene por qué ir en un fichero aparte ¿o me equivoco? (esa parte no la entendí muy bien...

Es correcto lo que dices. Lo que te faltó para entender esa parte es el concepto de inode (o igual ya lo tienes pero te faltó vincularlo). El inode es el bloque básico de información del fichero, es metainformación y no tiene contenido real. Por ejemplo guardaría el tamaño, fecha de creación, permisos, puntero al contenido... eso se lee antes de acceder al contenido en sí. Es…   » ver todo el comentario
votos: 1    karma: 15
#73   #51: Este formato para Web parece muy interesante, sobretodo si se permite usar compresión, porque SVG está bien pero ocupa mucho pudiendo ocupar menos.
votos: 0    karma: 11
#60   #18 Dependiendo del dispositivo de almacenamiento y de la CPU, puede darle tiempo a renderizar muchas veces el gráfico en lo que de otra forma tendría que esperar a terminar de leerlo "del disco".
votos: 0    karma: 7
 *   Lb2A3qA Lb2A3qA
#36   #11 Y también lo peor, en cuanto a eficiencia de cálculo.
Nadie piensa en el cambio climático? :'(
votos: 1    karma: 20
#13   Iconos vectoriales, eso lleva años en GNU/Linux por ejemplo en Gnome2 fue cuando lo descubrí...después la cagaron con el 3...pero menos mal que existe Mate.
votos: 0    karma: 9
#19   #13 la gracia de este formato es que los gráficos sean pequeños y que quepan en un inodo para minimizar la lectura de disco y que carguen más rápido, no el que el gráfico sea vectorial
votos: 11    karma: 103
#20   #19 por fin alguien lo ha comprendido!!!!!
votos: 1    karma: 13
#24   #20 Hombreeee...comprender que es un "inodo" lleva su tiempo :3 De todas formas no es tanto el tamaño(un icono no pasa mas alla de uno cuantos kb) sino reducir el numero de peticiones.
votos: 1    karma: 21
#44   #19 Sigo sin verle la gracia. Cualquier sistema medianamente avanzado tiene una caché de iconos, que además suele ser persistente y no se pierde cuando se reinicia, así que por lo general solo se requiere una lectura de esa caché al arrancar el PC, lo que es un tiempo despreciable comparado con todas las otras cosas que hace un sistema al arrancar.
votos: 1    karma: 14
#47   #44 uf, si supiera desactivar la cache o hacer que se limpiase sola... de vez en cuando tengo que usar un alias que tengo puesto para borrar .thumbnails...
votos: 0    karma: 12
#15   Los iconos vectoriales son muy antiguos. Vamos, con GNOME 2 y KDE 3 ya se podían usar.
votos: 1    karma: 18
#61   #15 #16 ¿Cuánto ocupaban?
votos: 0    karma: 7
 *   Lb2A3qA Lb2A3qA
#16   IRIX, el UNIX de Silicon Graphics, ya usaba iconos vectoriales.  media
votos: 4    karma: 38
#17   Hay una variación de PNG, PNG de Fireworks, que muchos visores entienden y también es vectorial, nunca entenderé por que no se popularizó más ese formato y la herramienta, son geniales.

Respecto a los SVG.. Anda que no se utilizan hace tiempo para cientos de cosas... Por desgracia todavía son de dificil integración en algunos motores/entornos.

Por ejemplo, Unity no entiende vectoriales de forma nativa, en Visual Studio + Xamarin es dificilisimo...

Pero hay muchas webs que ya lo utilizan en todo.
votos: 0    karma: 7
#22   #17: ¿No serían PNGs con el código SVG dentro?

Yo lo hago a veces, metiendo el código en el propio SVG mediante un editor de metadatos.
votos: 0    karma: 11
#25   #17 XamSvg, y así tendrás el componente SvgImage que añades directamente en el xaml. En Unity no he probado, pero sí he escuchado que da dolores de cabeza.
votos: 2    karma: 27
#27   #25 gracias! No lo conocía, entiendo que es un componente de xamarin forms y no especifico por plataforma, correcto?

Hasta ahora hemos trabajado en proyectos nativos unificados con xamarin pero sin xamarin forms, lo tendré en cuenta para próximas aventuras.
votos: 0    karma: 7
#35   #27 Soporta Xamarin Forms y también nativos. Te lo instalas de nuget, y tiras millas.
votos: 1    karma: 16
#42   #35 grache mile! Le daré un ojo seguro
votos: 0    karma: 7
#21   Yo tengo siempre dos maquinas virtuales: una con Haiku y otra con ReactOS.
Hay vida opensource mas alla de Gnu/Linux y Windows...por mucho que se empeñen en lo contrario 8-D
votos: 6    karma: 61
#31   #21 y como sistema host qué tienes, si no es indiscreción?
votos: 0    karma: 7
#37   #31 FreeBSD
votos: 2    karma: 29
#54   #21 Nadie se empeña en lo contrario, pero hay cosas más útiles que otras. A mi los iconitos me importan un carajo.
votos: 0    karma: 6
#28   Quién se empaña en lo contrario?? yo llevo años usando (también) FreeBSD.
Lo de ReactOS no lo conozco. Le echaré un vistazo a ver quienes lo hacen...
votos: 1    karma: 21
#32   me parece una puta maravilla
votos: 0    karma: 9
#40   Llega la era de los ssd y ahora nos preocupamos por un acceso a disco...
votos: 2    karma: 22
#46   #40 por supuesto los SSD son mucho más rápidos pero no para tanto.
votos: 1    karma: 17
#48   #46 Que va, de pocas centenas de iops a decenas de miles. No es para tanto.
votos: 0    karma: 6
#50   #48 pero no como para no preocuparse, con SSD las operaciones de disco siguen siendo las mas lentas.
votos: 0    karma: 7
#63   #48 Hasta los miles de millones de instrucciones por segundo de una CPU, sí es para tanto.
votos: 1    karma: 17
 *   Lb2A3qA Lb2A3qA
#64   #63 espera, espera, que #46 hablaba de discos, de ahí lo de IOPS, que no tiene nada que ver con las IPS de una CPU.
votos: 0    karma: 6
#76   #64 "Esperar" es lo que hace la CPU cuando pide datos del disco, y el disco (SSD) tarda lo mismo que 100.000 instrucciones de CPU para entregarle los datos que ha pedido.

¿Que no tiene nada que ver? y una leche.
votos: 0    karma: 7
 *   Lb2A3qA Lb2A3qA
#79   #76 pero tu estas contestando solo por hacerte el gracioso y llevarte karma, o sabes de lo que hablas; porque menospreciar una mejora de tres órdenes de magnitud no es como para decir 'no es para tanto'
votos: 0    karma: 6
#82   #79 Pero tú sabes a lo que respondes, o te haces el tonto; porque menosprecias una diferencia de cinco órdenes de magnitud justificando que "oye, ya no son ocho órdenes de magnitud" :roll:
votos: 0    karma: 7
#62   #40 Sí, llega la era en la que un procesador puede ejecutar 80.000 instrucciones en lo que tiene que esperar a un SSD, en vez de poder ejecutar 40.000.000 de instrucciones en lo que le tocaba esperar a un HDD... ¿y? :roll:
votos: 2    karma: 24
#43   Para mi gusto lo interesante es por qué quieren tener iconos de 500 bytes, el resto viene rodado cualquier equipo llegaría a mismo o similar formato si les obligan a tener iconos de 500 bytes. Para qué reducirlo tanto? no es por calidad, tampoco por ahorrar espacio en disco, es por velocidad pero el tamaño de un icono solo afecta a cuando lo quieres leer del disco para enseñarlo eso normalmente es cuando en el explorador abres una carpeta el sistema operativo mira en la tabla de ficheros del…   » ver todo el comentario
votos: 3    karma: 36
#49   Ui si, gran descubrimiento, aprovechar cada bit en vez de usar burradas como XML...
votos: 1    karma: 18
#71   #49 <Hilo id="2667223">
<Respuesta origen="49">
<párrafo class="inline">
<línea value="1">
No veo que XML sea tan farragoso.
</línea>
</párrafo>
</Respuesta>
</Hilo>

:troll:
votos: 1    karma: 19
#74   #71: Y te falta la cabecera, eso si hubiera sido pwneante. :-D

De hecho si hicieran el SVG con opción de guardarse en JSON ganarían mucho. :-P
votos: 2    karma: 22
#53   En otro orden de cosas, un formato de imagen hecho para ser comprimido y que su tamaño con GZIP / XZ sea menor que un PNG manteniendo toda la calidad:
tools.suckless.org/farbfeld/
votos: 2    karma: 24
#56   Y no sería mejor utilizar para todo PiedPiper??? Consigue una compresión sin pérdida del 75%...

www.piedpiper.com/
votos: 1    karma: 20
#69   Hay Bender, hay meneo.  media
votos: 2    karma: 23
#88   200 iconos no son 200 accesos a disco. Son dos accesos a disco: uno para leer un mapa de bits con 200 iconos y dos para leer un fichero con las coordenadas de cada uno de ellos.

Podrías meter todo en unico fichero, pero vamos, ya andarías manipulando los bytes del jpg o el png.
votos: 0    karma: 9
 *   scalvo
comentarios cerrados

menéame