Convertir SVG a BMP

Estos dos formatos están en polos opuestos. Un SVG es texto: una lista de trazos, rellenos y transformaciones que un motor de render convierte en imagen al tamaño que se le pida, así que el archivo no tiene resolución fija ni un peso predecible. Un BMP es la imagen ya hecha, guardada como filas literales de color sin compresión y sin estructura que interpretar.

Esa distancia es el tema entero de esta página. Ir en un sentido es un render: una decisión sobre tamaño, fondo y antialiasing, tomada una vez y luego permanente. Ir en el otro sentido no es posible; no hay camino de vuelta de una cuadrícula de bytes a las formas que la dibujaron.

Un atributo width o height en un SVG es una sugerencia, no un tamaño real: el dibujo está definido por su viewBox y se puede producir a cualquier resolución. La conversión tiene que elegir una, y el ajuste de escala es esa decisión. Por defecto renderiza a 1.024 píxeles de ancho y la altura sigue las proporciones del dibujo; la escala va de 0,1 a 10, es decir de 102 a 10.240 píxeles.

Conviene elegir el número que realmente pide el destino, no el mayor disponible, porque el coste aquí es especialmente pronunciado. A diferencia de un PNG o un WebP, el peso de un mapa de bits no depende de lo que haya dibujado: doblar el ancho cuadruplica el archivo, tanto si el dibujo es una ilustración completa como si es una sola línea negra.

Cada píxel ocupa tres bytes —azul, verde y rojo, en ese orden— y cada fila se rellena hasta un múltiplo de cuatro. Súmale una cabecera de 54 bytes y eso es el archivo entero. Un cuadrado de 1.024 píxeles son 3.072 bytes por fila y 3.145.728 bytes de datos de imagen, con un total de 3.145.782.

Así que un SVG de unos pocos cientos de bytes se convierte en unos tres megabytes con el ajuste por defecto, y en unos doce a escala 2. No es un defecto del conversor; es lo que es un BMP, y por eso cualquier cosa que pueda elegir escoge otro formato. Si el destino tiene un límite de tamaño, haz la cuenta antes de convertir, no después.

El mapa de bits que se escribe aquí es de 24 bits por píxel, sin un cuarto canal. Existe una variante de cabecera que define un canal alfa y hay archivos que la usan, pero admitirla es justo el tipo de complicación que un BMP suele elegirse para evitar, así que la transparencia se resuelve primero.

El dibujo se renderiza sobre nada y luego se aplana sobre el color de fondo en una sola pasada, y el orden importa: rellenar primero y escalar después mezclaría el relleno con los bordes, y escalar una imagen transparente antes de aplanarla deja un borde de píxeles semitransparentes que el relleno oscurece. Ajusta el color a la superficie donde va a apoyarse el mapa de bits: blanco es el valor por defecto y queda mal sobre un panel oscuro.

El render lo hace resvg compilado a WebAssembly y no el propio motor de SVG del navegador, y eso es deliberado. Entregarle un SVG a un lienzo del navegador da lo que ese navegador decida: métricas de texto distintas, soporte de filtros distinto, resultados visiblemente diferentes para el mismo archivo en Chrome y en Safari. Un solo motor de render significa que el mapa de bits es idéntico en cualquier equipo que lo produzca.

Eso importa más aquí que en la mayoría de destinos. Un mapa de bits que va a un aparato o a un instalador suele revisarse una vez y darse por bueno para siempre, a veces comparado byte a byte contra una referencia. Un render que cambiara según el navegador dejaría esa comparación sin sentido.

El SVG guarda el texto como texto y hace referencia a una tipografía por su nombre. Si esa fuente no va incrustada en el archivo, el motor de render elige otra cosa, y un logotipo con un espaciado cuidado vuelve con letras distintas y otro espaciado. Es la causa más habitual de que un SVG renderizado salga mal.

La solución va en el programa de diseño, no aquí: convierte el texto en trazados o rutas antes de exportar, y las letras se vuelven formas que nada puede sustituir. También hace el archivo seguro de entregar a cualquiera, algo que conviene de todas formas si el dibujo va a un sistema que no controlas.

Porque leerlo no necesita ninguna biblioteca. Un microcontrolador que gobierna una pantalla pequeña puede saltarse la cabecera de 54 bytes y copiar bytes al búfer de imagen con un bucle sencillo; admitir PNG en el mismo dispositivo implica añadir un descompresor, un asignador de memoria y un analizador de bloques a algo que puede tener 32 KB de RAM.

La misma lógica cubre recursos de instaladores cargados a través de las funciones de mapa de bits del propio sistema, controles antiguos de Windows y bancos de pruebas que comparan imágenes sin ningún códec de por medio. En cada caso el formato se elige por previsibilidad, y los megabytes son el precio que se paga por ella.

Borra el mapa de bits y puedes hacer otro. Borra el SVG y el mapa de bits es todo lo que queda, y todo lo que hacía útil al dibujo —edición cómoda, resolución arbitraria, un historial legible en el control de versiones— desaparece para siempre. Vectorizar un BMP de vuelta a trazados adivina los bordes y produce un archivo distinto, con más nodos y curvas peores.

Trata la conversión como un paso de exportación, idealmente uno que ejecute el propio proceso de compilación y no una persona a mano. Cuando el panel necesite otro tamaño el año que viene, vuelve a renderizar desde el vector en lugar de escalar un mapa de bits de tres megabytes.

Suelta el conjunto entero. Cada archivo se renderiza a la misma escala y se aplana sobre el mismo fondo, que suele ser lo que estos destinos necesitan: un conjunto de gráficos de panel que no se ponen de acuerdo sobre su fondo se ve peor que cualquiera de ellos siendo individualmente imperfecto.

Vigila el peso total. Veinte dibujos a la escala por defecto son unos sesenta megabytes de mapas de bits antes del ZIP, suficiente para ir lento en un móvil y para llenar el almacenamiento de un dispositivo pequeño. Bajar la escala a lo que la pantalla realmente muestra es lo más eficaz que se puede hacer contra esa cifra.

resvg se ejecuta como WebAssembly en esta misma pestaña, y el mapa de bits se ensambla aquí también, que es también la razón de que un resultado de tres megabytes aparezca sin ninguna subida ni descarga intermedia.

Sin servidor de por medio tampoco hay cuenta que crear ni límite diario impuesto por nosotros: se puede soltar una carpeta entera hasta cien archivos por tanda, con un tope de cien megabytes por archivo, y todo vuelve en un solo ZIP.

Antes de convertir toda la carpeta, abre el primer resultado en el mismo programa o equipo que lo va a usar. Un mapa de bits técnicamente correcto puede seguir estando mal para un destino concreto: el orden de los bytes, la resolución declarada o el propio tamaño en píxeles pueden no ser lo que esa aplicación en particular espera, y es mejor descubrirlo con un archivo que con veinte.

Si el primero funciona, el resto se comportará igual, porque todos los archivos de un mismo lote pasan por el mismo código con los mismos ajustes. Ese es precisamente el motivo por el que conviene fijar la escala y el color de fondo antes de soltar la carpeta, y no ir corrigiendo archivo a archivo después.