Una foto, vista por un modelo

En la lección anterior viste que el modelo de C01 recibe 150,528 números. ¿De dónde salen, si Ana subió una foto?

Acércate mucho a cualquier foto en tu celular, haciendo zoom hasta que ya no se pueda más. En algún momento dejas de ver tenis y empiezas a ver cuadritos, cada uno de un solo color. Cada cuadrito es un píxel (de picture element, «elemento de imagen»). Una foto digital no es otra cosa: una cuadrícula de píxeles, tantos de ancho por tantos de alto.

Cuántos píxeles tiene es su resolución, y se dice como ancho × alto. Muchos celulares toman fotos de 4032 × 3024:

4032 × 3024 = 12,192,768 píxeles

Un megapíxel (MP) es un millón de píxeles, así que esa foto tiene ≈ 12.2 MP. Es el número que anuncian las cámaras de los celulares.

Más píxeles quiere decir más detalle, pero también más números que guardar y que procesar. Esa tensión aparece en todo C01: la cámara de Ana toma 12 MP, y el modelo solo necesita 224 × 224 = 50,176 píxeles. De cada 243 píxeles de la foto original, el modelo termina usando el equivalente a uno (12,192,768 ÷ 50,176 = 243). Para reconocer unos tenis alcanza. Para encontrar una grieta de 0.2 mm en una pieza de metal no alcanza, y al final de la lección vas a ver por qué.

Tres números por píxel: RGB

¿Cómo se guarda el color de un píxel? Con tres números: cuánta luz roja, cuánta verde y cuánta azul tiene. Por las iniciales en inglés (red, green, blue) se le llama RGB. Mezclando esas tres luces en distintas cantidades sale cualquier color de la pantalla, que es justo como funciona: cada píxel de tu pantalla son tres lucecitas, una roja, una verde y una azul.

Cada uno de los tres números va de 0 (nada de esa luz) a 255 (toda):

¿Por qué 255? Por cómo guarda números una computadora. Su unidad mínima es el bit, que solo puede valer 0 o 1. Ocho bits forman un byte. Con 8 bits hay 2 × 2 × 2 × 2 × 2 × 2 × 2 × 2 = 2⁸ = 256 combinaciones posibles, así que un byte puede guardar los enteros del 0 al 255. A ese tipo de número se le llama uint8: unsigned (sin signo, es decir, sin negativos), int (entero) y 8 (bits).

Con tres canales de 256 valores cada uno hay 256 × 256 × 256 = 16,777,216 colores posibles. Por eso se dice que las pantallas muestran «16.7 millones de colores».

Los canales

Fíjate en la parte de abajo de la figura. En vez de pensar en «9 píxeles con 3 números cada uno», puedes pensar en «3 cuadrículas de 9 números»: la de los rojos, la de los verdes y la de los azules. Cada una de esas cuadrículas se llama canal. Es la misma información, acomodada de otra forma, y es justo la forma en que la recibe el modelo de C01.

No todas las imágenes tienen tres canales:

• Una foto en blanco y negro (escala de grises) tiene uno solo: qué tan claro es cada píxel.
• Una imagen con transparencia tiene cuatro: RGBA. La A (alpha) dice qué tan opaco es cada píxel.

El modelo de C01 espera exactamente tres. Por eso, antes de nada, toda imagen se convierte a RGB: a la de blanco y negro se le copia su único canal tres veces, y a la RGBA se le quita la transparencia.

Cuánto ocupa una foto abierta

Ya puedes calcular cuánta memoria ocupa la foto de 12 MP cuando está abierta, como cuadrícula de píxeles:

Si una foto abierta ocupa 36.6 MB, ¿por qué el archivo pesa unos 3 MB? Porque el archivo no guarda la cuadrícula tal cual: guarda una versión comprimida. Convertir ese archivo comprimido de vuelta en la cuadrícula de píxeles se llama decodificar (decode).

Antes de decodificar, la foto de Ana es una ristra de bytes que no se parece en nada a una cuadrícula. No se le puede preguntar «¿de qué color es el píxel 10?» sin decodificarla primero.

JPEG y PNG

Hay muchos formatos de archivo de imagen. C01 acepta tres: JPEG, PNG y WebP (uno más reciente que, para la misma foto, suele dar archivos más chicos). Los dos que más vas a ver:

JPEG divide la imagen en bloques de 8 × 8 píxeles y en cada uno se queda con lo importante. Cuanto más se comprime, más se notan esos bloques: es la foto «pixeleada» que se ve cuadriculada cuando alguien la reenvió muchas veces. Por eso dos JPEG de la misma escena, guardados con distinta calidad, no dan los mismos píxeles. Lo vas a necesitar cuando veas el skew.

Decodificar cuesta

Decodificar no es gratis. Una foto de 12 MP hay que reconstruirla píxel por píxel en el procesador principal de la computadora, la CPU, y luego ocupa 36.6 MB de memoria. El modelo, en cambio, corre en una GPU: un chip hecho para hacer miles de cuentas sencillas a la vez. En C01, decodificar y preparar una foto toma unos 6 ms de CPU en promedio: tanto o más de lo que tarda el propio modelo en la GPU (≈ 3 a 6 ms). Lo vas a ver en la lección «CPU y GPU».

Y un archivo chiquito puede estar hecho a propósito para decodificarse en una imagen gigantesca que se coma la memoria del servidor: una bomba de descompresión. La sección «Archivos que explotan» cuenta cómo se defiende C01.

Lo que la foto trae escondido: EXIF

Además de los píxeles, un JPEG suele traer datos escondidos que se llaman EXIF: qué teléfono la tomó, la fecha y la hora, la exposición, cómo estaba girado el teléfono y, muchas veces, las coordenadas GPS de dónde se tomó. Importan por dos razones.

La orientación. Muchos teléfonos guardan los píxeles siempre «acostados», como los ve el sensor, y anotan en el EXIF cómo hay que girarlos. Si Ana tomó la foto con el celular de pie, el archivo trae 4032 × 3024 píxeles acostados y una nota: orientación 6, «gira 90° a la derecha para verla bien». Tu galería aplica esa nota sin que te des cuenta, y por eso tú la ves derecha. Pero una librería que solo lee los píxeles la entrega de lado. Pillow, la librería de imágenes más común en Python, no la gira a menos que se lo pidas; OpenCV, otra librería de imágenes muy usada, en sus versiones actuales la gira sola al leer, a menos que le pidas que no. Si un lado gira y el otro no, el modelo ve tenis acostados.

La privacidad. Con las coordenadas GPS de la foto de unos tenis tomada en la sala de Ana, cualquiera podría saber dónde vive. Por eso en C01 ni la foto ni su EXIF se guardan en los registros, y las pocas fotos que se copian para que una persona las etiquete (≈ 5,000 al mes) se guardan sin EXIF. Lo ves a fondo en la lección «Datos personales y la ley».

Ya tienes la cuadrícula de píxeles, derecha y en RGB. Todavía no se la puedes dar al modelo: la ResNet-50 de C01 espera una entrada de un tamaño exacto, con números de cierto tipo y en cierta escala. Todos los pasos que convierten la foto cruda en esa entrada exacta se llaman preprocesamiento (preprocessing).

Sigamos la foto de 12 MP de Ana, ya girada: 3024 de ancho × 4032 de alto.

1. 1

   Resize: el lado corto a 256

   Se achica la foto sin deformarla, hasta que su lado más corto mida 256. El ancho pasa de 3024 a 256, y el alto se achica en la misma proporción: 4032 × 256 ÷ 3024 = 341.3, que se redondea a 341. Queda de 256 × 341. A eso se le llama resize. Al achicar, cada píxel nuevo se calcula mezclando varios de los viejos; la regla para mezclarlos es la interpolación. C01 usa la bilinear con antialias, que hace que cada píxel nuevo tome en cuenta a todos los viejos que le caen debajo (la sección 5 lo explica con números).

2. 2

   Center crop: el cuadro del centro

   El modelo espera un cuadrado de 224 × 224, así que se recorta el cuadro del centro: es el crop. A lo ancho sobran 256 − 224 = 32 píxeles, 16 de cada lado. A lo alto sobran 341 − 224 = 117, unos 58 arriba y 59 abajo. ¿Por qué 256 y luego 224, y no directo a 224? Porque es la receta clásica para evaluar una ResNet-50: al entrenar, el modelo vio recortes de 224 × 224 sacados de fotos más grandes, y el recorte del centro es la versión fija, sin azar, de esos recortes. Descarta un poco de orilla, donde casi nunca está lo importante.

3. 3

   A float32 y entre 255

   Hasta aquí cada número es un uint8 de 0 a 255. Se convierte a float32, un número con decimales que ocupa 4 bytes, y se divide entre 255: ahora cada número va de 0 a 1. El naranja 236 queda en 236 ÷ 255 = 0.925.

4. 4

   Normalizar

   A cada número se le resta un promedio y se divide entre una desviación, distintos para cada canal. Es la normalización, y la vemos con números abajo.

5. 5

   Reordenar y agrupar

   Se acomodan los números en el orden que espera el modelo, primero por canal, y se les agrega una dimensión más al frente, que dice cuántas fotos van juntas. Queda el tensor [1, 3, 224, 224], que es la siguiente sección.

La normalización, con números

Después de dividir entre 255, cada número va de 0 a 1. La normalización lo mueve para que quede alrededor de 0:

valor normalizado = (valor − media del canal) ÷ desviación del canal

Para los modelos entrenados con ImageNet (un dataset famoso de ≈ 1.28 millones de fotos en 1,000 clases, con el que se entrenó la ResNet-50 original), los números son estos:

Son el promedio y la desviación estándar (qué tanto se alejan los valores de su promedio) de cada canal en las fotos de ImageNet. Lo normal es partir de un modelo ya entrenado con ImageNet y ajustarlo a tus categorías (eso es el transfer learning), y entonces se conservan sus números. C01 los usa: en la Ronda verás «normalización ImageNet».

Lo mismo en Python. Se copia y se corre tal cual, sin instalar nada:

MEDIA = (0.485, 0.456, 0.406)   # R, G y B, las de ImageNet
DESV = (0.229, 0.224, 0.225)

def normaliza(pixel):
    # de 0–255 a 0–1, y luego (valor − media) ÷ desviación, canal por canal
    return [round((v / 255 - m) / d, 2) for v, m, d in zip(pixel, MEDIA, DESV)]

print("naranja:", normaliza((236, 106, 63)))
print("negro:  ", normaliza((0, 0, 0)))
print("blanco: ", normaliza((255, 255, 255)))

naranja: [1.92, -0.18, -0.71]
negro:   [-2.12, -2.04, -1.8]
blanco:  [2.25, 2.43, 2.64]

¿Para qué tanta vuelta? Porque las cuentas del entrenamiento funcionan mucho mejor con números chicos alrededor de 0 que con números de 0 a 255 (lo vas a entender en la lección «Cómo aprende un modelo»). Y una vez que el modelo aprendió con números preparados así, solo sabe interpretar números preparados así.

Así se ve con PyTorch

Con PyTorch (la librería de Python más usada para redes neuronales), cada paso de arriba es una línea. La parte de TF es la misma que escribe la Ronda en M07; abajo, antes de usarla, se abre la foto, se gira según su EXIF y se pasa a RGB. Es una ilustración: necesita PyTorch y una foto, así que no lleva salida, y no hace falta entender cada línea.

from PIL import Image, ImageOps
import torch
from torchvision.transforms import v2 as T

TF = T.Compose([
    T.ToImage(),                           # de Pillow a tensor (orden CHW), todavía uint8
    T.Resize(256),                         # el lado corto a 256 (bilinear con antialias)
    T.CenterCrop(224),                     # el cuadro del centro, 224 × 224
    T.ToDtype(torch.float32, scale=True),  # a float32 y ÷ 255
    T.Normalize([0.485, 0.456, 0.406],     # la media de R, G y B
                [0.229, 0.224, 0.225]),    # la desviación de R, G y B
])

img = Image.open("tenis.jpg")              # abre el archivo
img = ImageOps.exif_transpose(img)         # lo gira según su EXIF
x = TF(img.convert("RGB")).unsqueeze(0)    # a RGB, preprocesa y agrega el batch
print(x.shape)                             # torch.Size([1, 3, 224, 224])

Lo que sale del preprocesamiento es un tensor: una tabla de números con cualquier cantidad de dimensiones, todos del mismo tipo. La palabra asusta más de lo que es:

Cuántos números hay en cada dimensión, en orden, es su shape (su «forma»). El de la foto de Ana es [1, 3, 224, 224]. Número por número:

• 1: cuántas fotos van juntas. Los modelos casi siempre procesan las entradas en grupos, que se llaman batches, porque calcular varias a la vez sale más barato que una por una. Una sola foto es un batch de 1. El servidor de modelos de C01 junta hasta 32 fotos que llegan casi al mismo tiempo; si junta 32, el shape es [32, 3, 224, 224].
• 3: los canales: rojo, verde y azul.
• 224: el alto, en píxeles.
• 224: el ancho, en píxeles.

Multiplica todo: 1 × 3 × 224 × 224 = 150,528 números. Esos son los 150,528 de la lección anterior.

CHW: primero los canales

El orden [canales, alto, ancho] se llama CHW (channels, height, width). Las librerías de imágenes, como Pillow, entregan otro orden: HWC, alto, ancho y los tres números de cada píxel juntos. Son los mismos 150,528 números, acomodados distinto:

• En HWC (224, 224, 3), los primeros tres números en la memoria son el R, el G y el B del primer píxel.
• En CHW (3, 224, 224), los primeros 50,176 números son todos los rojos; luego vienen todos los verdes y luego todos los azules: las tres cuadrículas de la figura de arriba, una tras otra.

PyTorch y el modelo de C01 esperan CHW. Con el batch al frente se escribe NCHW: N es cuántas fotos.

Cuánto pesa el tensor

Aquí hay que tener cuidado con las unidades. Un KB (kilobyte) son 1,000 bytes. Un KiB (kibibyte) son 1,024 bytes, porque a las computadoras les acomodan las potencias de 2. Se parecen, pero no son lo mismo, y muchos programas escriben «KB» cuando quieren decir KiB.

Y no es un tensor, son cientos por segundo. Cuando llegan 500 fotos por segundo, esos 602 KB por foto se vuelven ≈ 2.4 gigabits por segundo en la red de C01: la sección 6 hace la cuenta.

Recuerda los dos momentos de un modelo: entrenar y usar. Las fotos pasan por el preprocesamiento en los dos. Al entrenar, cada una de las fotos del dataset, que son millones; en producción, cada foto que sube Ana. Y aquí está la regla más importante de esta lección:

El preprocesamiento tiene que ser idéntico en los dos momentos.

El modelo aprendió con fotos preparadas de cierta forma. Sus perillas están ajustadas a esos números. Si en producción la foto se prepara distinto, el modelo recibe números que nunca vio, y lo peor es cómo falla: no hay ningún error. El servicio contesta rápido, con su top-5 y su porcentaje. Solo que acierta menos, y nadie se entera hasta que alguien mide.

La Ronda lo cuenta así en M09. El modelo de C01 saca 85 % de top-1 en su examen. Se despliega, y los vendedores aceptan sus sugerencias menos de lo esperado. Alguien manda fotos ya etiquetadas por el gateway real (el programa de C01 que recibe cada foto y la prepara para el modelo), y el top-1 da 80 %. En los registros no hay un solo error.

Esa diferencia tiene nombre: training-serving skew (desfase entre entrenamiento y servicio). El modelo ve en producción entradas preparadas distinto de las que aprendió por culpa de tu sistema, no porque el mundo haya cambiado.

Las causas

Todas tienen la misma forma: dos caminos de código que «hacen lo mismo» y no lo hacen.

Cómo se evita

Con tres medidas que vas a ver en la Ronda:

1. Un solo código. El preprocesamiento vive en un solo archivo, y lo importan el entrenamiento, la evaluación y el servicio. En C01 se llama preprocess.py. No dos copias «iguales» que alguien un día cambia en un solo lado.
2. Las mismas versiones. La misma librería de imágenes, en la misma versión, en los dos lados.
3. Una prueba de paridad. Unas cuantas fotos fijas (C01 usa 20) pasan por el preprocesamiento en cada cambio de código, y el tensor que sale se compara número por número con el del otro camino y con uno guardado. Es una prueba de paridad (parity test): si alguien cambia algo sin querer, falla antes de llegar a producción.

¿Qué tan grande tiene que ser una diferencia para que la prueba falle? Con el mismo código y las mismas versiones, las cuentas son las mismas y en el mismo orden, así que la diferencia debe ser exactamente 0. Si no es 0, algo cambió. Y los errores de la tabla se ven enormes en el tensor:

1. 1

   Convertir a float32 antes de achicar

   La foto de 12 MP en float32 ocupa ≈ 146 MB, solo para tirar casi todo un paso después. Cómo evitarlo: achica primero, en uint8, y convierte al final, cuando ya son 224 × 224.

2. 2

   Leer con OpenCV y olvidar que entrega BGR

   El modelo recibe el rojo y el azul cambiados, sin ningún error. Cómo evitarlo: convierte a RGB justo después de leer, dentro del archivo de preprocesamiento, y ten en las pruebas una foto de color conocido.

3. 3

   Dividir entre 255 dos veces, o ninguna

   ToDtype(..., scale=True) ya divide entre 255; si además divides tú, todo queda entre 0 y 0.004, y para el modelo la foto es casi negra. Si nadie divide, los valores llegan a ≈ 1,000. Cómo evitarlo: una sola función hace la escala y la normalización, y la prueba de paridad la vigila.

4. 4

   Confundir ancho × alto con el orden del shape

   Las fotos se dicen ancho × alto; los tensores, alto primero. Confundirlos voltea o deforma la foto. Cómo evitarlo: escribe el orden en un comentario junto a cada shape y prueba con una foto que no sea cuadrada.

5. 5

   Achicar un PNG con paleta antes de convertirlo a RGB

   En un PNG con paleta, cada píxel no guarda su color sino el número de un color en una lista. Como no tiene sentido promediar esos números, Pillow lo achica con nearest (copia al vecino más cercano) sin avisar, y la foto sale escalonada. Cómo evitarlo: primero convert("RGB"), después el resize.

6. 6

   Calcular la memoria con el peso del archivo

   Un archivo de 12 KB puede pedir 300 MB. Lo que ocupa en memoria depende de los píxeles, no del archivo. Cómo evitarlo: lee el ancho y el alto del encabezado y calcula ancho × alto × canales × bytes antes de decodificar.

7. 7

   «Arreglar» el skew reentrenando

   Si reentrenas con fotos que pasaron por un servicio que lee BGR, el modelo nuevo aprende BGR... hasta que alguien arregla el servicio y todo empeora. Es convertir un error en una dependencia. Cómo evitarlo: el skew se corrige en el código, con una prueba que impida que vuelva.

Resuélvelos con lápiz antes de abrir la solución. Los números son los de la lección. El 5 y el 9 usan las secciones extra 5 y 7: si todavía no las lees, déjalos para la segunda pasada.

1. 1Fácil

   Una imagen RGB mide 640 × 480. ¿Cuántos números son, cuántos bytes ocupa en uint8 y cuántos en float32?

   Ver la solución paso a paso

   Píxeles: 640 × 480 = 307,200. Números: 307,200 × 3 canales = 921,600.

   • En uint8, un byte por número: 921,600 B ≈ 922 KB (921,600 ÷ 1,024 = 900 KiB).
   • En float32, cuatro bytes por número: 921,600 × 4 = 3,686,400 B ≈ 3.7 MB.
2. 2Fácil

   Normaliza un píxel gris medio, (128, 128, 128), con las medias y desviaciones de ImageNet. ¿Por qué no quedan iguales los tres canales?

   Ver la solución paso a paso

   Primero, 128 ÷ 255 ≈ 0.502 en los tres canales. Después, cada uno con su media y su desviación:

   • R: (0.502 − 0.485) ÷ 0.229 ≈ 0.07
   • G: (0.502 − 0.456) ÷ 0.224 ≈ 0.21
   • B: (0.502 − 0.406) ÷ 0.225 ≈ 0.43

   No quedan iguales porque cada canal tiene su propia media: en las fotos de ImageNet hay, en promedio, más rojo que azul (0.485 contra 0.406). Comparado con lo que el modelo suele ver, este gris tiene «de más» sobre todo en el azul.

3. 3Fácil

   Una cámara graba a 25 fps: 25 frames (fotos) por segundo. ¿Cada cuántos milisegundos llega un frame y cuántos frames manda en un minuto? ¿Y una de C02, a 5 fps?

   Ver la solución paso a paso

   A 25 fps: 1,000 ÷ 25 = 40 ms entre frames, y 25 × 60 = 1,500 frames por minuto.

   A 5 fps: 1,000 ÷ 5 = 200 ms, y 5 × 60 = 300 frames por minuto: cinco veces menos trabajo para el detector.

4. 4Fácil

   El servidor de modelos junta 8 fotos de C01. ¿Qué shape tiene el tensor y cuánto pesa en float32?

   Ver la solución paso a paso

   [8, 3, 224, 224]: 8 fotos, 3 canales, 224 de alto y 224 de ancho. Son 8 × 150,528 = 1,204,224 números, por 4 bytes = 4,816,896 B ≈ 4.8 MB.

5. 5Medio

   Una fila de dos píxeles, [40, 200], se agranda a 4 píxeles. ¿Qué da con nearest y qué da con bilinear?

   Ver la solución paso a paso

   Nearest copia el vecino más cercano: [40, 40, 200, 200].

   Bilinear usa los pesos de una fila, (1, 0), (0.75, 0.25), (0.25, 0.75) y (0, 1):

   • Píxel 0: 40.
   • Píxel 1: 40 × 0.75 + 200 × 0.25 = 30 + 50 = 80.
   • Píxel 2: 40 × 0.25 + 200 × 0.75 = 10 + 150 = 160.
   • Píxel 3: 200.

   Nearest da un escalón; bilinear, una rampa.

6. 6Medio

   Un píxel rojo, (200, 30, 30), se lee con OpenCV y nadie lo convierte a RGB. ¿Qué número recibe el modelo en el canal R, y cuál debía recibir?

   Ver la solución paso a paso

   OpenCV lo entrega como (30, 30, 200), así que al canal R le llega 30:

   • Recibe: (30 ÷ 255 − 0.485) ÷ 0.229 = (0.118 − 0.485) ÷ 0.229 ≈ −1.60.
   • Debía recibir: (200 ÷ 255 − 0.485) ÷ 0.229 = (0.784 − 0.485) ÷ 0.229 ≈ 1.31.

   Una diferencia de ≈ 2.9 en una escala que va de −2.12 a +2.64: para el modelo, la cosa roja es azul. Ningún error lo avisa.

7. 7Medio

   El tráfico de C01 crece 10 veces: 5,000 fotos por segundo. ¿Cuántos Gb/s de tensores viajan del gateway a la GPU en float32, en float16 y en uint8?

   Ver la solución paso a paso

   Cada foto son 150,528 números. A 5,000 por segundo y 8 bits por byte:

   • float32: 150,528 × 4 B × 5,000 × 8 ≈ 24.1 Gb/s.
   • float16: la mitad, ≈ 12.0 Gb/s.
   • uint8: la cuarta parte, ≈ 6.0 Gb/s.

   Por eso, si C01 crece, la primera palanca de la Ronda es mandar uint8 y normalizar dentro del servidor del modelo: la red baja 4 veces, y a la GPU solo le toca una resta y una división más por número, que le cuestan casi nada.

8. 8Medio

   Un sitio de C02 tiene 40 cámaras y un enlace a internet de 50 Mb/s. ¿Cabe el video si manda el stream principal (15 fps, ≈ 4 Mb/s por cámara)? ¿Y el de 5 fps (≈ 1.5 Mb/s)?

   Ver la solución paso a paso

   • Principal: 40 × 4 = 160 Mb/s, más de 3 veces el enlace.
   • 5 fps: 40 × 1.5 = 60 Mb/s: tampoco cabe, ni usando el enlace entero.

   Ninguno cabe. Por eso C02 analiza el video en el sitio y solo sube los eventos: unas fotos y un clip corto cuando pasa algo.

9. 9Reto

   El encabezado de un PNG dice 30,000 × 30,000. ¿Cuántos megapíxeles son y cuánta memoria pediría en RGB uint8 y en float32? ¿Qué hace con él la guarda de C01, y qué haría Pillow sin configurar?

   Ver la solución paso a paso

   • Píxeles: 30,000 × 30,000 = 900,000,000 = 900 MP.
   • En RGB uint8: 900 M × 3 B = 2.7 GB. En float32: × 4 = 10.8 GB.
   • La guarda de C01 lo rechaza con un 413 en cuanto lee el encabezado: 900 MP es más de 22 veces el límite de 40 MP. No se decodifica ni un píxel.
   • Pillow, sin configurar, también se negaría: 900 MP pasa del doble de su límite de ≈ 89 MP. Pero con un PNG de 100 MP solo avisaría, y por eso C01 no depende de ese default.
10. 10Reto

    En C03, la cámara ve 150 mm de pieza en 2,448 píxeles. ¿Cuántos píxeles mide una grieta de 0.2 mm? ¿Y si la imagen se achicara a 224 de ancho? ¿Cuántos tiles de 512 × 512 hacen falta para cubrir la imagen de 2,448 × 2,048?

    Ver la solución paso a paso

    • Cada píxel cubre 150 ÷ 2,448 ≈ 0.061 mm. La grieta: 0.2 ÷ 0.061 ≈ 3.3 píxeles.
    • A 224 de ancho, cada píxel cubre 150 ÷ 224 ≈ 0.67 mm, y la grieta mide 0.2 ÷ 0.67 ≈ 0.3 píxeles: se mezcla con el metal de alrededor y desaparece.
    • Tiles: a lo ancho, 2,448 ÷ 512 ≈ 4.8, así que hacen falta 5; a lo alto, 2,048 ÷ 512 = 4. En total, 5 × 4 = 20. Cinco tiles miden 2,560 píxeles y la imagen 2,448, así que a lo ancho se traslapan un poco (112 píxeles en total), y eso ayuda a no cortar una grieta justo en la orilla de un tile. A lo alto, cuatro tiles miden justo 2,048: ahí no hay traslape.

En la Ronda:

• M01 · El mapa y la entrevista: la caja de preprocesamiento («decodificar, rotar según EXIF, redimensionar, normalizar»), con la advertencia de que tiene que ser idéntica en training y en serving, y el ejemplo de alguien que reescribe el preprocesamiento con OpenCV.
• M07 · Servidores de modelos: el gateway decodifica y normaliza en ≈ 6 ms con el mismo paquete que el entrenamiento, y manda a Triton el tensor de 602 KB en binario. En JSON, el mismo tensor pesaría ≈ 3.1 MB.
• M09 · Datos y features: la tabla completa de causas del training-serving skew, cómo se detecta y en qué se distingue del drift.
• C01: la cuenta de red (≈ 2.4 Gb/s a 500 fotos por segundo), la mejora de mandar uint8, los límites de 10 MB y 40 MP, el draft mode y la prueba con 20 fotos de referencia.
• C02, C03 y C04: frames por segundo y ancho de banda; resolución y tiles; imágenes que no caben en la memoria.
• M15 · Seguridad y confiabilidad: el EXIF con GPS como dato personal, y por qué una foto de 40 MP pesa tanto en la CPU (decenas de ms de decodificar, hasta ≈ 320 MB de memoria) que C01 limita cuántas se decodifican a la vez.

En el Dojo, la estación 1 (Datos y etiquetas) quita el EXIF de las fotos antes de mandarlas a etiquetar. Cuando estén listas, la estación 5 (Export, engine y paridad) aplica la idea de la prueba de paridad al modelo exportado, y la 6 (Código de serving) arma el gateway, que usa el mismo preprocesamiento que el entrenamiento.

En Sensei sigue «Datos, ejemplos, features y etiquetas», donde la foto ya preparada se vuelve un ejemplo con su etiqueta. Más adelante, «Redes neuronales y CNNs» muestra qué hace el modelo con los 150,528 números, «Números grandes, unidades y estimaciones» practica bits, bytes y Gb/s, y «Cómo guarda números una computadora» explica por dentro uint8, float16 y float32.

Estos son los conceptos que presentó esta lección.

Intenta responder en tu cabeza antes de abrir cada respuesta.

1. 1¿Por qué un JPEG de ≈ 3 MB ocupa 36.6 MB cuando se abre?Ver respuesta

   Porque el archivo guarda una versión comprimida: JPEG descarta detalle que el ojo casi no nota. Abierta, la foto es la cuadrícula completa: 4032 × 3024 píxeles × 3 números × 1 byte = 36.6 MB.

2. 2¿Por qué se achica la foto antes de convertirla a float32 y no al revés?Ver respuesta

   Porque la foto de 12 MP completa ocupa 36.6 MB en uint8 y 146 MB en float32. Achicar primero ahorra memoria y tiempo: la conversión se hace solo sobre los 150,528 números que de verdad llegan al modelo.

3. 3El modelo se entrenó leyendo las fotos con Pillow, y el servicio nuevo las lee con OpenCV. ¿Qué pasa?Ver respuesta

   OpenCV entrega los colores como BGR, así que el rojo y el azul llegan intercambiados: los tenis naranjas parecen azules. No sale ningún error; el modelo solo acierta menos. Es training-serving skew, y una prueba de paridad que compare los tensores de unas fotos fijas lo atrapa antes de producción.

4. 4Los vendedores empiezan a subir fotos de una categoría nueva y el modelo acierta menos. ¿Es training-serving skew?Ver respuesta

   No: es drift. Cambió el mundo, no tu código, y se arregla con datos nuevos y reentrenando. El skew aparece cuando tu propio sistema prepara las fotos distinto al entrenar y al servir, y se arregla en el código.

5. 5¿Por qué C01 lee el tamaño de la foto en su encabezado antes de decodificarla?Ver respuesta

   Para defenderse de las bombas de descompresión: un archivo de unos KB puede pedir cientos de MB al abrirse. El encabezado dice el ancho y el alto sin decodificar nada; si pasan de 40 MP, la foto se rechaza con un 413.

6. 6¿Por qué hay que leer el EXIF de una foto, y por qué después hay que quitarlo?Ver respuesta

   Hay que leerlo para aplicar la orientación: muchos teléfonos guardan los píxeles acostados y anotan en el EXIF cómo girarlos. Si no se aplica, el modelo ve la foto de lado. Y hay que quitarlo de lo que se guarda porque puede traer las coordenadas GPS de dónde se tomó: es un dato personal.