Conversor BMP a JPG — Reducción Sustancial de Tamaño vía DCT del JPEG
Convierte BMP (Microsoft Bitmap, originado en Windows 1.0 en 1985 como bitmap dependiente del dispositivo; formato moderno BITMAPFILEHEADER + BITMAPINFOHEADER introducido con Windows 3.0 en mayo de 1990 según learn.microsoft.com/en-us/windows/win32/gdi/bitmap-storage) a JPG (ITU-T Recommendation T.81 / ISO/IEC 10918-1:1994, 18 de septiembre de 1992) para tamaños de archivo sustancialmente menores. BMP almacena píxeles sin comprimir (modo de compresión BI_RGB a 1/4/8/16/24/32 bits por píxel) — un BMP de 1920×1080 a 24 bits pesa ~6,2 MB (1920 × 1080 × 3 bytes + cabecera de 54 bytes), mientras que la misma imagen como JPG a calidad 85 normalmente queda por debajo de 500 KB. La pipeline DCT + Huffman + submuestreo de croma del JPEG (según ITU-T T.81 baseline) intercambia una pequeña cantidad de detalle de alta frecuencia perceptualmente invisible por un ratio de compresión de 10-20× en contenido fotográfico. La conversión corre localmente vía WHATWG Canvas drawImage + HTMLCanvasElement.toBlob('image/jpeg', quality). BMP se decodifica nativamente por todo navegador moderno (Chrome, Firefox, Safari, Edge) así que el origen carga limpiamente sin polyfills. Los archivos nunca salen del dispositivo.
Cómo convertir BMP a JPG
- Arrastra un .bmp a la herramienta o haz clic para seleccionarlo. El decodificador BMP integrado del navegador lee el BITMAPFILEHEADER + BITMAPINFOHEADER y decodifica los datos de píxeles BI_RGB.
- Elige el nivel de calidad JPG. 85 es el punto dulce web estándar según el Anexo K de ITU-T T.81 (pérdida visualmente invisible); 90+ se aproxima a visualmente sin pérdida; por debajo de 70 produce bloques 8×8 y ringing visibles.
- La herramienta ejecuta Canvas drawImage (BMP decodificado → canvas a dimensiones nativas) → toBlob('image/jpeg', quality) que aplica la pipeline DCT + Huffman + submuestreo de croma del JPEG.
- Revisa la comparación de tamaño antes/después: un BMP de 1920×1080 a 24 bits (~6,2 MB) normalmente queda por debajo de 500 KB a calidad 85 — una reducción de ~10-20×.
- Descarga el JPG. El BMP original queda intacto en el disco — los archivos nunca salen del dispositivo.
Casos de uso comunes
- Reducir capturas de Windows guardadas como BMP (Imprimir Pantalla → Paint por defecto) a tamaños JPG amigables para web para entradas de blog, adjuntos de correo o informes de incidencias.
- Convertir bibliotecas de recursos BMP heredadas de software Windows antiguo (era 1990-2000) a un formato moderno portable que cualquier plataforma acepte.
- Preparar salidas de escáner BMP (algunos drivers de escáner usan BMP por defecto para captura sin pérdida) para subir a plataformas que rechazan BMP o imponen límites estrictos de tamaño.
- Convertir por lotes capturas BMP de herramientas de prueba (los frameworks Win32 de comparación de imágenes a menudo emiten BMP) a adjuntos JPG para sistemas de seguimiento de incidencias.
- Reducir la huella de almacenamiento de una librería fotográfica BMP archivada antes de respaldarla en almacenamiento en la nube que cobra por GB.
Preguntas frecuentes
¿La conversión pierde calidad?
Sí — JPG es con pérdida. A calidad 85+ la pérdida es visualmente invisible a distancias de visualización normales según las tablas de cuantización perceptual del Anexo K de ITU-T T.81; por debajo de 70 los artefactos de compresión (fronteras de bloque 8×8, ringing cerca de bordes nítidos, banding en gradientes suaves) se hacen visibles. BMP es sin compresión (sin pérdida), así que cualquier salida JPG es un intercambio unidireccional de fidelidad por tamaño. Para salida ráster sin pérdida, convierte BMP a PNG vía una herramienta de escritorio (GIMP, Paint.NET, IrfanView) en su lugar.
¿Por qué mi BMP es tan grande?
BMP almacena píxeles sin comprimir en modo BI_RGB: los píxeles de 24 bits ocupan exactamente 3 bytes cada uno (~3,6 MB para HD 720p, ~6,2 MB para 1080p, ~24,9 MB para 4K). Las variantes BMP de 32 bits con padding alfa ocupan 4 bytes por píxel, aumentando esos números ~33%. La pipeline DCT + submuestreo de croma + Huffman del JPEG intercambia detalle de alta frecuencia perceptualmente invisible por un ratio de compresión de 10-20× en contenido fotográfico (1920×1080 normalmente queda por debajo de 500 KB a calidad 85).
¿Y la transparencia?
El BMP estándar (BI_RGB a 24 bits) no soporta transparencia — todo píxel es totalmente opaco. La variante BMP de 32 bits (BI_BITFIELDS o algunos BI_RGB a 32 bpp) puede llevar alfa en codificaciones específicas de Windows, pero son raras en la práctica. JPEG tampoco tiene alfa — la salida es siempre totalmente opaca. Si necesitas transparencia, la elección del formato origen ya la excluyó; considera convertir BMP → PNG en su lugar vía otra herramienta.
¿Funcionará toda variante BMP?
El decodificador BMP nativo del navegador maneja las variantes comunes: BI_RGB a 24 bits y 32 bits, a veces BI_BITFIELDS para 16 bits o 32 bits, a veces variantes BI_RLE8 / BI_RLE4 codificadas con run-length. Las variantes exóticas (BITMAPV4HEADER / BITMAPV5HEADER con perfiles ICC embebidos, OS22XBITMAPHEADER de OS/2) pueden fallar al cargar. Reexporta desde una herramienta de escritorio (GIMP, Paint.NET, IrfanView) como BMP estándar BI_RGB de 24 bits e intenta de nuevo si la carga falla.
¿Se sube mi archivo?
No. La decodificación + dibujo en canvas + codificación JPEG corren todos del lado cliente vía WHATWG Canvas drawImage + HTMLCanvasElement.toBlob('image/jpeg', quality). La pestaña Network de DevTools muestra cero peticiones de subida durante la conversión.
Por qué BMP se vuelve tan grande — y cómo el DCT del JPEG intercambia fidelidad por tamaño
La simplicidad estructural del BMP es también su problema de tamaño. El formato almacena píxeles sin comprimir en modo BI_RGB (la variante más común): los píxeles de 24 bits ocupan exactamente 3 bytes cada uno, más una cabecera de 54 bytes (BITMAPFILEHEADER de 14 bytes + BITMAPINFOHEADER de 40 bytes) y padding de alineación de 4 bytes por fila. Una foto de 1920×1080: 6.220.854 bytes ≈ 6,22 MB. Una foto 4K (3840×2160) a 24 bits: 24.883.254 bytes ≈ 24,88 MB. (Las variantes BMP de 32 bits con padding alfa ocupan 4 bytes por píxel, aumentando esos números ~33% hasta ~8,3 MB y ~33,2 MB respectivamente.) La pipeline de compresión del JPEG (ITU-T T.81 baseline DCT) hace tres cosas: (1) convierte RGB a espacio de color Y′CbCr y submuestrea el croma 4:2:0 (reducción inmediata ~50% ya que la visión humana es menos sensible a la resolución de croma); (2) aplica un DCT directo de 8×8 a cada bloque Y/Cb/Cr, transformando píxeles espaciales en coeficientes de frecuencia; (3) cuantiza los coeficientes de alta frecuencia vía las tablas del Anexo K escaladas por el deslizador de calidad (1-100), poniendo a cero los coeficientes por debajo del umbral de ruido perceptual; (4) codifica con Huffman los coeficientes supervivientes. El resultado para un origen fotográfico típico de 1920×1080: 200-500 KB a calidad 85 (90-95% más pequeño que el BMP origen). Calidad 90+ se aproxima a visualmente sin pérdida; por debajo de 70 produce bloques 8×8 y ringing visibles. El BMP estándar no soporta transparencia, así que la cuestión del canal alfa no aplica — la falta de alfa del JPEG no pierde nada que el BMP llevara. La variante BI_BITFIELDS del BMP puede llevar RGBA de 32 bits en algunas codificaciones específicas de Windows, pero son raras en la práctica.
- Origen BMP decodificado según el formato BITMAPFILEHEADER + BITMAPINFOHEADER de Microsoft Windows 3.0 (mayo de 1990)
- Decodificación BMP nativa del navegador vía HTMLImageElement (Chrome, Firefox, Safari, Edge todos soportados)
- Calidad JPEG ajustable 1-100 mapeada a las tablas de cuantización del Anexo K de ITU-T T.81
- Reducción de tamaño sustancial — normalmente 10-20× más pequeño (90-95% de reducción) para contenido fotográfico a calidad 85
- Contenedor de salida JFIF v1.02 (Hamilton, C-Cube Microsystems, 1 de septiembre de 1992) ampliamente aceptado por editores heredados y plataformas CMS
- Comparación de tamaño antes/después en tiempo real vía la longitud en bytes del Blob del canvas
- En el navegador vía WHATWG Canvas drawImage + HTMLCanvasElement.toBlob('image/jpeg', quality) — sin subida
- Opera en sRGB (IEC 61966-2-1:1999) a precisión de 8 bits; los BMP sin perfil ICC embebido se interpretan como sRGB
Gratis. Sin registro. Sin subidas. Anuncios mediante AdSense (con consentimiento).
Fuentes (6)
- Microsoft Corporation (1990). Windows Bitmap (BMP) File Format — BITMAPFILEHEADER + BITMAPINFOHEADER. learn.microsoft.com/en-us/windows/win32/gdi/bitmap-storage — modern BMP format introduced with Windows 3.0 (May 1990) extending the device-dependent bitmap (DDB) of Windows 1.0 (1985) and Windows 2.0 (1987) DIB support; uncompressed BI_RGB pixel storage at 1/4/8/16/24/32 bits per pixel; BITMAPFILEHEADER (14 bytes) + BITMAPINFOHEADER (40 bytes) header structure that virtually every modern BMP file uses.
- ITU-T (CCITT) Study Group VIII & ISO/IEC JTC 1/SC 29/WG 10 (JPEG) (1992). Information technology — Digital compression and coding of continuous-tone still images: Requirements and guidelines. ITU-T Recommendation T.81 (18 September 1992) / ISO/IEC 10918-1:1994 — target JPEG baseline DCT bitstream; quality 1–100 maps to Annex K quantisation tables. Converting BMP (uncompressed) to JPG (lossy DCT) typically achieves 90-95% file size reduction at quality 85.
- Hamilton, E. (C-Cube Microsystems) (1992). JPEG File Interchange Format (JFIF) Version 1.02. 1 September 1992 — target de facto JPEG container; APP0 marker, density units, thumbnail handling.
- WHATWG (live). HTML Living Standard — HTMLImageElement (browser-native BMP decoding). html.spec.whatwg.org/#htmlimageelement — BMP is natively decoded by every modern browser (Chrome, Firefox, Safari, Edge) via their built-in BMP decoder; common Windows BMP variants (BI_RGB uncompressed at 24-bit and 32-bit, optionally with BITFIELDS or RLE compression) all work.
- WHATWG (live). HTML Living Standard — Canvas 2D Context: drawImage() + toBlob('image/jpeg', quality). html.spec.whatwg.org/#dom-context-2d-drawimage + canvas section 4.12.5 — browser conversion mechanism: load BMP into HTMLImageElement → drawImage onto canvas at native dimensions → toBlob('image/jpeg', quality) re-encodes via the browser's built-in JPEG encoder.
- International Electrotechnical Commission (IEC) (1999). Multimedia systems and equipment — Colour measurement and management — Part 2-1: Default RGB colour space — sRGB. IEC 61966-2-1:1999 — default 8-bit RGB colour space the Canvas 2D path operates in; BMP files without an embedded colour profile are interpreted as sRGB by the browser decoder.
Son las especificaciones del W3C, ISO/IEC, ITU-T e IETF que la herramienta implementa o sobre las que se apoya. Localízalas en w3.org, iso.org, itu.int o datatracker.ietf.org.
Por Marco B. ·