paintqrCómo comprobamos que un código QR se lee, y cómo hacerlo tú
Un código que se lee en la pantalla del portátil puede fallar en una carta de restaurante. Este es el método detrás de cada diseño de PaintQR: dos lectores de software en cada código, catorce condiciones de cámara simuladas en el laboratorio y hojas impresas escaneadas con teléfonos reales. Ese mismo método, en versión corta, es el que deberías aplicar a tu propia impresión.
Actualizado el 10 de noviembre de 2026
Tres capas, no una
No existe una prueba única que garantice que un QR se va a leer. Un decodificador en un ordenador perdona mucho más que la cámara de un teléfono a la distancia del brazo, y ese mismo teléfono perdona menos en una tienda con luz intensa que sobre un escritorio. Por eso PaintQR comprueba en tres capas, cada una más barata y frecuente que la siguiente: todo diseño se decodifica por software antes de poder descargarse; las reglas que aplica ese software salieron de pruebas con teléfonos sobre hojas impresas; y el banco de pruebas del laboratorio, con el que comparamos estilos y ajustes, somete el código a las condiciones que crea una cámara.
Cada capa detecta un fallo distinto. Los lectores de software cazan el código que sencillamente está mal. Las reglas derivadas de los teléfonos cazan diseños que se leen en el ordenador pero fallaron en dispositivos reales. El banco de pruebas nos dice, antes de que exista una regla, qué decisiones hacen frágil un código.
Primera capa: dos lectores en cada diseño
Cada diseño que ves en el generador ya ha sido decodificado dos veces. El primer lector es zxing-cpp, la biblioteca de la que descienden la mayoría de las apps de escaneo de Android. El segundo es el detector de OpenCV, que binariza la imagen por bloques y falla de otra manera: es el que sufre con los rellenos sólidos grandes. Cada lector recibe la versión en color, una versión en blanco y negro y una copia desenfocada a tres píxeles por cuadrado, que hace las veces de una impresión pequeña o borrosa.
Si el lector de referencia no consigue decodificar la imagen limpia, el diseño se rechaza sin más y el generador explica por qué. Eso no debería ocurrir nunca, y es la única comprobación sin excepciones. Los resultados de los demás lectores sobre las copias desenfocadas se guardan y aparecen en el informe; alimentan las reglas de abajo en lugar de bloquear por sí solos, porque con el desenfoque se comportan de forma errática y distinta a los teléfonos.
Segunda capa: reglas sacadas de 140 intentos con teléfonos
En septiembre de 2026 imprimimos hojas de diseños y las escaneamos con un iPhone y un Motorola con Android, con las apps de cámara de serie, a la distancia del brazo y con luz de interior, tanto en pantalla como en papel: unos 140 intentos en total. Todos los diseños que los teléfonos rechazaron seguían leyéndose en el ordenador. Por eso las reglas se construyeron a partir de las características del diseño que anticipaban los fallos en el teléfono, no a partir de los lectores de software.
Fallaron tres patrones. Un diseño en el que los cuadrados oscuros ocupan más de la mitad de la zona de datos y la mayoría forman bloques macizos, a partir de la versión 15: los casos fueron un hibisco y un corazón. Un icono de la biblioteca, oscuro y en color, en versión 15, donde fallaron 6 de 8 intentos frente a 5 de 5 que pasaron en versión 10. Y un diseño con color de acento en versión 15 que gastaba más de una quinta parte de su capacidad de corrección de errores en la imagen. Todo lo demás, letras, logotipos y fotografías en versiones de la 6 a la 15 con el ajuste por defecto, pasó todos los intentos.
Un diseño que encaja en uno de esos patrones se marca como frágil. El generador no lo vende tal cual: baja el detalle o el presupuesto de la imagen, vuelve a generar, vuelve a comprobar y te muestra qué ha cambiado. La única excepción es la versión 20, el detalle máximo: falló al tamaño que funciona para la versión 15 pero se lee si se imprime más grande, así que se permite con un tamaño mínimo de impresión mayor.
Tercera capa: el banco de pruebas
Cuando comparamos un estilo, un ajuste o un cambio en el motor, que una imagen limpia se decodifique nos dice poco. El banco de pruebas toma un código renderizado y lo pasa por catorce condiciones que imitan lo que hace una cámara: el código pequeño en el encuadre, a tres y a 2,4 píxeles por cuadrado; desenfoque; inclinación de 25 y de 40 grados y una inclinación lateral de 30; iluminación desigual; poco contraste; ruido del sensor; compresión JPEG; una captura de pantalla; la expansión de la tinta sobre el papel; y una combinación de inclinación, iluminación y desenfoque. Cada imagen pasa por todos los lectores que podemos instalar: zxing-cpp, OpenCV, el detector WeChat de OpenCV, zbar y el ZXing clásico de Java, cuyo binarizador antiguo es el menos tolerante de todos y el más parecido a las apps de escaneo viejas.
La puntuación de escaneo es la proporción de pares condición-lector que decodifican el texto correcto, y el informe señala las condiciones más débiles. Así se ajustaron la regla del tamaño de impresión y los niveles de seguridad de escaneo, y es lo que ejecutamos antes de tocar cualquier cosa que afecte a la imagen.
Cómo medimos los tamaños de impresión
Los códigos normales impresos se decodificaron hasta unos 0,4 mm por cuadrado a la distancia del brazo. Los que llevan imagen necesitaron aproximadamente una vez y media más: la versión 15 funcionó a 0,66 mm por cuadrado y falló a 0,5. La versión 20 también falló a 0,5; para ella y las superiores indicamos 0,8 mm por cuadrado, un margen por encima del fallo, hasta que una prueba de impresión a 6,5, 8,5 y 10 cm sustituya la estimación por una medida. El tamaño que aparece bajo cada diseño es su número de cuadrados, margen incluido, multiplicado por la cifra correspondiente y redondeado hacia arriba. La tabla completa por versión está en la guía de tamaños de impresión.
Comprueba tu propia impresión en cinco minutos
Nuestras comprobaciones hacen improbable un mal diseño. Lo que no pueden ver es tu impresora, tu papel ni la luz de tu local. Antes de una tirada de cartas o tarjetas, haz esto una vez:
- Imprime una sola copia al tamaño previsto y compruébala con una regla. Una página impresa con 'ajustar a la página' sale más pequeña de lo diseñado, y un código a su tamaño mínimo no tiene margen para encoger.
- Usa dos teléfonos de marcas distintas con sus apps de cámara de serie, no una app de escaneo que quizá perdone más que los teléfonos de tus clientes.
- Escanea a la distancia del brazo con la luz que tendrá el código en su sitio; luego desde una vez y media esa distancia; luego con el teléfono inclinado unos treinta grados.
- No tomes una prueba en pantalla por una prueba de impresión. Una pantalla está retroiluminada y es más nítida que el papel; un código que se lee en tu monitor solo demuestra que el diseño es válido.
- Si la superficie es brillante o está plastificada, escanéala bajo una luz de techo. Un reflejo sobre uno de los tres cuadrados grandes de las esquinas impide la lectura.
- Si algún escaneo falla, primero imprime más grande; después elige la seguridad de escaneo equilibrada o un detalle menor; por último simplifica la imagen. Casi siempre basta con una de las dos primeras.
Lo que no afirmamos
Dos teléfonos y cinco lectores no son todos los teléfonos ni todas las apps. Las apps de escaneo antiguas, construidas sobre el binarizador clásico de ZXing, leen menos que las apps de cámara modernas, y eso lo probamos en el laboratorio, no en dispositivos. Tu impresora, tu tinta y tu papel cambian el contraste de maneras que ningún modelo predice del todo. Las comprobaciones de arriba son un filtro que elimina los diseños que sabemos que fallan; la prueba impresa es la demostración, y te toca a ti hacerla.
Un límite actual, dicho sin rodeos: la opción que conserva exactas las formas de un logotipo, con el patrón del código fuera de ellas, ha superado los lectores de software y el banco de pruebas en el ajuste de máxima imagen, pero su prueba con teléfonos sobre hojas impresas aún está en curso. Hasta que termine, imprime esas marcas en grande y haz la prueba de cinco minutos antes de una tirada larga, o elige la seguridad de escaneo equilibrada, que añade corrección de errores a cambio de un poco de espacio.
Preguntas frecuentes
Mi código se lee en la pantalla pero no en papel. ¿Por qué?
El papel es más oscuro, más borroso y más pequeño que una pantalla. Las causas habituales, por orden: la impresión salió más pequeña que el tamaño mínimo, muchas veces por el 'ajustar a la página'; una superficie brillante que refleja una luz hacia la cámara; o un diseño al límite de lo que tolera el teléfono, que se arregla imprimiendo más grande o con el ajuste equilibrado.
¿Con qué teléfonos y apps hicisteis las pruebas?
Las hojas impresas se escanearon con un iPhone y un Motorola con Android usando sus apps de cámara de serie, unos 140 intentos en septiembre de 2026, con pruebas adicionales de la versión 20 en octubre. El banco de pruebas añade cinco lectores de software, entre ellos el ZXing clásico de Java, que representa a las apps de escaneo más antiguas.
¿Un código en color se lee igual de bien que uno en blanco y negro?
El teléfono distingue oscuro de claro, no colores. PaintQR mantiene cada cuadrado oscuro por debajo de un umbral de brillo y cada cuadrado claro por encima, así que los colores son para las personas y el contraste para la cámara. El único patrón en color que falló en los teléfonos, un acento fuerte en versión 15 con mucho presupuesto de imagen, ahora lo detectan las reglas.
¿Cuánta corrección de errores consume la imagen?
Un código estándar en el nivel más bajo puede reparar en torno al 7 % de sus cuadrados; en el nivel medio, en torno al 15 %. El ajuste de seguridad de escaneo decide qué parte de ese presupuesto de reparación puede gastar la imagen: Seguro, alrededor de una décima parte; Equilibrado, una quinta; Máxima imagen, alrededor de un tercio. El resto queda para arrugas, reflejos y manos temblorosas.