Existen diversas estrategias para la transferencia de color entre imágenes, incluyendo modelos basados en mezclas gaussianas, enfoques estadísticos, métodos apoyados en machine learning, así como combinaciones de varios enfoques.

Muchos métodos de transferencia de color presentan una limitación importante cuando no existe correspondencia semántica entre la imagen fuente y la imagen objetivo. En estos casos, los enfoques basados en transferencias globales tienden a producir resultados inconsistentes, al no considerar la semántica de la escena.

Una estrategia habitual para abordar esta limitación consiste en incorporar información semántica mediante técnicas de segmentación. Sin embargo, la segmentación precisa de una imagen sigue siendo una tarea compleja, especialmente cuando se busca una solución completamente automatizada. Por esta razón, cuando se requiere un mayor nivel de control y coherencia visual, resulta común recurrir a métodos de transferencia de color asistidos por el usuario.

En la práctica, la transferencia de color suele implementarse mediante transformaciones estadísticas aplicadas sobre los canales de color. Estas transformaciones difieren principalmente en qué estadísticas de la imagen se igualan y en cuánta información de la distribución cromática se tiene en cuenta, lo que da lugar a métodos con distintos niveles de expresividad y complejidad.

A continuación se presentan tres métodos estadísticos clásicos para la transferencia global de color.

Normalización de media y desviación estándar (Reinhard)

El método propuesto por Reinhard constituye un enfoque fundamental al formular la transferencia de color como un problema de igualación de estadísticas de primer y segundo orden. El procedimiento se realiza en el espacio de color Lab, elegido por su mayor aproximación a la percepción humana y su separación explícita entre luminancia (L) y cromaticidad (a, b).

Para cada canal c ∈ {L, a, b}, el método ajusta la imagen fuente para que su media y desviación estándar coincidan con las de la imagen objetivo:

$$I_c' = \frac{\sigma_c^{(t)}}{\sigma_c^{(s)}} (I_c - \mu_c^{(s)}) + \mu_c^{(t)}$$

Este proceso puede interpretarse como una normalización seguida de una reescalación, aplicada de forma independiente a cada canal. El resultado es una transferencia estable, computacionalmente eficiente y robusta frente al ruido.

Sin embargo, al limitarse a estadísticas de primer y segundo orden, este método no puede alterar la forma de la distribución (asimetría, multimodalidad), ni modelar correlaciones entre canales.

(Reinhard):

Input: source_image, target_image
Convert source_image and target_image to Lab space

for each channel c in {L, a, b}:
    mu_s  = mean(source_image[c])
    sigma_s = std(source_image[c])

    mu_t  = mean(target_image[c])
    sigma_t = std(target_image[c])

    for each pixel p in source_image[c]:
        p' = (p - mu_s) * (sigma_t / sigma_s) + mu_t
        assign p' to output_image[c]

Convert output_image back to RGB

Ajuste de histogramas y CDF matching

Para superar las limitaciones asociadas al uso de estadísticas de bajo orden, los métodos basados en histogram matching o ajuste de la función de distribución acumulada (CDF) extienden el control estadístico al considerar la distribución marginal completa de cada canal.

La idea central consiste en encontrar una transformación monótona Tc tal que la CDF del canal fuente coincida con la del canal objetivo:

$$T_c(x) = F_c^{(t),-1}(F_c^{(s)}(x))$$

Donde

$$\quad( F_c^{(s)}) \quad y \quad (F_c^{(t)} )$$

son las CDF del canal ( c ) de la imagen fuente y objetivo, respectivamente.

Este enfoque permite redistribuir los valores de intensidad de manera no lineal, ajustando contraste, rango dinámico y densidad de probabilidad, lo que resulta especialmente útil en el canal de luminancia. No obstante, al operar de forma independiente sobre cada canal, sigue sin capturar dependencias estadísticas entre componentes cromáticas.

Pseudocódigo (Histogram Matching):

Input: source_image, target_image
Convert images to chosen color space (e.g., Lab)

for each channel c:
    hist_s = histogram(source_image[c])
    hist_t = histogram(target_image[c])

    cdf_s = cumulative_sum(hist_s)
    cdf_t = cumulative_sum(hist_t)

    mapping = inverse_cdf(cdf_t) ∘ cdf_s

    for each pixel p in source_image[c]:
        p' = mapping(p)
        assign p' to output_image[c]

Convert output_image back to RGB

Transformación de blanqueamiento y recoloreo (WCT)

A diferencia de los enfoques anteriores, la Whitening and Coloring Transform (WCT) formula la transferencia de color como un problema estadístico multivariado, modelando explícitamente la matriz de covarianza completa de la distribución cromática.

Sea

$$X_s \in \mathbb{R}^{3 \times N}$$

la imagen fuente representada como un conjunto de vectores de color centrados. El método consta de dos etapas:

1. Blanqueamiento (Whitening): elimina las correlaciones entre canales y normaliza la varianza, transformando la distribución para que tenga covarianza identidad.

2. Recolorización (Coloring): impone la covarianza de la imagen objetivo, reintroduciendo correlaciones y escalas cromáticas.

Este procedimiento permite transferir no solo estadísticas marginales, sino también estructuras de dependencia entre canales, lo que se traduce en resultados visualmente más ricos y coherentes.

Es importante destacar que WCT no genera nueva información cromática: la distribución final replica la del objetivo. Por tanto, la calidad del resultado depende directamente de la diversidad cromática presente en la imagen de referencia.

(WCT):

Input: source_image, target_image
Reshape images to matrices X_s, X_t of size (3, N)

Compute mean vectors mu_s, mu_t
Center data:
    X_s = X_s - mu_s
    X_t = X_t - mu_t

Compute covariance matrices:
    C_s = cov(X_s)
    C_t = cov(X_t)

Eigen decomposition:
    C_s = E_s * D_s * E_s^T
    C_t = E_t * D_t * E_t^T

Whitening:
    X_w = D_s^{-1/2} * E_s^T * X_s

Coloring:
    X_c = E_t * D_t^{1/2} * X_w

Add target mean:
    X_out = X_c + mu_t

Reshape X_out back to image

Cada uno de los métodos ofrece un nivel distinto de control sobre el color transferido. Sin embargo, en la práctica, los tres tienden a producir resultados visualmente similares cuando se aplican a imágenes con distribuciones cromáticas compatibles. Esto se debe a que todos parten de una misma idea fundamental: la redistribución estadística de los canales de color.

Las diferencias se vuelven más evidentes en escenarios de estilización, especialmente cuando la imagen objetivo presenta una estructura cromática muy distinta de la imagen fuente, caso en el cual WCT puede ofrecer resultados más expresivos.

Aplicaciones

Aunque la transferencia global de color no resulta adecuada para muchas aplicaciones, existe un escenario en el que puede ser especialmente útil: el realce cromático de una imagen. Cuando se dispone de imágenes con una estructura de color similar, es posible emplear una imagen objetivo con mayor dispersión cromática o contraste para transferir estas características a la imagen fuente.

El objetivo, por tanto, no es cambiar la semántica de la imagen ni su contenido visual, sino redistribuir la información de color para mejorar contraste, saturación y riqueza cromática, preservando la estructura original. Desde un punto de vista estadístico, este problema puede interpretarse como una expansión y reorganización de la varianza de los canales de color, sin introducir nuevas estructuras ni dependencias espaciales.

Bajo estas condiciones, la transferencia global de color resulta adecuada siempre que la imagen objetivo comparta una estructura cromática global similar con la imagen fuente, pero presente una mayor dispersión en su distribución de color. En la práctica, esto implica elegir imágenes de referencia más contrastadas o con una paleta cromática más rica, pero sin diferencias extremas que puedan introducir artefactos visuales.

Conclusión

Muchos de los trabajos revisados para escribir este articulo abordan la transferencia de color desde una perspectiva orientada a la estilización visual, buscando efectos artísticos como transformar un amanecer en un atardecer o modificar radicalmente la atmósfera de una escena. Sin embargo, siendo crítico, gran parte de estos enfoques presenta limitaciones importantes para lograr este tipo de resultados de forma consistente y controlada.

Para obtener resultados visualmente satisfactorios en escenarios de estilización compleja suele requerir el uso de herramientas de edición manual, como Photoshop, que permiten realizar correcciones locales y ajustes finos. Aun así, los métodos de transferencia de color pueden desempeñar un papel valioso como punto de partida, proporcionando una base cromática mejorada que reduce significativamente el número de ajustes posteriores necesarios.

Esta limitación se hizo muy evidente mientras desarrollaba mi propia librería de algoritmos de procesamiento de imágenes que inicie justo en Python para aprovechar el amplio soporte de bibliotecas que tiene. En un inicio, la librería surgió únicamente como apoyo para los ejemplos de código de mis artículos, pero con el tiempo fue creciendo y comencé a utilizarla también en otros proyectos.

Aunque el rendimiento no siempre era el mejor, durante bastante tiempo no le di importancia, hasta que los tiempos de ejecución comenzaron a volverse un problema real, pero la cantidad de código y la complejidad hacían poco viable una reescritura completa en C++.

En lugar de optar por la reescritura, decidí explorar alternativas de optimización dentro del propio ecosistema de Python, comenzando por la simplificación de los algoritmos y la utilización de librerías para ciertas operaciones, pero la mejora más significativa que obtuve fue el uso de Numba.

Qué es Numba

Numba es un compilador just-in-time (JIT) para Python que transforma funciones numéricas en código máquina optimizado durante la ejecución. Su principal ventaja es acelerar secciones críticas del código sin abandonar Python ni reescribirlo en otro lenguaje.

El mayor beneficio se obtiene en funciones numéricas bien definidas, con control de flujo simple y uso intensivo de bucles, especialmente cuando operan sobre arreglos de NumPy con tipos homogéneos. En cambio, código fuertemente dependiente de objetos de Python, estructuras dinámicas o librerías ya optimizadas en C suele beneficiarse poco, e incluso puede verse afectado por la sobrecarga del proceso JIT.

Como ejemplo voy a mostrar el proceso de optimizacion de mi propia implementacion del algoritmo CLAHE. Al trabajar con cálculos locales y recorridos explícitos sobre los pixels de la imagen, resulta apropiado para mostrar cómo Numba puede acelerar este tipo de código en procesamiento de imágenes.

Breve explicación de qué es CLAHE

CLAHE (Contrast Limited Adaptive Histogram Equalization) es una variante del ecualizado de histograma que mejora el contraste de forma local. En lugar de aplicar una transformación global, divide la imagen en bloques y calcula un histograma independiente por región, lo que permite realzar detalles locales incluso en presencia de variaciones de iluminación.

Para evitar la amplificación del ruido, introduce un límite de recorte (clip limit) sobre los histogramas locales y redistribuye el exceso de forma controlada. Posteriormente, los resultados de cada bloque se combinan mediante interpolación para evitar discontinuidades visibles entre regiones.

Por su estructura basada en cálculos locales repetitivos y recorridos explícitos sobre los pixels de la imagen, hacen de CLAHE un buen candidato para analizar el impacto de distintas estrategias de optimización en Python.

En una implementación escrita solo en python, el coste de los bucles domina el tiempo de ejecución, dando lugar a un rendimiento muy inferior al de implementaciones optimizadas como la de OpenCV(hasta 17,000 veces mas lento), lo que hace evidente la necesidad de refactorizacion.

Identificación del cuello de botella

El primer paso en cualquier proceso de optimización consiste en identificar con claridad el cuello de botella, es decir, la operación o conjunto de operaciones que están dominando el tiempo total de ejecución. Para ello se pueden utilizar herramientas de análisis como cProfile, lo que permite obtener una visión global del comportamiento de la implementación del algoritmo.

print("=== cProfile: Custom CLAHE ===")
cProfile.run("HistogramEqualizationClaheGrayscale(img)")

El análisis muestra que la mayor parte del tiempo de ejecución no se concentraba en el cálculo de histogramas ni en la generación de las tablas de búsqueda, sino en la etapa de interpolación final. En particular, la función encargada de aplicar la interpolación espacial entre bloques acumulaba más del 60% del tiempo total, con cientos de miles de llamadas a funciones auxiliares y operaciones elementales dentro de bucles en Python.

Este resultado dejaba claro que el principal problema de rendimiento no esta en el algoritmo en sí, sino en la ejecución repetitiva de bucles y operaciones a bajo nivel dentro del intérprete de Python.

La interpolación como principal problema

Al inspeccionar el perfil, la función que más tiempo consume es la encargada de la interpolación bilineal:

1.096 s  ApplyInterpolation
0.234 s  InterpolationIndices

Es decir, la mayor parte del tiempo se recorre píxel a píxel en la imagen, combinando los mapas de transformación generados.

Implementación original: clara pero costosa

La versión original priorizaba la legibilidad y la separación de responsabilidades. Conceptualmente es correcta, pero desde el punto de vista del rendimiento es muy cara:

for y in range(height):
    i0, i1, y_weight = InterpolationIndices(y, cell_h, n_rows)

    for x in range(width):
        j0, j1, x_weight = InterpolationIndices(x, cell_w, n_cols)
        ...

Aquí ocurre lo peor para Python:

• Bucles anidados en Python puro

• Llamadas repetidas a InterpolationIndices

• Uso de np.floor y np.round en contexto escalar

Cada una de estas operaciones es pequeña, pero ejecutadas cientos de miles de veces se vuelven dominantes.

Enfoque optimizado: menos abstracción, más control

La versión optimizada cambia completamente el enfoque. En lugar de llamar a funciones auxiliares, toda la lógica de interpolación se integra directamente dentro del bucle, y se compila con Numba:

@njit(cache=True, fastmath=True)
def apply_interpolation_numba(...):
    for y in range(h):
        fy = (y + 0.5) / cell_h - 0.5
        ...
        for x in range(w):
            fx = (x + 0.5) / cell_w - 0.5
            ...

Las decisiones clave aquí son:

• Eliminar llamadas a funciones dentro del bucle crítico

• Reemplazar operaciones de NumPy por aritmética simple

• Usar tipos estáticos y bucles compilados con @njit

Esto permite que Numba genere código máquina eficiente, muy cercano a lo que escribirías en C o C++.

Este ejemplo deja una lección clara:
cuando el cuello de botella está en bucles intensivos y operaciones simples repetidas muchas veces, el problema no es Python como lenguaje, sino el coste del intérprete. En esos casos, Numba encaja de forma natural como una herramienta de optimización, especialmente en contextos de investigación donde la claridad del código sigue siendo importante. ahora las ordenes de magnitud estan solo en 5 y no en 170000.

Evitar comprobaciones repetitivas en el camino crítico

Una optimización menos evidente, pero igual de importante, es, eliminar validaciones y comprobaciones dentro de funciones que se ejecutan miles de veces. En Python solemos escribir código defensivo, validando tipos, dimensiones y rangos en cada llamada. Esto es correcto desde el punto de vista de la robustez, pero puede ser muy costoso cuando esas funciones forman parte del camino crítico del algoritmo.

Por ejemplo, en la versión original del cálculo del histograma se realizan varias comprobaciones en cada llamada:

def cal_histogram(channel):
    if not isinstance(channel, np.ndarray):
        raise TypeError(...)

    if channel.ndim != 2:
        raise ValueError(...)

    if channel.dtype != np.uint8:
        raise ValueError(...)

Estas validaciones son razonables si la función se usa de forma aislada o como API pública. El problema es que, en CLAHE, esta función se ejecuta una vez por bloque, y el número de bloques puede crecer rápidamente. El coste de estas comprobaciones termina siendo mayor que el propio cálculo del histograma.

Validar una vez, no cien veces

La clave aquí es separar responsabilidades:

• Las validaciones deben hacerse una sola vez, al inicio del procesamiento.

• Las funciones internas deben asumir que los datos ya son correctos.

En el contexto de CLAHE, tiene mucho más sentido comprobar que la imagen es uint8, 2D y válidar antes de entrar al bucle principal, y no dentro de cada llamada al histograma o al recorte del histograma.

Este cambio reduce drásticamente el trabajo innecesario del intérprete y, siguiendo esa misma idea, las versiones especializadas para el núcleo del algoritmo —como las optimizadas con Numba— eliminan por completo las comprobaciones para centrarse exclusivamente en el cálculo.

@njit(cache=True, fastmath=True)
def cal_histogram_numba(block):
    hist = np.zeros(256, dtype=np.int32)
    h, w = block.shape

    for y in range(h):
        for x in range(w):
            hist[block[y, x]] += 1

    return hist

Aquí se asume explícitamente que:

• block es 2D

• los valores están en [0, 255]

• el tipo de dato es el esperado

No hay verificaciones, no hay conversiones, no hay llamadas a funciones externas. Solo bucles y operaciones simples, exactamente lo que Numba puede optimizar bien.

Lo mismo ocurre con el recorte del histograma:

@njit(cache=True, fastmath=True)
def clip_histogram_numba(hist, clip_limit):
    excess = 0
    for i in range(256):
        if hist[i] > clip_limit:
            excess += hist[i] - clip_limit
            hist[i] = clip_limit

    incr = excess // 256
    for i in range(256):
        hist[i] += incr

    return hist

Ejemplos

conclusion

La idea central es simple: el código rápido no es el más defensivo, sino el que ejecuta solo lo necesario, una vez y en el lugar correcto. En algoritmos intensivos, como los de procesamiento de imágenes, conviene validar al inicio, fallar rápido y mantener el núcleo del algoritmo lo más simple y predecible posible.

Numba refuerza esta mentalidad al separar claramente la lógica de alto nivel del código crítico de bajo nivel. Aunque Python tenga límites en cómputo intensivo, un algoritmo bien diseñado —con lógica simplificada y sin trabajo innecesario en el camino crítico— puede acercarse mucho al rendimiento de código compilado usando herramientas como NumPy y Numba.

Este enfoque requiere definir un umbral que permita separar correctamente ambas regiones. El análisis del histograma de intensidades resulta especialmente útil en este contexto, ya que, en muchos casos, el fondo y el objeto presentan distribuciones de intensidad diferenciadas.

Los métodos de umbralización automática buscan explotar esta característica para determinar el umbral de manera simple y rapida. Uno de los más utilizados es el algoritmo de Otsu, que selecciona el umbral óptimo maximizando la separabilidad estadística entre las dos clases de píxeles.

¿Cómo funciona?

El algoritmo de Otsu determina automáticamente un umbral global analizando la distribución de intensidades de la imagen. Su objetivo es encontrar el valor de umbral que separa los píxeles en dos clases de la forma más discriminativa posible, basándose únicamente en la información estadística del histograma.

1. Cálculo del histograma
El proceso comienza calculando el histograma de la imagen en escala de grises. Este histograma representa la frecuencia de cada nivel de intensidad y constituye la base para evaluar todos los posibles valores de umbral.

2. Evaluación de umbrales candidatos
Cada posible nivel de intensidad se considera como un umbral candidato. Para un umbral dado, la imagen se divide en dos clases: una correspondiente a los píxeles con intensidades menores o iguales al umbral y otra con intensidades mayores.

3. Cálculo de estadísticas por clase
Para cada una de las dos clases se calculan su peso (proporción de píxeles) y su media de intensidad. Estas magnitudes describen cómo se distribuyen los valores de gris en cada grupo.

4. Varianza entre clases
A partir de los pesos y las medias de ambas clases, se calcula la varianza entre clases, que mide qué tan separadas están estadísticamente. Cuanto mayor es esta varianza, mejor es la separación entre fondo y objeto para ese umbral.

5. Selección del umbral óptimo
El algoritmo recorre todos los umbrales posibles y selecciona aquel que maximiza la varianza entre clases. Este valor corresponde al umbral óptimo, ya que proporciona la mejor separabilidad estadística entre las dos regiones de la imagen.

def OtsuThreshold(I):
    """Implementación del algoritmo de Otsu para encontrar el umbral óptimo."""
    # 1. Calcular el histograma
    hist = CalHistogram(I)
    total_pixels = I.size

    # Inicialización de las medias m0 y m1
    m0 = 0
    m1 = np.sum(np.arange(256) * hist)
    w0 = 0
    w1 = np.sum(hist)

    # 2. Calcular el umbral óptimo
    max_between_class_variance = 0
    optimal_threshold = 0

    # Calcular la varianza intra-clase para cada umbral
    for t in range(1, 256):  # Iterar por todos los posibles umbrales (1 a 255)
        w0 += hist[t - 1]  # Proporción de píxeles en el grupo 0 (fondo)
        w1 -= hist[t - 1]  # Proporción de píxeles en el grupo 1 (objeto)

        # Calcular las medias de los grupos
        m0 += (t - 1) * hist[t - 1]
        m1 -= (t - 1) * hist[t - 1]

        # Si no hay píxeles en el fondo o en el objeto, continuar
        if w0 == 0 or w1 == 0:
            continue

        # Calcular la varianza entre clases
        mean_diff = m0 / w0 - m1 / w1
        between_class_variance = w0 * w1 * mean_diff ** 2

        # Comparar la varianza entre clases
        if between_class_variance > max_between_class_variance:
            max_between_class_variance = between_class_variance
            optimal_threshold = t

    return optimal_threshold

Resultados

Una vez obtenido el umbral óptimo con el algoritmo de Otsu, el siguiente paso consiste en aplicar la binarización de la imagen utilizando ese valor:

thr_ots = lip.OtsuThreshold(img) 
_, binary_img = cv.threshold(img, thr_ots, 255, cv.THRESH_BINARY)

En esta línea, thr_ots corresponde al umbral calculado automáticamente, y binary_img es la imagen binaria resultante, en la que los píxeles del objeto se asignan al valor máximo (255) y los del fondo a cero.

Este procedimiento es un método sencillo y eficiente de umbralización, que funciona particularmente bien cuando el fondo es claramente distinguible del objeto. La facilidad de cálculo y su efectividad en imágenes con histogramas bimodales lo convierten en una herramienta práctica para segmentación rápida y confiable.

El algoritmo de Otsu es un método robusto y eficiente para la umbralización de imágenes en escala de grises, especialmente cuando el fondo y el objeto están claramente diferenciados y el histograma presenta una distribución bimodal. Su simplicidad y capacidad para calcular automáticamente un umbral óptimo lo hacen ideal para tareas de segmentación rápida sin necesidad de calculos manuales.

Limitaciones

Sin embargo, esta técnica presenta limitaciones importantes. En imágenes más complejas, donde el fondo y el objeto exhiben intensidades similares, o donde intervienen sombras, gradientes de iluminación o ruido, la segmentación mediante un único umbral global suele resultar ineficaz. Esto se debe a que dicho enfoque no considera variaciones locales de intensidad, lo que puede conducir a errores en la separación de regiones.

Un ejemplo de esta situación se observa en la imagen de las monedas: aunque el fondo es visualmente distinguible de los objetos, el histograma de intensidades muestra una fuerte concentración en valores superiores a 200.

Esto ocurre debido a la predominancia del fondo blanco y de los tonos grises claros presentes en la imagen, lo que provoca que el método de Otsu no logre una separación adecuada entre fondo y objetos.

Una solución simple consiste en eliminar explícitamente el rango de intensidades correspondiente al fondo. Dado que el fondo se concentra en valores altos de intensidad, se puede aplicar una umbralización por rango para suprimir dichos píxeles.

img_rg, mask_rg = lip.RemoveIntensityRange(img, low=245, high=255, fill=0)

En este caso, se descartan las intensidades comprendidas entre 0 y 245 , asignándoles un valor 255, lo que permite reducir la influencia del fondo y resaltar las regiones de interés antes de aplicar técnicas de segmentación posteriores.

La umbralización y, en particular, el método de Otsu, constituyen herramientas simples y eficientes para la segmentación de imágenes en escala de grises cuando existe una separación clara entre fondo y objeto. No obstante, su carácter global limita su desempeño en escenas más complejas, donde la distribución de intensidades está dominada por el fondo o presenta variaciones locales significativas. En estos casos, resulta necesario complementar la umbralización automática con estrategias adicionales, como la supresión de rangos de intensidad o el uso de espacios de color más adecuados, con el fin de mejorar la separación de las regiones de interés.

Esta sección se centra en esos aspectos prácticos. Se examina el paso de argumentos, la propiedad de los hilos y la organización de múltiples hilos en ejecución. Cada uno de estos elementos define la manera en que un programa concurrente distribuye su trabajo y aprovecha realmente los recursos del sistema.

Pasar argumentos a una función de hilo

Cuando creamos un hilo en C++ con std::thread, además de especificar la función que ejecutará, también podemos pasarle argumentos. Esto se realiza directamente en el constructor del hilo, como si estuviéramos llamando a la función:

void f(int i, std::string const& s);

int main() {
    std::thread t(f, 3, "hello");
    t.join();
}

En este caso, el hilo ejecutará la llamada f(3, "hello"). Sin embargo, aunque parezca una llamada directa, internamente el constructor de std::thread copia los argumentos a un almacenamiento interno, y luego los pasa a la función como valores temporales (rvalues) dentro del nuevo hilo de ejecución.

Esto tiene varias consecuencias importantes.

Copias internas y conversiones tardías

Los argumentos se copian tal cual son proporcionados, antes de que ocurra cualquier conversión de tipo esperada por la función.
Por ejemplo, en el siguiente código:

void f(int i, std::string const& s);

void oops(int some_param) {
    char buffer[1024];
    sprintf(buffer, "%i", some_param);
    std::thread t(f, 3, buffer);  // <- Peligroso
    t.detach();
}

Aquí buffer es un arreglo local, y lo que realmente se pasa al hilo es un puntero (char*). El constructor de std::thread copia ese puntero sin realizar la conversión a std::string, porque esa conversión ocurre más tarde, cuando el hilo comienza su ejecución.
El problema es que, para cuando el nuevo hilo intenta hacer la conversión, buffer podría haber dejado de existir, produciendo comportamiento indefinido.

La forma correcta es convertir explícitamente a std::string antes de pasar el argumento:

void not_oops(int some_param) {
    char buffer[1024];
    sprintf(buffer, "%i", some_param);
    std::thread t(f, 3, std::string(buffer));  // <- Correcto
    t.detach();
}

En este caso, la conversión a std::string ocurre en el hilo principal, de modo que lo que se copia internamente es un objeto completamente válido e independiente.

Paso por referencia: std::ref y std::cref

De manera predeterminada, std::thread copia todos los argumentos, incluso si la función espera una referencia.
Esto significa que el siguiente código no compilará:

void update_data_for_widget(widget_id w, widget_data& data);

void oops_again(widget_id w) {
    widget_data data;
    std::thread t(update_data_for_widget, w, data);  // <- Error
    t.join();
}

Aquí, update_data_for_widget espera una referencia, pero std::thread intenta pasar una copia de data como si fuera un rvalue, lo cual no es válido para una referencia no constante.

Para indicar explícitamente que queremos pasar una referencia, debemos envolver el argumento con std::ref (o std::cref si es una referencia constante):

std::thread t(update_data_for_widget, w, std::ref(data));

Ahora el hilo recibirá una referencia real a data, y la función podrá modificarla correctamente.

Paso de objetos no copiables (uso de std::move)

Existen tipos que no pueden copiarse, como std::unique_ptr, pero que sí pueden moverse. En estos casos, es necesario usar std::move para transferir la propiedad del objeto al hilo:

void process_big_object(std::unique_ptr<big_object> ptr);

int main() {
    std::unique_ptr<big_object> p(new big_object);
    p->prepare_data(42);

    std::thread t(process_big_object, std::move(p));
    t.join();
}

Aquí, la propiedad del puntero se transfiere al hilo, y el objeto p en el hilo principal queda vacío. Este enfoque es muy útil cuando se desea pasar recursos dinámicos de forma segura y eficiente.

Funciones miembro y lambdas

std::thread también puede ejecutar funciones miembro de una clase. En ese caso, el primer argumento debe ser el puntero al objeto sobre el cual se invocará el método:

class X {
public:
    void do_lengthy_work() {
        std::cout << "Ejecutando trabajo largo...\n";
    }
};

int main() {
    X x;
    std::thread t(&X::do_lengthy_work, &x);
    t.join();
}

Esto ejecutará x.do_lengthy_work() en el nuevo hilo.

De manera análoga, es posible usar lambdas para encapsular tanto la función como los argumentos:

int main() {
    int value = 10;
    std::thread t([value]() {
        std::cout << "Valor: " << value << '\n';
    });
    t.join();
}

Las lambdas capturan los valores según sus reglas ([value], [&value], [=], [&]), lo que permite controlar explícitamente si se copian o se referencian los datos.

Consideraciones sobre el tiempo de vida

Es fundamental garantizar que los objetos referenciados por el hilo permanezcan válidos mientras el hilo los use.
Esto implica:

• Si pasas referencias (con std::ref), asegúrate de que el objeto exista al menos hasta que el hilo finalice.

• Si pasas punteros, evita apuntar a variables automáticas que puedan salir de alcance.

• Si usas detach(), ten cuidado: el hilo puede seguir ejecutándose después de que el contexto local haya terminado.

En general, es más seguro pasar copias o usar std::shared_ptr si el objeto necesita sobrevivir más allá del alcance del hilo que lo creó.

Transferir la propiedad de un hilo

Cada objeto std::thread posee un hilo de ejecución: es el responsable de gestionar su ciclo de vida, ya sea esperando su finalización mediante join() o liberándolo con detach().

Esta relación exclusiva implica que solo un objeto std::thread puede poseer un hilo determinado a la vez.

A diferencia de otros tipos copiables, los hilos no pueden duplicarse, porque esto implicaría que dos objetos intentaran controlar el mismo recurso del sistema operativo. Sin embargo, sí pueden transferirse entre objetos mediante move semantics —el mismo mecanismo que utilizan clases como std::unique_ptr para transferir propiedad de recursos únicos.

Propiedad y movimiento de hilos

El siguiente ejemplo muestra cómo puede moverse la propiedad de un hilo entre distintos objetos std::thread:

void some_function();
void some_other_function();

int main() {
    std::thread t1(some_function);        // t1 posee el hilo
    std::thread t2 = std::move(t1);       // t2 toma la propiedad
    t1 = std::thread(some_other_function); // t1 crea y posee un nuevo hilo
    std::thread t3;                       // hilo vacío
    t3 = std::move(t2);                   // t3 toma el hilo original
    t1 = std::move(t3);                   // ¡Error! std::terminate()
}

El flujo de propiedad es el siguiente:

1. t1 crea un hilo que ejecuta some_function.

2. t2 = std::move(t1) transfiere la propiedad del hilo de t1 a t2.
   Después de esto, t1 queda sin hilo asociado.

3. t1 = std::thread(some_other_function) inicia un nuevo hilo y se convierte en su dueño.

4. t3 toma el hilo de t2 con std::move(t2).

5. Finalmente, la reasignación t1 = std::move(t3) provoca la terminación del programa, ya que t1 aún era dueño de un hilo no finalizado.

Este último punto es importante: asignar un nuevo hilo a un objeto que ya posee uno activo invoca std::terminate().
La norma impone esto para mantener la consistencia con el destructor de std::thread, que también requiere que el hilo se haya sincronizado o desacoplado antes de destruir el objeto.

Transferencia de hilos entre funciones

El soporte de movimiento en std::thread permite devolver o recibir hilos por valor en funciones, algo muy útil para diseñar interfaces limpias y seguras.

std::thread create_thread() {
    return std::thread([] {
        std::cout << "Ejecutando hilo...\n";
    });
}

void consume_thread(std::thread t) {
    if (t.joinable()) t.join();
}

int main() {
    std::thread t = create_thread();   // El hilo se transfiere por retorno
    consume_thread(std::move(t));      // Se pasa la propiedad a la función
}

En este ejemplo:

• create_thread() devuelve un std::thread movido, que transfiere su propiedad al llamador.

• consume_thread() acepta el hilo por valor, y puede unirse a él sin preocuparse de interferir con otros dueños.

La transferencia explícita mediante std::move() evita copias ilegales y garantiza que solo exista un dueño válido del hilo en cada momento.

Clases auxiliares: scoped_thread y joining_thread

A menudo es conveniente encapsular la gestión del hilo dentro de un objeto que asegure la sincronización automática al salir del ámbito. Una forma sencilla de hacerlo es con una clase llamada scoped_thread, que toma la propiedad de un hilo en su constructor y lo une en su destructor:

class scoped_thread {
    std::thread t;
public:
    explicit scoped_thread(std::thread t_) : t(std::move(t_)) {
        if (!t.joinable())
            throw std::logic_error("No thread");
    }
    ~scoped_thread() {
        t.join();
    }

    scoped_thread(const scoped_thread&) = delete;
    scoped_thread& operator=(const scoped_thread&) = delete;
};

Su uso es simple y seguro:

void task();

int main() {
    scoped_thread worker(std::thread(task));  // El hilo se une automáticamente al salir
}

Gracias a este patrón, se evita olvidar la llamada a join(), reduciendo el riesgo de errores y cierres abruptos del programa.

Una variante más flexible es la clase joining_thread, que se comporta como un std::thread estándar pero se une automáticamente en su destructor. Esto permite usarla de forma más natural en estructuras dinámicas o funciones que retornan hilos

class joining_thread {
    std::thread t;
public:
    joining_thread() noexcept = default;

    template <typename Callable, typename... Args>
    explicit joining_thread(Callable&& f, Args&&... args)
        : t(std::forward<Callable>(f), std::forward<Args>(args)...) {}

    joining_thread(joining_thread&& other) noexcept
        : t(std::move(other.t)) {}

    joining_thread& operator=(joining_thread&& other) noexcept {
        if (joinable()) join();
        t = std::move(other.t);
        return *this;
    }

    ~joining_thread() noexcept {
        if (joinable()) join();
    }

    bool joinable() const noexcept { return t.joinable(); }
    void join() { t.join(); }
    void detach() { t.detach(); }
};

De esta forma, joining_thread combina la seguridad de scoped_thread con la flexibilidad de std::thread.

Contenedores de hilos

El soporte de movimiento también permite almacenar hilos en contenedores dinámicos como std::vector.

Esto resulta útil para lanzar múltiples tareas y luego sincronizarlas en grupo:

void do_work(unsigned id) {
    std::cout << "Trabajando en hilo " << id << "\n";
}

int main() {
    std::vector<std::thread> threads;

    for (unsigned i = 0; i < 8; ++i)
        threads.emplace_back(do_work, i);

    for (auto& t : threads)
        if (t.joinable()) t.join();
}

Cada hilo se crea y se almacena dentro del vector mediante movimiento implícito, y luego todos son sincronizados al final del programa.
Esta técnica permite administrar un número variable de hilos sin declarar múltiples variables, facilitando la creación de thread pools o sistemas de tareas paralelas.

Elegir el número de hilos en tiempo de ejecución

Determinar cuántos hilos crear en un programa concurrente es una de las decisiones más importantes al diseñar una aplicación paralela eficiente. Crear demasiados hilos puede saturar el sistema operativo con cambios de contexto innecesarios; crear muy pocos desaprovecha el potencial de paralelismo del hardware.

Por ello, el número de hilos óptimo debe elegirse en tiempo de ejecución, tomando en cuenta los recursos físicos disponibles y el tipo de carga de trabajo.

Consultar el hardware: std::thread::hardware_concurrency()

La biblioteca estándar de C++ proporciona una función que sirve como guía inicial para decidir cuántos hilos pueden ejecutarse realmente de forma concurrente:

unsigned int n = std::thread::hardware_concurrency();

Esta función devuelve el número de hardware threads (generalmente, el número de núcleos o núcleos lógicos) disponibles para el programa.
Por ejemplo, en un CPU con cuatro núcleos físicos y hyper-threading, el valor devuelto podría ser 8.

Sin embargo, es importante entender que este valor es solo una sugerencia.
La implementación puede devolver 0 si la información no está disponible, por lo que es buena práctica definir un valor por defecto:

unsigned int num_threads = std::thread::hardware_concurrency();
if (num_threads == 0)
    num_threads = 2;  // valor por defecto razonable

Este número sirve como punto de partida para asignar trabajo entre hilos, pero no siempre representa la cantidad ideal: en tareas muy ligeras o con fuerte interacción entre hilos, crear un hilo por núcleo puede no ser lo más eficiente.

Estrategia básica: dividir la carga de trabajo

Una forma sencilla de aplicar este principio es dividir un conjunto de datos entre varios hilos.

El ejemplo siguiente implementa una versión paralela del algoritmo std::accumulate, que suma los elementos de un rango, dividiéndolos entre varios hilos según la cantidad de núcleos disponibles.

accumulate_CD_04

template <typename Iterator, typename T>
struct accumulate_block {
    void operator()(Iterator first, Iterator last, T& result) {
        result = std::accumulate(first, last, result);
    }
};

template <typename Iterator, typename T>
T parallel_accumulate(Iterator first, Iterator last, T init) {
    unsigned long const length = std::distance(first, last);
    if (!length)
        return init;

    unsigned long const min_per_thread = 25;
    unsigned long const max_threads =
        (length + min_per_thread - 1) / min_per_thread;

    unsigned long const hardware_threads =
        std::thread::hardware_concurrency();

    unsigned long const num_threads =
        std::min(hardware_threads != 0 ? hardware_threads : 2, max_threads);

    unsigned long const block_size = length / num_threads;

    std::vector<T> results(num_threads);
    std::vector<std::thread> threads(num_threads - 1);

    Iterator block_start = first;
    for (unsigned long i = 0; i < (num_threads - 1); ++i) {
        Iterator block_end = block_start;
        std::advance(block_end, block_size);
        threads[i] = std::thread(
            accumulate_block<Iterator, T>(),
            block_start, block_end, std::ref(results[i])
        );
        block_start = block_end;
    }

    accumulate_block<Iterator, T>()(
        block_start, last, results[num_threads - 1]
    );

    for (auto& t : threads)
        t.join();

    return std::accumulate(results.begin(), results.end(), init);
}

Análisis del algoritmo

1. Verificación del tamaño de entrada
   Si el rango está vacío, simplemente se devuelve el valor inicial init.
   Esto evita lanzar hilos innecesarios cuando no hay trabajo que hacer.

2. Límite mínimo por hilo
   Se define un número mínimo de elementos por hilo (min_per_thread), con el fin de evitar la sobrecarga que supondría crear muchos hilos para tareas pequeñas.

3. Cálculo del número máximo de hilos
   A partir del tamaño del rango y del mínimo por hilo, se obtiene el número máximo de hilos que tendría sentido crear.

4. Número real de hilos a usar
   Se elige el menor valor entre el número máximo calculado y el número de hilos de hardware disponibles. Además, si la consulta al hardware falla, se usa un valor por defecto (en este caso, 2).

5. División del trabajo
   El tamaño del bloque asignado a cada hilo se calcula dividiendo la longitud total entre el número de hilos (block_size).

6. Creación y ejecución de hilos
   Se lanzan num_threads - 1 hilos, cada uno procesando una parte del rango.
   El hilo principal procesa el último bloque para evitar crear un hilo adicional.

7. Sincronización final
   Todos los hilos creados se sincronizan mediante join(), y luego se combinan los resultados parciales con un último std::accumulate.

Consideraciones sobre rendimiento

El objetivo de este enfoque es maximizar la utilización del hardware evitando el fenómeno de oversubscription, que ocurre cuando hay más hilos activos que núcleos disponibles. El exceso de hilos genera cambios de contexto constantes, lo que degrada el rendimiento en lugar de mejorarlo.

Algunos puntos clave:

• Sobrecarga de creación: lanzar un hilo tiene un costo no trivial; conviene hacerlo solo cuando el trabajo lo justifique.

• Equilibrio de carga: si los hilos procesan bloques de distinto tamaño o complejidad, algunos núcleos quedarán inactivos antes que otros.

• Afinidad de CPU: en casos de alta demanda puede ser beneficioso fijar ciertos hilos a núcleos específicos, aunque esto se gestiona a nivel del sistema operativo.

• Reutilización de hilos: en tareas repetitivas conviene emplear un thread pool, que mantiene un conjunto fijo de hilos reutilizables en lugar de crearlos y destruirlos continuamente.

Ejemplo práctico: elegir dinámicamente según carga

Una mejora práctica consiste en ajustar el número de hilos según la carga real y no solo por hardware. Por ejemplo:

unsigned int hardware = std::thread::hardware_concurrency();
unsigned int num_threads = std::min(hardware != 0 ? hardware : 2,
                                    total_tasks / min_work_per_thread);
num_threads = std::max(1u, num_threads);  // garantizar al menos un hilo

Esta estrategia evita crear más hilos de los necesarios cuando la tarea es pequeña, pero aprovecha al máximo los núcleos disponibles cuando hay suficiente trabajo.

Identificar hilos

Cuando se trabaja con múltiples hilos, puede ser necesario distinguir cuál de ellos está ejecutando una determinada parte del código. Por ejemplo, podríamos querer registrar qué hilo está procesando una tarea, asignar recursos según el hilo, o simplemente generar trazas para depurar comportamientos concurrentes.
La biblioteca estándar de C++ proporciona un mecanismo seguro y eficiente para realizar esta identificación mediante la clase std::thread::id.

Obtener el identificador de un hilo

Existen dos formas principales de obtener un identificador de tipo std::thread::id:

1. Desde un objeto std::thread

    std::thread t(f);
    std::thread::id id = t.get_id();
   

El método get_id() devuelve el identificador del hilo asociado al objeto.

Si el objeto std::thread no está asociado a ningún hilo de ejecución (por ejemplo, porque fue creado sin función o ya se le hizo join() o detach()), la llamada devuelve un identificador por defecto, que representa “ningún hilo”.

2. Desde el hilo actual

    std::thread::id id = std::this_thread::get_id();
   

   Esta función devuelve el identificador del hilo que la invoca. Es especialmente útil dentro de funciones que pueden ser ejecutadas por distintos hilos, ya que permite saber cuál de ellos está ejecutando la llamada.

Propiedades del identificador

Los objetos de tipo std::thread::id son copiables y comparables. Esto permite usarlos de forma natural para verificar si dos hilos son el mismo:

if (t1.get_id() == t2.get_id())
    std::cout << "Ambos objetos representan el mismo hilo\n";

Si dos identificadores son iguales, representan el mismo hilo o ambos son “ningún hilo”. Además, la clase proporciona un orden total: pueden compararse con <, >, etc., lo que permite usarlos como claves en contenedores asociativos, tanto ordenados (std::map) como no ordenados (std::unordered_map), gracias a que existe una especialización de std::hash<std::thread::id>.

Ejemplo:

std::unordered_map<std::thread::id, std::string> thread_names;
thread_names[std::this_thread::get_id()] = "Hilo principal";

Uso en registro y depuración

El identificador de hilo resulta especialmente útil para generar trazas de ejecución.

Por ejemplo, en un sistema concurrente de procesamiento de tareas, podríamos imprimir qué hilo está procesando cada bloque de datos:

void process_task(int task_id) {
    std::cout << "Hilo " << std::this_thread::get_id()
              << " procesando tarea " << task_id << '\n';
}

Cada ejecución imprimirá un valor distinto de std::thread::id, lo que permite identificar fácilmente qué hilo realizó cada operación. El formato exacto del identificador depende de la implementación, pero la norma garantiza que hilos diferentes producirán salidas distintas**, y que **hilos iguales producirán la misma salida.

Ejemplo: distinguir el hilo maestro de los trabajadores

Supongamos que el hilo principal lanza varios hilos para realizar trabajo paralelo, pero necesita ejecutar una tarea especial que solo él debe realizar. En ese caso, puede almacenar su propio identificador antes de lanzar los hilos y luego compararlo dentro del código compartido:

std::thread::id master_thread;

void some_core_part_of_algorithm() {
    if (std::this_thread::get_id() == master_thread) {
        do_master_thread_work();   // tarea exclusiva del hilo maestro
    }
    do_common_work();              // tarea común a todos los hilos
}

int main() {
    master_thread = std::this_thread::get_id();
    std::thread worker1(some_core_part_of_algorithm);
    std::thread worker2(some_core_part_of_algorithm);

    some_core_part_of_algorithm(); // ejecuta el maestro

    worker1.join();
    worker2.join();
}

Aquí, todos los hilos ejecutan la misma función, pero solo el hilo maestro realiza la sección especial al comparar su std::thread::id con el almacenado.

Asociar datos a hilos mediante identificadores

En ocasiones, es útil mantener información específica de cada hilo, como estadísticas o configuraciones locales.
Si no se desea usar thread-local storage, puede construirse un contenedor donde la clave sea el identificador del hilo:

std::map<std::thread::id, ThreadStats> stats_map;

void log_event(std::string event) {
    stats_map[std::this_thread::get_id()].events.push_back(event);
}

Este enfoque resulta práctico cuando se requiere que un hilo externo (por ejemplo, un controlador) acceda a información de otros hilos mediante sus identificadores.

Consideraciones sobre la reutilización de IDs

Aunque los identificadores son únicos durante la vida activa de un hilo, los sistemas operativos pueden reutilizarlos una vez que un hilo termina y su recurso ha sido liberado. Esto significa que un std::thread::id antiguo no debe conservarse para identificar un hilo después de que este haya finalizado, ya que podría ser asignado a otro hilo nuevo.

Conclusion

La gestión de argumentos, el control sobre la propiedad de los datos y la organización de varios hilos sirven como base práctica para construir programas concurrentes más claros y manejables. Estos mecanismos ayudan a distribuir el trabajo de forma ordenada, a mantener un seguimiento preciso de cada hilo y a evitar errores típicos relacionados con el tiempo de vida de los datos. A partir de aquí, el siguiente paso será es explorar cómo varios hilos pueden acceder y manipular la misma información sin generar inconsistencias. Ese será el punto de partida de la próxima sección: compartir datos entre hilos.

Hasta ahora he abordado los fundamentos conceptuales de la concurrencia: qué es, cuándo conviene usarla y por qué es un elemento esencial en los sistemas modernos. En esta sección daremos el siguiente paso, centrando nuestra atención en la práctica: la gestión de hilos en C++ y su aplicación a través de ejemplos concretos.

Todo programa en C++ comienza con un único hilo: aquel que ejecuta la función main(). Sin embargo, la verdadera potencia del lenguaje aparece cuando aprendemos a lanzar nuevos hilos que ejecutan tareas de manera independiente y concurrente. El punto de partida es la clase std::thread, introducida en C++11. Esta clase encapsula la creación y control de un hilo de ejecución. En su forma más simple, lanzar un hilo consiste en construir un objeto std::thread y especificar qué función se ejecutará en ese nuevo hilo.

Hello_Concurrent_World CD_01:

#include <iostream>
#include <thread>

void hello() {
    std::cout << "Hello Concurrent World\n";
}

int main() {
    std::thread t(hello);  // Lanza un nuevo hilo
    t.join();              // Espera a que el hilo termine
}

Este pequeño programa crea dos hilos:

• el hilo principal, que inicia en main(),

• y un hilo secundario, que comienza ejecutando la función hello().

El flujo principal continúa inmediatamente después de lanzar el hilo. Si no esperáramos a que el hilo termine, el programa podría finalizar antes de que el mensaje se muestre. Por eso llamamos a join(), que bloquea la ejecución hasta que el hilo finaliza. Aunque el ejemplo parece trivial, marca un cambio profundo: desde este punto, el control de flujo deja de ser lineal. Cada hilo representa un camino de ejecución independiente, y depende de nosotros decidir cómo y cuándo sincronizarlos.

2. Lanzar un hilo

En C++, crear un hilo siempre se reduce a construir un objeto std::thread, pasando como argumento una función o cualquier objeto callable.

Por ejemplo, podríamos usar una función normal:

void do_some_work();
std::thread worker(do_some_work);

o un objeto que sobrecarga el operador ():

class background_task {
public:
    void operator()() const {
        do_something();
        do_something_else();
    }
};

background_task task;
std::thread worker(task);

Cuando se crea el objeto std::thread, su constructor copia la función u objeto callable dentro del contexto del nuevo hilo y comienza su ejecución inmediatamente. Una vez que el hilo inicia, su función de entrada se ejecutará hasta completarse, momento en el cual el hilo finalizará de forma automática.

Riesgos iniciales

Lanzar un hilo puede parecer una operación simple, pero implica un cambio fundamental en la gestión de recursos y en el tiempo de vida de los datos. Si el programa termina o un objeto local se destruye antes de que el hilo haya terminado de usarlo, se entra en terreno de comportamiento indefinido.

En particular, si no esperas a que el hilo finalice (por ejemplo, al no llamar a join(), debes asegurarte de que los datos a los que accede el hilo sigan siendo válidos hasta que este complete su ejecución.

Este problema no es exclusivo del código concurrente: incluso en un solo hilo es incorrecto acceder a un objeto destruido. Sin embargo, con múltiples hilos, la posibilidad de error se amplifica, porque el momento exacto en que el hilo accede a la memoria depende del planificador del sistema operativo.

Considera el siguiente ejemplo:

struct func {
    int& i;
    func(int& i_) : i(i_) {}

    void operator()() {
        for (unsigned j = 0; j < 1000000; ++j) {
            do_something(i);
        }
    }
};

void oops() {
    int some_local_state = 0;
    func my_func(some_local_state);
    std::thread my_thread(my_func);
    my_thread.detach();  // No esperamos a que termine
}

Aquí el hilo creado con my_thread continúa ejecutándose incluso después de que la función oops() haya retornado, el objeto some_local_state deja de existir al salir de la función, pero el hilo aún podría estar ejecutando do_something(i), accediendo a una referencia colgante, esto constituye un acceso a memoria destruida, lo que provoca un comportamiento indefinido: desde fallos silenciosos hasta bloqueos o corrupciones de datos.

La situación es similar a mantener un puntero o referencia a una variable local fuera de su ámbito, pero en programación concurrente el error es más fácil de pasar por alto, porque el hilo podría seguir corriendo en segundo plano sin que sea evidente.

Una manera segura de evitar este tipo de errores es:

• Hacer que la función del hilo sea autosuficiente, copiando los datos que necesita en lugar de referenciarlos.

• Asegurarse de que el hilo haya completado su ejecución antes de que los recursos que usa sean destruidos, normalmente mediante una llamada a join().

3. Estado joinable y ciclo de vida del hilo

Cada objeto std::thread mantiene una asociación con un hilo real del sistema operativo. Mientras esa asociación exista, el hilo se considera joinable, es decir, puede ser esperado o desacoplado.

Cuando se llama a join(), suceden dos cosas:

1. El hilo que hace la llamada se bloquea hasta que el hilo asociado termina.

2. Los recursos del sistema utilizados por el hilo son liberados, y el objeto std::thread deja de estar asociado a ningún hilo.

Después de esa llamada, el hilo ya no es joinable, y cualquier intento posterior de llamar a join() sobre él producirá un error en tiempo de ejecución.

Puedes verificar este estado con el método joinable():

std::thread worker(do_some_work);
if (worker.joinable()) {
    worker.join();
}

Por lo tanto, cada hilo debe terminar de una de dos formas:

• sincronizándose mediante join()

• liberándose mediante detach(), que lo convierte en un hilo en segundo plano (background thread).

Hilos en segundo plano

El método detach() permite que un hilo se ejecute de manera independiente, sin necesidad de que el hilo principal espere su finalización. Al llamarlo, el hilo queda completamente desacoplado del objeto std::thread, pasando a ser gestionado por el sistema operativo.

background_task_CD_02

void background_task() {
    std::cout << "Tarea en segundo plano iniciada\n";
    std::this_thread::sleep_for(std::chrono::seconds(3));
    std::cout << "Tarea en segundo plano finalizada\n";
}

int main() {
    std::thread t(background_task);
    t.detach();  // El hilo continúa ejecutándose de forma independiente
    std::cout << "Hilo principal continúa sin esperar\n";
}

Este enfoque resulta útil cuando la tarea es autónoma —por ejemplo, registrar información, limpiar recursos o realizar un trabajo no crítico— y su finalización no afecta al flujo principal del programa.

Sin embargo, el uso de detach() implica una pérdida total de control sobre el hilo: ya no puede ser sincronizado, y si accede a recursos locales que ya fueron destruidos, el comportamiento será indefinido. Por ello, debe usarse con precaución y únicamente cuando el hilo no dependa de datos cuyo ciclo de vida sea más corto que el suyo.

Esperas más precisas

El método join() ofrece una sincronización binaria: esperas completamente o no esperas en absoluto. Si necesitas comprobar periódicamente si el hilo ha terminado, o limitar el tiempo de espera, deberás recurrir a mecanismos más avanzados como futures, promises o condition variables, que permiten un control más granular sobre la sincronización.

Estos temas se abordarán más adelante, pero por ahora basta con entender que join() es la forma más directa y segura de garantizar que un hilo haya finalizado antes de continuar, mientras que detach() ofrece una ejecución completamente independiente, con la responsabilidad adicional de asegurar que los recursos del hilo sigan siendo válidos durante su ejecución.

4. Esperar en circunstancias de excepciones

Gestionar correctamente los hilos no solo implica saber cuándo sincronizarlos, sino también asegurar que siempre sean liberados, incluso si ocurre una excepción. Recordemos que un objeto std::thread debe terminar su ciclo de vida habiendo sido unido (join()) o desacoplado (detach()).
De lo contrario, al destruirse un objeto std::thread todavía joinable, el programa llamará a std::terminate().

Esto representa un riesgo evidente en contextos donde el flujo puede interrumpirse abruptamente, por ejemplo, debido a una excepción. Si el control abandona una función antes de ejecutar la llamada a join(), el hilo quedará sin gestionar y el programa fallará.

Ejemplo del problema

Supón el siguiente escenario simplificado:

void f() {
    int some_local_state = 0;
    func my_func(some_local_state);
    std::thread t(my_func);

    do_something_in_current_thread();
    t.join();
}

En condiciones normales, este código funciona correctamente: el hilo se une antes de salir de la función.

Pero si do_something_in_current_thread() lanza una excepción, la llamada a join() nunca se ejecutará, y cuando t se destruya, el programa terminará con std::terminate().

Manejo explícito con try/catch

Una solución inmediata consiste en usar un bloque try/catch para garantizar que el hilo se una tanto en la ejecución normal como en la excepcional:

void f() {
    int some_local_state = 0;
    func my_func(some_local_state);
    std::thread t(my_func);

    try {
        do_something_in_current_thread();
    } catch (...) {
        t.join();  // Asegura que el hilo se libere
        throw;     // Repropaga la excepción
    }

    t.join();  // Camino normal
}

Esta estrategia es funcional, pero tiene dos inconvenientes:

• Duplica la llamada a join(), lo que ensucia el código.

• Es propensa a errores si el bloque try no cubre todas las rutas de salida posibles.

Solución RAII clásica: el patrón thread guard

En C++ Concurrency in Action, Anthony Williams propone una solución basada en RAII (Resource Acquisition Is Initialization) mediante una clase llamada thread_guard. Su destructor garantiza que el hilo se una automáticamente al salir del alcance, incluso si se lanza una excepción.

class thread_guard {
    std::thread& t;
public:
    explicit thread_guard(std::thread& t_) : t(t_) {}
    ~thread_guard() {
        if (t.joinable())
            t.join();
    }
    thread_guard(thread_guard const&) = delete;
    thread_guard& operator=(thread_guard const&) = delete;
};

El principio es simple: cuando el objeto thread_guard sale de ámbito —ya sea por una salida normal o por una excepción— su destructor invoca join() si el hilo sigue activo. Este patrón es una aplicación directa del RAII y resulta muy eficaz para C++11 y C++17.

5. std::jthread

En C++20, el estándar introdujo std::jthread, que ya implementa automáticamente la lógica de unión en su destructor, reemplazando la necesidad de un thread_guard manual. Al destruirse un std::jthread, si el hilo sigue ejecutándose, el destructor llama a join() de manera segura, eliminando el riesgo de std::terminate().

Además, std::jthread admite cancelación cooperativa mediante std::stop_token, lo que facilita el diseño de tareas que pueden detenerse desde fuera del hilo.

Ejemplo con std::jthread

#include <iostream>
#include <thread>
#include <chrono>

void do_work() {
    std::cout << "Hilo iniciado\n";
    std::this_thread::sleep_for(std::chrono::seconds(2));
    std::cout << "Hilo finalizado\n";
}

void f() {
    std::jthread t(do_work);  // Se unirá automáticamente al salir del scope
    do_something_in_current_thread();  // Si lanza, no hay problema
}

Si do_something_in_current_thread() lanza una excepción, el hilo t se unirá automáticamente al salir del ámbito de la función, gracias al destructor de std::jthread.
Esto elimina por completo la necesidad de un bloque try o de una clase auxiliar.

Ejemplo con cancelación cooperativa

stop_token_CD_03

#include <iostream>
#include <thread>
#include <chrono>

void task(std::stop_token st) {
    while (!st.stop_requested()) {
        std::cout << "Trabajando...\n";
        std::this_thread::sleep_for(std::chrono::milliseconds(500));
    }
    std::cout << "Cancelado\n";
}

int main() {
    std::jthread t(task);  // hilo con soporte de cancelación
    std::this_thread::sleep_for(std::chrono::seconds(2));
    t.request_stop();      // solicita la detención
}

El hilo se ejecuta mientras no se solicite su detención, y al salir del main(), el destructor de std::jthread realiza el join() automáticamente, garantizando una finalización limpia.

Hasta este punto se he mostrado las bases para lanzar hilos y aplicar una forma sencilla de sincronización en C++. El trabajo con hilos empieza a adquirir estructura: ya no se trata solo de ejecutar tareas, sino de comprender ciclo de vida del hilo y mantener el control sobre cada una de ellos. En la siguiente parte se profundizaré en la gestión de los hilos, el paso de argumentos y el manejo de su propiedad.

Recientemente estuve desarrollando un plugin para Photoshop, implementado de forma completamente secuencial. Sin embargo, el tiempo de ejecución resultaba demasiado lento, y pronto me di cuenta de que la tarea podía dividirse fácilmente en bloques independientes, lo que la convertía en un algoritmo altamente paralelizable.

Me decidí a tomar un curso, ver algunos tutoriales y revisar ejemplos de código. Aunque logré aprender ciertos conceptos, no puedo decir que los comprendi en profundidad. Por eso opté por empezar de nuevo, esta vez con calma, yendo paso a paso desde el principio. Elegí leer el libro C++ Concurrency in Action, que muchos consideran el mejor material para aprender de forma sólida y profunda sobre la programación multihilo en C++.

He leído varios capítulos del libro y he afianzado mucho más mi comprensión del tema. Me ha fascinado el nivel de conocimiento y detalle que requiere desarrollar aplicaciones de calidad que aprovechen el paralelismo y la concurrencia de forma correcta.

Por eso, esta serie de artículos estará dedicada a explorar los temas tratados en el libro, explicando sus ejemplos y acompañándolos con aplicaciones propias que iré desarrollando a lo largo del proceso.

1. ¿Qué es la concurrencia?

En su forma más básica, la concurrencia es la capacidad de realizar múltiples actividades al mismo tiempo. No se trata únicamente de ejecutar instrucciones en paralelo, sino de organizar el trabajo de manera que varias tareas progresen de forma independiente, solapando su ejecución en el tiempo. Este concepto no es exclusivo de la computación: en la vida diaria también actuamos concurrentemente. Podemos caminar y hablar a la vez, escribir con una mano mientras sostenemos un objeto con la otra o realizar distintas tareas en paralelo con personas diferentes.

En programación, la concurrencia busca aprovechar esta idea para aumentar la eficiencia y la capacidad de respuesta de los programas, especialmente en sistemas modernos donde los procesadores disponen de múltiples núcleos. Sin embargo, concurrencia no significa necesariamente paralelismo: un programa concurrente puede manejar varias tareas en progreso, aunque el hardware ejecute solo una a la vez; en cambio, el paralelismo implica que las tareas realmente se ejecutan simultáneamente en distintos núcleos o procesadores.

Enfoques de la concurrencia

Existen dos formas principales de implementar concurrencia en una aplicación:
usando múltiples procesos o usando múltiples hilos dentro de un mismo proceso. Aunque ambos enfoques persiguen el mismo objetivo —permitir que varias tareas avancen de forma independiente—, difieren en la manera en que gestionan los recursos y se comunican.

Concurrencia con múltiples procesos

En este modelo, la aplicación se divide en varios procesos independientes, cada uno con su propio espacio de memoria y su propio flujo de ejecución.
Cada proceso se comporta como una entidad aislada: si uno falla, no afecta directamente a los demás, y la comunicación entre ellos se realiza mediante mecanismos de comunicación entre procesos (IPC), como tuberías (pipes), sockets, archivos compartidos o señales del sistema operativo.

Este enfoque tiene ventajas importantes:

• Mayor aislamiento y seguridad. Los procesos están protegidos entre sí, lo que reduce el riesgo de errores de memoria o corrupción de datos compartidos.

• Mayor estabilidad. Si un proceso se bloquea, los demás pueden continuar funcionando sin problema.

• Escalabilidad. Es posible distribuir los procesos entre distintos equipos conectados por red, aumentando así la capacidad de procesamiento del sistema.

Sin embargo, también presenta desventajas:

• Comunicación más costosa. Los datos deben copiarse entre espacios de memoria separados, lo que añade latencia.

• Mayor sobrecarga del sistema. Crear y gestionar varios procesos consume más recursos del sistema operativo.

• Dificultad de sincronización. Coordinar el trabajo entre procesos puede requerir estructuras de comunicación complejas.

A pesar de estos inconvenientes, muchos lenguajes y sistemas distribuidos (como Erlang) usan este modelo por su fiabilidad y facilidad para construir aplicaciones robustas.

Concurrencia con múltiples hilos

El segundo enfoque —y el más utilizado en C++— es la concurrencia basada en hilos. Aquí, una única aplicación (un solo proceso) puede contener varios hilos de ejecución que comparten el mismo espacio de memoria. Cada hilo se comporta como un flujo independiente, capaz de ejecutar una parte distinta del programa, pero todos tienen acceso directo a las mismas variables y recursos.

Esto hace que la comunicación entre hilos sea mucho más rápida y eficiente, ya que los datos pueden compartirse directamente sin mecanismos externos. Sin embargo, esta facilidad trae consigo nuevos desafíos: si varios hilos acceden a la misma variable al mismo tiempo, pueden producirse condiciones de carrera o inconsistencias en la memoria.

Por ello, el programador debe garantizar manualmente la sincronización del acceso a los datos compartidos mediante mutexes, bloqueos u otros mecanismos de control.

Las principales ventajas de este enfoque son:

• Bajo costo de creación y comunicación. Los hilos son más livianos que los procesos.

• Mayor eficiencia. Permiten aprovechar al máximo los procesadores multinúcleo.

• Integración directa con C++. Desde C++11, la biblioteca estándar incluye soporte nativo para hilos (std::thread) y sincronización.

Pero también tiene desventajas notables:

• Mayor complejidad. Es necesario diseñar cuidadosamente cómo se comparten y modifican los datos.

• Riesgo de errores difíciles de depurar. Problemas como bloqueos mutuos o interferencias entre hilos pueden ser difíciles de reproducir y corregir.

Por estas razones, el modelo multihilo es más rápido pero también más exigente. Requiere disciplina, conocimiento del modelo de memoria y el uso adecuado de las herramientas de sincronización.

En esta serie de artículos me enfocaré principalmente en este segundo enfoque —la concurrencia mediante múltiples hilos—, siguiendo las bases teóricas y prácticas que plantea el libro C++ Concurrency in Action.

2. Concurrencia vs Paralelismo

Aunque los términos concurrencia y paralelismo suelen usarse indistintamente, en el contexto de la programación multihilo existe una distinción conceptual importante entre ambos. Ambos se refieren a la ejecución simultánea de múltiples tareas, pero difieren en su propósito y enfoque.

La concurrencia se centra en la estructura y la organización del software. Su objetivo principal es permitir que diferentes tareas avancen de manera independiente, incluso si no se ejecutan estrictamente al mismo tiempo. Es una herramienta para manejar múltiples actividades que comparten recursos o requieren coordinación, buscando mejorar la responsividad y la separación de responsabilidades dentro de una aplicación.

Por otro lado, el paralelismo es una cuestión de rendimiento. Se trata de aprovechar el hardware disponible —como múltiples núcleos de CPU— para realizar varios cálculos en simultáneo. Su propósito es claro: reducir el tiempo total de ejecución de una tarea o aumentar el volumen de trabajo que puede procesarse en un mismo intervalo de tiempo. En pocas palabras, mientras la concurrencia busca organizar mejor el trabajo, el paralelismo busca hacerlo más rápido.

Esta diferencia de enfoque implica que no toda aplicación concurrente es necesariamente paralela. Una interfaz gráfica que mantiene su fluidez mientras realiza operaciones en segundo plano es concurrente, aunque no necesariamente paralela. En cambio, un programa que divide un conjunto de datos entre varios hilos para procesarlos por separado es claramente un caso de paralelismo.

3. ¿Por qué usar concurrencia?

Existen dos razones fundamentales para utilizar concurrencia en una aplicación: separación de responsabilidades y rendimiento. Ambas son pilares del diseño moderno de software y reflejan diferentes motivaciones detrás del uso de múltiples hilos o procesos.

Separación de responsabilidades

Una de las mejores prácticas en ingeniería de software es dividir el sistema en componentes bien delimitados. La concurrencia permite llevar esta idea un paso más allá: no solo separar el código, sino también permitir que distintas partes de una aplicación se ejecuten de forma independiente.

Imaginemos una aplicación como un reproductor de DVD. Este debe, por un lado, leer los datos del disco, decodificar el video y el audio, y enviarlos al hardware sin interrupciones; y por otro lado, debe responder a las acciones del usuario —como pausar o detener la reproducción— sin retrasos. Si todo se ejecutara en un solo hilo, el programa tendría que alternar manualmente entre tareas, complicando el diseño y reduciendo la fluidez de la interfaz.

La solución natural es utilizar hilos separados: uno para la reproducción y otro para la interfaz de usuario. De este modo, cada componente puede concentrarse en su función principal, y la interacción entre ambos ocurre solo en puntos bien definidos, como al recibir una orden de pausa. Este enfoque mejora la organización interna del código y crea una sensación de responsividad inmediata, incluso cuando el sistema está ocupado realizando tareas intensivas.

Concurrencia para mejorar el rendimiento

Durante décadas, el aumento del rendimiento en software venía “gratis”: los procesadores mejoraban su velocidad con cada nueva generación, y los programas se volvían automáticamente más rápidos. Sin embargo, esta tendencia llegó a su límite físico y térmico. Los fabricantes cambiaron de estrategia: en lugar de aumentar la frecuencia de reloj, comenzaron a incorporar múltiples núcleos en un mismo chip.

El resultado es que ahora la única forma de aprovechar plenamente la capacidad de cómputo de una máquina moderna es mediante la concurrencia. Para que una aplicación se beneficie de un procesador multinúcleo, debe ser capaz de dividir su trabajo en tareas que puedan ejecutarse simultáneamente.

Existen dos enfoques principales para lograrlo:

• Paralelismo de tareas (Task Parallelism): consiste en dividir una tarea compleja en subtareas independientes que pueden ejecutarse al mismo tiempo. Por ejemplo, distintos hilos podrían encargarse de etapas separadas de un algoritmo o de diferentes componentes de un sistema.

• Paralelismo de datos (Data Parallelism): implica aplicar la misma operación sobre diferentes partes de un conjunto de datos. Un ejemplo clásico es el procesamiento de imágenes, donde varios hilos pueden aplicar el mismo filtro sobre diferentes regiones de la imagen.

Los algoritmos que se prestan fácilmente a esta división se denominan embarrassingly parallel, un término que resalta lo sencillo que resulta paralelizarlos. Este tipo de algoritmos escalan muy bien, ya que pueden aprovechar un número creciente de núcleos para reducir proporcionalmente su tiempo de ejecución.

Finalmente, el paralelismo no siempre se usa para reducir el tiempo de procesamiento de una sola tarea: también puede servir para aumentar el volumen de trabajo procesado en paralelo. Por ejemplo, un programa puede procesar varias imágenes o archivos simultáneamente, aumentando así su rendimiento global o throughput.

4. Cuándo no usar concurrencia

Tan importante como saber cuándo aplicar concurrencia es reconocer cuándo no hacerlo. A pesar de sus beneficios, la concurrencia introduce una capa adicional de complejidad que puede volverse contraproducente si el problema no lo justifica.

La razón fundamental para evitar la concurrencia es simple: cuando el beneficio no compensa el costo. Escribir código concurrente suele ser más difícil de entender, probar y mantener. La interacción entre múltiples hilos puede generar errores sutiles, como condiciones de carrera, bloqueos mutuos (deadlocks) o inconsistencias de memoria. Estos problemas no solo consumen tiempo de desarrollo, sino que también aumentan el riesgo de fallos en producción.

Además del costo cognitivo, la concurrencia implica costos de rendimiento. Cada hilo consume recursos del sistema operativo —memoria para su pila, estructuras de control y tiempo de planificación—, por lo que crearlo y sincronizarlo nunca es gratuito. Si la tarea es demasiado breve, ese overhead puede anular cualquier ganancia esperada, e incluso empeorar el rendimiento. A esto se suma que los hilos son un recurso limitado: lanzar demasiados puede saturar el sistema, consumir memoria en exceso o degradar la eficiencia por un exceso de context switching. Cada cambio de contexto implica guardar y restaurar estados del procesador, una operación costosa que se multiplica cuando el número de hilos activos supera la cantidad de núcleos disponibles.

Por estas razones, la concurrencia como estrategia de optimización debe aplicarse con el mismo criterio que cualquier otra técnica de alto rendimiento: solo vale la pena cuando los beneficios son medibles y compensan la complejidad añadida. En muchos casos, optar por un enfoque secuencial o asincrónico ofrece un mejor equilibrio entre claridad, mantenibilidad y eficiencia.

Sin embargo, si el diseño requiere separación de responsabilidades —por ejemplo, para mantener una interfaz fluida mientras se ejecutan tareas de fondo— o si el rendimiento depende directamente del aprovechamiento del hardware disponible, entonces la concurrencia se convierte en una herramienta valiosa y necesaria. La clave está en usarla con criterio y propósito, no por simple moda o entusiasmo técnico.
Una idea que resume bien esta reflexión aparece en la charla “Multithreading is the answer. What is the question?” de Ansel Sermersheim (CppCon 2017), donde se enfatiza que aplicar multithreading sin un propósito claro suele generar más problemas que beneficios. En otras palabras, la concurrencia no debe ser la respuesta automática a todo desafío de rendimiento, sino una decisión técnica fundamentada en la naturaleza del problema.

El redimensionamiento de imágenes consiste en cambiar las dimensiones de una imagen, ya sea para aumentar su tamaño (upscaling) o reducirlo (downscaling), manteniendo la mayor fidelidad posible respecto a la imagen original.Este proceso es ampliamente usado, tanto en la edición de fotos y videos como en aplicaciones de procesamiento de imágenes como reconocimiento facial, visión robótica, y entrenamiento de modelos de inteligencia artificial, donde la coherencia y la calidad de los datos visuales son determinantes.

Aunque la idea parece sencilla —simplemente ampliar o reducir una imagen—, esto supone un desafío técnico: cada píxel agregado o eliminado debe generarse de manera que respete la estructura visual, así como los bordes. De lo contrario, pueden aparecer artefactos como pixelado, borrosidad o aliasing, afectando tanto la percepción visual como el rendimiento de algoritmos posteriores.

Existen múltiples métodos de redimensionamiento, cada uno con sus ventajas y limitaciones, que se diferencian principalmente por la manera en que calculan los nuevos valores de pixel a partir de los existentes. En este artículo exploraremos cuatro técnicas ampliamente utilizadas: Vecino más cercano (Nearest Neighbor), Interpolación bilineal, Interpolación bicúbica y Lanczos, analizando cómo funcionan, sus ventajas, desventajas y resultados prácticos sobre imágenes reales.

1. Conceptos básicos

Antes de profundizar en los métodos de redimensionamiento, es importante entender algunos conceptos fundamentales que determinan cómo y por qué se transforman las imágenes.

1.1 Píxeles y resolución

Una imagen digital está compuesta por píxeles, que son los elementos mínimos de información visual. Cada píxel contiene información de color y, en conjunto, forman la imagen completa. La resolución de una imagen se define por la cantidad de píxeles en sus dimensiones: ancho × alto. Por ejemplo, una imagen de 800×600 píxeles tiene 480,000 píxeles en total.

Cambiar la resolución de una imagen implica recalcular la información de los píxeles para ajustarla a las nuevas dimensiones.

1.2 Upscaling y downscaling

• Upscaling: aumentar el tamaño de la imagen. Esto requiere generar nuevos píxeles a partir de los existentes. El desafío principal es preservar detalles y evitar que la imagen se vea borrosa o pixelada.

• Downscaling: reducir el tamaño de la imagen. Aquí se deben combinar o eliminar píxeles de manera que la información relevante se mantenga y no se pierdan detalles importantes.

Cada operación tiene implicaciones diferentes sobre la calidad de la imagen y sobre el rendimiento de los algoritmos que la procesarán.

1.3. Problemas comunes

Al redimensionar imágenes, es habitual enfrentarse a ciertos artefactos:

• Pixelado: ocurre cuando se usan métodos muy simples, como el vecino más cercano, y los bordes aparecen escalonados.

• Borroso o suavizado excesivo: puede aparecer al usar interpolaciones que promedian demasiado los píxeles cercanos, como bilineal o bicúbica.

• Aliasing: sucede cuando se reduce demasiado la resolución y se pierden detalles finos, generando patrones no deseados en la imagen.

Comprender estos problemas permite elegir el método de redimensionamiento más adecuado según el objetivo, ya sea velocidad, fidelidad visual o preservación de detalles.

2. Vecino más cercano (Nearest Neighbor)

El método de vecino más cercano es la forma más simple de redimensionar imágenes. Su funcionamiento es intuitivo: cada píxel de la nueva imagen toma el valor del píxel más cercano de la imagen original, sin realizar ningún tipo de interpolación. Esto significa que no se generan valores intermedios; simplemente se copia la información existente.

Ventajas:

• Muy rápido y eficiente.

• Fácil de implementar y comprender.

Desventajas:

• Produce bordes escalonados o pixelados, especialmente al aumentar la imagen.

• No preserva detalles finos ni suaviza transiciones de color.

Implementación en Python:

def resize_nearest_neighbor(image, new_width, new_height):
    """
    Redimensiona una imagen usando interpolación Nearest Neighbor (vecino más cercano).

    :param image: imagen de entrada (numpy array)
    :param new_width: ancho deseado
    :param new_height: alto deseado
    :return: imagen redimensionada
    """
    h_in, w_in = image.shape[:2]
    h_out, w_out = new_height, new_width

    # Crear imagen vacía de salida
    if len(image.shape) == 3:  # Imagen en color
        output = np.zeros((h_out, w_out, image.shape[2]), dtype=image.dtype)
    else:  # Imagen en escala de grises
        output = np.zeros((h_out, w_out), dtype=image.dtype)

    # Escalamiento
    for y_out in range(h_out):
        for x_out in range(w_out):
            # Mapeo inverso (salida → entrada)
            x_in = int(round(x_out * w_in / w_out))
            y_in = int(round(y_out * h_in / h_out))

            # Clamping para evitar índices fuera de rango
            x_in = min(w_in - 1, x_in)
            y_in = min(h_in - 1, y_in)

            output[y_out, x_out] = image[y_in, x_in]

    return output

Explicación del algoritmo:

1. Se determina el tamaño de la imagen original (h_in, w_in) y el tamaño deseado (h_out, w_out).

2. Se crea una matriz vacía para la imagen de salida.

3. Para cada píxel de la imagen de salida, se calcula la posición correspondiente en la imagen original mediante un mapeo inverso.

4. Se aplica un clamping para evitar acceder fuera del rango de la imagen original.

5. Se copia el valor del píxel más cercano al nuevo píxel.

2. Interpolación bilineal (Bilinear)

La interpolación bilineal es un método más avanzado que el de vecino más cercano, ya que calcula cada nuevo píxel como una combinación ponderada de los cuatro píxeles más cercanos de la imagen original. En lugar de copiar un único valor, el algoritmo realiza un promedio lineal en ambas direcciones —horizontal y vertical—, lo que produce transiciones más suaves y bordes menos marcados.

En términos geométricos, puede interpretarse como una interpolación primero a lo largo del eje x (entre los píxeles vecinos horizontales) y luego a lo largo del eje y (entre los resultados de esas interpolaciones).

Ventajas:

• Genera resultados más suaves y agradables visualmente.

• Reduce el efecto de pixelado presente en el método de vecino más cercano.

Desventajas:

• Puede producir una ligera pérdida de nitidez.

• Requiere más cálculos, por lo que es más lento.

Implementación en Python

def resize_bilinear(image, new_width, new_height):
    """
    Redimensiona una imagen usando interpolación bilineal.

    :param image: Imagen de entrada (numpy array)
    :param new_width: Ancho de salida
    :param new_height: Alto de salida
    :return: Imagen redimensionada
    """
    h_in, w_in = image.shape[:2]
    h_out, w_out = new_height, new_width

    # Imagen de salida
    if len(image.shape) == 3:
        output = np.zeros((h_out, w_out, image.shape[2]), dtype=np.float32)
    else:
        output = np.zeros((h_out, w_out), dtype=np.float32)

    for y_out in range(h_out):
        for x_out in range(w_out):
            # Mapear coordenada de salida a entrada (espacio continuo)
            x_in = (x_out + 0.5) * (w_in / w_out) - 0.5
            y_in = (y_out + 0.5) * (h_in / h_out) - 0.5

            x1 = int(np.floor(x_in))
            y1 = int(np.floor(y_in))
            x2 = min(x1 + 1, w_in - 1)
            y2 = min(y1 + 1, h_in - 1)

            a = x_in - x1
            b = y_in - y1

            # Píxeles vecinos
            Q11 = image[y1, x1]
            Q21 = image[y1, x2]
            Q12 = image[y2, x1]
            Q22 = image[y2, x2]

            # Interpolación bilineal
            output[y_out, x_out] = (1 - a) * (1 - b) * Q11 + \
                                   a * (1 - b) * Q21 + \
                                   (1 - a) * b * Q12 + \
                                   a * b * Q22

    return np.clip(output, 0, 255).astype(np.uint8)

Explicación paso a paso

1. Mapeo inverso:
   Cada coordenada de la imagen de salida se transforma a una posición continua en la imagen original (x_in, y_in).
   Este mapeo asegura que cada píxel de la salida “corresponda” a una ubicación en la entrada.

2. Selección de píxeles vecinos:
   Se identifican los cuatro píxeles más cercanos a esa posición continua:

   • Q11 = esquina superior izquierda

   • Q21 = esquina superior derecha

   • Q12 = esquina inferior izquierda

   • Q22 = esquina inferior derecha

3. Interpolación en dos direcciones:

   • Primero se interpola horizontalmente entre Q11 y Q21, y entre Q12 y Q22.

   • Luego se interpola verticalmente entre los resultados anteriores.

4. Normalización y clipping:
   Los valores resultantes se limitan al rango [0, 255] para mantener la validez de los niveles de intensidad.

Al comparar la imagen original con la redimensionada mediante interpolación bilineal, se observa una suavidad mayor respecto al método de vecino más cercano. Sin embargo, los bordes pueden perder algo de nitidez, especialmente cuando se amplía la imagen.

Este método es muy usado en aplicaciones donde se busca un equilibrio entre velocidad y calidad visual, como en la visualización de imágenes en tiempo real o el preprocesamiento para modelos de aprendizaje profundo.

3. Interpolación bicúbica (Bicubic)

La interpolación bicúbica es una extensión de la bilineal que utiliza 16 píxeles vecinos (una ventana de 4×4) para estimar el valor de cada nuevo píxel. En lugar de promediar linealmente, este método aplica una función cúbica para calcular los pesos de cada píxel según su distancia a la posición interpolada.

Este enfoque fue propuesto por Robert G. Keys en 1981, y su función de peso es una aproximación suave y continua que logra transiciones más naturales entre los píxeles. El resultado es una imagen más nítida y con mejor preservación de detalles, especialmente al realizar upscaling.

Implementación en Python

def cubic_weight(x, a=-0.5):
    """Función de pesos cúbica (Keys, 1981)"""
    x = abs(x)
    if x < 1:
        return (a + 2) * (x ** 3) - (a + 3) * (x ** 2) + 1
    elif x < 2:
        return a * (x ** 3) - (5 * a) * (x ** 2) + (8 * a) * x - 4 * a
    else:
        return 0

def resize_bicubic(image, new_width, new_height):
    """
    Redimensiona una imagen usando interpolación bicúbica.

    :param image: Imagen de entrada (numpy array)
    :param new_width: Ancho de salida
    :param new_height: Alto de salida
    :return: Imagen redimensionada
    """
    h_in, w_in = image.shape[:2]
    h_out, w_out = new_height, new_width

    # Imagen de salida
    if len(image.shape) == 3:
        output = np.zeros((h_out, w_out, image.shape[2]), dtype=np.float32)
    else:
        output = np.zeros((h_out, w_out), dtype=np.float32)

    scale_x = w_in / w_out
    scale_y = h_in / h_out

    for y_out in range(h_out):
        for x_out in range(w_out):
            # Posición en la imagen original
            x_in = (x_out + 0.5) * scale_x - 0.5
            y_in = (y_out + 0.5) * scale_y - 0.5

            x_base = int(np.floor(x_in))
            y_base = int(np.floor(y_in))

            value = np.zeros(image.shape[2], dtype=np.float32) if len(image.shape) == 3 else 0.0

            # Recorrer vecinos 4x4
            for m in range(-1, 3):
                for n in range(-1, 3):
                    x_idx = min(max(x_base + n, 0), w_in - 1)
                    y_idx = min(max(y_base + m, 0), h_in - 1)

                    wx = cubic_weight(x_in - (x_base + n))
                    wy = cubic_weight(y_in - (y_base + m))
                    w = wx * wy

                    value += image[y_idx, x_idx] * w

            output[y_out, x_out] = value

    return np.clip(output, 0, 255).astype(np.uint8)

Explicación del algoritmo

1. Función de peso cúbica (cubic_weight)
   Define cómo contribuye cada píxel vecino en función de su distancia.

   • El parámetro a controla la forma del kernel (por defecto a = -0.5, conocido como Bicubic de Catmull-Rom).

   • Si x < 1, el peso es mayor (vecinos más cercanos).

   • Si 1 ≤ x < 2, el peso decae suavemente.

   • Si x ≥ 2, el peso es cero (no contribuye).

2. Mapeo inverso y escalado:
   Cada coordenada de salida (x_out, y_out) se mapea a una posición flotante en la imagen original (x_in, y_in), manteniendo las proporciones.

3. Ventana de interpolación 4×4:
   Se toman 16 píxeles vecinos alrededor de la posición mapeada.
   Para cada uno, se calculan los pesos cúbicos wx y wy y su producto w = wx * wy.

4. Suma ponderada:
   Cada píxel vecino contribuye proporcionalmente a su peso.
   El resultado final se limita con np.clip() al rango [0, 255] para asegurar valores válidos de intensidad.

Características y efectos visuales

• Suavidad: las transiciones de color son más naturales que con interpolación bilineal.

• Nitidez: mantiene mejor los bordes y detalles finos, evitando el efecto borroso.

• Costo computacional: más lento, ya que se evalúan 16 píxeles por cada nuevo píxel.

Bilineal (izq.) · Bicúbica (centro)

Este método es ideal cuando se busca una alta calidad visual, por ejemplo, en procesamiento fotográfico o en tareas donde la textura y el detalle son importantes.

4. Interpolación Lanczos

La interpolación Lanczos es una de las técnicas más precisas y sofisticadas para el redimensionamiento de imágenes. Está basada en la función sinc, la cual representa el filtro de reconstrucción ideal en el dominio de la frecuencia. En teoría, este filtro preserva toda la información posible durante el reescalado, evitando aliasing y manteniendo los bordes definidos.

Sin embargo, la función sinc tiene soporte infinito, lo que la hace impráctica para implementaciones reales. Por ello, Lanczos propuso una versión ventaneada de la sinc —es decir, truncada mediante otra sinc— que conserva sus propiedades principales pero con un alcance finito controlado por el parámetro a.

Fundamento teórico

El kernel de Lanczos se define como:

$$L(x) = \begin{cases} sinc(x) \cdot sinc\!\left(\dfrac{x}{a}\right), & |x| < a \\[8pt] 0, & \text{en otro caso} \end{cases}$$

donde a (comúnmente 2 o 3) determina el tamaño del soporte:

• Un valor mayor de a produce resultados más suaves y detallados, pero aumenta el costo computacional.

• Un valor menor reduce el costo, pero puede generar aliasing.

La multiplicación de dos funciones sinc actúa como una ventana suavizadora, que atenúa las oscilaciones de alta frecuencia y evita los artefactos típicos de los métodos más simples.

Implementación en Python

def sinc(x):
    return np.sinc(x)  # np.sinc ya incluye π, usa sin(πx)/(πx)

def lanczos_kernel(a=3, size=1000):
    """Precalcula el kernel de Lanczos en un rango continuo"""
    x = np.linspace(-a+1, a-1, size)
    k = sinc(x) * sinc(x / a)
    k[np.abs(x) >= a] = 0
    return k

def resize_lanczos_fast(image, new_width, new_height, a=3):
    h_in, w_in = image.shape[:2]
    h_out, w_out = new_height, new_width

    scale_x = w_in / w_out
    scale_y = h_in / h_out

    # Precalcular posiciones en la imagen original
    x_coords = (np.arange(w_out) + 0.5) * scale_x - 0.5
    y_coords = (np.arange(h_out) + 0.5) * scale_y - 0.5

    # Precalcular los índices y pesos para X
    x_idx = np.floor(x_coords).astype(int)
    x_weights = np.zeros((w_out, 2*a))
    for i, xc in enumerate(x_coords):
        for n in range(-a+1, a+1):
            idx = min(max(x_idx[i] + n, 0), w_in - 1)
            x_weights[i, n + a - 1] = sinc(xc - (x_idx[i] + n)) * sinc((xc - (x_idx[i] + n)) / a)

    # Normalizar pesos
    x_weights /= np.sum(x_weights, axis=1, keepdims=True)

    # Paso 1: interpolación horizontal
    tmp = np.zeros((h_in, w_out, image.shape[2]), dtype=np.float32)
    for i in range(w_out):
        for n in range(-a+1, a+1):
            idx = np.clip(x_idx[i] + n, 0, w_in-1)
            tmp[:, i] += image[:, idx] * x_weights[i, n + a - 1]

    # Precalcular los índices y pesos para Y
    y_idx = np.floor(y_coords).astype(int)
    y_weights = np.zeros((h_out, 2*a))
    for j, yc in enumerate(y_coords):
        for m in range(-a+1, a+1):
            idy = min(max(y_idx[j] + m, 0), h_in - 1)
            y_weights[j, m + a - 1] = sinc(yc - (y_idx[j] + m)) * sinc((yc - (y_idx[j] + m)) / a)

    # Normalizar pesos
    y_weights /= np.sum(y_weights, axis=1, keepdims=True)

    # Paso 2: interpolación vertical
    output = np.zeros((h_out, w_out, image.shape[2]), dtype=np.float32)
    for j in range(h_out):
        for m in range(-a+1, a+1):
            idy = np.clip(y_idx[j] + m, 0, h_in-1)
            #output[j] += tmp[idy, :, :] * y_weights[j, m + a - 1][:, None]
            output[j] += tmp[idy, :, :] * y_weights[j, m + a - 1]


    return np.clip(output, 0, 255).astype(np.uint8)

Explicación del algoritmo

1. Función sinc y ventana:
   La función np.sinc(x) ya implementa la forma sin(πx)/(πx)..
   El kernel de Lanczos se obtiene multiplicando dos sinc: una principal y otra escalada por a.

2. Separabilidad:
   La interpolación Lanczos es separable, por lo que se puede aplicar primero en la dirección x y luego en y.
   Esto reduce drásticamente el costo computacional de una versión completamente 2D.

3. Pesos precalculados:
   Para optimizar el cálculo, los pesos de interpolación se precalculan tanto para las coordenadas horizontales como verticales, normalizándose después para conservar energía (sumen 1).

4. Interpolación en dos pasos:

   • Paso horizontal: se genera una imagen temporal tmp interpolando a lo largo de las columnas.

   • Paso vertical: se interpola tmp a lo largo de las filas para obtener la imagen final.

Características visuales y rendimiento

• Calidad sobresaliente: preserva detalles, bordes y textura con mínima pérdida visual.

• Sin aliasing: evita artefactos comunes en reducciones de tamaño.

• Costo computacional alto: debido a los cálculos del kernel sinc, aunque puede optimizarse mediante tablas precalculadas o procesamiento vectorizado.

El parámetro a actúa como control de calidad y rendimiento:

• a = 2: resultado más rápido, menos preciso.

• a = 3: equilibrio ideal entre detalle y costo (valor usado en esta implementación).

• a > 3: mejora marginal de calidad, pero con un aumento notable en el tiempo de cálculo.

En una comparación lado a lado con los métodos anteriores (Bilinear y Bicubic), la interpolación Lanczos muestra:

• Bordes más definidos sin escalones visibles.

• Preservación de texturas finas.

• Menor suavizado artificial en áreas con patrones repetitivos.

Bilineal (izq.) · Bicúbica (centro) · Lanczos (der.)

Por ello, este método suele ser la elección preferida en aplicaciones de procesamiento fotográfico profesional, restauración de imágenes o redimensionamiento de dataset de alta calidad.

5. Limitaciones de la interpolación y el camino hacia la superresolución

Las técnicas de interpolación tradicionales —como el vecino más cercano, bilineal, bicúbica o Lanczos— parten de un supuesto fundamental:

La imagen original contiene suficiente información para estimar razonablemente los valores intermedios.

En otras palabras, estos métodos no crean información nueva, solo estiman valores faltantes a partir de los píxeles existentes.

Pérdida de información al escalar

Cuando una imagen se amplía significativamente (por ejemplo, 4× o más), el proceso de interpolación comienza a evidenciar sus límites:

• Difuminado generalizado: los bordes pierden nitidez progresivamente.

• Pérdida de texturas finas: patrones como cabello, pasto o piel se suavizan hasta volverse irreconocibles.

• Artefactos de interpolación: algunos métodos producen halos, aliasing o patrones ondulados (especialmente en bicúbica o Lanczos).

Esto ocurre porque el algoritmo no puede inferir frecuencias espaciales que no existen en la imagen original: una textura de alta frecuencia se pierde si no está codificada en los píxeles.

Por tanto, el límite fundamental de la interpolación clásica está dado por el teorema de muestreo de Nyquist: no se pueden reconstruir detalles más finos que la mitad de la frecuencia máxima presente en los datos originales.

6. De la interpolación al aprendizaje profundo

Ante estas limitaciones surgieron las técnicas de superresolución (SR), cuyo objetivo es reconstruir detalles plausibles en imágenes de baja resolución.
A diferencia de la interpolación, que se basa en operaciones matemáticas locales, la superresolución utiliza redes neuronales profundas para aprender cómo debería lucir una imagen de alta resolución.

Modelos como SRCNN, EDSR o ESRGAN han demostrado que las redes pueden generar resultados con bordes definidos y texturas más naturales, al aprovechar el conocimiento aprendido de millones de imágenes.

En lugar de estimar píxeles faltantes mediante promedios, estas redes reconstruyen patrones visuales: detalles en cabello, piel, texto o superficies que las técnicas clásicas simplemente no pueden recuperar.
En artículos posteriores planeo abordar estas técnicas de superresolución con mayor profundidad, ya que, con la actual explosión de la IA generativa, han surgido numerosos modelos y arquitecturas especialmente interesantes que merecen análisis detallado.

Introducido por Jim Blinn en 1978, el texture mapping es una técnica esencial del pipeline gráfico que permite aplicar imágenes 2D (texturas) sobre mallas tridimensionales mediante coordenadas UV. En APIs gráficas como OpenGL, estas coordenadas son utilizadas por la GPU para muestrear la textura en el fragment shader, haciendo posible representar materiales complejos —como madera, ladrillo o metal— sin incrementar el número de polígonos.

Más allá de la simple asignación de una imagen, el texturizado moderno incorpora técnicas clave como el mipmapping, los filtros de textura (bilineal, trilineal y anisotrópico), los modos de wrapping y tiling, y la corrección de distorsión por perspectiva, todas orientadas a mejorar la calidad visual, la estabilidad de la imagen y la eficiencia del renderizado.

Este artículo presenta una introducción práctica al texture mapping en OpenGL, abordando tanto sus fundamentos como las extensiones más importantes que permiten obtener un texturizado robusto, eficiente y visualmente coherente en aplicaciones gráficas modernas.

El texture mapping actúa como un puente entre el mundo bidimensional de las imágenes y el tridimensional de los modelos, aportando realismo y eficiencia al proceso de renderizado.

Las principales ventajas de esta técnica son:

• Mayor realismo visual: las texturas aportan color, detalle y variaciones naturales en la superficie.

• Mejor rendimiento: se reduce la complejidad geométrica del modelo, lo que permite procesar escenas más grandes en menos tiempo.

• Versatilidad: posibilita combinar distintos tipos de mapas (de color, normales, especular, entre otros) para simular materiales complejos.

Soporte en hardware: Texture Units

Las GPU modernas incluyen unidades especializadas llamadas Texture Units, diseñadas para almacenar y procesar texturas directamente en el hardware.
Gracias a ellas, un mismo objeto puede usar varios mapas —como color base (diffuse), normales (normal map) o brillo (specular map)— sin afectar el rendimiento.

En OpenGL, estas unidades se controlan mediante funciones como:

glActiveTexture(GL_TEXTURE0);
glBindTexture(GL_TEXTURE_2D, brickTexture);

Aquí se activa la unidad de textura 0 y se vincula la textura correspondiente.
En el fragment shader, esta textura se accede a través de un sampler, que actúa como un enlace entre la unidad y el shader:

layout(binding = 0) uniform sampler2D samp;
vec4 color = texture(samp, texCoords);

De esta forma, cada fragmento obtiene su color desde la textura asociada, lo que permite representar materiales complejos con geometría mínima. El texture mapping es, por tanto, una de las bases del realismo visual en OpenGL: combina eficiencia de renderizado con un alto nivel de detalle.

Componentes del Texture Mapping

Aplicar texturas correctamente en OpenGL requiere comprender cómo interactúan tres elementos clave: el objeto de textura, las coordenadas de textura y las unidades de textura.

Texture Object

Un texture object almacena toda la información de una textura: imagen, formato, filtros, envoltura y niveles de mipmap.

Se crea y vincula con:

GLuint texID; glGenTextures(1, &texID);
glBindTexture(GL_TEXTURE_2D, texID);

Una vez vinculado, cualquier configuración o carga de datos afectará a ese objeto.

Coordenadas de textura (UV)

Cada vértice del modelo tiene asociadas coordenadas de textura (s, t) que indican qué parte de la imagen se aplica sobre él. Estas se almacenan en un VBO y se asocian al shader mediante atributos de vértice:

glGenBuffers(1, &texCoordBuffer);
glBindBuffer(GL_ARRAY_BUFFER, texCoordBuffer); glBufferData(GL_ARRAY_BUFFER, sizeof(texCoords), texCoords, GL_STATIC_DRAW);  glEnableVertexAttribArray(1); glVertexAttribPointer(1, 2, GL_FLOAT, GL_FALSE, 0, 0);

En el shader correspondiente:

layout(location = 1) in vec2 texCoord;

Texture Units

Las texture units son espacios de memoria dedicados dentro de la GPU que permiten usar múltiples texturas simultáneamente. Cada sampler en el shader se vincula a una de estas unidades mediante su binding.

Por ejemplo:

glActiveTexture(GL_TEXTURE0);
glBindTexture(GL_TEXTURE_2D, textureID);

OpenGL garantiza al menos 16 unidades por defecto, aunque la mayoría de las GPU actuales soportan muchas más, lo que permite combinar texturas de color, normales, o reflexión en un mismo objeto.

En conjunto, estos componentes —el objeto de textura, las coordenadas UV y las unidades de textura— forman el núcleo del texture mapping.

Comprender su interacción es esencial para aprovechar el potencial del pipeline gráfico antes de pasar a la etapa práctica, donde las texturas se cargan desde archivos mediante librerías como SOIL2 y se aplican directamente a los modelos 3D.

Carga de texturas con SOIL2

Una vez configurados los elementos básicos del texture mapping, el siguiente paso es cargar imágenes desde archivos para convertirlas en texturas utilizables por OpenGL. Aunque es posible hacerlo manualmente con las funciones nativas, resulta más práctico y eficiente emplear una librería como SOIL2 (Simple OpenGL Image Library 2). SOIL2 se encarga de leer los archivos de imagen, decodificarlos y transferirlos directamente a la memoria de la GPU en formato de textura.

Integración de SOIL2

Para usar SOIL2 basta con incluir su encabezado y enlazar la librería:

#include <SOIL2/SOIL2.h>

Una vez integrada, se puede cargar cualquier formato de imagen compatible (.jpg, .png, .bmp, .tiff, .gif, etc.) con la función SOIL_load_OGL_texture(), que realiza todo el proceso de forma automática.

Función Utils::loadTexture()

La siguiente función implementa la carga de texturas mediante SOIL2 dentro de una clase de utilidades (Utils.cpp). Encapsula la lectura del archivo, la generación de mipmaps y la configuración del filtrado anisotrópico:

// Carga de textura con SOIL2 y configuración avanzada
GLuint Utils::loadTexture(const char *texImagePath)
{
    GLuint textureRef = SOIL_load_OGL_texture(
        texImagePath,            // Ruta del archivo
        SOIL_LOAD_AUTO,          // Detecta formato automáticamente
        SOIL_CREATE_NEW_ID,      // Crea un nuevo ID de textura
        SOIL_FLAG_INVERT_Y       // Invierte el eje Y (compatibilidad con OpenGL)
    );

    // Verificación de errores
    if (textureRef == 0)
        std::cout << "No se encontró el archivo de textura: " << texImagePath << std::endl;

    // --- Configuración de mipmaps y filtrado ---
    glBindTexture(GL_TEXTURE_2D, textureRef);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR);
    glGenerateMipmap(GL_TEXTURE_2D);

    // Filtrado anisotrópico (si está disponible)
    if (isExtensionSupported("GL_EXT_texture_filter_anisotropic")) {
        GLfloat maxAniso = 0.0f;
        glGetFloatv(GL_MAX_TEXTURE_MAX_ANISOTROPY, &maxAniso);
        glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAX_ANISOTROPY, maxAniso);
    } else {
        std::cout << "Filtrado anisotrópico no soportado" << std::endl;
    }

    return textureRef;
}

Desglose del proceso

1. Carga de la imagen:
   SOIL_load_OGL_texture() abre el archivo, decodifica la imagen y genera automáticamente una textura 2D en la GPU. El uso de SOIL_FLAG_INVERT_Y es necesario porque muchas imágenes tienen el origen en la esquina superior izquierda, mientras que OpenGL lo maneja desde la inferior izquierda.

2. Verificación de errores:
   Si la carga falla, la función devuelve 0 y se muestra un mensaje en consola.

3. Generación de mipmaps:
   Los mipmaps son versiones reducidas de la textura que OpenGL selecciona según la distancia del objeto a la cámara, mejorando el rendimiento y la calidad visual.

4. Filtrado anisotrópico:
   Aumenta la nitidez de las texturas vistas en ángulos oblicuos. Si la extensión GL_EXT_texture_filter_anisotropic está disponible, se aplica el máximo nivel permitido por la GPU.

Con esta función, cargar una textura se reduce a una sola línea:

GLuint brickTexture = Utils::loadTexture("brick1.jpg");

En una sola llamada, se realiza todo el proceso: lectura del archivo, creación de la textura, generación de mipmaps y configuración del filtrado. Este enfoque mantiene el código modular, limpio y reutilizable, facilitando la gestión de texturas en cualquier proyecto OpenGL.

Ejemplo

El siguiente programa muestra el flujo esencial del texture mapping: carga, asociación y muestreo de una textura sobre un modelo 3D.
Utiliza SOIL para cargar la imagen y OpenGL 4.3 para gestionar los buffers y shaders.

Los buffers (VAO y VBO) almacenan la información necesaria para el renderizado: los vértices del cubo y sus coordenadas de textura, que van de (0.0, 0.0) a (1.0, 1.0). Estas coordenadas indican qué parte de la imagen corresponde a cada vértice, definiendo cómo se “mapea” la textura sobre la superficie del modelo.

Los shaders procesan esa información directamente en la GPU:

• El vertex shader transforma los vértices del modelo al espacio de proyección y pasa las coordenadas UV al siguiente paso.

• El fragment shader usa esas coordenadas para muestrear la textura mediante la función texture(), determinando el color final de cada fragmento.

De este modo, se aplica una imagen a un cubo con gran realismo visual y un costo computacional mínimo.

Resultado

Mipmapping

Cuando una textura se visualiza a distintas distancias de la cámara, su resolución efectiva cambia. Si siempre se utilizara la textura original, OpenGL tendría que muestrear muchos texels que finalmente terminan contribuyendo a un solo fragmento, lo que produce aliasing, parpadeos y pérdida de estabilidad visual.

El mipmapping soluciona este problema generando una pirámide de versiones reducidas de la textura. Cada nivel mipmap es una imagen con la mitad de resolución del nivel anterior, hasta llegar a una textura de 1×1 texel. Durante el renderizado, la GPU selecciona automáticamente el nivel más adecuado según el tamaño del fragmento en pantalla.

En OpenGL, los mipmaps pueden generarse de forma automática:

glBindTexture(GL_TEXTURE_2D, textureID);
glGenerateMipmap(GL_TEXTURE_2D);

Para que OpenGL los utilice, es necesario configurar el filtro de minimización:

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR);

Este modo combina interpolación lineal dentro de cada mipmap y entre niveles consecutivos, logrando transiciones suaves entre resoluciones.

Las ventajas del mipmapping son claras:

• Reduce el aliasing y el shimmering en objetos lejanos.

• Mejora el rendimiento, ya que se accede a texturas más pequeñas.

• Aumenta la estabilidad visual en escenas con movimiento.

Por estas razones, el uso de mipmaps no es opcional en motores gráficos modernos: es una práctica estándar.

Filtrado anisotrópico

El mipmapping mejora la calidad a distancia, pero no resuelve un problema frecuente: las texturas vistas en ángulos oblicuos. En estos casos, una superficie puede cubrir muchos texels en una dirección y muy pocos en otra. Los filtros bilineales o trilineales asumen una huella cuadrada del fragmento, lo cual no refleja la realidad geométrica.

El filtrado anisotrópico corrige este efecto adaptando el muestreo de la textura a una huella elíptica, alineada con la proyección del fragmento sobre la superficie. El resultado es una textura mucho más nítida cuando se observa en perspectiva rasante, como suelos, carreteras o paredes largas.

En OpenGL, este filtrado depende de la extensión:

GL_EXT_texture_filter_anisotropic

Si está disponible, se puede configurar de la siguiente manera:

GLfloat maxAniso;
glGetFloatv(GL_MAX_TEXTURE_MAX_ANISOTROPY, &maxAniso);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAX_ANISOTROPY, maxAniso);

El valor indica cuántas muestras adicionales puede tomar la GPU en la dirección dominante. Cuanto mayor sea, mejor será la calidad, aunque con un ligero costo adicional.

En la práctica, el filtrado anisotrópico ofrece una de las mejores mejoras visuales por costo computacional, por lo que suele activarse siempre que el hardware lo permita.

Wrapping y Tiling de texturas

Las coordenadas de textura normalmente se definen en el rango [0, 1]. Sin embargo, es común que estas coordenadas excedan ese intervalo, ya sea intencionalmente (para repetir una textura) o por la forma en que se modela la geometría.

El wrapping define cómo OpenGL maneja las coordenadas fuera del rango válido. Los modos más comunes son:

• GL_REPEAT: la textura se repite indefinidamente.

• GL_MIRRORED_REPEAT: se repite invirtiéndose en cada ciclo.

• GL_CLAMP_TO_EDGE: se extiende el borde de la textura.

• GL_CLAMP_TO_BORDER: se usa un color constante en los bordes.

Ejemplo de configuración:

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);

El tiling es una consecuencia directa del wrapping. Si las coordenadas UV se escalan más allá de [0,1], la textura se repite múltiples veces sobre la superficie:

vec2 tiledUV = texCoord * 4.0;
vec4 color = texture(samp, tiledUV);

Esta técnica es especialmente útil para suelos, paredes o terrenos, donde una textura pequeña puede cubrir grandes áreas sin aumentar el uso de memoria.

El control adecuado del wrapping y el tiling es esencial para evitar costuras visibles y patrones repetitivos poco realistas.

Corrección de distorsión por perspectiva

Un error conceptual común es asumir que la interpolación de coordenadas UV es siempre correcta. En realidad, si la interpolación se realiza de forma lineal en espacio de pantalla, se produce una distorsión por perspectiva, visible como estiramientos o deslizamientos incorrectos de la textura en superficies inclinadas.

La solución es la perspective-correct interpolation, que tiene en cuenta el valor w del espacio homogéneo al interpolar las coordenadas. Afortunadamente, en OpenGL moderno esta corrección se realiza automáticamente cuando se usan shaders estándar y un pipeline correcto.

Internamente, la GPU interpola las coordenadas como:

$$\frac{u}{w}, \frac{v}{w}$$

y luego reconstruye el valor correcto por fragmento. Esto garantiza que la textura se proyecte correctamente en superficies tridimensionales.

Solo en casos especiales —como el uso de interpoladores personalizados o técnicas de rasterización manual— es posible desactivar esta corrección, pero hacerlo casi siempre conduce a errores visuales evidentes.

Por tanto, la corrección de perspectiva no es una opción avanzada, sino un requisito fundamental para un texturizado físicamente coherente.

Conclusión

El texture mapping constituye uno de los pilares fundamentales del renderizado moderno en OpenGL. A través de la asignación de coordenadas UV y el muestreo de imágenes en el fragment shader, es posible representar superficies visualmente ricas sin incrementar la complejidad geométrica de los modelos, logrando una combinación óptima entre realismo y rendimiento.

Sin embargo, la calidad final del texturizado no depende únicamente de aplicar una imagen sobre una malla. Técnicas complementarias como el mipmapping permiten adaptar la resolución de la textura a la distancia de la cámara, reduciendo aliasing y mejorando la estabilidad visual. El filtrado anisotrópico refina este proceso al preservar el detalle en superficies observadas en ángulos oblicuos, uno de los casos más críticos en escenas tridimensionales.

Por otro lado, el control del wrapping y tiling ofrece flexibilidad para reutilizar texturas y cubrir grandes superficies de forma eficiente, mientras que la corrección de distorsión por perspectiva, aplicada automáticamente en el pipeline moderno, garantiza que la interpolación de las coordenadas UV sea geométricamente coherente con la proyección 3D.

En OpenGL, la aplicación no dibuja los píxeles directamente. Lo que hacemos es enviar datos al pipeline —posiciones de vértices, colores, texturas, transformaciones— y la GPU se encarga de procesarlos paso a paso hasta producir la imagen final en el framebuffer.

A grandes rasgos, el pipeline de OpenGL pasa por estas etapas:

• Aplicación (CPU): desde C++ (u otro lenguaje) definimos la geometría, configuramos buffers y cargamos los shaders.

• Vertex Shader: transforma cada vértice aplicando las matrices de modelo, vista y proyección.

• Ensamblaje de primitivas: los vértices se agrupan en puntos, líneas o triángulos.

• Rasterización: esas primitivas se convierten en fragmentos (los candidatos a ser píxeles), interpolando atributos como color o coordenadas de textura.

• Fragment Shader: decide el color de cada fragmento, aplicando iluminación o texturas.

• Pruebas y mezcla: antes de dibujar el píxel final, se aplican pruebas (profundidad, stencil) y se combinan colores con el fondo si es necesario.

En las siguientes secciones veremos cómo todo esto se traduce en la práctica con OpenGL: cómo enviamos datos a la GPU, cómo se guardan en buffers y cómo los shaders los usan para construir una escena 3D.

2. Mecanismos de Envío de Datos: Buffers vs. Uniforms

Para que el pipeline de OpenGL funcione, necesitamos pasarle datos desde nuestra aplicación en C++. Estos datos suelen dividirse en dos tipos:

1. Datos que varían por vértice o por fragmento (por ejemplo, la posición de un vértice o su color).

2. Datos que permanecen constantes para todos los vértices o fragmentos de una misma invocación de renderizado (por ejemplo, una matriz de transformación o la posición de la cámara).

OpenGL ofrece dos mecanismos distintos para enviar esta información a los shaders: buffers y uniforms.

2.1 Buffers y Vertex Attributes

Los Vertex Buffer Objects (VBOs) permiten guardar en la memoria de la GPU grandes cantidades de datos, como posiciones de vértices, normales, colores o coordenadas de textura. Estos datos se asocian a atributos de vértice en el vertex shader, lo que significa que cada vértice recibe sus propios valores.

Ejemplo conceptual en GLSL:

layout(location = 0) in vec3 position; // posición de cada vértice
layout(location = 1) in vec3 color;    // color de cada vértice

Cada llamada a glDrawArrays() o glDrawElements() hará que OpenGL recorra el buffer, entregando a la GPU un conjunto distinto de atributos para cada vértice.

2.2 Variables Uniformes

Las uniforms funcionan de manera diferente: son variables globales dentro de un shader y su valor se mantiene constante durante todo un draw call.
A diferencia de los atributos de vértice, no cambian de uno a otro.

Ejemplo en GLSL:

uniform mat4 mv_matrix;   // matriz de modelo-vista
uniform mat4 proj_matrix; // matriz de proyección

Estas variables se cargan desde la aplicación mediante funciones como glGetUniformLocation() y glUniformMatrix4fv(). Un caso típico de uso es enviar las matrices de transformación que se aplican a todos los vértices de un objeto en una misma pasada de renderizado.

3. Buffers y Vertex Attributes (VBOs y VAOs)

En OpenGL, los datos geométricos no se envían uno por uno desde la CPU. En vez de eso, se cargan en la memoria de la GPU mediante estructuras llamadas buffers. Más adelante, estos buffers se organizan y se enlazan a los atributos de los shaders usando los Vertex Array Objects (VAOs).

3.1 Vertex Buffer Object (VBO)

Un Vertex Buffer Object (VBO) es un bloque de memoria en la GPU que contiene datos de vértices. Por ejemplo, un cubo puede representarse como 36 vértices (12 triángulos, 3 vértices cada uno). Estos datos se cargan una única vez y luego la GPU puede acceder a ellos directamente durante el renderizado.

Un ejemplo típico de creación de un VBO es:

glGenBuffers(numVBOs, vbo);  
glBindBuffer(GL_ARRAY_BUFFER, vbo[0]);  
glBufferData(GL_ARRAY_BUFFER, sizeof(vertexPositions), vertexPositions, GL_STATIC_DRAW);

• glGenBuffers: crea un identificador de buffer.

• glBindBuffer: lo activa para operar sobre él.

• glBufferData: copia los datos desde la RAM del CPU hasta la memoria de la GPU.

3.2 Vertex Array Object (VAO)

El Vertex Array Object (VAO) es un contenedor que guarda la configuración de cómo se deben interpretar los datos del VBO. Esto incluye:

• Qué atributos de vértice existen (posición, color, normales, etc.).

• Cómo se distribuyen en memoria (stride, offset).

• Qué buffer está asociado a cada atributo.

Ejemplo de creación:

glGenVertexArrays(1, vao);  
glBindVertexArray(vao[0]);

De esta forma, cada vez que se hace glBindVertexArray(vao[0]), toda la configuración de atributos y buffers queda lista sin tener que repetirla.

3.3 Atributos de Vértice

Una vez que los datos están cargados en el VBO, hay que indicarle a OpenGL cómo debe entregarlos al vertex shader. Esto se hace con glVertexAttribPointer y glEnableVertexAttribArray.

Ejemplo

glBindBuffer(GL_ARRAY_BUFFER, vbo[0]);  
glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 0, 0);  
glEnableVertexAttribArray(0);

• glVertexAttribPointer(0, 3, GL_FLOAT, ...): indica que el atributo en la location 0 del shader corresponde a grupos de 3 floats consecutivos en el buffer (x, y, z).

• glEnableVertexAttribArray(0): habilita el atributo de posición para que pueda usarse en el shader.

En el shader se vería así:

layout(location = 0) in vec3 position;

De esta forma, cada vértice del cubo se enviará automáticamente al shader en la variable position.

3.4 Flujo de Inicialización vs. Renderizado

Es importante distinguir entre:

• Etapa de inicialización (init())

  • Crear los buffers (VBOs).

  • Cargar los datos en ellos.

  • Configurar los VAOs y atributos.

• Etapa de renderizado por frame (display())

  • Limpiar los buffers de color y profundidad.

  • Activar el shader program.

  • Actualizar uniforms (por ejemplo, las matrices de transformación).

  • Llamar a glDrawArrays() o glDrawElements().

glDrawArrays(GL_TRIANGLES, 0, 36);

• Los VBOs guardan los datos en la GPU.

• Los VAOs almacenan la configuración de cómo leer esos datos.

• Los vertex attributes conectan directamente esos datos con el shader.

Entender esta relación es fundamental para trabajar con geometría en OpenGL, porque sobre esta base se añaden más atributos (colores, normales, coordenadas de textura) en escenas más complejas.

4. Variables Uniformes

En OpenGL no todo tiene que cambiar vértice a vértice. Muchas veces necesitamos parámetros que se mantengan constantes durante toda una llamada de dibujo. Para eso existen las variables uniformes (uniforms), que son la forma estándar de enviar datos globales desde la aplicación en C++ a los shaders.

4.1 Cómo se declaran los uniforms en los shaders

Un uniform se declara en GLSL dentro del shader. A diferencia de los atributos (in), un uniform no cambia de un vértice a otro: su valor es el mismo para todos los vértices y fragmentos durante un draw call.

Ejemplo en un vertex shader:

#version 430 core
layout(location = 0) in vec3 position;

uniform mat4 mv_matrix;   // Modelo-Vista
uniform mat4 proj_matrix; // Proyección

void main(void) {
    gl_Position = proj_matrix * mv_matrix * vec4(position, 1.0);
}

Aquí mv_matrix combina las transformaciones de modelo y vista, mientras que proj_matrix define la proyección (perspectiva u ortográfica).
Ambas matrices se aplican igual a todos los vértices en el mismo dibujo.

4.2 Cómo se cargan los uniforms desde C++

Una vez compilado y enlazado el programa de shaders, podemos localizar y actualizar los uniforms desde C++. Esto ocurre en dos pasos:

1. Obtener la ubicación del uniform en el programa:

mvLoc = glGetUniformLocation(renderingProgram, "mv_matrix");
projLoc = glGetUniformLocation(renderingProgram, "proj_matrix");

Nota: el programa (renderingProgram) debe estar enlazado antes de llamar a glGetUniformLocation.

2. Enviar los datos al uniform con funciones glUniform*:

glUniformMatrix4fv(mvLoc, 1, GL_FALSE, glm::value_ptr(mvMat)); glUniformMatrix4fv(projLoc, 1, GL_FALSE, glm::value_ptr(pMat));

• glUniformMatrix4fv: actualiza un uniform de tipo mat4.

• El 1 indica que se pasa una sola matriz.

• GL_FALSE señala que no deben transponerse los datos.

• glm::value_ptr(...) obtiene un puntero compatible con OpenGL.

En la función display(), justo antes de dibujar, se realiza este proceso.

4.3 Uso típico de Uniforms

Algunos de los usos más comunes de uniforms son:

• Matrices de transformación: modelo, vista, proyección.

• Parámetros de cámara: posición, dirección, matrices de vista.

• Propiedades de materiales: color base, reflectividad, coeficientes de iluminación.

• Luces: posición, color, intensidad.

• Texturas: identificadores de samplers (aunque las texturas en sí se gestionan con otra API, se referencian mediante uniforms).

4.4 Diferencia con los Atributos

• Atributos (in) → Se actualizan por vértice y pueden ser interpolados por el rasterizador.

• Uniforms → Se mantienen constantes para todos los vértices/fragmentos durante un draw call.

Ejemplo práctico:

• Un atributo puede ser el color distinto en cada vértice del cubo.

• Un uniform puede ser la matriz de proyección que se aplica por igual a todos los vértices del cubo.

En pocas palabras: los uniforms son la forma de pasar información global al shader. Permiten aplicar transformaciones, parámetros de cámara o iluminación de manera coherente a toda la geometría, sin necesidad de duplicar datos en cada vértice.

5. Ejemplo

Dibujar un cubo coloreado en OpenGL

Ya que hemos repasado los conceptos de buffers, shaders y uniforms, veamos cómo se usan en un programa real. El siguiente ejemplo dibuja un cubo 3D coloreado paso a paso, poniendo en práctica todo lo explicado sobre el pipeline de OpenGL.

5.1 Preparar los datos del cubo

Lo primero es definir los vértices que forman las caras del cubo y asignarles un color. Cada cara está compuesta por dos triángulos (6 vértices), y en total el cubo necesita 36 vértices.

// Posiciones de los vértices (36 vértices = 12 triángulos)
float cubeVertexPositions[108] = {
    // cara frontal
    -1.0f, -1.0f,  1.0f,
     1.0f, -1.0f,  1.0f,
     1.0f,  1.0f,  1.0f,
    -1.0f, -1.0f,  1.0f,
     1.0f,  1.0f,  1.0f,
    -1.0f,  1.0f,  1.0f,
    // ... resto de las caras (izquierda, derecha, trasera, etc.)
};

// Colores asociados a cada vértice
float cubeVertexColors[108] = {
    // frontal (rojo)
    1.0f, 0.0f, 0.0f,
    1.0f, 0.5f, 0.5f,
    1.0f, 0.0f, 0.0f,
    // ... resto de colores
};

5.2 Crear VAO y VBOs

Un VAO almacena la configuración de atributos, y dos VBOs guardan posiciones y colores.

GLuint vao[1];
GLuint vbo[2];

// Generar y enlazar VAO
glGenVertexArrays(1, vao);
glBindVertexArray(vao[0]);

// VBO de posiciones
glGenBuffers(2, vbo);
glBindBuffer(GL_ARRAY_BUFFER, vbo[0]);
glBufferData(GL_ARRAY_BUFFER, sizeof(cubeVertexPositions), cubeVertexPositions, GL_STATIC_DRAW);
glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 0, 0);
glEnableVertexAttribArray(0);

// VBO de colores
glBindBuffer(GL_ARRAY_BUFFER, vbo[1]);
glBufferData(GL_ARRAY_BUFFER, sizeof(cubeVertexColors), cubeVertexColors, GL_STATIC_DRAW);
glVertexAttribPointer(1, 3, GL_FLOAT, GL_FALSE, 0, 0);
glEnableVertexAttribArray(1);

5.3 Shaders: Vertex y Fragment

El vertex shader transforma posiciones con las matrices de modelo-vista y proyección, y pasa el color al fragment shader.

#version 430 core
layout(location = 0) in vec3 position;
layout(location = 1) in vec3 color;

out vec4 varyingColor;

uniform mat4 mv_matrix;
uniform mat4 proj_matrix;

void main(void) {
    gl_Position = proj_matrix * mv_matrix * vec4(position, 1.0);
    varyingColor = vec4(color, 1.0);
}

El fragment shader recibe el color interpolado y lo envía al framebuffer:

#version 430 core
in vec4 varyingColor;
out vec4 fragColor;

void main(void) {
    fragColor = varyingColor;
}

5.4 Uso de uniforms

Desde C++ cargamos las matrices de transformación en los uniforms:

mvLoc   = glGetUniformLocation(renderingProgram, "mv_matrix");
projLoc = glGetUniformLocation(renderingProgram, "proj_matrix");

glUniformMatrix4fv(mvLoc, 1, GL_FALSE, glm::value_ptr(mvMat));
glUniformMatrix4fv(projLoc, 1, GL_FALSE, glm::value_ptr(pMat));

5.5 Dibujar el cubo

En la función de renderizado, limpiamos la pantalla y dibujamos los vértices:

glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glUseProgram(renderingProgram);

glUniformMatrix4fv(mvLoc, 1, GL_FALSE, glm::value_ptr(mvMat));
glUniformMatrix4fv(projLoc, 1, GL_FALSE, glm::value_ptr(pMat));

glBindVertexArray(vao[0]);
glDrawArrays(GL_TRIANGLES, 0, 36);

5.6 Resultado

El programa muestra un cubo 3D con colores en cada cara, renderizado con profundidad para que las caras ocultas no se dibujen.

• VBOs y VAO para manejar los datos de vértices.

• Shaders para transformar y colorear la geometría.

• Uniforms para aplicar matrices de cámara y proyección.

• El pipeline de OpenGL trabajando de principio a fin.

Conclusión

A lo largo del artículo vimos cómo funciona el recorrido de los datos en OpenGL: desde que definimos un conjunto de vértices en la aplicación, hasta que finalmente esos datos se transforman en píxeles en pantalla.

• Los buffers nos permiten organizar la geometría en memoria para que la GPU la procese eficientemente.

• Los uniforms actúan como parámetros globales que guían al pipeline sin repetirse en cada vértice.

• Las etapas programables (vertex y fragment shaders) son los lugares donde podemos intervenir directamente para dar forma y color a lo que se dibuja.

• Finalmente, todo desemboca en el framebuffer, que es el lienzo final donde queda guardada la imagen.

Este recorrido muestra que dibujar en 3D no es magia: es un proceso ordenado de transformaciones y cálculos que, etapa tras etapa, convierten datos numéricos en una escena visible.

Con estos conceptos en mente, ya cuentas con la base para dar el siguiente paso: experimentar con texturas, iluminación y efectos visuales que harán tus programas mucho más expresivos y atractivos.

En OpenGL, cada vértice comienza su recorrido en un sistema de coordenadas muy simple: el espacio local del objeto. Sin embargo, antes de llegar a convertirse en un fragmento visible en pantalla, ese mismo vértice debe atravesar una serie de transformaciones geométricas que lo llevan por distintos espacios de coordenadas. Este proceso no es un capricho del pipeline gráfico, sino una necesidad: permite separar responsabilidades, facilitar cálculos como la iluminación, y mantener una forma ordenada y flexible de describir escenas complejas.

English version of this article. Click here

El objetivo final de este recorrido es obtener las llamadas Coordenadas de Dispositivo Normalizadas (NDC), que son indispensables para que el rasterizador pueda convertir la geometría en píxeles. Para llegar a ellas, OpenGL utiliza una secuencia de transformaciones aplicadas mediante matrices: Model, View y Projection. La clave está en que estas operaciones no se aplican por separado, sino que se concatenan en una sola cadena de transformaciones, lo que permite expresar de manera compacta la transición desde el espacio local de un objeto hasta su representación en pantalla.

En este artículo exploraremos cada uno de los espacios de coordenadas que intervienen en este proceso —Local, Mundial, de Vista, de Clip, de NDC y de Pantalla— y veremos cómo la composición de matrices hace posible que un vértice atraviese este camino de forma precisa y eficiente.

2. El Panorama General: La Cadena de Transformación

Para comprender cómo OpenGL lleva un vértice desde su posición original en un objeto hasta su representación final en la pantalla, conviene tener una vista global del proceso. El pipeline gráfico no aplica una única transformación, sino una cadena de operaciones sucesivas, cada una asociada a un espacio de coordenadas específico.

En total, un vértice atraviesa cinco espacios fundamentales:

1. Espacio Local (Object Space): el sistema propio del objeto, definido durante el modelado.

2. Espacio Mundial (World Space): unifica todos los objetos de la escena bajo un mismo sistema de referencia global.

3. Espacio de Vista (Eye Space o View Space): representa la escena desde el punto de vista de la cámara.

4. Espacio de Clip (Clip Space): el resultado de aplicar la proyección; aquí se determina qué geometría será visible.

5. Espacio de Dispositivo y Pantalla (NDC y Screen Space): la conversión final a coordenadas normalizadas y luego a píxeles.

La transición entre estos espacios se logra mediante tres matrices principales:

• Matriz de Modelo (M): lleva vértices del espacio local al mundo.

• Matriz de Vista (V): convierte las coordenadas del mundo al sistema de la cámara.

• Matriz de Proyección (P): proyecta la escena de 3D a 2D, generando el espacio de clip.

Estas matrices se aplican de forma concatenada en una expresión compacta:

$$\text{MVP} = P \cdot V \cdot M$$

donde cada vértice v se transforma como:

$$v_{clip} = P \cdot V \cdot M \cdot v_{local}$$

Este esquema refleja el corazón del pipeline gráfico: una secuencia de transformaciones geométricas expresadas como multiplicaciones de matrices. Comprender esta cadena es esencial antes de entrar al detalle de cada espacio, pues ofrece la intuición general del recorrido de un vértice en OpenGL.

3. Espacio Local (Object Space)

El recorrido de un vértice en OpenGL comienza en el espacio local, también llamado object space. Este es el sistema de coordenadas propio del objeto, definido normalmente durante la etapa de modelado. En este espacio, cada vértice se expresa con respecto a un origen y ejes internos al objeto, sin ninguna relación todavía con la escena global ni con la cámara.

Un ejemplo sencillo: al crear un cubo en un programa de modelado, sus vértices suelen estar centrados en el origen (0,0,0), con coordenadas que van de −0.5 a 0.5. En ese momento, no importa dónde aparecerá el cubo en la escena: lo único que importa es su forma y su escala relativas a su propio sistema.

    float CubeVertexPositions[108] = {
        -1.0f,  1.0f, -1.0f, -1.0f, -1.0f, -1.0f,  1.0f, -1.0f, -1.0f,
         1.0f, -1.0f, -1.0f,  1.0f,  1.0f, -1.0f, -1.0f,  1.0f, -1.0f,
         1.0f, -1.0f, -1.0f,  1.0f, -1.0f,  1.0f,  1.0f,  1.0f, -1.0f,
         1.0f, -1.0f,  1.0f,  1.0f,  1.0f,  1.0f,  1.0f,  1.0f, -1.0f,
         1.0f, -1.0f,  1.0f, -1.0f, -1.0f,  1.0f,  1.0f,  1.0f,  1.0f,
        -1.0f, -1.0f,  1.0f, -1.0f,  1.0f,  1.0f,  1.0f,  1.0f,  1.0f,
        -1.0f, -1.0f,  1.0f, -1.0f, -1.0f, -1.0f, -1.0f,  1.0f,  1.0f,
        -1.0f, -1.0f, -1.0f, -1.0f,  1.0f, -1.0f, -1.0f,  1.0f,  1.0f,
        -1.0f, -1.0f,  1.0f,  1.0f, -1.0f,  1.0f,  1.0f, -1.0f, -1.0f,
         1.0f, -1.0f, -1.0f, -1.0f, -1.0f, -1.0f, -1.0f, -1.0f,  1.0f,
        -1.0f,  1.0f, -1.0f,  1.0f,  1.0f, -1.0f,  1.0f,  1.0f,  1.0f,
         1.0f,  1.0f,  1.0f, -1.0f,  1.0f,  1.0f, -1.0f,  1.0f, -1.0f,
    };

El objetivo principal en este espacio es permitir transformaciones de modelado tales como:

• Traslación: mover el objeto en relación con su propio origen.

• Rotación: girar el objeto alrededor de sus ejes locales.

• Escalado: modificar su tamaño en una o varias direcciones.

Todas estas operaciones se combinan en la llamada Matriz de Modelo (M), que actúa como el puente entre el espacio local y el espacio mundial. Matemáticamente, si v_local es un vértice en coordenadas locales, la conversión al mundo se expresa como:

$$v_{world} = M \cdot v_{local}$$

Un punto crucial es que estas transformaciones no son independientes, sino que pueden concatenarse en una sola matriz. Por ejemplo, si primero escalamos, luego rotamos y después trasladamos un objeto, la matriz resultante será el producto:

$$M = T \cdot R \cdot S$$

donde el orden importa, ya que la multiplicación de matrices no es conmutativa.

glm::mat4 mMat;

mMat = glm::translate(glm::mat4(1.0f), glm::vec3(cubeLocX, cubeLocY, cubeLocZ));

mMat = glm::scale(mMat, glm::vec3(1.5f, 1.5f, 1.5f));

mMat = glm::rotate(mMat, glm::radians(45.0f), glm::vec3(0.0f, 1.0f, 0.0f));

Este espacio local resulta particularmente útil porque permite describir la geometría de manera sencilla y reutilizable: un mismo modelo puede colocarse en diferentes posiciones y escalas en la escena simplemente cambiando su matriz de modelo.

4. Espacio Mundial (World Space)

Una vez que un vértice ha sido definido en el espacio local del objeto, el siguiente paso es situarlo dentro de la escena completa. Para ello se utiliza el espacio mundial (world space), un sistema de coordenadas global que sirve como referencia común para todos los objetos.

En este espacio, cada modelo deja de estar aislado en su propio origen y se coloca en una posición coherente con el resto de la escena. Así, si un cubo se ubica a la izquierda y una esfera a la derecha, ambas comparten un mismo marco de referencia que permite describir sus relaciones espaciales de forma consistente.

La transición de local → mundial ya está definida por la matriz de modelo (M), la cual integra todas las transformaciones aplicadas a cada objeto (escala, rotación y traslación). Al aplicar esta matriz sobre todos los vértices del objeto, se logra colocar el modelo en el mundo en la posición y orientación deseadas:

$$v_{world} = M \cdot v_{local}$$

Un aspecto esencial del espacio mundial es que permite la interacción entre múltiples objetos. Por ejemplo:

• Colocar una mesa en el centro de una habitación.

• Ubicar una lámpara sobre la mesa.

• Posicionar una cámara frente a toda la escena.

Otro punto importante es que las transformaciones de modelado suelen organizarse de forma jerárquica. Esto significa que la posición de un objeto puede depender de otro. Por ejemplo, si un robot tiene un brazo articulado, al mover el cuerpo completo, el brazo también se mueve, ya que hereda las transformaciones de su “padre” en la jerarquía. En este caso, la concatenación de matrices resulta fundamental, pues la matriz de modelo final de un objeto puede estar compuesta por varias transformaciones heredadas.

5. Espacio de Vista (Eye Space / View Space)

Una vez que los objetos han sido colocados en la escena global mediante el espacio mundial, el siguiente paso es observar esa escena desde un punto de vista particular. Aquí es donde entra en juego el espacio de vista, también conocido como eye space o view space.

En este sistema de coordenadas, todo se reinterpreta como si estuviéramos mirando la escena desde los “ojos” de una cámara. Sin embargo, es importante aclarar una confusión muy común: en OpenGL no existe realmente un objeto “cámara” que se pueda mover o renderizar. Lo que hacemos, en realidad, es aplicar una transformación matemática a toda la escena para simular lo que una cámara vería desde cierta posición y orientación.

El concepto clave es el siguiente:

• Mover la cámara hacia adelante es equivalente a mover toda la escena hacia atrás.

• Girar la cámara hacia la derecha es lo mismo que rotar todo el mundo hacia la izquierda.

De esta manera, en lugar de trasladar o rotar una cámara, lo que hacemos es aplicar la Matriz de Vista (V) a todos los vértices de la escena:

$$v_{view} = V \cdot v_{world}$$

La matriz de vista se construye generalmente a partir de tres parámetros:

1. La posición de la cámara (desde dónde miramos).

2. El punto de enfoque (hacia dónde miramos).

3. El vector “arriba” (up vector), que define la orientación vertical.

Con esta información, la matriz de vista se calcula de forma que traslada y rota la escena entera, colocando la cámara en el origen del espacio de vista, mirando hacia el eje −Z por convención en OpenGL.

glm::mat4 vMat;

vMat = glm::lookAt(
glm::vec3(cameraX, cameraY, cameraZ), // eye position
glm::vec3(0.0f, 0.0f, 0.0f),         // center: where the eye is looking at
glm::vec3(0.0f, 1.0f, 0.0f)          // up: the upward direction
);

¿Por qué este paso es tan útil? Porque muchos cálculos gráficos, como la iluminación y el sombreado, se simplifican al trabajar en un sistema donde el observador está en un punto fijo y conocido: el origen de coordenadas.

6. Espacio de Clip (Clip Space)

Después de transformar la escena al espacio de vista (Eye Space), el siguiente paso es proyectarla al espacio de clip (clip space). Este es un espacio intermedio donde OpenGL decide qué geometría está dentro del campo de visión y, por tanto, puede llegar a la pantalla.

La transición de vista → clip se realiza mediante la matriz de proyección P:

$$v_{clip} = P \cdot v_{view}$$

En este punto, cada vértice todavía tiene cuatro componentes (x,y,z,w), y será la división por w la que lo convertirá en coordenadas normalizadas (NDC).

6.1 Matriz de Proyección en Perspectiva

La proyección en perspectiva imita la forma en que los humanos percibimos el mundo: los objetos cercanos se ven más grandes que los lejanos. Esto se logra mediante una transformación que introduce la componente w, de manera que la profundidad afecta al tamaño aparente de los objetos.

Para construir esta matriz se necesitan cuatro parámetros:

1. Field of View (FOV): ángulo vertical del campo de visión.

2. Aspect ratio: relación ancho/alto de la ventana de visualización.

3. Near clipping plane (Znear): plano cercano donde se empieza a proyectar la escena.

4. Far clipping plane (Zfar): plano lejano que limita la proyección.

Geométricamente, estos parámetros definen un frustum, una pirámide truncada que representa todo lo que la cámara puede ver. Todo objeto fuera de este volumen es descartado mediante clipping.

En código, usando GLM, se construye así:

float aspect = (float)width / (float)height;
glm::mat4 pMat = glm::perspective(1.0472f, aspect, 0.1f, 1000.0f);  // 60 grados vertical

Esta matriz transforma coordenadas de Eye Space a Clip Space, ajustando la perspectiva y preparando los vértices para la normalización posterior en NDC.

6.2 Matriz de Proyección Ortográfica

En una proyección ortográfica, los objetos no se escalan con la distancia: las líneas paralelas permanecen paralelas, y no hay efecto de profundidad visual. Esto es útil en CAD, mapas, o cuando queremos mediciones precisas de los objetos, sin distorsión por perspectiva.

Para construir esta matriz se definen los límites del volumen de visión ortográfico:

• L, R: límites izquierdo y derecho en X.

• B, T: límites inferior y superior en Y.

• Znear, Zfar: planos cercanos y lejanos en Z.

La proyección ortográfica proyecta directamente todos los vértices dentro de este volumen hacia Clip Space sin alterar sus proporciones. En GLM, se construye con:

glm::mat4 pMat = glm::ortho(left, right, bottom, top, nearPlane, farPlane);

7. Coordenadas de Dispositivo Normalizadas (NDC)

Una vez que los vértices han sido transformados al espacio de clip, todavía no están listos para el rasterizador. En este punto, cada vértice se representa en coordenadas homogéneas de la forma (x,y,z,w). Para normalizarlos y llevarlos a un espacio uniforme, OpenGL realiza automáticamente la llamada división de perspectiva (perspective divide):

$$v_{ndc} = \left(\frac{x}{w}, \frac{y}{w}, \frac{z}{w}\right)$$

Este paso tiene dos consecuencias fundamentales:

1. Normalización:
   Los vértices quedan contenidos en un cubo de coordenadas conocido como volumen NDC (Normalized Device Coordinates), que va de −1 a 1 en cada eje.

   $$-1 \leq x{ndc}, y{ndc}, z_{ndc} \leq 1$$

2. Profundidad en perspectiva:
   En una proyección en perspectiva, los objetos lejanos obtienen un valor de w mayor, lo que hace que sus coordenadas normalizadas se reduzcan, simulando así el efecto de que los objetos se ven más pequeños al alejarse.

De esta manera, la división entre w es el paso que convierte la proyección en perspectiva en algo tangible: el foreshortening o acortamiento visual que da realismo a la escena.

El volumen NDC tiene una forma cúbica muy estricta:

• En el eje x, de −1 (izquierda) a 1 (derecha).

• En el eje y, de −1 (abajo) a 1 (arriba).

• En el eje z, de −1 (cerca) a 1 (lejos) en OpenGL clásico. (Nota: algunas APIs como DirectX usan [0,1] para z).

Cualquier vértice que quede fuera de este rango será descartado, pues no puede ser representado en pantalla.

8. Espacio de Pantalla (Screen Space)

Después de normalizar los vértices en el espacio NDC, todavía nos queda un último paso: transformarlos a coordenadas de pantalla que correspondan a píxeles reales en el monitor. Este espacio se conoce como screen space o window space.

El mapeo de NDC a pantalla se realiza mediante la transformación de ventana (viewport transform). Conceptualmente, esta transformación escala y traslada las coordenadas normalizadas [−1,1] de cada eje a valores enteros correspondientes a píxeles:

$$\text{Eje } x: \; [-1, 1] \;\;\longrightarrow\;\; [0, \text{ancho de la ventana}]$$

$$\text{Eje } y: \; [-1, 1] \;\;\longrightarrow\;\; [0, \text{alto de la ventana}]$$

La función de OpenGL glViewport(x, y, width, height) define esta correspondencia. Esencialmente, indica:

• (x, y): la esquina inferior izquierda del área de renderizado.

• (width, height): las dimensiones del viewport, es decir, el área de la ventana donde se dibujará la escena.

Matemáticamente, la conversión de NDC a pantalla para cada eje se puede expresar como:

$$x_{screen} = \frac{(x_{ndc} + 1)}{2} \cdot \text{width} + x$$

$$y_{screen} = \frac{(y_{ndc} + 1)}{2} \cdot \text{height} + y$$

El eje z también se transforma a un rango apropiado para el depth buffer, que permite el cálculo de la visibilidad de los fragmentos durante el rasterizado. (este tema sera tratado en articulos posteriores).

Ejemplo.

Conclusión: ¿Por Qué Tantos Espacios de Coordenadas?

A lo largo del recorrido de un vértice en OpenGL, hemos visto cómo pasa por diferentes espacios de coordenadas: local, mundial, de vista, de clip, NDC y finalmente de pantalla. A primera vista, puede parecer que el vértice “viaja” por distintos mundos o que cada espacio es un lugar físico distinto. Pero no es así.

En realidad, cada espacio no es más que un marco de referencia matemático, una forma conveniente de describir posiciones y transformaciones en el proceso de generación de gráficos. No hay múltiples escenas o cámaras flotando en paralelo: todo ocurre dentro de un mismo sistema numérico, y lo único que hacemos es reinterpretar las coordenadas en función del problema que queremos resolver en cada etapa.

• Espacio local: sirve como marco para modelar un objeto respecto a sí mismo.

• Espacio mundial: nos da un punto de referencia común para posicionar varios objetos en una misma escena.

• Espacio de vista: cambia el marco de referencia a la perspectiva de la cámara (o más bien, del observador).

• Espacio de clip y NDC: son marcos diseñados para simplificar el proceso de proyección y rasterización.

La clave está en la concatenación de matrices (modelo, vista, proyección), que nos permite pasar de un marco a otro sin perder información esencial. Cada transformación se aplica con un propósito específico, y al final todo converge en el mismo resultado: coordenadas listas para dibujarse como píxeles en pantalla.

Las matemáticas son el lenguaje oculto de los gráficos por computadora: nos permiten describir y manipular situaciones complejas que, de otra forma, serían difíciles de abordar. Sin embargo, los símbolos cobran sentido solo cuando comprendemos lo que representan y cómo se aplican en la práctica.

En programación gráfica, la mayoría de los efectos que percibimos como naturales en una escena 3D —movimiento de objetos, escala, perspectiva, iluminación o sombras— son transformaciones matemáticas cuidadosamente aplicadas. No es necesario ser un matemático profesional; lo esencial es aprender las nociones suficientes para usar las matemáticas de forma efectiva dentro de OpenGL.

English version of this article. Click here

En este articulo se presentan los fundamentos que sostienen el pipeline gráfico: sistemas de coordenadas, notación homogénea de puntos, matrices y sus transformaciones, y operaciones vectoriales clave. Lejos de ser conceptos abstractos, estas herramientas serán indispensables al diseñar y animar escenas tridimensionales.

1. Sistemas de Coordenadas en 3D: La Base de Todo Mundo Virtual

Al ingresar al universo de los gráficos 3D, lo primero que debemos comprender es el espacio en el que se desarrolla todo. Así como un cartógrafo necesita de latitud y longitud para situar un punto en un mapa, un programador gráfico requiere un sistema de coordenadas para definir la posición, orientación y escala de cada objeto dentro de una escena. Este sistema constituye el marco de referencia invisible sobre el que se levanta cualquier mundo virtual.

1.1 Definición de los Ejes X, Y y Z

Un sistema de coordenadas tridimensional está formado por tres ejes ortogonales (perpendiculares entre sí) que se cruzan en un punto común, el origen (0, 0, 0):

• Eje X: Representa la dirección horizontal (izquierda-derecha). Por convención, los valores positivos se extienden hacia la derecha y los negativos hacia la izquierda.

• Eje Y: Representa la dirección vertical (arriba-abajo). Los valores positivos crecen hacia arriba y los negativos hacia abajo.

• Eje Z: Representa la profundidad (adelante-atrás). Es el eje que otorga tridimensionalidad, diferenciando un plano bidimensional de un espacio 3D real.

Cualquier punto dentro de este espacio puede describirse de manera única mediante un trío de valores (X, Y, Z), conocidos como coordenadas o vector de posición.

1.2 La Diferencia Crucial: Sistemas Diestros (Right-Handed) vs. Zurdos (Left-Handed)

A primera vista, definir tres ejes parece trivial. Sin embargo, la forma en que se orientan en la práctica determina toda la coherencia espacial de la escena. Aquí es donde aparece una distinción fundamental: los sistemas de coordenadas diestros y zurdos.

• Sistema Diestro (Right-Handed):
  Imagina tu mano derecha abierta. Apunta los dedos (excepto el pulgar) en la dirección positiva del eje X. Luego dóblalos hacia la dirección positiva del eje Y. Tu pulgar extendido señalará automáticamente la dirección positiva del eje Z.

  • Visualización: el eje Z positivo “sale” de la pantalla hacia el observador. Este sistema es el estándar en matemáticas y física, y también el que usa OpenGL de forma predominante.

• Sistema Zurdo (Left-Handed):
  Ahora haz el mismo gesto con tu mano izquierda. Los dedos siguen apuntando hacia X positivo y al doblarlos hacia Y positivo, el pulgar indicará la dirección positiva del eje Z.

  • Visualización: en este caso, el eje Z positivo se interna “hacia adentro” de la pantalla, alejándose del observador. Este sistema es empleado en Direct3D y puede resultar más intuitivo en entornos bidimensionales, ya que un mayor valor de Z equivale a “más lejos”.

1.3 Consecuencia Práctica: Rotaciones Positivas

La elección entre un sistema diestro o zurdo no es un mero tecnicismo. Una de sus implicaciones más directas es la definición de las rotaciones positivas.

• En un sistema diestro, la dirección del giro se determina aplicando la regla de la mano derecha: si apuntas el pulgar en la dirección positiva de un eje, la curva de los demás dedos indica el sentido positivo de rotación.

• En un sistema zurdo, se aplica la misma regla, pero con la mano izquierda.

Si se mezclan ambos sistemas en un mismo proyecto, los objetos girarán en sentido contrario al esperado, lo que puede generar inconsistencias difíciles de detectar. Por ello, es esencial tener claro desde el inicio cuál sistema de coordenadas se está utilizando.

2. Representación de Puntos: Precisión y Potencia en Notación Homogénea

Definir la posición de un vértice es quizá la acción más fundamental en los gráficos por computadora. Sin embargo, la manera en que representamos matemáticamente estos puntos tiene un impacto directo en la eficiencia y en las posibilidades de transformación que ofrece un motor gráfico. La evolución desde la notación cartesiana clásica hacia la notación homogénea no fue un simple cambio de convención, sino un paso crucial que cimentó gran parte del rendering moderno.

2.1 Notación Cartesiana Clásica: (x, y, z)

Es la forma más intuitiva y familiar de describir un punto en el espacio tridimensional.

• Definición: Un trío de números reales que indican la distancia a lo largo de cada eje respecto al origen.

• Ejemplo: El punto (2, 8, -3) se ubica 2 unidades a la derecha, 8 unidades hacia arriba y 3 unidades hacia atrás, si asumimos un sistema de coordenadas diestro donde el eje Z positivo “sale” hacia el observador.

• Limitación: Aunque es útil para representar posiciones absolutas, esta notación se queda corta al intentar unificar transformaciones más complejas, como proyecciones en perspectiva, dentro de un mismo marco algebraico.

2.2 Notación Homogénea: (x, y, z, w)

Para superar esas limitaciones, se recurre a la notación homogénea, una herramienta matemática que se ha convertido en estándar en gráficos 3D.

• Definición: Un punto en notación homogénea se representa con cuatro componentes: (x, y, z, w), donde w es el componente homogéneo.

• Punto ordinario: Cuando w = 1, las coordenadas (x, y, z, 1) equivalen al punto cartesiano (x, y, z).

• Vector de dirección: Cuando w = 0, la tupla (x, y, z, 0) ya no describe un punto, sino un vector. Este vector no tiene posición fija: indica solo dirección y magnitud, lo que lo hace inmune a las traslaciones (exactamente el comportamiento que se busca al aplicar transformaciones a normales, velocidades o rayos de luz).

2.3 Ventajas de la Notación Homogénea

El verdadero poder de la notación homogénea se revela en el manejo de las transformaciones geométricas:

1. Unificación de operaciones: Traslaciones, rotaciones, escalados y proyecciones se pueden expresar bajo un mismo mecanismo: la multiplicación por matrices 4x4. En notación cartesiana, cada operación requeriría un tratamiento distinto; en homogénea, todas se reducen a un producto matricial.

2. Proyección en perspectiva: La proyección en perspectiva, que hace que los objetos lejanos se vean más pequeños, requiere dividir por una escala dependiente de la profundidad. En coordenadas homogéneas, esta operación se integra naturalmente: la matriz de proyección ajusta el valor de w, y la GPU realiza automáticamente la división de perspectiva (x/w, y/w, z/w) antes del rasterizado.

3. Distinción clara entre punto y vector: (x, y, z, 1) es un punto (posee posición), mientras que (x, y, z, 0) es un vector (posee dirección). Gracias a esta diferencia, las traslaciones afectan a los puntos pero no a los vectores, lo que permite modelar de manera precisa el comportamiento geométrico del mundo 3D.

3. Vectores en Gráficos 3D: Representación y Operaciones

En gráficos 3D, los vectores son herramientas esenciales para describir posiciones, direcciones y magnitudes. Comprender su representación y propiedades es clave para manipular objetos, calcular normales y determinar relaciones geométricas entre elementos de una escena.

3.1 Representación y Propiedades

Un vector se define por su magnitud y dirección. A diferencia de un punto, que indica una posición específica en el espacio, un vector representa únicamente desplazamiento o dirección, sin un origen fijo. Esta distinción conceptual es fundamental: mientras que los puntos se usan para situar objetos, los vectores se utilizan para describir movimientos, fuerzas, velocidades y normales de superficies.

En OpenGL y GLM, los vectores se representan principalmente mediante las estructuras vec3 y vec4:

// Vector 3D clásico: solo dirección
glm::vec3 direccion(1.0f, 2.0f, 3.0f);

// Vector homogéneo: usado para multiplicaciones con matrices 4x4
glm::vec4 punto(1.0f, 2.0f, 3.0f, 1.0f);   // w = 1 indica un punto
glm::vec4 vectorDir(1.0f, 2.0f, 3.0f, 0.0f); // w = 0 indica un vector de dirección

La componente w en vec4 permite distinguir entre puntos y vectores cuando se aplican transformaciones homogéneas mediante matrices 4x4: los puntos (w=1) se trasladan y rotan, mientras que los vectores (w=0) solo se rotan, preservando su magnitud y dirección relativa.

En el shader (GLSL):

• vec3 y vec4 son los análogos directos.

• Los atributos de vértice suelen ser vec3 o vec4, mientras que las matrices de transformación (mat4) actúan sobre estos datos.

// Definiciones dentro del vertex shader
layout (location = 0) in vec3 aPos;
layout (location = 1) in vec3 aNormal;

// Convertimos a homogéneas para multiplicar por mat4
vec4 posicion = vec4(aPos, 1.0);
vec4 normal   = vec4(aNormal, 0.0);

3.2 Operaciones con Vectores

Los vectores admiten una serie de operaciones algebraicas que resultan fundamentales para gráficos 3D:

1. Suma y resta:
   La suma o resta de vectores se realiza componente a componente. Por ejemplo, dado A = (x₁, y₁, z₁) y B = (x₂, y₂, z₂), se tiene:

   $$\begin{aligned} A + B &= (x_1 + x_2, \; y_1 + y_2, \; z_1 + z_2) \[6pt] A - B &= (x_1 - x_2, \; y_1 - y_2, \; z_1 - z_2) \end{aligned}$$

2. Normalización:
   Convertir un vector a longitud unitaria (magnitud 1) es crucial para calcular direcciones, iluminación y reflejos. La normalización se realiza dividiendo cada componente por la magnitud del vector:

   $$\hat{V} = \frac{V}{|V|} = \frac{(x, y, z)}{\sqrt{x^2 + y^2 + z^2}}$$

3. Producto punto (dot product):
   El producto punto entre dos vectores A y B se define como:

   $$A \cdot B = x_A x_B + y_A y_B + z_A z_B$$

   Sus aplicaciones incluyen:

   • Determinar el ángulo entre vectores:

     $$\cos\theta = \frac{A \cdot B}{|A||B|}$$

   • Verificar perpendicularidad: A·B = 0 indica vectores ortogonales.

   • Calcular la distancia a un plano a partir de la normal del mismo.

4. Producto cruz (cross product):
   Produce un vector perpendicular a dos vectores dados. Dado A y B:

$$A \times B = \begin{bmatrix} y_A z_B - z_A y_B \\ z_A x_B - x_A z_B \\ x_A y_B - y_A x_B \end{bmatrix}$$

Esta operación es esencial para: - Calcular normales de superficies, necesarias para iluminación y sombreado. - Determinar dirección de ejes ortogonales en sistemas de coordenadas locales de objetos.

4. Uso de Matrices en Gráficos 3D

Las matrices son el andamiaje algebraico sobre el que se construyen los mundos virtuales. Funcionan como máquinas que, con una elegancia matemática, transforman puntos y vectores en el espacio. Gracias a ellas, un objeto puede moverse, girar, cambiar de tamaño o proyectarse en perspectiva, y todo ocurre mediante reglas precisas que la GPU ejecuta millones de veces por segundo.

4.1 Definición y Tipos de Matrices

Estructura de una matriz 4x4

Una matriz es un arreglo rectangular de números organizados en filas y columnas. En gráficos 3D, la más relevante es la matriz 4x4, con 16 elementos dispuestos en 4 filas y 4 columnas:

$$\begin{bmatrix} m_{00} & m_{01} & m_{02} & m_{03} \\ m_{10} & m_{11} & m_{12} & m_{13} \\ m_{20} & m_{21} & m_{22} & m_{23} \\ m_{30} & m_{31} & m_{32} & m_{33} \end{bmatrix}$$

Los subíndices siguen la convención [fila][columna].
Esta estructura no es arbitraria: está diseñada para operar de forma directa con puntos en coordenadas homogéneas (x, y, z, w), mediante la multiplicación de matrices.

4.2 Matriz Identidad

La matriz identidad (I) es el equivalente algebraico a “no hacer nada”. Es una matriz cuadrada con unos en la diagonal principal y ceros en las demás posiciones:

$$\begin{bmatrix} 1 & 0 & 0 & 0 \\ 0 & 1 & 0 & 0 \\ 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 1 \end{bmatrix}$$

Su propiedad fundamental es mantener inalterado cualquier objeto sobre el que actúe:

• M * I = M

• I * M = M

• I * P = P

En gráficos, representa la transformación neutra o de “reposo”. En GLM se construye con glm::mat4(1.0f).

4.3 Transpuesta de una Matriz

La transpuesta (Mᵀ) se obtiene intercambiando filas por columnas.

Ejemplo:

$$M = \begin{bmatrix} a & b \\ c & d \end{bmatrix}, \quad M^{\mathrm{T}} = \begin{bmatrix} a & c \\ b & d \end{bmatrix}$$

En gráficos, se utiliza en operaciones como el cálculo de matrices normales, fundamentales para el sombreado e iluminación. Tanto GLM como GLSL incluyen la función transpose().

4.4 Operaciones Básicas

• Suma de matrices: Se realiza sumando cada elemento con su correspondiente. Solo es válida entre matrices del mismo tamaño.

• Multiplicación de matrices (concatenación): Es la operación clave en 3D.

  • No es conmutativa → A * B ≠ B * A en general.

  • Es asociativa → A * (B * C) = (A * B) * C.

La no conmutatividad refleja que el orden importa: rotar un objeto y luego trasladarlo no produce el mismo resultado que trasladarlo primero y después rotarlo.

4.5 Multiplicación Matriz-Punto

Un punto en coordenadas homogéneas puede representarse como una columna:

$$P = \begin{bmatrix} x \\ y \\ z \\ w \end{bmatrix}$$

Al multiplicarlo por una matriz M (4x4) obtenemos un nuevo punto P':

$$P' = M * P$$

En código (GLM o GLSL), esta operación se expresa naturalmente como vec4 nuevoPunto = M * P;.

4.6 Multiplicación Matriz-Matriz (Concatenación)

Multiplicar dos matrices A y B produce una nueva matriz C = A * B que combina ambas transformaciones. La GPU aprovecha la propiedad asociativa para optimizar cálculos:

En lugar de aplicar tres matrices diferentes a cada vértice:

$$\text{NuevoPunto} = M_1 \cdot \big( M_2 \cdot \big( M_3 \cdot P \big) \big)$$

se calcula primero la matriz compuesta:

$$\text{Modelo} = M_1 \cdot M_2 \cdot M_3$$

y luego:

$$\text{NuevoPunto} = \text{Modelo} \cdot P$$

Esto evita millones de operaciones redundantes en escenas con gran cantidad de vértices.

4.7 Matriz Inversa

La inversa de M (denotada M⁻¹) es la única matriz que cumple:

$$M \cdot M^{-1} = I$$

No todas las matrices son invertibles, y calcular la inversa es costoso. Aun así, es esencial en situaciones como:

• Transformar vectores normales (usando la transpuesta de la inversa).

• Convertir coordenadas de un objeto al espacio de la cámara.

GLM y GLSL proporcionan inverse(), pero debe usarse con cautela en tiempo real.

5. Matrices de Transformación

Las matrices de transformación constituyen una herramienta fundamental en gráficos por computadora, pues permiten modificar la posición, orientación y tamaño de los objetos dentro de un espacio tridimensional. El uso de matrices 4x4 junto con coordenadas homogéneas ofrece una representación unificada de traslaciones, escalados y rotaciones. Gracias a ello, estas transformaciones pueden combinarse de manera consistente, lo que constituye la base del pipeline de renderizado moderno.

5.1 Traslación

La traslación es la operación que desplaza un objeto de una posición a otra en el espacio.

• Matriz de traslación:
  Se obtiene a partir de la matriz identidad, insertando los valores de desplazamiento (Tx, Ty, Tz) en la última columna:

$$- \begin{bmatrix} 1.0 & 0.0 & 0.0 & T_x \\ 0.0 & 1.0 & 0.0 & T_y \\ 0.0 & 0.0 & 1.0 & T_z \\ 0.0 & 0.0 & 0.0 & 1.0 \end{bmatrix}$$

• Efecto:
  Al multiplicar un punto homogéneo P = (x, y, z, 1) por esta matriz, se obtiene

  $$P' = (x + Tx, y + Ty, z + Tz, 1)$$

  La traslación es una transformación afín, lo que significa que conserva distancias relativas y ángulos.

Ejemplo:

Para desplazar un objeto 5 unidades en el eje X, se utiliza (Tx=0, Ty=5, Tz=0). En GLM, esto se implementa con:

glm::translate(glm::mat4(1.0f), glm::vec3(5.0f, 0.0f, 0.0f));

5.2 Escalado

El escalado modifica el tamaño de un objeto o lo refleja respecto a un plano.

• Matriz de escalado:

$$\begin{bmatrix} S_x & 0.0 & 0.0 & 0.0 \\ 0.0 & S_y & 0.0 & 0.0 \\ 0.0 & 0.0 & S_z & 0.0 \\ 0.0 & 0.0 & 0.0 & 1.0 \end{bmatrix}$$

• Efecto sobre un punto:
  Al aplicar esta matriz a P = (x, y, z, 1) se obtiene

• $$P' = (Sx * x, Sy * y, Sz * z, 1).$$

• Los factores de escala producen los siguientes efectos:

  • > 1: el objeto se amplía.

  • 0 < valor < 1: el objeto se reduce.

  • < 0: el objeto se refleja (efecto espejo).

Aplicación práctica:
Una de sus utilidades es la conversión entre sistemas de coordenadas diestro y zurdo. Como se explicó en la sección 1, la diferencia principal radica en la dirección del eje Z. Para invertirla, basta usar un escalado con (Sx=1, Sy=1, Sz=-1), lo que invierte el eje Z y cambia la handedness del sistema.

 mv_matrix = glm::scale(mv_matrix, glm::vec3(0.0, 0.0, 0.0));

5.3 Rotación

La rotación es la transformación más compleja, ya que implica girar un objeto alrededor de un eje.

• Rotaciones alrededor de ejes principales:
  Las formas más sencillas corresponden a giros alrededor de los ejes cartesianos. Siendo θ el ángulo (en radianes), las matrices son:

  • En X:

$$\begin{bmatrix} 1.0 & 0.0 & 0.0 & 0.0 \\ 0.0 & \cos\theta & -\sin\theta & 0.0 \\ 0.0 & \sin\theta & \cos\theta & 0.0 \\ 0.0 & 0.0 & 0.0 & 1.0 \end{bmatrix}$$

- En Y:

$$R_y = \begin{bmatrix} \cos\theta & 0.0 & \sin\theta & 0.0 \\ 0.0 & 1.0 & 0.0 & 0.0 \\ -\sin\theta & 0.0 & \cos\theta & 0.0 \\ 0.0 & 0.0 & 0.0 & 1.0 \end{bmatrix}$$

- En Z:

$$R_z = \begin{bmatrix} \cos\theta & -\sin\theta & 0.0 & 0.0 \\ \sin\theta & \cos\theta & 0.0 & 0.0 \\ 0.0 & 0.0 & 1.0 & 0.0 \\ 0.0 & 0.0 & 0.0 & 1.0 \end{bmatrix}$$

• Ángulos de Euler:
  El teorema de Euler establece que cualquier rotación 3D puede expresarse como una secuencia de tres rotaciones elementales sobre los ejes X, Y y Z, conocidas como ángulos de Euler (e.g., pitch-yaw-roll). Para rotar alrededor de un eje arbitrario que no pase por el origen, la estrategia típica es:

  1. Trasladar el objeto para que el eje coincida con el origen.

  2. Aplicar la rotación deseada.

  3. Revertir la traslación inicial.

• Limitación: Gimbal Lock:
  Los ángulos de Euler presentan un problema conocido como Gimbal Lock, que ocurre cuando dos ejes se alinean, reduciendo los grados de libertad de la rotación. Esto afecta a la animación fluida y a la interpolación de orientaciones.

  

    mv_matrix = glm::rotate(mv_matrix, angle, glm::vec3(0.0f, 0.0f, 1.0f));
  

• Alternativa: Cuaterniones:
  Para evitar el Gimbal Lock y manejar rotaciones de forma más robusta, se emplean cuaterniones. Estas estructuras de cuatro componentes permiten:

  • Representar rotaciones sin pérdida de grados de libertad.

  • Concatenar e interpolar rotaciones de forma eficiente (slerp).

  • Convertirse fácilmente en matrices de rotación mediante librerías como GLM (glm::mat4_cast(myQuat)).

Conclusión

En gráficos 3D, la combinación de matrices de transformación y vectores constituye el fundamento matemático que permite ubicar, orientar y escalar objetos en un espacio tridimensional. Las matrices 4x4 homogéneas ofrecen un marco unificado para realizar traslaciones, escalados y rotaciones, mientras que los vectores permiten representar posiciones, direcciones y magnitudes, así como realizar operaciones clave como suma, resta, normalización, producto punto y producto cruz.

Comprender la distinción conceptual entre puntos y vectores, así como el uso correcto de vec3 y vec4 en OpenGL/GLM, es esencial para garantizar que las transformaciones se apliquen de forma coherente y eficiente en el pipeline de renderizado. Asimismo, dominar estas herramientas permite calcular normales, definir sistemas de coordenadas locales, realizar interpolaciones y evitar problemas comunes, como el Gimbal Lock en rotaciones.

En conjunto, matrices y vectores no solo representan conceptos matemáticos abstractos, sino que constituyen el lenguaje central para manipular geometría y controlar la dinámica de cualquier escena 3D, sentando las bases para técnicas más avanzadas de modelado, animación e iluminación

1.1. Ruido en imágenes: conceptos básicos

En el procesamiento digital de imágenes, el ruido es cualquier elemento no deseado que altera la fidelidad visual y dificulta el análisis posterior. Sus causas pueden ir desde fluctuaciones aleatorias en los sensores hasta interferencias generadas por el propio equipo o el entorno.

English version of this article. Click here

En la práctica, el ruido modifica la representación original de la escena: reduce el contraste, introduce patrones que no existen en la realidad o esconde detalles importantes. Por eso, eliminarlo o al menos reducirlo es un paso clave en áreas donde la calidad de la imagen es crítica, como el diagnóstico médico, la observación satelital o la visión por computadora.

1.2. Ruido periódico: características y causas

El ruido periódico se distingue del aleatorio porque forma patrones repetitivos y predecibles: franjas, bandas o texturas regulares que, a simple vista, parecen parte de la imagen, pero en realidad no lo son.

En el dominio espacial, estos patrones suelen mantener una orientación y amplitud constantes. En el dominio de Fourier, se hacen evidentes como picos bien definidos, situados en posiciones específicas lejos del centro de la transformada.

Entre sus causas más comunes se encuentran:

• Interferencias eléctricas durante la captura, como en sistemas de escaneo o transmisión de datos.

• Defectos de calibración en sensores, que generan líneas o bandas fijas.

• Problemas de muestreo como el aliasing, que replican patrones indeseados.

Un ejemplo claro es el banding en imágenes satelitales causado por fallos en detectores CCD, o las resonancias magnéticas con artefactos producidos por vibraciones mecánicas.

2. Filtrado tradicional: el filtro notch

2.1. Fundamentos del filtro notch en el dominio de Fourier

El filtro notch es una herramienta diseñada para atenuar frecuencias específicas sin alterar el resto del espectro. Cuando el ruido es periódico, en la transformada de Fourier aparece como pares de picos simétricos respecto al centro. Si se eliminan o reducen esas frecuencias, gran parte del patrón indeseado desaparece, mientras que el resto de la imagen se conserva.

2.2. Implementación paso a paso

El proceso clásico consiste en:

1. Calcular la transformada de Fourier de la imagen para obtener su espectro.

2. Localizar los picos asociados al ruido —a menudo por inspección visual—.

3. Diseñar el filtro notch, que puede ser de corte abrupto (ideal) o con transición suave (gaussiano).

4. Aplicar el filtro multiplicándolo por el espectro.

5. Obtener la imagen filtrada mediante la transformada inversa.

def NotchFiltering(img, d0, notch_coords, n=2):
    """
    Applies a Butterworth notch filter to an image at specified frequency coordinates.

    Parameters:
        img : np.ndarray
            Input grayscale image to be filtered.
        d0 : float
            The cutoff radius of the notch filter. Frequencies within this radius will be attenuated.
        notch_coords : list of tuples
            A list of (u_k, v_k) coordinates in the frequency domain where periodic noise is present.
        n : int, optional
            The order of the Butterworth filter. Higher values result in a sharper transition. Default is 2.

    Returns:
        img_filtered : np.ndarray
            The filtered image in the spatial domain.
        magnitude_spectrum : np.ndarray
            The magnitude spectrum of the original image in the frequency domain.
        H_total : np.ndarray
            The combined notch filter applied in the frequency domain.

    Notes:
    -----
    - The function computes the Fourier Transform of the input image, applies the notch filter, 
      and then performs the inverse Fourier Transform to return the filtered image.
    - The filter is applied at all specified coordinates in [notch_coords] and their symmetric counterparts.
    """
    f = np.fft.fft2(img)
    fshift = np.fft.fftshift(f)

    magnitude_spectrum = 20 * np.log(np.abs(fshift) + 1)

    # Construct combined filter
    H_total = np.ones_like(img, dtype=np.float32)
    for u_k, v_k in notch_coords:
        H = ButterworthNotchFilter(img.shape, d0, u_k, v_k, n)
        H_total *= H

    # Apply the notch filter
    filtered_spectrum = fshift * H_total
    f_ishift = np.fft.ifftshift(filtered_spectrum)
    img_filtered = np.fft.ifft2(f_ishift)
    img_filtered = np.abs(img_filtered)

    return img_filtered, magnitude_spectrum, H_total

2.3. Ejemplo práctico

Supongamos que tenemos una imagen satelital con bandas horizontales. En el espectro, estas se manifiestan como picos sobre el eje vertical.

Al aplicar un filtro notch Butterworth en esas posiciones, el patrón de bandas se reduce considerablemente, conservando la mayoría de los detalles originales.

3. Limitaciones del filtro notch

hay que identificar manualmente las frecuencias a eliminar y ajustar el ancho del filtro. Esto resulta poco práctico cuando el espectro está plagado de múltiples picos dispersos, o cuando el ruido se encuentra muy cerca de la frecuencia cero (DC), ya que puede confundirse con información real de la imagen.

4. Filtrado automático de ruido cuasiperiódico

4.1. Idea general del método

El enfoque propuesto por Sur y Grédiac parte de una observación clave: cuando una imagen está contaminada con ruido periódico que se extiende por toda su superficie, ese patrón es el único elemento que se repite de manera consistente en cualquier región que seleccionemos.

Aprovechando esto, se calcula un espectro de potencia promedio a partir de múltiples parches extraídos de la imagen. Al promediar, las texturas y detalles propios de la escena tienden a cancelarse, mientras que el patrón repetitivo del ruido permanece visible en el dominio de Fourier como picos bien localizados.

4.2. Modelado y detección de picos espurios

El espectro promedio obtenido se compara con el comportamiento esperado para imágenes “naturales”, cuyo espectro de potencia sigue una ley de decaimiento en frecuencia (aproximadamente proporcional a 1/f^α).
Cualquier desviación significativa respecto a esta tendencia —en especial, picos muy por encima del nivel esperado— se interpreta como un indicio de ruido cuasiperiódico.

En vez de seleccionar manualmente las frecuencias problemáticas, el algoritmo identifica automáticamente estas “anomalías” como valores atípicos en el espectro.

4.3. Construcción del filtro notch adaptativo

Una vez localizadas las frecuencias sospechosas, se genera un mapa de picos que actúa como plantilla para construir un filtro notch. Este filtro no se limita a eliminar un par de frecuencias concretas, sino que atenúa de forma controlada todas las regiones del espectro asociadas al ruido detectado.

La imagen filtrada se reconstruye aplicando la transformada inversa de Fourier, resultando en una versión con el patrón periódico reducido o eliminado.

5. Descripción del algoritmo paso a paso

El procedimiento para eliminar ruido cuasiperiódico de manera automática se puede dividir en varias fases bien definidas, inspiradas en el método de Sur y Grédiac y adaptadas a una implementación práctica en Python:

1. Conversión y normalización de la imagen
   La imagen se transforma a escala de grises y se normaliza a valores entre 0 y 1. Esto unifica el formato de entrada y evita que las diferencias de iluminación o codificación de color influyan en el análisis espectral.

2. División en parches con ventana de Hann
   Se fragmenta la imagen en parches cuadrados de tamaño fijo (patch size) usando un solapamiento moderado. Cada parche se multiplica por una ventana de Hann bidimensional, lo que suaviza los bordes y reduce artefactos en el espectro causados por discontinuidades.

3. Cálculo del espectro promedio
   Para cada parche se obtiene su espectro de potencia (módulo al cuadrado de la Transformada de Fourier). Estos espectros se combinan mediante media geométrica, que atenúa valores extremos y realza la estructura común: el patrón del ruido.

4. Ajuste de un modelo estadístico
   Se calcula la frecuencia radial de cada punto del espectro promedio y se ajusta una ley de potencia $1/f^\alpha$ mediante regresión robusta (Huber). Este modelo describe cómo debería decaer la energía en una imagen natural sin ruido periódico.

5. Detección de picos anómalos
   Se calculan los residuos entre el espectro real y el modelo ajustado. Aquellos puntos que superan un umbral estadístico (kσ) y que están por encima de una frecuencia mínima f₂ se marcan como outliers, es decir, posibles frecuencias de ruido.

6. Construcción del mapa de picos
   Los outliers se organizan en una máscara binaria que respeta la simetría del espectro. Esta máscara se interpola al tamaño original de la imagen y se suaviza con un filtro gaussiano para evitar cortes bruscos.

7. Filtrado notch adaptativo
   Se multiplica el espectro original de la imagen por el complemento de la máscara suavizada. Este paso atenúa o elimina las frecuencias asociadas al ruido detectado, dejando intactas las demás.

8. Reconstrucción y extracción del ruido
   Mediante la transformada inversa de Fourier se obtiene la imagen filtrada. El componente de ruido se calcula restando la imagen filtrada de la original, lo que permite analizar qué ha sido eliminado.

9. Visualización y validación
   Se muestran los espectros antes y después del filtrado, junto con el espectro del ruido, lo que permite verificar visualmente la efectividad del proceso.

def RemoveQuasiperiodicNoise(image, patch_size=128, threshold=3.0, fmax=0.61):
    """
    Removes quasiperiodic noise from images using adaptive notch filtering.
    Based on the method by Sur & Grédiac (2015) with practical adjustments.

    Parameters:
        image (np.ndarray): Input image in grayscale or color (BGR).
        patch_size (int): Size of the square patch for spectral analysis.
        threshold (float): Standard deviation factor for detecting noise peaks.
        fmax (float): Maximum frequency for noise detection.

    Returns:
        denoised_image (uint8): Filtered image (values in range 0-255).
        noise_component (uint8): Extracted noise component (values in range 0-255).
    """
    # Convert to grayscale and normalize to [0, 1]
    if image.ndim == 3:
        image = cv.cvtColor(image, cv.COLOR_BGR2GRAY)
    image = image.astype(np.float32) / 255.0
    height, width = image.shape

    # Adjust parameters according to image dimensions
    patch_size = min(patch_size, height, width)
    step = max(1, patch_size // 8)  # Overlap L/8
    f2 = 8 / patch_size             # Minimum frequency

    # Precompute Hann window
    hann_window = np.outer(np.hanning(patch_size), np.hanning(patch_size))

    # Extract patches and compute power spectra
    patches = [
        image[y:y+patch_size, x:x+patch_size] * hann_window
        for y in range(0, height - patch_size, step)
        for x in range(0, width - patch_size, step)
    ]
    power_spectra = np.array([np.abs(fftshift(fft2(p)))**2 for p in patches])

    # Average power spectrum (geometric mean)
    avg_power_spectrum = np.exp(np.mean(np.log(power_spectra + 1e-10), axis=0))

    # Radial frequencies
    fy = np.fft.fftfreq(patch_size)[:, np.newaxis]
    fx = np.fft.fftfreq(patch_size)
    f = np.sqrt(fx**2 + fy**2)
    valid_mask = (f > f2 / 4) & (f < fmax)

    # Robust fit of the power law
    log_f = np.log(f[valid_mask]).reshape(-1, 1)
    log_P = np.log(avg_power_spectrum[valid_mask]).ravel()
    model = HuberRegressor().fit(log_f, log_P)

    log_P_pred = model.predict(log_f)
    residuals = log_P - log_P_pred
    std_res = np.std(residuals)
    upper_bound = log_P_pred + threshold * std_res

    # Noise peak detection
    outliers = (log_P > upper_bound) & (f[valid_mask].ravel() >= f2)

    # Outlier map with symmetry
    outlier_mask = np.zeros_like(avg_power_spectrum, dtype=bool)
    outlier_mask[valid_mask] = outliers
    outlier_mask |= np.flip(outlier_mask, axis=0)
    outlier_mask |= np.flip(outlier_mask, axis=1)

    # Resize and smooth the mask
    outlier_map = cv.resize(outlier_mask.astype(np.float32), (width, height), interpolation=cv.INTER_LINEAR)
    outlier_map = gaussian_filter(outlier_map, sigma=2.0)

    # Protect the DC component
    cy, cx = height // 2, width // 2
    outlier_map[cy-1:cy+2, cx-1:cx+2] = 0.0

    # Notch filtering
    fft_image = fftshift(fft2(image))
    fft_filtered = fft_image * (1 - outlier_map)
    denoised_image = np.real(ifft2(ifftshift(fft_filtered)))
    noise_component = image - denoised_image

    # Normalize and convert to uint8
    denoised_image = np.clip(denoised_image * 255, 0, 255).astype(np.uint8)
    noise_component = ((noise_component - noise_component.min()) / 
                       (noise_component.max() - noise_component.min()) * 255).astype(np.uint8)

    return denoised_image, noise_component

6. Limitaciones y consideraciones prácticas

• Suposición de naturalidad: el modelo espectral está pensado para imágenes naturales. En datos sintéticos o experimentales, puede no ajustarse bien.

• Sensibilidad en frecuencias bajas: cuando el ruido está muy cerca de la frecuencia cero (DC), su separación respecto a la información útil se complica, pudiendo introducir pérdidas de detalle.

• Ruido de alta frecuencia: no aborda el ruido aleatorio fino ni patrones no periódicos.

• Confusión con detalles reales: si el patrón de ruido se parece a estructuras de la imagen (p. ej., líneas finas en la misma dirección), puede eliminar información válida o generar artefactos.

El algoritmo ofrece parámetros ajustables, como el tamaño de parche, el umbral de detección y el ancho del suavizado, que permiten optimizar su rendimiento según el tipo de imagen. Sin embargo, estos ajustes deben hacerse con cuidado, especialmente cuando se intenta eliminar frecuencias cercanas a DC, donde existe

7. Resultados

Derecha: imagen original, Centro: image resultante, Izquierda: ruido filtrado.

8. Conclusiones

El filtrado automático de ruido cuasiperiódico mediante análisis estadístico del espectro promedio ofrece una alternativa potente a los métodos manuales tradicionales. Su capacidad para identificar picos espurios sin intervención humana lo convierte en una herramienta ideal para flujos de trabajo donde se procesan grandes volúmenes de imágenes.

Si bien no es infalible —especialmente en escenas no naturales o cuando el ruido se confunde con detalles reales—, en la mayoría de los casos logra un equilibrio eficaz entre limpieza y preservación de la información visual. Además, su naturaleza adaptativa le permite enfrentarse a patrones complejos y distribuciones irregulares de ruido que serían tediosas de manejar de forma manual.

bibliografía

Frédéric Sur and Michel Grediac "Automated removal of quasiperiodic noise using frequency domain statistics," Journal of Electronic Imaging 24(1), 013003 (11 February 2015). https://doi.org/10.1117/1.JEI.24.1.013003

Este enfoque aprovecha una propiedad fundamental de la teoría de señales: el teorema de convolución circular, que establece que la convolución espacial entre dos señales es equivalente a la multiplicación de sus representaciones en frecuencia. Esto permite transformar una operación local —como un desenfoque— en una operación global pero computacionalmente eficiente. En el caso de imágenes, esto significa que podemos aplicar un filtro multiplicando espectros, para luego recuperar la imagen filtrada mediante la transformada inversa.

Además de la eficiencia, una de las grandes ventajas del dominio frecuencial es la intuitividad en el diseño de filtros. Es más sencillo entender cómo un filtro afecta una imagen al observar su respuesta en frecuencia que al inspeccionar directamente los valores de un kernel en el espacio. Esta perspectiva permite crear filtros como el pasa-bajos ideal, el filtro de Butterworth, o el filtro homomórfico, cada uno con aplicaciones específicas que van desde la restauración de imágenes degradadas hasta el realce de detalles.

1. Fundamentos del Filtrado en el Dominio de la Frecuencia

1.1. Equivalencia entre convolución espacial y multiplicación frecuencial

Uno de los pilares del análisis en frecuencia es el teorema de la convolución, que establece una relación directa entre la convolución en el dominio espacial y la multiplicación en el dominio frecuencial. Formalmente, si se tiene una imagen g(x, y) y un filtro espacial h(x, y), su convolución se denota como:

$$g_r(x, y) = g(x, y) * h(x, y)$$

donde * representa la operación de convolución bidimensional. La Transformada de Fourier convierte esta operación en una simple multiplicación:

$$G_r(k_x, k_y) = G(k_x, k_y) \cdot H(k_x, k_y)$$

donde:

$$\begin{align*} G(k_x, k_y) & \quad \text{: transformada de Fourier de la imagen original}, \\ H(k_x, k_y) & \quad \text{: transformada de Fourier del kernel de filtrado}, \\ G_r(k_x, k_y) & \quad \text{: transformada de Fourier de la imagen resultante}. \end{align*}$$

Esta propiedad es especialmente útil porque muchas operaciones de convolución que en el dominio espacial requieren recorrer cada píxel y aplicar un kernel local, en el dominio de la frecuencia se reducen a multiplicaciones punto a punto entre matrices de la misma dimensión.

Cabe mencionar que, debido a la naturaleza discreta y finita de las imágenes digitales, esta relación se da en términos de convolución circular. Para que la equivalencia sea válida en la práctica, es necesario aplicar relleno con ceros (zero-padding) antes de transformar las imágenes, de modo que se eviten artefactos de aliasing o envolvimiento (wrapping) al realizar la multiplicación en frecuencia.

def ApplyFrequencyDomainFilter(image, kernel):
    """
    Applies a frequency domain filter to a grayscale image.

    This function computes the 2D Fourier Transform of the input image, applies the given filter 
    in the frequency domain, and then performs the inverse Fourier Transform to return the filtered image.

    Parameters:
    ----------
    image : np.ndarray
        Input grayscale image (2D numpy array).

    kernel : np.ndarray
        Frequency domain filter (2D numpy array) with the same shape as the input image.

    Returns:
    -------
    filtered_image : np.ndarray
        Filtered image (uint8) normalized to the range [0, 255].

    Notes:
    -----
    - The input image is assumed to be in grayscale format.
    - The kernel should be designed in the frequency domain and have the same dimensions as the input image.
    - The output image is normalized to ensure proper visualization.
    """
    # Compute the 2D Fourier Transform of the image
    f = np.fft.fft2(image)
    fshift = np.fft.fftshift(f)  # Shift zero frequency to the center

    # Apply the filter in the frequency domain
    filtered_freq = fshift * kernel

    # Compute the inverse Fourier Transform to return to the spatial domain
    temp = np.abs(np.fft.ifft2(np.fft.ifftshift(filtered_freq)))

    # Normalize the result to the range [0, 255] and convert to uint8
    filtered_image = cv.normalize(temp, None, 0, 255, cv.NORM_MINMAX)
    filtered_image = np.uint8(filtered_image)

    return filtered_image

Esta equivalencia no solo es una herramienta matemática elegante, sino que fundamenta toda una clase de técnicas de filtrado frecuencial utilizadas tanto en restauración como en mejoramiento de imágenes.

1.2. Ventajas del dominio frecuencial

El filtrado en el dominio de la frecuencia presenta ventajas claras sobre el filtrado espacial en ciertos contextos:

• Diseño intuitivo de filtros: En el dominio espacial, los kernels de convolución pueden parecer arbitrarios o difíciles de interpretar. Por el contrario, en el dominio de la frecuencia, los filtros se diseñan directamente en función de las componentes espectrales que se desean atenuar o resaltar. Por ejemplo, un filtro pasa-bajos simplemente bloquea las frecuencias altas que corresponden a detalles finos o ruido, mientras deja pasar las bajas frecuencias responsables de las estructuras globales.

• Eficiencia computacional con kernels grandes: Aunque la Transformada de Fourier y su inversa requieren procesamiento adicional, la Transformada Rápida de Fourier (FFT) permite implementaciones altamente eficientes. Cuando el kernel de convolución es grande, realizar una convolución directa en el dominio espacial tiene un costo computacional de Ο(N² M²) para una imagen de tamaño N × N y un kernel de tamaño M × M. En cambio, la transformación a frecuencia, multiplicación espectral y reconversión por FFT se realiza en Ο(N² log N), lo cual es más eficiente para kernels grandes.

Sin embargo, es importante notar que esta ventaja se diluye para kernels pequeños (por ejemplo, de 3x3 o 5x5), donde la convolución directa en el dominio espacial puede ser más rápida. Además, muchas aplicaciones modernas utilizan enfoques multiescala o convoluciones separables que reducen el costo espacial sin necesidad de transformarse al dominio frecuencial.

2. Tipos de Filtrado y Aplicaciones

El filtrado en el dominio de la frecuencia permite realizar tanto restauración como mejoramiento de imágenes. Dependiendo de cómo se diseñe la respuesta en frecuencia del filtro, se pueden atenuar detalles finos, resaltar bordes, eliminar ruido o incluso modificar propiedades de iluminación. A continuación se describen los tipos más comunes de filtros frecuenciales, sus fundamentos matemáticos y sus aplicaciones prácticas.

2.1. Restauración vs. Mejoramiento

Es importante distinguir entre dos objetivos principales del filtrado:

• Restauración: Busca reconstruir la imagen original eliminando distorsiones o ruido que hayan degradado la calidad de la imagen. Este tipo de filtrado suele requerir una estimación del proceso de degradación (modelo del sistema de adquisición o transmisión) y es más común en aplicaciones científicas o médicas.

• Mejoramiento (enhancement): No busca recuperar una "verdadera imagen", sino hacerla más útil para una tarea específica, como mejorar la visibilidad de bordes, estructuras o texturas. Es frecuente en aplicaciones de visión artificial y fotografía.

Ambos enfoques pueden beneficiarse del análisis en frecuencia, ya que permiten aislar las escalas o rangos espectrales relevantes a la tarea.

2.2. Filtros Pasa-Bajos (Lowpass)

Los filtros pasa-bajos permiten el paso de las bajas frecuencias y atenúan las altas. Su función principal es suavizar la imagen, reduciendo el ruido o eliminando detalles finos.

Filtro ideal

La versión más simple y teóricamente pura es el filtro pasa-bajos ideal, definido en el dominio de la frecuencia como:

$$H_{\text{ideal}}(f)| = \begin{cases} 1, & \text{si } |f| \leq f_c \\ 0, & \text{si } |f| > f_c \end{cases}$$

donde fc es la frecuencia de corte. Este filtro elimina completamente todas las frecuencias por encima de fc. Sin embargo, su implementación práctica es problemática: la transformada inversa de este filtro da lugar a una función sinc en el dominio espacial, que se extiende infinitamente y presenta efectos de oscilación (ringing) debido al fenómeno de Gibbs.

def CreateIdealLowpassFilter(shape, cutoff_frequency):
    """
    Creates an ideal low-pass filter kernel in the frequency domain.

    Parameters:
    ----------
    shape : tuple
        Shape of the filter (rows, cols), typically matching the image dimensions.
    cutoff_frequency : float
        Cutoff frequency for the low-pass filter.

    Returns:
    -------
    filter_kernel : np.ndarray
        Ideal low-pass filter kernel as a 2D numpy array.
    """
    rows, cols = shape
    crow, ccol = rows // 2, cols // 2
    Y, X = np.ogrid[:rows, :cols]
    distance = np.sqrt((X - ccol)**2 + (Y - crow)**2)

    # Ideal low-pass filter formula
    filter_kernel = distance <= cutoff_frequency
    return filter_kernel.astype(np.float32)

Filtro Gaussiano

Una alternativa más suave es el filtro gaussiano, cuya respuesta en frecuencia está dada por:

$$H_{\text{gauss}}(f)| = e^{-\frac{f^2}{2\sigma^2}}$$

Este filtro tiene la ventaja de no presentar ringing y de ser separable (puede aplicarse por filas y columnas), lo cual lo hace computacionalmente eficiente. Sin embargo, su desventaja es su transición suave, lo que implica un menor control sobre las frecuencias que se atenúan o conservan.

def CreateGaussianLowpassFilter(shape, cutoff_frequency):
    """
    Creates a Gaussian low-pass filter kernel in the frequency domain.

    Parameters:
    ----------
    shape : tuple
        Shape of the filter (rows, cols), typically matching the image dimensions.
    cutoff_frequency : float
        Cutoff frequency for the low-pass filter.

    Returns:
    -------
    filter_kernel : np.ndarray
        Gaussian low-pass filter kernel as a 2D numpy array.
    """
    rows, cols = shape
    crow, ccol = rows // 2, cols // 2
    Y, X = np.ogrid[:rows, :cols]
    distance = np.sqrt((X - ccol)**2 + (Y - crow)**2)

    # Gaussian low-pass filter formula
    filter_kernel = np.exp(-(distance**2) / (2 * (cutoff_frequency**2)))
    return filter_kernel.astype(np.float32)

Filtro de Butterworth

Este filtro busca un compromiso entre la transición abrupta del filtro ideal y la suavidad del gaussiano. Su respuesta está definida como:

$$H_{\text{bw}}(f)| = \frac{1}{1 + \left( \frac{f}{f_c} \right)^{2n}}$$

donde n es el orden del filtro, que controla la pendiente de la caída en la banda de transición. Es conocido como un filtro "máximamente plano", ya que no presenta ondulaciones (ripple) en la banda pasante.

def CreateButterworthLowpassFilter(shape, cutoff_frequency, order):
    """
    Creates a Butterworth low-pass filter kernel in the frequency domain.

    Parameters:
    ----------
    shape : tuple
        Shape of the filter (rows, cols), typically matching the image dimensions.
    cutoff_frequency : float
        Cutoff frequency for the low-pass filter.
    order : int
        Order of the Butterworth filter, controlling the sharpness of the transition.

    Returns:
    -------
    filter_kernel : np.ndarray
        Butterworth low-pass filter kernel as a 2D numpy array.
    """
    rows, cols = shape
    crow, ccol = rows // 2, cols // 2
    Y, X = np.ogrid[:rows, :cols]
    distance = np.sqrt((X - ccol)**2 + (Y - crow)**2)

    # Butterworth low-pass filter formula
    filter_kernel = 1 / (1 + (distance / (cutoff_frequency + 1e-5))**(2 * order))  # Avoid division by zero
    return filter_kernel.astype(np.float32)

Filtro de Lanczos

El filtro de Lanczos surge principalmente en tareas de reescalado de imágenes y reconstrucción, y está basado en una ventana truncada de la función sinc:

$$h(x) = \text{sinc}(x) \cdot \text{sinc}\left(\frac{x}{a}\right)$$

donde a es un parámetro que controla el ancho de la ventana. En frecuencia, ofrece una buena supresión de aliasing con una transición más nítida que el gaussiano, pero con menor ringing que el filtro ideal.

def CreateLanczosLowpassFilter(shape, cutoff_frequency, a=3):
    """
    Creates a Lanczos low-pass filter kernel in the frequency domain.

    Parameters:
    ----------
    shape : tuple
        Shape of the filter (rows, cols), typically matching the image dimensions.
    cutoff_frequency : float
        Frequency scaling factor (controls sharpness).
    a : int
        Lanczos window parameter (commonly 2 or 3). Larger values = narrower main lobe.

    Returns:
    -------
    filter_kernel : np.ndarray
        Lanczos low-pass filter kernel as a 2D numpy array.
    """
    rows, cols = shape
    crow, ccol = rows // 2, cols // 2

    # Coordenadas relativas al centro
    Y, X = np.ogrid[:rows, :cols]
    dx = X - ccol
    dy = Y - crow
    radius = np.sqrt(dx**2 + dy**2)

    # Normalizar el radio para hacerlo compatible con el parámetro a
    x = (radius / cutoff_frequency).astype(np.float32)

    # sinc(x) = sin(pi x) / (pi x), definida como 1 en x = 0
    def sinc(z):
        z = np.where(z == 0, 1e-8, z)  # evitar división por cero
        return np.sin(np.pi * z) / (np.pi * z)

    # Kernel de Lanczos en 2D: sinc(x) * sinc(x/a)
    lanczos_kernel = sinc(x) * sinc(x / a)

    # Forzar ceros fuera de la ventana a
    lanczos_kernel[x > a] = 0

    return lanczos_kernel.astype(np.float32)

2.3 Filtrado de Imágenes a Color en el Dominio de la Frecuencia

Al extender el filtrado en el dominio de la frecuencia a imágenes a color, una estrategia directa consiste en aplicar el mismo filtro frecuencial a cada canal (B, G, R) de forma independiente. La función ApplyFrequencyDomainFilterBGR realiza exactamente esto: procesa por separado cada componente de color, aplica el filtro en frecuencia y luego los vuelve a combinar. Aunque este método es sencillo y coherente con el filtrado en escala de grises, puede introducir ligeras distorsiones de color, ya que cada canal se modifica sin considerar su relación perceptual con los otros. Para evitar este problema, se pueden utilizar espacios de color alternativos como Lab o HSV, en los que se aplica el filtrado únicamente sobre el componente de luminancia, preservando así mejor la fidelidad del color original.

def ApplyFrequencyDomainFilterBGR(image_bgr, kernel):
    """
    Applies a frequency domain filter to each BGR channel of a color image independently.

    Parameters:
        image_bgr : np.ndarray
            Input color image (H x W x 3) in uint8 format.

        kernel : np.ndarray
            Frequency domain filter (2D array) of shape (H, W).

    Returns:
        np.ndarray:
            Filtered BGR image (uint8), same size as input.
    """
    if image_bgr.ndim != 3 or image_bgr.shape[2] != 3:
        raise ValueError("Input image must be BGR (H x W x 3).")

    filtered_channels = []
    for c in range(3):
        channel = image_bgr[:, :, c]
        filtered = ApplyFrequencyDomainFilter(channel, kernel)
        filtered_channels.append(filtered)

    return cv.merge(filtered_channels)

2.4. Filtros Pasa-Altos (Highpass)

Los filtros pasa-altos cumplen la función opuesta a los pasa-bajos: atenúan las bajas frecuencias (responsables de estructuras suaves y cambios graduales) y conservan o enfatizan las altas frecuencias, que suelen corresponder a bordes, texturas finas y detalles locales.

Una forma directa de obtener un filtro pasa-alto es restar un filtro pasa-bajo de una función constante:

$$H_{\text{highpass}}(f)| = 1 - |H_{\text{lowpass}}(f)$$

Esto permite generar versiones pasa-altas correspondientes a cualquier diseño pasa-bajo conocido, como los ideales, gaussianos o Butterworth.

Filtro Ideal

Similar al caso pasa-bajo, el filtro pasa-alto ideal se define como:

$$H_{\text{highpass}}(f)| = 1 - |H_{\text{lowpass}}(f)$$

En el dominio espacial, este filtro genera oscilaciones significativas (ringing) alrededor de los bordes y también se ve afectado por el fenómeno de Gibbs, por lo que rara vez se implementa directamente.

def CreateIdealHighpassFilter(shape, cutoff_frequency):
    """
    Creates an ideal high-pass filter kernel in the frequency domain.

    Parameters:
        shape : tuple
            Shape of the filter (rows, cols), typically matching the image dimensions.
        cutoff_frequency : float
            Cutoff frequency for the high-pass filter.

    Returns:
        filter_kernel : np.ndarray
            Ideal high-pass filter kernel as a 2D numpy array.
    """

    rows, cols = shape
    crow, ccol = rows // 2, cols // 2
    Y, X = np.ogrid[:rows, :cols]
    distance = np.sqrt((X - ccol)**2 + (Y - crow)**2)

    # Ideal high-pass filter formula
    filter_kernel = distance > cutoff_frequency
    return filter_kernel.astype(np.float32)

Filtro Gaussiano

La versión pasa-alta del filtro gaussiano se obtiene de manera complementaria:

$$H_{\text{gauss-high}}(f)| = 1 - e^{-\frac{f^2}{2\sigma^2}}$$

Este filtro es útil para detectar bordes suaves o graduales, especialmente cuando se requiere evitar artefactos de sobre-resaltado.

def CreateGaussianHighpassFilter(shape, cutoff_frequency):
    """
    Creates a Gaussian high-pass filter kernel in the frequency domain.

    Parameters:
        shape : tuple
            Shape of the filter (rows, cols), typically matching the image dimensions.
        cutoff_frequency : float
            Cutoff frequency for the high-pass filter.

    Returns:
        filter_kernel : np.ndarray
            Gaussian high-pass filter kernel as a 2D numpy array.
    """
    rows, cols = shape
    crow, ccol = rows // 2, cols // 2
    Y, X = np.ogrid[:rows, :cols]
    distance = np.sqrt((X - ccol)**2 + (Y - crow)**2)

    # Gaussian high-pass filter formula
    lowpass_kernel = np.exp(-(distance**2) / (2 * (cutoff_frequency**2)))
    highpass_kernel = 1 - lowpass_kernel
    return highpass_kernel.astype(np.float32)

Filtro de Butterworth

El filtro pasa-alto de Butterworth se define como:

$$H_{\text{bw}}(f)| = \frac{1}{1 + \left( \frac{f_c}{f} \right)^{2n}}$$

Este diseño, con su control por orden n, permite ajustar finamente el compromiso entre nitidez y estabilidad numérica. A diferencia del filtro ideal, el de Butterworth presenta una transición continua y suave, evitando oscilaciones excesivas.

def CreateButterworthHighpassFilter(shape, cutoff_frequency, order):
    """
    Creates a Butterworth high-pass filter kernel in the frequency domain.

    Parameters:
        shape : tuple
            Shape of the filter (rows, cols), typically matching the image dimensions.
        cutoff_frequency : float
            Cutoff frequency for the high-pass filter.
        order : int
            Order of the Butterworth filter, controlling the sharpness of the transition.

    Returns:
        filter_kernel : np.ndarray
            Butterworth high-pass filter kernel as a 2D numpy array.
    """
    rows, cols = shape
    crow, ccol = rows // 2, cols // 2
    Y, X = np.ogrid[:rows, :cols]
    distance = np.sqrt((X - ccol)**2 + (Y - crow)**2)

    # Butterworth high-pass filter formula
    filter_kernel = 1 / (1 + (cutoff_frequency / (distance + 1e-5))**(2 * order))  # Avoid division by zero
    return filter_kernel.astype(np.float32)

Aplicaciones

Los filtros pasa-altos son esenciales en tareas como:

• Detección de bordes: Las transiciones abruptas en la intensidad de la imagen se traducen en frecuencias altas, que estos filtros conservan o acentúan. Aunque los métodos espaciales como Sobel o Laplaciano son comunes, los enfoques frecuenciales permiten un control más preciso de la respuesta espectral.

• Realce de detalles (Detail Enhancement): Al aplicar un filtro pasa-alto y sumarlo nuevamente a la imagen original, se pueden enfatizar detalles sin perder información global. Esta técnica es la base del enmascaramiento no agudo y otras estrategias de mejora visual.

2.5. Filtros Pasa-Banda (Bandpass)

Los filtros pasa-banda están diseñados para aislar un rango específico de frecuencias, bloqueando tanto las bajas como las altas. Son útiles cuando se desea conservar estructuras que se encuentren a una escala intermedia, ignorando patrones demasiado gruesos o demasiado finos.

Una implementación clásica de filtro pasa-banda se logra como la diferencia entre un filtro pasa-bajo y un filtro pasa-alto con distintas frecuencias de corte. Pero existen también filtros diseñados directamente para resaltar componentes de ciertas frecuencias, como el Laplaciano de Gaussiano y técnicas de enmascaramiento no agudo.

Filtro Laplaciano de Gaussiano (LoG)

El filtro LoG surge de la combinación de dos operaciones: suavizado mediante un filtro gaussiano, seguido por la aplicación del operador Laplaciano (segunda derivada). Aunque originalmente se define en el dominio espacial, también tiene una expresión directa en frecuencia:

$$H_{\text{LoG}}(f)| = -f^2 \cdot e^{-\frac{f^2}{2f_c^2}}$$

Este filtro actúa como un detector de bordes, pero a diferencia de los filtros pasa-altos convencionales, resalta frecuencias intermedias y suprime tanto bajas como altas. De ahí su naturaleza pasa-banda.

• La parte f² enfatiza componentes de frecuencia creciente.

• El término exponencial atenúa frecuencias más allá del umbral fc.

Este filtro también es isotrópico (invariante a rotaciones) y ampliamente utilizado en visión por computadora y reconocimiento de patrones, como en la detección de blobs.

def CreateLaplacianOfGaussianFilter(shape, cutoff_freq):
    """
    Create a Laplacian of Gaussian (LoG) filter in the frequency domain.

    Parameters:
        shape        : tuple, (height, width) of the image
        cutoff_freq  : float, frequency cutoff (f_c) that controls the Gaussian spread

    Returns:
        log_filter   : 2D numpy array with the filter in the frequency domain
    """
    rows, cols = shape
    cy, cx = rows // 2, cols // 2

    # Create frequency grids centered at (0,0)
    u = np.fft.fftfreq(cols).reshape(1, -1)
    v = np.fft.fftfreq(rows).reshape(-1, 1)

    # Shift the frequency grids so that (0,0) is at the center
    u = np.fft.fftshift(u)
    v = np.fft.fftshift(v)

    # Compute squared frequency radius: f^2 = u^2 + v^2
    f_squared = u**2 + v**2

    # Laplacian of Gaussian filter in frequency domain
    log_filter = -4 * (np.pi**2) * f_squared * np.exp(-f_squared / (2 * (cutoff_freq ** 2)))

    return log_filter

Enmascaramiento no agudo (Unsharp Masking)

A pesar de su nombre, el enmascaramiento no agudo (unsharp masking) es una técnica para agudizar (realzar) los detalles de una imagen. Su funcionamiento se basa en extraer las componentes de alta frecuencia y sumarlas de nuevo a la imagen original:

$$g_{\text{realzada}}(x, y) = g(x, y) + \alpha \cdot \left[g(x, y) - g_{\text{suavizada}}(x, y)\right]$$

Este esquema puede verse como:

$$g_{\text{realzada}} = (1 + \alpha) \cdot g - \alpha \cdot (g * h)$$

donde h es un filtro pasa-bajo (por ejemplo, Gaussiano) y α un parámetro de realce.

En frecuencia, esta operación corresponde a aplicar un filtro con respuesta:

$$H_{\text{unsharp}}(f) = 1 + \alpha \cdot \left[1 - H_{\text{lowpass}}(f)\right]$$

Esto da como resultado una respuesta pasa-banda modificada, que enfatiza un rango intermedio de frecuencias con ganancia ajustable.

• Ventajas: control preciso sobre el nivel de realce.

• Aplicaciones: mejora de detalles en imágenes médicas, documentos escaneados, o fotografía digital.

def CreateUnsharpMaskingFilter(shape, cutoff_freq, alpha=1.0, method='gaussian'):
    """
    Create an unsharp masking filter in the frequency domain.

    Parameters:
        shape        : tuple, (height, width) of the image
        cutoff_freq  : float, cutoff frequency for the lowpass component
        alpha        : float, sharpening factor (>0)
        method       : str, type of lowpass ('gaussian', 'ideal', 'butterworth')

    Returns:
        H_unsharp    : 2D numpy array with the unsharp masking filter
    """
    if method == 'gaussian':
        H_lowpass = CreateGaussianLowpassFilter(shape, cutoff_freq)
    elif method == 'ideal':
        H_lowpass = CreateIdealLowpassFilter(shape, cutoff_freq)
    elif method == 'butterworth':
        H_lowpass = CreateButterworthLowpassFilter(shape, cutoff_freq, order=2)
    else:
        raise ValueError("Unsupported method. Choose 'gaussian', 'ideal', or 'butterworth'.")

    # Unsharp masking filter: H_unsharp(f) = 1 + alpha * (1 - H_lowpass(f))
    H_unsharp = 1 + alpha * (1 - H_lowpass)

    return H_unsharp

2.6. Filtrado Homomórfico

En muchas imágenes del mundo real, especialmente en condiciones de iluminación natural, la intensidad registrada por el sensor es una combinación de dos factores principales:

• Iluminación (L(x, y)): una componente de variación lenta, asociada con las condiciones externas de luz, sombras suaves y gradientes globales.

• Reflectancia (R(x, y)): una componente de variación rápida, relacionada con los detalles locales, texturas y estructuras intrínsecas de la escena.

El modelo multiplicativo que describe esta relación es:

$$E(x, y) = L(x, y) \cdot R(x, y)$$

Este modelo es problemático para el análisis frecuencial directo, ya que la Transformada de Fourier no maneja productos de funciones de forma directa. Para resolver esto, el filtrado homomórfico transforma el modelo multiplicativo en uno aditivo mediante un logaritmo:

$$log E(x, y) = \log L(x, y) + \log R(x, y)$$

Una vez en esta forma, es posible aplicar un filtro frecuencial que suprima las bajas frecuencias (iluminación) y preserve o realce las altas (reflectancia). Típicamente, se utiliza un filtro pasa-alto suave o un filtro pasa-banda con énfasis controlado.

Proceso general:

1. Aplicar logaritmo a la imagen:

   $$s(x, y) = \log E(x, y)$$

2. Transformar al dominio de la frecuencia:

   $$S(k_x, k_y) = \mathcal{F}{s(x, y)}$$

3. Aplicar un filtro H(kₓ , ky) que atenúe las bajas frecuencias:

   $$S_r(k_x, k_y) = S(k_x, k_y) \cdot H(k_x, k_y)$$

4. Transformar de regreso al dominio espacial e invertir el logaritmo:

   $$E_r(x, y) = \exp\left(\mathcal{F}^{-1}{S_r(k_x, k_y)}\right)$$

Resultados y aplicaciones

• Realce de detalles en sombras: al atenuar la iluminación global, se pueden destacar detalles que de otro modo quedarían ocultos.

• Compensación de iluminación desigual: muy útil en imágenes médicas, fotografía artística y escaneos de documentos.

• Preprocesamiento para segmentación: al normalizar variaciones de iluminación, se mejora la robustez de algoritmos posteriores.

La clave del filtrado homomórfico está en elegir adecuadamente el filtro H(kₓ, ky), que suele tener forma de filtro pasa-alto modulado:

$$H(k_x, k_y) = (\gamma_H - \gamma_L) \cdot \left[1 - e^{-\frac{(k_x^2 + k_y^2)}{2\sigma^2}}\right] + \gamma_L$$

donde:

$$\begin{align*} \gamma_L &< 1 \quad \text{: controla el nivel de atenuación de la iluminación}, \\ \gamma_H &> 1 \quad \text{: define el realce de detalles}, \\ \sigma &\quad \text{: regula la transición entre bandas}. \end{align*}$$

def HomomorphicFilterLab(bgr_img: np.ndarray, gammaL=0.5, gammaH=1.5, sigma=30) -> np.ndarray:
    """
    Applies homomorphic filtering to the L (lightness) channel of a BGR image using the CIELAB color space.

    Parameters:
        bgr_img : np.ndarray
            Input image in BGR format (as used by OpenCV), with dtype uint8 and shape (H, W, 3).
        gammaL : float
            Gain for low frequencies (<1, suppresses illumination).
        gammaH : float
            Gain for high frequencies (>1, enhances details).
        sigma : float
            Controls the transition between low and high frequencies.

    Returns:
        np.ndarray:
            BGR image after homomorphic filtering on the luminance channel (dtype uint8, same shape as input).
    """

    # Convert to LAB color space
    lab = cv.cvtColor(bgr_img, cv.COLOR_BGR2LAB)
    l, a, b = cv.split(lab)

    # Convert L to float32 and scale to [0, 255] if necessary (OpenCV stores L in [0, 255] already)
    l_float = l.astype(np.float32)

    # Step 1: Log-transform
    log_l = np.log1p(l_float)

    # Step 2: DFT (centered)
    dft = np.fft.fft2(log_l)
    dft_shift = np.fft.fftshift(dft)

    # Step 3: Homomorphic filter in frequency domain
    rows, cols = l.shape
    u = np.arange(-cols//2, cols//2)
    v = np.arange(-rows//2, rows//2)
    U, V = np.meshgrid(u, v)
    D2 = U**2 + V**2
    H = (gammaH - gammaL) * (1 - np.exp(-D2 / (2 * sigma**2))) + gammaL

    # Step 4: Apply filter
    filtered_dft = dft_shift * H

    # Step 5: Inverse DFT
    inv_dft = np.fft.ifft2(np.fft.ifftshift(filtered_dft))
    inv_dft = np.real(inv_dft)

    # Step 6: Inverse log
    l_filtered = np.expm1(inv_dft)

    # Normalize and clip to [0, 255]
    l_filtered = np.clip(l_filtered, 0, 255).astype(np.uint8)

    # Merge back and convert to BGR
    lab_filtered = cv.merge([l_filtered, a, b])
    bgr_result = cv.cvtColor(lab_filtered, cv.COLOR_LAB2BGR)

    return bgr_result

3. Limitaciones y Alternativas

Aunque el filtrado en el dominio de la frecuencia ofrece herramientas poderosas para modificar, restaurar o mejorar imágenes, no está exento de limitaciones. En esta sección se abordan los principales desafíos asociados a esta técnica, así como algunas alternativas o extensiones que intentan superarlos.

3.1. Límite de Gabor y Localización Tiempo-Frecuencia

Un principio fundamental en el análisis de señales es que no se puede lograr simultáneamente una alta resolución en el dominio espacial y en el dominio frecuencial. Esta idea se expresa en el llamado límite de Gabor, una manifestación de la desigualdad de Heisenberg adaptada al procesamiento de señales:

$$\sigma_x \cdot \sigma_f \geq \frac{1}{4\pi}$$

donde:

$$\begin{align*} \sigma_x &= \text{Dispersión (ancho) en el dominio espacial}, \\ \sigma_f &= \text{Dispersión en el dominio de la frecuencia}. \end{align*}$$

Este límite implica que al utilizar la Transformada de Fourier clásica, se pierde completamente la información de localización espacial: sabemos qué frecuencias están presentes, pero no dónde ocurren. Esto es suficiente para imágenes globalmente estacionarias, pero no para patrones locales o texturas que cambian en distintas regiones.

Ejemplo ilustrativo:

En procesamiento de audio, una señal musical puede analizarse en frecuencia, pero con la Transformada de Fourier tradicional no se puede saber cuándo suenan ciertas notas, solo que están presentes. En imágenes, ocurre algo similar: podemos detectar ciertas frecuencias, pero no identificar en qué zonas específicas se encuentran.

Alternativas:

Para superar esta limitación, se han desarrollado métodos que permiten un compromiso mejor entre resolución espacial y frecuencial. Algunas de las alternativas más relevantes son:

• Transformada de Fourier de ventana (STFT): Aplica la transformada a segmentos locales de la imagen, lo que permite una cierta localización espacial. Sin embargo, la resolución está limitada por el tamaño fijo de la ventana.

• Transformadas multiescala (como wavelets): Proveen una descomposición jerárquica con mejor adaptabilidad. Las wavelets permiten una buena localización espacial para frecuencias altas y una buena localización frecuencial para frecuencias bajas, lo cual es ideal para imágenes con estructuras a múltiples escalas.

• Filtros de Gabor: Son versiones localizadas en espacio y frecuencia de la transformada de Fourier. Ofrecen una excelente representación para texturas y patrones periódicos en distintas orientaciones y escalas, a costa de mayor complejidad computacional.

Conclusión

El filtrado en el dominio de la frecuencia ofrece una perspectiva poderosa y elegante para el procesamiento de imágenes. A diferencia de los métodos espaciales, permite analizar y modificar el contenido de una imagen según la escala y complejidad de sus estructuras internas, revelando patrones que no siempre son evidentes en el dominio de los píxeles.

A lo largo del artículo hemos visto cómo, gracias al teorema de la convolución circular, es posible transformar una operación costosa como la convolución espacial en una multiplicación eficiente en frecuencia. Esto abre la puerta a filtros intuitivos, como los pasa-bajos, pasa-altos, pasa-banda y homomórficos, cada uno con propiedades específicas y aplicaciones particulares.

También se destacó que, si bien el dominio frecuencial permite diseñar filtros globales con mayor control y eficiencia para kernels grandes, presenta limitaciones inherentes en la localización espacial. Por ello, en escenarios donde el contexto local es crítico —como en el análisis de texturas o en imágenes no estacionarias—, conviene considerar enfoques híbridos o alternativos como los filtros de Gabor o las transformadas wavelet.

El dominio de la frecuencia no solo amplía el repertorio de herramientas disponibles en el procesamiento de imágenes, sino que ofrece un marco teórico profundo para entender cómo fluye la información visual en distintos niveles de escala y complejidad. Conocerlo, y saber cuándo aplicarlo, es esencial para el diseño de sistemas robustos de análisis visual, compresión, restauración y mejora de calidad.

En el siglo XVI, Girolamo Cardano fue uno de los primeros en abordar estos problemas desde una perspectiva sistemática. Más adelante, en el siglo XVII, el matemático Christiaan Huygens escribió el primer tratado formal sobre el tema; Aquel impulso inicial —entender cómo apostar de forma más justa— dio origen a una teoría que ha crecido en profundidad y alcance. De los dados y las cartas, la probabilidad pasó a convertirse en un marco sólido para describir fenómenos aleatorios en física, ingeniería, biología y economía.

Sin embargo, los principios fundamentales siguen siendo los mismos**.** La intuición frente a lo aleatorio sigue poniéndose a prueba, incluso en situaciones simples. Imagina que entras a un casino y comienzas a apostar en un juego de dados. Tras veinte tiradas consecutivas, el resultado ha sido siempre el número 7. ¿Esa secuencia sería suficiente para que te retires, pensando que algo no anda bien? ¿O seguirías jugando, confiando en que, aunque improbable, es un evento posible?

Podrías basar tu decisión en una corazonada… o en un razonamiento más estructurado: ¿qué tan probable es que algo así ocurra por puro azar?

Conceptos clave.

En el campo de la estadística, el punto de partida es el análisis de fenómenos aleatorios que se manifiestan durante experimentos planificados o investigaciones científicas. Estos fenómenos suelen registrarse como datos, ya sean numéricos —como el número de accidentes en una intersección— o categóricos —como la clasificación de productos defectuosos en una línea de producción . Lo esencial es que cada unidad de información recogida en el proceso se denomina observación.

Una observación puede representar tanto una medición cuantitativa como una categoría cualitativa. Por ejemplo, los números 2, 0, 1 y 2 pueden representar el número de accidentes registrados mes a mes en una misma localización, mientras que las letras D y N podrían indicar si ciertos productos inspeccionados resultaron “defectuosos” o “no defectuosos”. En ambos casos, se trata de observaciones que conforman el insumo primario del análisis estadístico.

Para describir el proceso mediante el cual se generan estas observaciones, se utiliza el término experimento. En estadística, un experimento no se limita a entornos controlados como los de laboratorio. Puede tratarse de un evento tan simple como lanzar una moneda o tan complejo como medir la velocidad de un proyectil o recolectar opiniones sobre una política pública. Lo relevante es que cada repetición del experimento produce un resultado que, aunque no puede conocerse con certeza de antemano, conocemos el conjunto completo de posibilidades.

Dado que los resultados de muchos experimentos dependen del azar, la repetición bajo condiciones similares no garantiza la obtención del mismo resultado. Esta variabilidad es precisamente lo que da sentido al uso de herramientas probabilísticas en estadística. Incluso procesos aparentemente simples, como el lanzamiento de una moneda, revelan una estructura subyacente al observarse repetidamente.

Es importante aclarar que el término experimento se aplica de manera general en estadística, incluso en contextos donde no hay manipulación activa de variables. Los estudios observacionales, en los que solo se registran datos sin intervenir en el sistema, o los estudios retrospectivos, que analizan registros históricos, también generan observaciones sujetas a incertidumbre. Por lo tanto, estos casos también se consideran, en esencia, experimentos desde el punto de vista estadístico.

Espacio muestral.

Definición: Al conjunto de todos los resultados posibles de un experimento estadístico se le denomina espacio muestral, y suele representarse con la letra S.

Cada resultado individual dentro de este conjunto se conoce como punto muestral, aunque también puede llamarse elemento o miembro del espacio muestral. Cuando el espacio muestral contiene un número finito de resultados, es posible enumerarlos explícitamente, separándolos por comas y encerrándolos entre llaves.

Por ejemplo, si el experimento consiste en lanzar una moneda al aire, el espacio muestral correspondiente puede expresarse como: S={H, T} Donde H representa “cara” y T, “cruz”.

Ejemplo: Considere el experimento de lanzar un dado. Si nos interesa el número que aparece en la cara superior, el espacio muestral se define como:

$$S_1 = \{1, 2, 3, 4, 5, 6\}$$

Sin embargo, si solo nos interesa saber si el número obtenido es par o impar, podemos definir un espacio muestral alternativo:

$$S_2 = \{\text{par}, \text{impar}\}$$

Este ejemplo ilustra que un mismo experimento puede describirse mediante distintos espacios muestrales, dependiendo del nivel de detalle que se desea capturar. En este caso, S₁ proporciona más información que S₂, ya que conocer el resultado en S₁ permite deducir el correspondiente en S₂​, pero no ocurre lo mismo en sentido contrario. Por lo tanto, en general, es preferible elegir un espacio muestral que conserve la mayor cantidad de información relevante sobre los posibles resultados del experimento.

Ejemplo: Imagina una bolsa que contiene tres bolas de colores diferentes: una roja, una azul y una verde. El experimento consiste en sacar las tres bolas una por una, sin devolverlas, y registrar la secuencia de colores en el orden en que salen.

El espacio muestral aquí está formado por todas las posibles secuencias ordenadas que se pueden obtener al extraer las bolas.

Por lo tanto, el espacio muestral S queda definido como el conjunto de todas las permutaciones de los colores:

$$S = \{ (\text{roja}, \text{azul}, \text{verde}),\ (\text{roja}, \text{verde}, \text{azul}),\ (\text{azul}, \text{roja}, \text{verde}),\ (\text{azul}, \text{verde}, \text{roja}),\ (\text{verde}, \text{roja}, \text{azul}),\ (\text{verde}, \text{azul}, \text{roja}) \}$$

Cada elemento de S representa una posible secuencia en la que pueden salir las bolas. Por ejemplo, la secuencia (azul,roja,verde) indica que primero salió la bola azul, luego la roja y finalmente la verde.

Cuando el espacio muestral contiene un gran número de elementos, o incluso es infinito, resulta inviable enumerar todos los posibles resultados. En estos casos, es más práctico describir el espacio muestral mediante una regla o enunciado que defina sus elementos.

Ejemplo 1: Consideremos un experimento donde seleccionamos al azar un número entero entre 1 y 1,000,000. En lugar de listar cada número, el espacio muestral se describe como

$$S = \{ x \mid x \text{ es un número entero tal que } 1 \leq x \leq 1{,}000{,}000 \}$$

Lo que se lee: “S es el conjunto de todos los números enteros x tales que x está entre 1 y 1,000,000 inclusive”.

Ejemplo 2: Ahora imaginemos un experimento en el que elegimos un punto aleatorio dentro de una línea de longitud 5 metros. El espacio muestral contiene todos los puntos sobre la línea, y se representa por

$$S = \{ x \mid 0 \leq x \leq 5 \}$$

Donde x indica la posición sobre la línea, medida en metros desde un extremo.

Estos ejemplos muestran cómo se pueden manejar espacios muestrales grandes o continuos usando una descripción matemática que delimita claramente los resultados posibles, sin necesidad de listarlos uno por uno.

Eventos

En cualquier experimento, a menudo nos interesa la ocurrencia de ciertos eventos más que la ocurrencia de un resultado específico dentro del espacio muestral. Un evento puede entenderse como un conjunto de resultados o puntos muestrales que cumplen una condición particular.

Por ejemplo, consideremos el experimento de lanzar un dado, cuyo espacio muestral es

$$S_1 = \{1, 2, 3, 4, 5, 6\}$$

Si nos interesa el evento A “el resultado es divisible entre 3”, este evento corresponde al subconjunto

$$A = \{3, 6 \} \subseteq S_1$$

Es decir, A contiene todos los puntos muestrales para los cuales la condición es verdadera.

Otro ejemplo puede surgir en la inspección de productos. Supongamos que se revisan tres artículos y cada uno puede ser “defectuoso” (D) o “no defectuoso” (N). El espacio muestral estará formado por todas las secuencias posibles de resultados, por ejemplo:

$$S = \{DDD, DDN, DND, DNN, NDD, NDN, NND, NNN\}$$

Donde cada secuencia representa el estado de los tres artículos inspeccionados. Si nos interesa el evento B: “más de un artículo es defectuoso”, entonces

$$B = \{DDD, DDN, DND, NDD\} \subseteq S$$

Es el subconjunto de secuencias en las cuales al menos dos artículos son defectuosos. A cada evento corresponde un subconjunto del espacio muestral que agrupa todos los resultados que hacen cierto el evento.

Definición: Un evento es un subconjunto del espacio muestral.

Complemento de un Evento

En muchos experimentos, es común analizar no solo la ocurrencia de un evento específico, sino también su complemento, es decir, todos los resultados que no pertenecen a ese evento.

Consideremos, por ejemplo, un estudio sobre los hábitos de tabaquismo entre los empleados de una empresa industrial. Un posible espacio muestral para clasificar a cada individuo podría ser:

$$S = \{\text{no fumador}, \text{fumador ocasional}, \text{fumador moderado}, \text{fumador empedernido}\}.$$

Si definimos el evento A como “ser fumador”, entonces

$$A = \{\text{fumador ocasional }, \text{fumador moderado}, \text{fumador empedernido}\} \subseteq S$$

El complemento de este evento, que denotaremos como Aᶜ, es el conjunto de todos los elementos del espacio muestral que no están en A. En este caso, corresponde al grupo de no fumadores:

$$A^c = \{\text{no fumador}\}.$$

Es decir, Aᶜ agrupa todos los resultados donde el evento A no ocurre.

Definición: El complemento de un evento A respecto del espacio muestral S es el subconjunto de todos los elementos de S que no pertenecen a A. Se denota como Aᶜ.

Operaciones con eventos

Una vez definidos los eventos como subconjuntos del espacio muestral, es natural preguntarse qué sucede cuando combinamos eventos. Existen operaciones entre eventos que permiten formar nuevos eventos, también representados como subconjuntos del mismo espacio muestral.

Intersección de eventos

Supongamos ahora que dos eventos, A y B, están asociados a un mismo experimento, es decir, son subconjuntos del mismo espacio muestral. En el lanzamiento de un dado, por ejemplo, podemos definir:

$$S = \{1, 2, 3, 4, 5, 6\}$$

$$A = \{2, 4, 6\} \quad \text{(número par)}, \quad B = \{4, 5, 6\} \quad \text{(número mayor que 3)}.$$

Los resultados que hacen que ambos eventos ocurran simultáneamente corresponden a los elementos comunes entre A y B, es decir: A ∩ B = {4, 6}.

Definición: La intersección de dos eventos A y B, denotada por A ∩ B, es el conjunto de todos los elementos que pertenecen simultáneamente a ambos eventos.

Ejemplo: Sea E el evento “la persona seleccionada al azar en un salón es estudiante de ingeniería”, y F el evento “la persona es mujer”. Entonces, la intersección E ∩ F representa el evento “la persona es una estudiante mujer de ingeniería”, es decir, aquellas personas que cumplen ambas condiciones.

Eventos mutuamente excluyentes

En algunos casos, dos eventos no pueden ocurrir al mismo tiempo. Por ejemplo, si definimos:

$$V = \{\text{a}, \text{e}, \text{i}, \text{o}, \text{u}\} \quad \text{(vocales)}, \quad C = \{\text{l}, \text{r}, \text{s}, \text{t}\} \quad \text{(ciertas consonantes)}$$

entonces

$$V \cap C = \varnothing$$

lo cual indica que no hay ningún elemento en común entre los dos conjuntos. En este caso, decimos que los eventos V y C son mutuamente excluyentes.

Definición: Dos eventos A y B son mutuamente excluyentes (o disjuntos) si:

$$A \cap B = \varnothing$$

Es decir, si no tienen ningún punto muestral en común y, por lo tanto, no pueden ocurrir al mismo tiempo.

Ejemplo: Imaginemos una empresa de televisión por cable que ofrece programación en 8 canales. La distribución es la siguiente:

• 3 canales afiliados a ABC

• 2 canales afiliados a NBC

• 1 canal afiliado a CBS

• 1 canal educativo

• 1 canal deportivo (ESPN)

Supongamos que un espectador enciende el televisor sin seleccionar un canal específico, es decir, se elige uno al azar. Definimos los siguientes eventos:

• A: “el canal pertenece a la cadena NBC”

• B: “el canal pertenece a la cadena CBS”

En este caso:

$$A = \{\text{Canal 4, Canal 5}\}, \quad B = \{\text{Canal 6}\}$$

Como ningún canal puede pertenecer a más de una cadena, los eventos A y B son disjuntos. Es decir: A∩B=∅ Por tanto, no hay intersección posible: un canal no puede ser de NBC y de CBS al mismo tiempo. Esto los convierte en eventos mutuamente excluyentes.

Unión de eventos

Hasta ahora, hemos explorado el complemento e intersección de eventos. Sin embargo, en muchos contextos prácticos estamos interesados en determinar si ocurre al menos uno de dos eventos. Este concepto se representa mediante la unión de eventos.

Ahora consideremos un ejemplo numérico más tradicional. Supongamos que lanzamos un dado, con espacio muestral:

S = {1, 2, 3, 4, 5, 6}

Definimos dos eventos:

• A = {2, 4, 6}: el número es par

• B = {4, 5, 6}: el número es mayor que 3

Queremos ahora describir el evento “ocurre A o ocurre B” (o ambos). Esto nos lleva a definir la unión:

$$A \cup B = \{2, 4, 5, 6\}$$

Definición: La unión de dos eventos A y B, denotada por A ∪ B, es el conjunto de todos los resultados que pertenecen a A, B o a ambos.

• A ∩ B: representa los resultados que satisfacen simultáneamente ambos eventos.

• A ∪ B: representa los resultados que satisfacen al menos uno de los eventos.

Ejemplo con código.

from matplotlib import pyplot as plt
from matplotlib_venn import venn3

# Definir tres conjuntos con más elementos
A = {'libro', 'computadora', 'papel', 'pluma', 'lápiz', 'borrador', 'regla'}
B = {'papel', 'teléfono', 'libro', 'cuaderno', 'marcador', 'regla', 'calculadora'}
C = {'computadora', 'cuaderno', 'papel', 'marcador', 'tijeras', 'lápiz'}

# Crear el conjunto universo (para ilustrar el complemento)
U = A.union(B).union(C)

# Crear el diagrama de Venn para tres conjuntos
venn = venn3([A, B, C], set_labels=('A', 'B', 'C'))

# Personalizar el diagrama de Venn
venn.get_label_by_id('100').set_text('Solo en A')
venn.get_label_by_id('010').set_text('Solo en B')
venn.get_label_by_id('001').set_text('Solo en C')
venn.get_label_by_id('110').set_text('A ∩ B')
venn.get_label_by_id('101').set_text('A ∩ C')
venn.get_label_by_id('011').set_text('B ∩ C')
venn.get_label_by_id('111').set_text('A ∩ B ∩ C')

# Mostrar el gráfico
plt.title("Operaciones entre conjuntos A, B y C")
plt.show()

# Imprimir operaciones adicionales
print("A ∪ B ∪ C =", A.union(B).union(C))
print("A ∩ B ∩ C =", A.intersection(B).intersection(C))
print("A - (B ∪ C) =", A.difference(B.union(C)))
print("B - A =", B.difference(A))
print("Complemento de C respecto al universo:", U.difference(C))
print("Elementos comunes entre A y B pero no en C:", (A & B) - C)

A ∪ B ∪ C = {'marcador', 'calculadora', 'tijeras', 'regla', 'computadora', 'teléfono', 'lápiz', 'libro', 'borrador', 'papel', 'cuaderno', 'pluma'}

A ∩ B ∩ C = {'papel'}

A - (B ∪ C) = {'borrador', 'pluma'}

B - A = {'cuaderno', 'marcador', 'teléfono', 'calculadora'}

Complemento de C respecto al universo: {'calculadora', 'regla', 'teléfono', 'libro', 'borrador', 'pluma'}

Elementos comunes entre A y B pero no en C: {'libro', 'regla'}

La probabilidad, al final, es una herramienta para dar forma numérica a la incertidumbre. Nos permite medir cuán confiable es un evento, y con ello, tomar decisiones más informadas en contextos donde el azar también juega su parte. Con estos conceptos fundamentales claros, ya estamos en condiciones de avanzar hacia ideas más abstractas y útiles dentro del estudio de la probabilidad.

English version of this article. Click here

Esta dificultad para anticipar su intensidad los hace destacar frente al resto de la imagen y, por tanto, son cruciales para describir su contenido. De hecho, incluso representaciones reducidas en forma de simples dibujos de líneas permiten a los humanos reconocer objetos y escenarios con notable facilidad. Este fenómeno muestra que los bordes de intensidad no solo son importantes en la percepción visual humana, sino también en los sistemas de visión por computadora, donde capturar correctamente estas transiciones es esencial para interpretar lo que hay en una imagen.

Entre los distintos tipos de bordes de intensidad —como los bordes escalón (step edges), de línea, de techo o rampa— los bordes escalón son los más comunes y representativos. En una dimensión, este tipo de borde se manifiesta como un valor elevado en la primera derivada de la señal. En dos dimensiones, esta idea se generaliza al concepto de gradiente: una medida vectorial que indica tanto la dirección como la intensidad del cambio en la imagen.

Si bien existen múltiples formas de estimar el gradiente mediante filtros como Sobel, Prewitt, Scharr o derivados de Gauss, obtener bordes claros y bien definidos requiere más que simplemente calcular derivadas. El algoritmo de Canny aborda esta necesidad con un enfoque robusto y refinado, y se ha convertido en una de las técnicas más utilizadas para la detección de bordes. Diseñado con criterios precisos —buena detección, localización exacta y mínima respuesta múltiple—, sigue siendo una referencia clave en segmentación, reconocimiento de patrones y análisis de escenas.

Etapas del algoritmo de detección de bordes tipo Canny

• Cálculo del gradiente de intensidad

  La imagen se suaviza mediante un filtro Gaussiano para reducir el ruido. Luego se calculan las derivadas parciales en las direcciones horizontal y vertical Gₓ y Gy, a partir de las cuales se obtiene:

  Magnitud del gradiente:

• $$G_{\text{mag}} = \sqrt{Gx^2 + Gy^2}$$

• Supresión de no-máximos con interpolación subpíxel

  Para conservar únicamente los bordes más significativos, se suprimen los valores que no son máximos locales en la dirección del gradiente. En lugar de discretizar esta dirección en pocos ángulos (como 0°, 45°, 90°, 135°), se realiza una interpolación lineal entre los píxeles vecinos a lo largo de la dirección exacta del gradiente. Esta aproximación subpíxel mejora la precisión de la detección, eliminando bordes falsos y afinando las líneas detectadas.

• Normalización de la respuesta

  Tras la supresión, la imagen se normaliza a una escala de 0 a 255. Esta operación facilita la aplicación de umbrales en la etapa siguiente, garantizando una separación clara entre bordes fuertes y débiles.

• Umbralización por histéresis

  Se aplican dos umbrales:

  Umbral alto (T_high): identifica los píxeles que forman parte de bordes fuertes.

  Umbral bajo (T_low): marca como candidatos a borde aquellos píxeles con respuesta intermedia, que podrían formar parte de un borde si están conectados a píxeles fuertes.

  La conectividad se propaga mediante un recorrido tipo BFS (cola FIFO), agrupando píxeles débiles que estén directa o indirectamente conectados con los fuertes. Esto permite cerrar contornos y preservar estructuras continuas.

• Generación del mapa de bordes

  El resultado es una imagen binaria en la que los bordes detectados se representan con intensidad máxima (255) y el fondo con 0. Solo sobreviven los píxeles que cumplieron con todos los criterios: magnitud alta, máximo local y conexión estructural.

def CannyLikeDetector(image: np.ndarray, sigma=1.0, tlow=0.1, thigh=0.3) -> np.ndarray:

    Gx, Gy, Gmag, Gphase = ComputeImageGradient(image, sigma_s=sigma, sigma_d=sigma)

    suppressed = NonMaximumSuppressionSubpixel(Gx, Gy, Gmag)

    # Normalización post-supresión
    norm_suppressed = np.clip((suppressed / suppressed.max()) * 255.0, 0, 255).astype(np.float32)

    # Umbrales escalados
    T_high = thigh * 255
    T_low = tlow * 255

    edges = HysteresisThresholdFIFO(norm_suppressed, T_high, T_low)
    return edges

Supresión de no-máximos con interpolación subpíxel

Esta técnica busca conservar únicamente aquellos puntos cuya magnitud del gradiente es un verdadero máximo local en la dirección de mayor cambio de intensidad. A diferencia de métodos clásicos que discretizan la orientación en pocos ángulos, esta variante mejora la precisión al trabajar directamente con la dirección continua del gradiente, empleando interpolación bilineal.

Para cada píxel, se calcula el vector gradiente y se normaliza para obtener la dirección dx, dy. Luego, se estima la magnitud del gradiente en posiciones desplazadas hacia adelante y hacia atrás siguiendo esa dirección, utilizando interpolación bilineal sobre la imagen de magnitudes. A continuación, se comparan tres valores: el del píxel actual y los dos interpolados. Si el valor central es mayor o igual que ambos vecinos, se conserva; en caso contrario, se suprime.

def NonMaximumSuppressionSubpixel(Gx: np.ndarray, Gy: np.ndarray, Gmag: np.ndarray) -> np.ndarray:
    rows, cols = Gmag.shape
    output = np.zeros_like(Gmag, dtype=np.float32)

    for i in range(1, rows - 1):
        for j in range(1, cols - 1):
            gx, gy = Gx[i, j], Gy[i, j]
            mag = Gmag[i, j]
            if gx == 0 and gy == 0:
                continue
            norm = np.hypot(gx, gy)
            dx, dy = gx / norm, gy / norm

            def interp(y, x):
                x0, y0 = int(x), int(y)
                x1 = min(x0 + 1, cols - 1)
                y1 = min(y0 + 1, rows - 1)
                a, b = x - x0, y - y0
                return (
                    Gmag[y0, x0] * (1 - a) * (1 - b) +
                    Gmag[y0, x1] * a * (1 - b) +
                    Gmag[y1, x0] * (1 - a) * b +
                    Gmag[y1, x1] * a * b
                )

            mag1 = interp(i + dy, j + dx)
            mag2 = interp(i - dy, j - dx)

            if mag >= mag1 and mag >= mag2:
                output[i, j] = mag
    return output

La imagen resultante contiene únicamente los puntos que se destacan como máximos locales en la dirección del gradiente, representando con mayor fidelidad los bordes reales en la escena y favoreciendo una delineación más precisa y continua de los contornos.

Derecha: gradiente de la imagen, izquierda: imagen resultante de la supresión.

Umbralizado por histéresis

Después de la supresión de no-máximos, nos queda una imagen donde los bordes están bien localizados, pero aún pueden incluir ruido o detalles poco relevantes. Para decidir cuáles bordes conservar, Canny propuso usar dos umbrales:

• Tₕ (umbral alto): cualquier píxel con una magnitud mayor o igual a este se considera un borde fuerte (válido).

• Tₗ (umbral bajo): cualquier píxel con una magnitud entre Tₗ y Tₕ es un borde débil, que solo será aceptado si está conectado a un borde fuerte.

• Todo lo que está por debajo de Tₗ se descarta por completo.

Este proceso evita tanto la pérdida de bordes importantes (si se usara un único umbral alto), como la aceptación de ruido (si se usara un único umbral bajo).

Umbralizado por histéresis con propagación BFS

El umbralizado por histéresis se encarga de refinar los bordes detectados eliminando aquellos que no estén suficientemente respaldados por la estructura global de la imagen. Para ello, clasifica los píxeles según dos umbrales: alto y bajo. Aquellos cuya magnitud supera el umbral alto se consideran bordes fuertes; los que están entre ambos umbrales, bordes débiles; y el resto se descarta.

La técnica aplica un proceso de propagación que preserva únicamente los bordes débiles conectados a bordes fuertes, lo que garantiza una mayor continuidad y reduce los falsos positivos. Esta propagación se realiza mediante un recorrido tipo búsqueda en anchura (BFS) utilizando una cola FIFO.

Primero, se identifican y almacenan todos los píxeles fuertes. Luego, para cada uno de ellos, se exploran sus vecinos en una conectividad de 8. Si alguno de estos vecinos corresponde a un píxel débil aún no marcado, se lo promueve a borde definitivo y se agrega a la cola para seguir expandiendo la conexión.

def HysteresisThresholdFIFO(image, T_high, T_low):
    h, w = image.shape
    strong = (image >= T_high)
    weak = (image >= T_low) & ~strong
    result = np.zeros_like(image, dtype=np.uint8)
    queue = deque()

    for y in range(h):
        for x in range(w):
            if strong[y, x]:
                result[y, x] = 255
                queue.append((x, y))

    directions = [(-1, -1), (-1, 0), (-1, 1),
                  (0, -1),         (0, 1),
                  (1, -1), (1, 0), (1, 1)]

    while queue:
        x, y = queue.popleft()
        for dx, dy in directions:
            nx, ny = x + dx, y + dy
            if 0 <= nx < w and 0 <= ny < h:
                if weak[ny, nx] and result[ny, nx] == 0:
                    result[ny, nx] = 255
                    queue.append((nx, ny))
    return result

Este mecanismo asegura que los contornos detectados sean coherentes y estén respaldados por una estructura significativa, permitiendo preservar bordes reales mientras se descartan aquellos aislados o espurios.

Resultados.

Antes de aplicar el detector de bordes de Canny, es recomendable realizar un preprocesamiento mediante técnicas de filtrado que suavicen la imagen y reduzcan el ruido. Esta etapa no solo evita la detección de bordes espurios causados por pequeñas variaciones locales, sino que también ayuda a que los contornos verdaderamente relevantes se presenten de forma más continua y estable. En particular, filtros como el gaussiano o variantes más avanzadas como el bilateral pueden mejorar significativamente la coherencia espacial de los bordes detectados en la etapa posterior.

El algoritmo de Canny ha perdurado como uno de los métodos más eficaces y usados en el campo del procesamiento de imágenes debido a su formulación precisa y sus decisiones fundamentadas en principios matemáticos y perceptuales. A través de un enfoque estructurado que incluye suavizado gaussiano, cálculo de gradientes, supresión de no-máximos e histéresis con umbrales duales, logra detectar bordes bien localizados, continuos y con bajo nivel de falsos positivos.

La versión moderna del detector de Canny emplea técnicas avanzadas como la supresión de no-máximos con interpolación subpíxel y la propagación por histéresis basada en una cola FIFO. Estas estrategias refinan la localización de los bordes y mejoran su continuidad, incluso en escenas con transiciones suaves o estructuras poco definidas.

En la imagen de la derecha se aplico el algoritmo original, en la imagen de la izquierda se aplico el algoritmo optimizado.

Más allá de su efectividad práctica, el estudio del algoritmo de Canny revela cómo decisiones algorítmicas cuidadosamente diseñadas —como el uso conjunto de magnitud, orientación y conectividad— pueden reproducir con notable precisión la percepción humana de los contornos. Por ello, Canny no solo representa un hito histórico en visión por computadora, sino que sigue siendo una herramienta vigente y valiosa en aplicaciones modernas como análisis de imágenes, visión artificial y preprocesamiento para modelos de aprendizaje automático.

En contextos de baja iluminación, capturar esa atmósfera sin sacrificar calidad técnica representa un desafío importante. Para lograr una imagen adecuada en entornos con poca luz, el fotógrafo debe encontrar un equilibrio delicado entre la apertura del diafragma, el tiempo del obturador y la sensibilidad ISO. Aumentar el tiempo de exposición permite capturar más luz, pero puede producir desenfoques por movimiento (motion blur). Abrir más el diafragma reduce la necesidad de tiempos largos, pero disminuye la profundidad de campo. Elevar el ISO aumenta la sensibilidad del sensor, aunque también incrementa la presencia de ruido, especialmente en exposiciones cortas.

English version of this article. Click here

Una solución común es el uso del flash, que permite obtener imágenes nítidas y bien expuestas. Sin embargo, esta técnica introduce varios problemas: los objetos cercanos tienden a sobreexponerse, se pierden los matices de la luz ambiental, y aparecen artefactos como ojos rojos, sombras duras o brillos especulares indeseados.

En el trabajo "Digital Photography with Flash and No-Flash Image Pairs". propusieron una técnica , para combinar una imagen con flash y otra sin el, para crear una nueva que conserva la iluminación natural de la escena mientras incorpora el nivel de detalle de la imagen con flash

Explicación del algoritmo

El algoritmo propuesto por Eisemann y Durand se compone de los siguientes pasos principales:

1. Reducción de ruido en la imagen sin flash
   Se utiliza la imagen con flash, que posee menor ruido, como referencia para eliminar el ruido de la imagen tomada con luz ambiente, preservando su iluminación original.

2. Transferencia de detalle de alta frecuencia
   Se extraen texturas finas y bordes nítidos de la imagen con flash y se incorporan en la imagen sin flash ya filtrada, mejorando su nivel de detalle sin alterar su tonalidad global.

3. Corrección de balance de blancos
   (opcional) A partir del color conocido del flash, se ajusta la temperatura de color de la imagen ambiental.

4. Interpolación continua entre ambas imágenes
   Se ajusta la intensidad del efecto del flash, interpolando o incluso extrapolando entre las dos imágenes originales para obtener un resultado personalizado.

5. Corrección de ojos rojos
   (opcional) Se detecta este artefacto comparando los colores de la pupila en ambas imágenes, aplicando una corrección precisa basada en el cambio producido por el flash.

def enhance_ambient_with_flash(ambient, flash):
    """
    Enhances the ambient image using the flash image.

    Parameters:
        ambient (numpy array): Ambient image.
        flash (numpy array): Flash image.

    Returns:
        numpy array: Enhanced ambient image.
    """
    ambient_lin = ambient.astype(np.float32) / 255
    flash_lin = flash.astype(np.float32) / 255

    # Compute ambient color and denoise
    denoised_ambient = joint_bilateral_filter(ambient, flash, sigma_d=10, sigma_r=0.2)

    # Compute detail layer
    detail_layer = compute_detail_layer(flash, sigma_d=30, sigma_r=0.9, epsilon=0.01)

    # Detect shadows and specular highlights
    specular_mask = detect_flash_specularities(flash_lin, threshold=0.95)
    mask = detect_flash_shadows(flash_lin, ambient_lin, tau=0.01)

    # Combine shadow and specular masks
    full_mask = np.clip(mask + specular_mask, 0, 1)
    full_mask = cv2.GaussianBlur(full_mask, (5, 5), 5)
    full_mask = np.repeat(full_mask[..., np.newaxis], 3, axis=2)

    # Final merge
    transferred = denoised_ambient * detail_layer
    final_image = apply_masked_merge(transferred, denoised_ambient, full_mask)

    return np.clip(final_image, 0, 255).astype(np.uint8)

Filtrado de ruido

La imagen sin flash suele presentar un nivel elevado de ruido, especialmente en condiciones de baja iluminación. Por esta razón, uno de los primeros pasos del algoritmo consiste en aplicar un proceso de reducción de ruido.

El filtrado es un área ampliamente estudiada en el procesamiento de imágenes, y existen numerosos filtros diseñados con este propósito. En esta técnica se emplea el filtro bilateral, debido a que ofrece una ventaja clave: suaviza la imagen sin destruir los bordes, preservando tanto la estructura como la información de iluminación.

El filtro bilateral funciona como un promedio ponderado de los píxeles vecinos, pero, a diferencia del promedio tradicional, asigna pesos no solo según la cercanía espacial, sino también según la similitud de intensidad. La fórmula general es:

$$h(x) = \sum_{i \in \Omega(x)} g_s(x - i) \cdot g_r(I(x) - I(i))$$

Sin embargo, en condiciones extremas —cuando la imagen sin flash tiene un nivel de ruido tan alto que incluso los bordes se vuelven poco distinguibles— es mejor utilizar una variante llamada Joint Bilateral Filter. Esta versión guía el filtrado de la imagen ruidosa utilizando otra imagen más confiable (en este caso, la imagen con flash G), lo cual permite preservar mejor los bordes reales.

$$h(x) = \sum_{i \in \Omega(x)} g_s(x - i) \cdot g_r(G(x) - G(i))$$

def joint_bilateral_filter(ambient, flash, sigma_d=15, sigma_r=0.1):
    """
    Applies a joint bilateral filter using the flash image as a guide.

    Parameters:
        ambient (numpy array): Ambient image (to be filtered).
        flash (numpy array): Flash image (used as a guide).
        sigma_d (float): Spatial sigma (controls the range of spatial smoothing).
        sigma_r (float): Range sigma (controls the range of intensity smoothing).

    Returns:
        numpy array: Filtered ambient image.
    """
    import cv2.ximgproc  # Ensure opencv-contrib-python is installed

    ambient_uint8 = ambient.astype(np.uint8)
    flash_uint8 = flash.astype(np.uint8)

    filtered = np.zeros_like(ambient_uint8)

    for i in range(3):  # Process each channel (BGR)
        filtered[..., i] = cv2.ximgproc.jointBilateralFilter(
            joint=flash_uint8[..., i],    # Guide image (flash)
            src=ambient_uint8[..., i],    # Image to be filtered (ambient)
            d=-1,
            sigmaColor=sigma_r * 255,
            sigmaSpace=sigma_d
        )

    return filtered.astype(np.float32)

Este enfoque permite reducir el ruido de manera más robusta, incluso cuando la imagen original está severamente degradada, ya que la información estructural proviene de una fuente externa más confiable.

Una vez que la imagen sin flash ha sido suavizada para aislar su iluminación global, el siguiente paso del algoritmo consiste en transferir los detalles de alta frecuencia —como bordes nítidos, contornos definidos y texturas finas— desde la imagen capturada con flash. Para lograr esto, se aplica nuevamente un filtro bilateral a la imagen con flash, obteniendo una versión suavizada que conserva la estructura general pero elimina las variaciones locales rápidas.

Transferencia de detalle.

La capa de detalle se calcula entonces como la relación entre la imagen original con flash y su versión filtrada, una operación que resalta los cambios relativos en intensidad y permite aislar las texturas de forma multiplicativa. Esta estrategia es especialmente efectiva porque es invariante a escalas de iluminación, lo que evita distorsiones cromáticas o de brillo al fusionar las imágenes.

def compute_detail_layer(flash, sigma_d=10, sigma_r=0.7, epsilon=0.5):
    """
    Computes the detail layer of the flash image.

    Parameters:
        flash (numpy array): Flash image.
        sigma_d (float): Spatial sigma for the bilateral filter.
        sigma_r (float): Range sigma for the bilateral filter.
        epsilon (float): Small constant to avoid division by zero.

    Returns:
        numpy array: Detail layer.
    """
    base = bilateral_filter(flash, sigma_d, sigma_r)
    detail = (flash + epsilon) / (base + epsilon)
    return detail

Finalmente, esta capa de detalle se incorpora sobre la imagen sin flash suavizada, conservando su atmósfera natural pero enriquecida visualmente con la nitidez aportada por el flash.

Detección de sombras y especularidades

El siguiente paso es identificar y excluir regiones afectadas por artefactos del flash, como las sombras proyectadas y los reflejos especulares. En el algoritmo propuesto, la detección de sombras se basa en comparar las versiones linealizadas (sin corrección gamma) de ambas imágenes, lo que garantiza que las diferencias de luminancia reflejen fielmente las variaciones físicas de iluminación.

Dado que los píxeles en sombra no reciben luz directa del flash, su luminancia en ambas imágenes debería ser muy similar o apenas superior, por lo que se construye una máscara de sombras mediante un umbral aplicado a la diferencia por canal en el espacio RGB lineal. Este criterio requiere que todos los canales estén por debajo de un umbral, asegurando así una detección robusta frente a variaciones cromáticas.

Aunque esta detección es efectiva, puede verse afectada por factores como el ruido de la imagen, las interreflexiones entre superficies, objetos de albedo muy bajo (negros absolutos) y regiones alejadas que no reciben iluminación del flash. Sin embargo, las dos últimas no comprometen el resultado final, pues ambas imágenes contienen información similar en esas zonas, evitando falsas detecciones.

def detect_flash_shadows(flash_lin, ambient_lin, tau=0.09):
    """
    Detects shadows caused by the flash.

    Parameters:
        flash_lin (numpy array): Flash image (linearized).
        ambient_lin (numpy array): Ambient image (linearized).
        tau (float): Threshold for shadow detection.

    Returns:
        numpy array: Shadow mask.
    """
    diff = flash_lin - ambient_lin
    shadow_mask = np.all(diff < tau, axis=2).astype(np.float32)
    return cv2.dilate(shadow_mask, None)

Para mejorar la máscara y evitar bordes fragmentados o ruidosos, se aplican operaciones morfológicas como la dilatación, que expanden y suavizan la cobertura de las sombras, garantizando una segmentación conservadora y continua de las áreas sombreadas. Esto resulta crucial para evitar que las sombras generen artefactos durante la fusión de las imágenes.

Por otro lado, las especularidades —reflejos intensos que saturan el sensor— también deben identificarse, ya que en esas zonas la imagen con flash pierde completamente el detalle. Para detectarlas, el algoritmo analiza la luminancia de la imagen con flash Fₗᵢₙ​ y marca como especular cualquier píxel cuya intensidad supere el 95% del rango del sensor.

def detect_flash_specularities(flash_lin, threshold=0.95):
    """
    Detects specular highlights caused by the flash.

    Parameters:
        flash_lin (numpy array): Flash image (linearized).
        threshold (float): Threshold for specular highlight detection.

    Returns:
        numpy array: Specular highlight mask.
    """
    luminance = 0.2126 * flash_lin[..., 2] + 0.7152 * flash_lin[..., 1] + 0.0722 * flash_lin[..., 0]
    specular_mask = (luminance >= threshold).astype(np.float32)
    return cv2.dilate(specular_mask, None)

Esta máscara también se refina con operaciones morfológicas, asegurando que se cubran adecuadamente las zonas saturadas. Al evitar el uso de datos provenientes de regiones con sombras duras o saturación especular, el algoritmo preserva tanto la estética natural de la iluminación ambiental como la calidad estructural de la imagen final.

Etapa final.

La etapa final del proceso consiste en combinar la imagen enriquecida con detalles y la imagen base suavizada, de forma que se aprovechen las fortalezas de ambas. Esta combinación se realiza mediante una mezcla ponderada controlada por una máscara, la cual indica en cada píxel qué proporción de cada imagen debe utilizarse.

En las zonas donde no hay artefactos —como sombras duras o reflejos especulares—, la máscara tiene valores cercanos a cero, permitiendo que predomine la imagen con detalles. Por el contrario, en regiones problemáticas la máscara toma valores cercanos a uno, priorizando la imagen base para evitar introducir errores visuales.

def apply_masked_merge(a, b, mask):
    """
    Merges two images using a mask.

    Parameters:
        a (numpy array): First image.
        b (numpy array): Second image.
        mask (numpy array): Mask to control blending.

    Returns:
        numpy array: Merged image.
    """
    return (1 - mask) * a + mask * b

Los valores intermedios permiten transiciones suaves entre ambas imágenes, lo que ayuda a mantener una apariencia continua y libre de bordes notorios. Gracias a esta interpolación controlada, se logra una imagen final que conserva la iluminación natural y la atmósfera ambiental, pero con una mejora perceptible en textura, nitidez y contraste.

La combinación de imágenes con y sin flash representa una solución ingeniosa y eficaz para superar las limitaciones de la captura de fotografias en ambientes de baja iluminacion. A través de un pipeline cuidadosamente diseñado, se logra un equilibrio entre la fidelidad atmosférica de la luz ambiental y la riqueza estructural que aporta el flash.

Este enfoque no solo mitiga defectos típicos como ruido, sombras duras o saturación especular, sino que también permite preservar la sensación original de la escena, respetando la intención artística del fotógrafo. Gracias al uso de herramientas como el filtrado bilateral guiado, la separación multiplicativa de detalles y de máscaras, el método ofrece una alternativa robusta para producir imágenes técnicamente sólidas y visualmente agradables, incluso en condiciones de iluminación desafiantes. La técnica propuesta en Digital Photography with Flash and No-Flash Image Pairs demuestra así que la fotografía computacional no solo puede corregir deficiencias, sino también ampliar las capacidades expresivas del medio fotográfico.

Resultados

Bibliografia.

Elmar Eisemann and Frédo Durand. 2004. Flash photography enhancement via intrinsic relighting. ACM Trans. Graph. 23, 3 (August 2004), 673–678. https://doi.org/10.1145/1015706.1015778

C. Chen, Q. Chen, J. Xu and V. Koltun, "Learning to See in the Dark," in 2018 IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), Salt Lake City, UT, USA, 2018, pp. 3291-3300, doi: 10.1109/CVPR.2018.00347.

English version of this article. Click here.

Transformada de Fourier 1D

Para una señal continua g(t), su transformada de Fourier está definida como:

$$G(f) = \int_{-\infty}^{\infty} g(t) \cdot e^{-j2\pi f t} , dt$$

donde:

• t representa el tiempo (o la posición, en el caso de imágenes),

• f representa la frecuencia,

• j = √-1 es la unidad imaginaria.

Este proceso equivale a medir cuánto "resuena" la señal g(t) con una onda sinusoidal de frecuencia f. Para cada frecuencia, el resultado G(f) es un número complejo que codifica tanto la magnitud como la fase de esa frecuencia dentro de la señal.

Aunque esta formulación puede parecer abstracta, se puede entender mejor aplicando la fórmula de Euler:

$$e^{−j2πft}=cos⁡(2πft)−jsin⁡(2πft)$$

Lo que nos permite ver la transformada como dos integrales:

$$G(f) = \int_{-\infty}^{\infty} g(t) \cos(2\pi f t) \, dt - j \int_{-\infty}^{\infty} g(t) \sin(2\pi f t) \, dt$$

Estas integrales separadas representan la contribución de las componentes pares y impares de la señal. Así, G(f) captura información tanto de la simetría como de la variabilidad de la señal en torno a cada frecuencia.

Transformada Inversa y Reconstrucción

Una de las propiedades más importantes de la Transformada de Fourier es su reversibilidad: a partir de la representación en el dominio de la frecuencia es posible reconstruir exactamente la señal original, siempre que se cumplan ciertas condiciones suaves sobre la señal (como ser absolutamente integrable o cuadrado-integrable).

La transformada inversa se define de forma muy similar a la directa, con un pequeño cambio en el signo del exponente:

$$g(t) = \int_{-\infty}^{\infty} G(f) \cdot e^{j2\pi f t} \, df$$

Esta simetría entre la transformada directa e inversa resalta una idea clave: la Transformada de Fourier no pierde información (cuando se aplica correctamente), sino que simplemente reorganiza los datos de una forma distinta, enfocándose en las frecuencias presentes en la señal en lugar de sus valores locales en el tiempo o el espacio.

La posibilidad de reconstruir exactamente una señal a partir de su representación en el dominio de la frecuencia es lo que hace viable el filtrado en este espacio. Gracias a esta propiedad, es posible transformar una señal —como una imagen— al dominio frecuencial, modificar selectivamente ciertas frecuencias mediante un filtro, y luego aplicar la transformada inversa para regresar al dominio original. Este proceso garantiza que los cambios realizados se reflejen con precisión en la señal reconstruida, conservando la información relevante mientras se eliminan o atenúan componentes no deseados.

Transformada de Fourier 2D

En el caso de imágenes, que pueden considerarse funciones bidimensionales g(x, y), se utiliza la Transformada de Fourier 2D:

$$G(u, v) = \iint_{-\infty}^{\infty} g(x, y) \cdot e^{-j2\pi (ux + vy)} \, dx \, dy$$

Aquí:

• (x, y) son las coordenadas espaciales,

• (u, v) son las coordenadas de frecuencia espacial,

• G(u, v) representa la contribución de la frecuencia $(u, v)$ a la imagen.

Este cambio de representación permite analizar la imagen desde una nueva perspectiva: en lugar de observar el contenido local de la imagen, nos enfocamos en cómo varía globalmente la intensidad en diferentes escalas y direcciones.

Muestreo y Aliasing

En la práctica, la mayoría de las señales que se procesan digitalmente (audio, imágenes, sensores) no son continuas, sino discretas: se obtienen mediante muestreo de una señal continua a intervalos regulares. Esta operación transforma una señal continua g(t) en una secuencia discreta g[n] = g(nT), donde T es el periodo de muestreo y fₛ = 1/T la frecuencia de muestreo.

Aquí entra en juego un principio fundamental: el teorema de muestreo de Nyquist-Shannon, que establece que:

Una señal puede ser reconstruida perfectamente a partir de sus muestras si ha sido muestreada a una frecuencia mayor que el doble de su frecuencia más alta (frecuencia de Nyquist).

Esto significa que si una señal contiene componentes hasta 500 Hz, debemos muestrearla a más de 1000 Hz para evitar pérdida de información. Una señal que cumple esta condición se denomina banda limitada, y cuando el muestreo se realiza adecuadamente, la señal original puede ser recuperada sin ambigüedades a partir de sus muestras.

Aliasing

Cuando la frecuencia de muestreo es insuficiente, es decir, menor que el doble de la frecuencia más alta presente en la señal, ocurre un fenómeno llamado aliasing. En este caso, las frecuencias altas comienzan a disfrazarse como frecuencias más bajas, dando lugar a distorsiones irreversibles en el dominio de la frecuencia.

Matemáticamente, si una señal de frecuencia f es muestreada con una frecuencia fₛ, la frecuencia aparente o alias que se observa está dada por:

$$f' = \left| f_s \cdot n - f \right| \quad n = \text{round}\left(\frac{f}{f_s}\right)$$

Esto significa que la muestra tomada a una frecuencia incorrecta puede ser indistinguible de otra frecuencia completamente diferente. Por ejemplo, si f = 1000 Hz y fₛ = 1250 Hz, el alias observado será f' = 250 Hz. En otras palabras, la señal de 1 kHz parecerá una de 250 Hz, y no hay forma de saber cuál era la original. Este tipo de ambigüedad destruye la posibilidad de una reconstrucción precisa.

Este fenómeno no es solo una curiosidad matemática: se manifiesta de forma visual en situaciones como el efecto de la rueda de carreta*, donde las ruedas parecen girar en sentido inverso cuando su velocidad supera la capacidad de muestreo de la cámara. Por esta razón, aliasing también es conocido como el* efecto wagon wheel*.*

Debido a este riesgo, en sistemas digitales se emplean filtros antialiasing antes del muestreo, los cuales eliminan las frecuencias que podrían provocar ambigüedad, asegurando que la señal resultante se mantenga dentro del rango permitido por la frecuencia de muestreo.

Tipos de muestreo

• Sobremuestreo: fₛ ≫ 2fₘₐₓ – Alta fidelidad, mayor tamaño de datos.

• Muestreo crítico: fₛ = 2fₘₐₓ – Reconstrucción exacta, pero sin margen de seguridad.

• Submuestreo: fₛ < 2fₘₐₓ – Ocurre aliasing, se pierde información.

Transformada de Fourier Discreta DFT

La Transformada de Fourier Discreta (DFT). permite representar señales digitales como combinaciones de frecuencias discretas, facilitando el análisis espectral, el filtrado y la compresión de datos. Además de su aplicabilidad, la DFT tiene la ventaja de que siempre existe, independientemente de las propiedades matemáticas de la señal, lo cual no ocurre con otras variantes como la serie de Fourier.

Transformada Discreta 1D

Sea g[x] una señal unidimensional discreta compuesta por $w$ muestras. La DFT se define como:

$$G[k] = \sum_{x=0}^{w-1} g[x] \cdot e^{-j2\pi \frac{kx}{w}}$$

donde k = 0, 1, ..., w-1 es el índice de frecuencia discreta. Esta fórmula reemplaza la integral de la versión continua por una suma finita, y convierte las frecuencias continuas en frecuencias discretas y periódicas.

Usando la fórmula de Euler, se puede reescribir en términos de funciones reales:

$$G[k] = \sum_{x=0}^{w-1} g[x] \cdot \left[\cos\left(\frac{2\pi kx}{w}\right) - j \sin\left(\frac{2\pi kx}{w}\right)\right]$$

Esto revela que cada valor G[k] representa cuánto de una sinusoide (frecuencia) de índice k está presente en la señal original.

Propiedades clave

• La señal de entrada g[x] típicamente es real, pero su DFT G[k] es compleja (parte real + imaginaria).

• La DFT produce el mismo número de muestras que la señal original: w puntos en el dominio de la frecuencia.

• Las frecuencias resultantes son periódicas, es decir, G[k] = G[k + w]. Esta periodicidad es clave en el análisis espectral.

Transformada Inversa 1D

La DFT es reversible, lo que significa que es posible recuperar la señal original a partir de sus coeficientes de frecuencia:

$$g[x] = \frac{1}{w} \sum_{k=0}^{w-1} G[k] \cdot e^{j2\pi \frac{kx}{w}}$$

Esto garantiza que ninguna información se pierde en la transformación, siempre que se conserve la totalidad de los coeficientes G[k].

Transformada de Fourier Discreta en 2D

En una función bidimensional sea g[x, y] como una imagen discreta de tamaño w × h, donde x y y representan las coordenadas espaciales horizontales y verticales respectivamente. La DFT 2D está definida como:

$$G[k_x, k_y] = \sum_{x=0}^{w-1} \sum_{y=0}^{h-1} g[x, y] \cdot e^{-j2\pi\left( \frac{k_x x}{w} + \frac{k_y y}{h} \right)}$$

donde kₓ y k_y son los índices de frecuencia discreta en las direcciones horizontal y vertical, respectivamente.

Forma real usando la fórmula de Euler

Usando la identidad de Euler, esta expresión puede descomponerse en términos reales e imaginarios:

$$G[k_x, k_y] = \sum_{x=0}^{w-1} \sum_{y=0}^{h-1} g[x, y] \cdot \left[\cos\left(2\pi\left( \frac{k_x x}{w} + \frac{k_y y}{h} \right)\right) - j \sin\left(2\pi\left( \frac{k_x x}{w} + \frac{k_y y}{h} \right)\right)\right]$$

Esto permite interpretar G[k_x, k_y] como una combinación de senos y cosenos bidimensionales, lo que resulta útil para analizar patrones periódicos en las imágenes, como texturas o bordes.

Propiedades clave de la DFT 2D

• La imagen de entrada g[x, y] suele ser real, pero su DFT G[kₓ , k_y] es compleja, conteniendo información de magnitud y fase.

• La DFT 2D produce una imagen en el dominio de la frecuencia del mismo tamaño que la original: w × h coeficientes complejos.

• El espectro de frecuencias es periódico tanto en kₓ como en k_y, con periodo w y h respectivamente.

• Se puede calcular como una composición de dos DFTs unidimensionales:

$$\text{DFT}_{2D}[g(x,y)] = \text{DFT}_x(\text{DFT}_y(g(x,y)))$$

Esto permite reutilizar implementaciones eficientes de la DFT 1D.

def FourierTransform2D(image):
    """
    Computes the 2D Fourier Transform of an image step by step
    using two 1D FFTs: first along rows, then along columns.

    Parameters:
    - image: Input image (2D numpy array).

    Returns:
    - 2D Fourier Transform of the image.
    """
    # First, apply FFT along the rows (axis=1)
    fft_rows = np.fft.fft(image, axis=1)

    # Then, apply FFT along the columns (axis=0)
    fft2d = np.fft.fft(fft_rows, axis=0)

    return fft2d

Transformada Inversa 2D

Al igual que en el caso unidimensional, la DFT 2D es reversible. La Transformada Inversa Discreta de Fourier 2D permite reconstruir exactamente la imagen original:

$$g[x, y] = \frac{1}{wh} \sum_{k_x=0}^{w-1} \sum_{k_y=0}^{h-1} G[k_x, k_y] \cdot e^{j2\pi\left( \frac{k_x x}{w} + \frac{k_y y}{h} \right)}$$

Esto garantiza que no se pierde información si se conserva el espectro completo G[kₓ , k_y].

Visualización de la DFT 2D

La Transformada Discreta de Fourier bidimensional (DFT 2D) produce una representación compleja de la frecuencia espacial de una imagen. Sin embargo, esta información no es directamente interpretable por el ojo humano, por lo que es necesario realizar ciertas transformaciones para poder visualizarla de forma útil.

Magnitud y fase

El primer paso consiste en descomponer la DFT compleja en dos componentes reales: la magnitud y la fase.

• La fase contiene la información sobre la alineación de las ondas sinusoidales en la reconstrucción de la imagen. Puede visualizarse escalándola linealmente al rango [0, 255] para mostrarla como una imagen en escala de grises.

• La magnitud, que representa la intensidad de cada frecuencia espacial presente, es más complicada de visualizar. Si se muestra directamente, se suele obtener una imagen casi negra con un único punto brillante en la esquina superior izquierda. Este punto representa la componente DC, que normalmente tiene un valor muy alto en comparación con las demás frecuencias.

Este comportamiento se debe a que el módulo de la DFT posee un rango dinámico extremadamente amplio: unas pocas frecuencias dominan en magnitud mientras que la mayoría de las demás tienen valores mucho menores. Así, si se visualiza sin ningún tipo de ajuste, los valores más pequeños quedan prácticamente invisibles.

def ComputeFourierSpectra(image):
    """
    Computes and returns the magnitude and phase spectra of a 2D Fourier Transform.

    This function takes a grayscale image as input, applies the 2D Fourier Transform,
    and returns both the magnitude and phase spectra. The magnitude spectrum is 
    log-scaled and normalized to enhance visibility, while the phase spectrum is also 
    normalized to the 0–255 range for visualization purposes.

    Parameters:
    ----------
    image : np.ndarray
        2D numpy array representing a grayscale image (real-valued input).

    Returns:
    -------
    magnitude : np.ndarray
        2D array (uint8) representing the normalized log-magnitude spectrum.

    phase : np.ndarray
        2D array (uint8) representing the normalized phase spectrum in the range [0, 255].

    Notes:
    -----
    - The function assumes the input is a 2D image.
    - Zero-frequency components are shifted to the center using `np.fft.fftshift`.
    - The Fourier transform is computed using a custom implementation `FourierTransform2D`.
    """
    dft = FourierTransform2D(image)

    # Compute magnitude and apply log-scaling
    magnitude = np.abs(dft)
    magnitude = np.log1p(magnitude)  # log(1 + |F(u,v)|)
    magnitude = np.fft.fftshift(magnitude)
    magnitude = (magnitude / np.max(magnitude) * 255).astype(np.uint8)

    # Compute and normalize phase
    phase = np.angle(dft)
    phase = np.fft.fftshift(phase)
    phase = (phase + np.pi) / (2 * np.pi) * 255  # Normalize to [0, 255]
    phase = phase.astype(np.uint8)

    return magnitude, phase

Uso del logaritmo y desplazamiento del espectro

Para hacer visible la magnitud, se aplican dos transformaciones:

1. Escala logarítmica:

   $$\log(1 + |G(k_x, k_y)|)$$

   Esto reduce las diferencias extremas entre las frecuencias fuertes y débiles, haciendo visibles las frecuencias de menor energía. El uso del logaritmo en este contexto es análogo a la percepción del sonido por parte del oído humano: no responde linealmente a la intensidad, sino logarítmicamente. De este modo, se preservan los detalles de baja frecuencia sin saturar las regiones dominadas por componentes de gran magnitud.

2. Centrar la componente DC:

   Por defecto, la componente DC (frecuencia cero) está en la esquina superior izquierda del espectro. Para una visualización más simétrica e intuitiva, se reorganizan los cuadrantes del espectro:

   • A = superior izquierda

   • B = superior derecha

   • C = inferior izquierda

   • D = inferior derecha

El reordenamiento D–C–B–A lleva la componente DC al centro de la imagen, colocando las bajas frecuencias en el centro y las altas en los bordes. Esta representación resulta más natural para el análisis visual, ya que alinea la estructura radial de la frecuencia con la disposición visual esperada.

Una forma matemática equivalente a este reordenamiento consiste en multiplicar la imagen original por (-1)ˣ⁺ʸ antes de aplicar la DFT:

$$\text{DFT} \left[ g(x, y)(-1)^{x+y} \right] = G\left(k_x - \frac{w}{2}, k_y - \frac{h}{2} \right)$$

donde w y h son el ancho y el alto de la imagen. Esta modulación espacial alterna el signo de los píxeles formando un patrón similar a un tablero de ajedrez, lo que tiene como efecto el desplazamiento del espectro de frecuencia. El resultado es una traslación del espectro tal que las bajas frecuencias se ubican en el centro de la imagen transformada, facilitando así su análisis visual y cuantitativo.

Interpretación periódica y replicación

La DFT asume que la imagen de entrada es periódica en ambas direcciones. Esto implica que su espectro también es periódico.

Si replicamos la imagen original cuatro veces (en una disposición 2×2) y aplicamos la DFT a esta imagen extendida, obtendremos una réplica del espectro en cada cuadrante. El cuadrante central (resultante del reordenamiento D–C–B–A) corresponde al espectro con la componente DC centrada.

Esta observación justifica conceptualmente por qué es válido y útil reordenar los cuadrantes del espectro para facilitar su interpretación: al centrar el origen de la frecuencia, se obtiene una vista más coherente y balanceada del contenido frecuencial de la imagen.

Observaciones sobre la distribución de energía

Este tipo de visualización revela patrones importantes. Por ejemplo, es común observar que las frecuencias ubicadas en el centro del espectro (bajas frecuencias) contienen la mayor parte de la energía, mientras que las frecuencias ubicadas hacia los bordes (altas frecuencias) tienen menor intensidad. Esto concuerda con el hecho de que la mayoría de las imágenes naturales presentan transiciones suaves y pocas variaciones abruptas.

En consecuencia:

• El centro del espectro suele brillar más debido a la mayor concentración de energía en frecuencias bajas.

• Las regiones periféricas contienen información sobre bordes, texturas y detalles finos de la imagen original.

• Esta distribución espectral refleja el contenido estructural de la imagen en el dominio de la frecuencia, permitiendo tanto su análisis cualitativo como su manipulación mediante filtrado.

La Transformada de Fourier constituye una de las herramientas más poderosas en el procesamiento de señales, ya sea en audio, imágenes o datos multidimensionales. Su capacidad para descomponer una señal en sus componentes frecuenciales permite revelar estructuras ocultas y operar sobre ellas de manera precisa. Comprender cómo se representa una imagen en el dominio de la frecuencia —y las condiciones necesarias para que esta representación sea fiel, como lo establece el teorema de muestreo de Nyquist-Shannon— es fundamental antes de aplicar cualquier técnica de filtrado.

En este artículo nos enfocamos en los fundamentos teóricos y computacionales que permiten transformar una imagen desde el dominio espacial al dominio frecuencial. También se abordó el fenómeno del aliasing, una distorsión crítica que puede surgir cuando las señales no se muestrean adecuadamente. En artículos posteriores, exploraremos con mayor profundidad el filtrado en el dominio de la frecuencia, analizando distintos tipos de filtros (ideales, Butterworth, gaussianos, etc.), su implementación práctica, y sus efectos visuales y espectrales en imágenes reales. Esta base conceptual será clave para comprender por qué y cómo aplicar estos filtros de forma eficaz en aplicaciones reales de procesamiento digital de imágenes.

Podemos imaginar al pipeline gráfico como una máquina de procesamiento en la que introducimos nuestros datos más básicos —como los vértices— y, a medida que avanzan por cada etapa, estos datos se transforman según los comandos e instrucciones que hemos definido en nuestro programa. Al final del recorrido, obtenemos una imagen 2D lista para mostrarse en pantalla.

English version of this article. Click here

Graphics pipeline

Para comprender mejor estos conceptos, exploraremos cómo funciona cada etapa del proceso, acompañándola con el código necesario en C++, OpenGL y GLSL.

vertex array

Aunque no es técnicamente parte del pipeline de renderizado, el proceso de obtención de los vértices que definen un objeto 3D es muy importante. Estos vértices suelen obtenerse mediante modelado 3D, donde se manipulan nubes de puntos para crear mallas poligonales (típicamente trianguladas).

En ejemplos posteriores trabajaremos con modelos 3D complejos, pero para esta demostración usaremos una geometría simple: un cuadrado construido con dos triángulos

    // Array de vértices para un cuadrado (dos triángulos)
    float vertexPositions[] = {
        // Primer triángulo
        -0.5f, -0.5f, 0.0f, // esquina inferior izquierda
        0.5f, -0.5f, 0.0f, // esquina inferior derecha
        0.5f,  0.5f, 0.0f, // esquina superior derecha

        // Segundo triángulo
        -0.5f, -0.5f, 0.0f, // esquina inferior izquierda
        0.5f,  0.5f, 0.0f, // esquina superior derecha
        -0.5f,  0.5f, 0.0f  // esquina superior izquierda
    };

Vertex Shader

El vertex shader es la primera etapa programable del pipeline gráfico de OpenGL y también la única obligatoria: Su función principal es transformar las posiciones de los vértices (de coordenadas del mundo a coordenadas de pantalla) y generar información que será utilizada por las siguientes etapas del pipeline.

Vertex Pulling

Antes de que se ejecute el vertex shader, OpenGL realiza automáticamente una etapa fija conocida como vertex pulling. Esta etapa no es programable por el usuario, y su tarea es extraer los datos de los vértices desde la memoria (almacenados en buffers) y proporcionarlos al shader como entradas.

Estos datos suelen residir en objetos llamados VBOs (Vertex Buffer Objects), que contienen atributos como posiciones, normales o coordenadas de textura y la forma en que estos atributos se organizan y enlazan se encapsula en un VAO (Vertex Array Object).

Configuración en C++

A continuación se muestra cómo se configura configura el VBO y VAO

glGenVertexArrays(numVAOs, vao);                 // Genera un VAO (almacena la configuración de atributos)
glBindVertexArray(vao[0]);                       // Activa el VAO

glGenBuffers(numVBOs, vbo);                      // Genera un VBO (almacena datos de vértices)
glBindBuffer(GL_ARRAY_BUFFER, vbo[0]);           // Lo enlaza como buffer de tipo GL_ARRAY_BUFFER
glBufferData(GL_ARRAY_BUFFER, sizeof(vertexPositions), vertexPositions, GL_STATIC_DRAW);  
// Carga los datos de los vértices al buffer

glEnableVertexAttribArray(0);                    // Habilita el atributo de vértice en la ubicación 0
glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 0, 0); 
// Define cómo deben interpretarse los datos del VBO: 
// - índice 0 (layout location)
// - 3 componentes por vértice (x, y, z)
// - tipo GL_FLOAT
// - sin normalizar
// - sin separación entre atributos (stride = 0)
// - sin desplazamiento inicial (offset = 0)

Correspondencia en el Shader

En el vertex shader, los atributos de vértice se declaran con el calificador in, que indica que los datos llegarán desde fuera del shader (desde la etapa de vertex pulling)

    const char *vshaderSource =
        "#version 450\n"
        "layout(location=0) in vec3 position;\n"
        "void main(void) {\n"
        "    gl_Position = vec4(position, 1.0);\n"
        "}\n";

• in se usa para recibir atributos de entrada. En el vertex shader, suele usarse para atributos como posición, color o normales.

• out se usa para enviar información a la siguiente etapa, como un fragment shader o geometry shader.

• layout(location=0) indica que este atributo corresponde al índice 0, el mismo que configuramos desde C++ con glVertexAttribPointer.

• in vec3 position; declara la variable que recibirá la posición de cada vértice.

• En el cuerpo de main(), esa posición se convierte en un vec4 y se asigna a gl_Position, la variable especial que representa la posición final del vértice.

Esta rutina de entrada y salida es la forma principal de transmitir información personalizada entre las distintas etapas del pipeline gráfico en OpenGL. A través de los calificadores in y out, no solo es posible llevar posiciones de vértices desde la aplicación al vertex shader, sino también pasar datos adicionales desde fuera como colores, normales, coordenadas de textura o cualquier otro atributo necesario para el procesamiento gráfico.

Primitivas y ensamblaje

Una vez que el vertex shader ha transformado las posiciones de los vértices y ha enviado sus datos a las etapas posteriores, el pipeline gráfico necesita agrupar esos vértices en unidades geométricas llamadas primitivas. Estas primitivas son la base sobre la cual OpenGL genera la geometría visible en pantalla. Las más comunes incluyen puntos, líneas y triángulos, siendo estos últimos la forma más utilizada en el renderizado 3D moderno.

En nuestro ejemplo, hemos definido un arreglo de vértices que representa dos triángulos, los cuales juntos forman un cuadrado. Estos vértices se almacenan en un VBO y son interpretados por OpenGL según el modo de dibujo especificado en la función glDrawArrays:

glDrawArrays(GL_TRIANGLES, 0, 6);

El primer parámetro (GL_TRIANGLES) le indica a OpenGL que cada grupo de tres vértices consecutivos debe interpretarse como un triángulo independiente. Esto implica que los vértices serán consumidos de la siguiente manera:

• Vértices 0, 1 y 2 → primer triángulo

• Vértices 3, 4 y 5 → segundo triángulo

Rasterización

Una vez que las primitivas han sido correctamente ensambladas a partir de los vértices procesados por el vertex shader, el pipeline gráfico de OpenGL continúa con una serie de etapas cruciales que determinan qué partes de esas primitivas realmente se dibujarán en pantalla. Este conjunto de pasos intermedios asegura que solo los fragmentos visibles y válidos de la geometría lleguen al fragment shader.

Clipping

La primera de estas etapas es el clipping, cuyo objetivo es eliminar las partes de las primitivas que quedan fuera del espacio visible de la escena. Este espacio visible es definido por el sistema de coordenadas de recorte (clip space), que abarca desde -1 hasta 1 en cada eje después de la transformación por la matriz de proyección.

Por ejemplo, si una primitiva cruza los límites de este volumen, OpenGL la recorta automáticamente y conserva solo la porción que permanece dentro del espacio visible. Este proceso es automático y no requiere intervención del programador.

🛈 El clipping puede modificar las primitivas originales, generando nuevos vértices en los bordes del volumen de recorte. Exploraremos el proceso con más detalle en futuros programas.

Transformación al viewport

Luego del clipping, los vértices que han sobrevivido son transformados desde coordenadas normalizadas (NDC, Normalized Device Coordinates) al sistema de coordenadas de pantalla mediante la transformación de viewport. Esta etapa adapta la escena para que se dibuje en una región específica de la ventana definida por el usuario (el viewport), usualmente con glViewport().

Este paso toma en cuenta el tamaño real de la ventana y convierte las coordenadas flotantes en coordenadas absolutas de píxeles, permitiendo que las primitivas se alineen correctamente en la pantalla.

🛈 Aunque aquí se menciona brevemente, el viewport y su rol en el pipeline serán explorados con mayor profundidad más adelante.

Culling (descartado de caras)

Antes de que las primitivas lleguen a la rasterización, OpenGL puede realizar una etapa llamada culling para descartar aquellas caras que no deberían ser visibles desde la posición actual de la cámara. Esto se basa en la orientación de los vértices (conocido como winding order): si los vértices se ordenan en sentido horario o antihorario.

Esta técnica es útil para mejorar el rendimiento, ya que evita renderizar superficies ocultas, como la parte trasera de un objeto sólido.

🛈 El culling también se tratará de forma detallada en un artículo posterior, incluyendo su configuración con glEnable(GL_CULL_FACE).

Rasterización de primitivas

Finalmente, las primitivas visibles pasan por la etapa de rasterización, donde se convierten en fragmentos. Aquí, OpenGL determina qué píxeles de la pantalla están cubiertos por la primitiva y genera un fragmento por cada uno de ellos. Estos fragmentos contienen información interpolada de los vértices originales, como color, coordenadas de textura o normales.

Cada fragmento generado será enviado al fragment shader, que se encargará de calcular su color final (y otras propiedades) antes de ser escrito al framebuffer.

La rasterización marca la transición del espacio continuo de coordenadas al mundo discreto de los píxeles, y es una de las etapas más intensivas del pipeline.

Fragment Shader

Una vez que la rasterización ha generado todos los fragmentos (uno por cada píxel cubierto por una primitiva), la siguiente etapa programable del pipeline gráfico es el fragment shader. Su tarea principal es calcular el color de cada fragmento individual, y potencialmente otras propiedades como la profundidad (depth), transparencia o coordenadas para mapas de texturas.

A diferencia del vertex shader, que opera por cada vértice, el fragment shader se ejecuta una vez por fragmento, lo que puede traducirse en millones de ejecuciones por cuadro en una escena compleja. Es aquí donde se definen los detalles visuales más importantes como: iluminación, texturas, reflejos, sombreado, etc.

este fragment shader asigna a cada fragmento un color rojo puro:

const char *fshaderSource =
    "#version 450\n"
    "out vec4 color;\n"
    "void main(void) {\n"
    "    color = vec4(1.0, 0.0, 0.0, 1.0);\n" // Rojo
    "}\n";

• out vec4 color;: Declara una variable de salida llamada color. Esta variable será el valor final que se escriba en el framebuffer para cada fragmento.

• vec4(1.0, 0.0, 0.0, 1.0): se asigna el color rojo en a cada fragmento.

En este caso, como no hay atributos adicionales, el fragment shader simplemente actúa como un generador de color constante.

Etapas finales: pruebas y mezcla de fragmentos

OpenGL realiza una serie de pruebas conocidas como etapas finales. Estas pruebas permiten controlar si el fragmento será realmente escrito en el framebuffer y cómo debe combinarse con los valores ya presentes en él. Estas etapas, aunque son parte del pipeline, pueden habilitarse o configurarse según el comportamiento deseado.

Pruebas de fragmentos (Final Fragment Tests)

Las pruebas más comunes son:

• Prueba de profundidad (Depth Test)
  Determina si un fragmento debe escribirse o no, comparando su valor de profundidad (gl_FragDepth) con el que ya está almacenado en el depth buffer. Si la prueba falla, el fragmento es descartado.
  Se activa con:

    glEnable(GL_DEPTH_TEST);
  

• Prueba de stencil (Stencil Test)
  Permite crear máscaras complejas en pantalla, útiles para efectos como espejos o reflejos. Se activa con:

    glEnable(GL_STENCIL_TEST);
  

• Prueba de scissor (Scissor Test)
  Limita el área de la ventana donde se puede dibujar. Es útil para renderizar solo una región específica de la pantalla.

    glEnable(GL_SCISSOR_TEST);
    glScissor(x, y, width, height);
  

Estas pruebas se ejecutan en orden, y si alguna de ellas falla, el fragmento se descarta, ahorrando cómputo y evitando escribir resultados innecesarios.

Blending: combinando colores en pantalla

Si un fragmento pasa todas las pruebas, entonces OpenGL puede combinar su color con el color que ya se encuentra en el framebuffer. Este proceso se llama blending (mezcla), y es esencial para representar transparencia, efectos de iluminación suaves, partículas, humo, etc.

🛈 Todas esta pruebas y configuraciones sera tratará de forma detallada en programas posteriores.

Resultados

Finalmente, si el fragmento pasa las pruebas y el blending ha sido aplicado (si está activo), el resultado final se escribe en el framebuffer. Este es el paso que realmente altera los píxeles de la ventana visible, concluyendo así el procesamiento de la imagen para ese cuadro.

Ejemplo 1

Ejemplo 2

puedes usar otras primitivas como las lineas para dibujar la geometría.

    glDrawArrays(GL_LINE_LOOP, 0, 6); // dibujar el cuadrado como un loop de lineas

Ejemplo 3

Con una pequeña modificación en el vertex shader, es posible asignar un color específico a cada vértice y transmitir esa información al fragment shader utilizando las variables out y in, que permiten compartir datos entre etapas del pipeline.

    const char *vshaderSource =
        "#version 450\n"
        "layout(location=0) in vec3 position;\n"
        "out vec4 color_;\n"
        "void main(void) {\n"
        "    gl_Position = vec4(position, 1.0);\n"
        "    if(gl_VertexID == 0 || gl_VertexID == 3) {\n"
        "        color_ = vec4(1.0, 0.0, 0.0, 1.0); // Rojo para los vértices 0 y 3\n"
        "    } else if(gl_VertexID == 1 || gl_VertexID == 5) {\n"
        "        color_ = vec4(0.0, 0.0, 1.0, 1.0); // Verde para los vértices 1 y 4\n"
        "    } else {\n"
        "        color_ = vec4(0.0, 1.0, 0.0, 1.0); // Azul para los vértices 2 y 5\n"
        "    }\n"
        "}\n";

¿Qué hace este shader?

• Primero, se posiciona cada vértice en el espacio de clip (gl_Position) usando los datos recibidos desde el VBO (vec3 position).

• Luego, se utiliza la variable incorporada gl_VertexID para asignar un color específico a ciertos vértices. Esta variable representa el índice del vértice que se está procesando en ese momento.

• Dependiendo del valor de gl_VertexID, se asigna un color diferente a color_, que es una variable out. Esta variable será enviada a la siguiente etapa del pipeline: el fragment shader.

Esto permite definir colores por vértice sin necesidad de pasar un segundo atributo en el VBO, utilizando solo la lógica dentro del shader.

    const char *fshaderSource =
        "#version 450\n"
        "out vec4 color;\n"
        "in vec4 color_;\n"
        "void main(void) {\n"
        "    color =  color_;\n" 
        "}\n";

• Aquí, el fragment shader recibe el color generado por el vertex shader a través de la variable in color_.

• El valor recibido no es exactamente el que se escribió en el vertex shader, sino una versión interpolada que OpenGL calcula automáticamente en la etapa de rasterización, dependiendo de la posición del fragmento dentro del triángulo.

• Finalmente, este color se asigna a la salida final del fragment shader, la variable out color, que se convierte en el color visible del píxel.

Cada etapa del pipeline gráfico cumple una función específica y secuencial en la transformación de los datos de la escena, preparando y refinando la información hasta convertirla en fragmentos listos para mostrarse en pantalla. En esta sección hemos realizado un recorrido general por cada una de estas fases, entendiendo su papel dentro del flujo de renderizado. Más adelante, exploraremos cómo estas etapas pueden ser controladas y modificadas para construir escenas más complejas, dinámicas e interesantes.

Puedes encontrar el código fuente en el siguiente repositorio

English version of this article

https://medium.com/p/aeb0def49e5a

Este enfoque facilita aprovechar el paralelismo de las GPU modernas: operaciones como transformar vértices, aplicar texturas o calcular colores de píxeles pueden ejecutarse de forma masiva y simultánea, lo que permite alcanzar un rendimiento elevado en aplicaciones interactivas y en tiempo real.

Sin embargo, el avance del hardware y la necesidad de un control más preciso han impulsado el desarrollo de APIs de bajo nivel como Vulkan, que ofrecen acceso directo a la GPU y una personalización detallada de cada etapa del proceso gráfico. Aunque OpenGL sigue siendo ampliamente utilizado —especialmente por su simplicidad y su curva de aprendizaje más amigable—, en contextos donde se busca la máxima eficiencia y control, Vulkan se está convirtiendo en la opción preferida.

Ahora que entendemos el papel de OpenGL en la programación gráfica y por qué sigue siendo una herramienta fundamental para iniciarse en este campo, es momento de preparar el entorno necesario para comenzar a escribir nuestros primeros programas. Esto implica integrar correctamente las bibliotecas complementarias, gestionar dependencias y establecer una estructura de proyecto robusta que facilite el desarrollo a medida que avanzamos.

Configuración y Estructura del Entorno

Antes de comenzar a escribir código, es necesario contar con un entorno de desarrollo que nos permita compilar y ejecutar nuestras aplicaciones.

Para trabajar con OpenGL de forma cómoda necesitamos integrar otras bibliotecas —como GLFW para el manejo de ventanas y contextos, GLAD para la carga de funciones—GLM para el manejo del algebra lineal entre otras que estaremos usando a lo largo de esta serie, para lograr la inclusion correcta utilizaremos CMake, que nos permiten coordinar todos estos componentes de forma ordenada.

En esta sección te explico cómo está estructurado el entorno de desarrollo, Si bien configurar todo esto puede requerir algo de experiencia, ya tienes el proyecto preparado en el repositorio principal de esta serie, así que puedes empezar directamente. si ya dominas estas herramientas, también tienes la libertad de montar tu propia configuración desde cero.

Estructura del Proyecto

El proyecto está organizado en carpetas específicas que separan claramente el código fuente, las librerías, los binarios y los shaders (la distribución del proyecto cambiara a lo largo de la serie).

A continuación, se muestra una visión general de la estructura:

graphics/
├── src/                # Archivos fuente .cpp, uno por cada programa
│   └── shaders/        # Shaders GLSL utilizados por los programas
├── libs/               # Librerías locales como GLAD
├── build/              # Carpeta generada por CMake para la compilación
├── CMakeLists.txt      # Script principal de configuración del proyecto
├── conanfile.py        # Script de Conan para gestión de dependencias
├── buildLinux.py       # Script Python para compilar en Linux
├── buildWindows.py     # Script Python para compilar en Windows
└── README.md           # Instrucciones y documentación del proyecto

Construcción del proyecto

CMake es una herramienta multiplataforma ampliamente utilizada en proyectos C++ para generar scripts de compilación adaptados a distintos entornos. En esta serie, nos enfocaremos principalmente en los sistemas operativos Windows y Linux, que son los más comunes entre los desarrolladores. Si bien CMake es sumamente poderosa y flexible, también puede resultar compleja para quienes no están familiarizados con ella. Por eso, aunque haremos uso de esta herramienta y puede que aparezcan algunas referencias a su funcionamiento, el enfoque de esta serie será mantener las cosas lo más simples posible, ya que el objetivo no es aprender CMake, sino centrarnos en la programación gráfica con OpenGL.

• Se requiere CMake versión 3.25 o superior.

• Se configura el proyecto para usar C++23.

• Se incluyen manualmente subdirectorios como libs/glad.

• Se integran las dependencias externas glfw, glm y OpenGL mediante find_package, que son gestionadas por Conan.

• Se detectan automáticamente todos los archivos .cpp en la carpeta src/ y se compilan como ejecutables individuales.

• Los ejecutables se colocan en build/programs/.

• Los shaders (.glsl) se copian automáticamente a build/programs/shaders/, garantizando que estén disponibles junto al ejecutable al momento de la ejecución.

•     file(GLOB SOURCE_FILES ${SOURCE_MAIN_DIR}/*.cpp)
  
      foreach(SOURCE_FILE ${SOURCE_FILES})
          get_filename_component(SOURCE_FILE_NAME ${SOURCE_FILE} NAME_WE)
  
          add_executable(${SOURCE_FILE_NAME} ${SOURCE_FILE})
          target_link_libraries(${SOURCE_FILE_NAME} PRIVATE glad glfw glm::glm ${OPENGL_LIBRARIES})
  
          set_target_properties(${SOURCE_FILE_NAME} PROPERTIES
              RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/programs
          )
      endforeach()
  

  Esto permite agregar nuevos programas simplemente añadiendo un nuevo archivo .cpp en src/, sin necesidad de modificar el archivo CMake.

Gestión de Dependencias

En este caso, utilizamos Conan, un moderno gestor de paquetes para C/C++, para descargar e instalar las dependencias externas como GLFW y GLM. Esto elimina la necesidad de configurar rutas manualmente o instalar librerías a mano.

El archivo conanfile.py especifica las librerías requeridas y sus versiones. Para preparar el entorno, basta con ejecutar

conan install . --build=missing

Esto descargará y configurará automáticamente todas las dependencias necesarias para que CMake pueda encontrarlas.

Scripts de Construcción

Para facilitar el proceso de compilación en distintos sistemas operativos, el proyecto incluye scripts auxiliares:

• buildLinux.py: Genera y compila el proyecto en sistemas Linux.

• buildWindows.py: Hace lo mismo en Windows, utilizando rutas y generadores adecuados para ese entorno.

Primer Programa con OpenGL

En este primer ejemplo, creamos una ventana a pantalla completa utilizando GLFW y limpiamos la pantalla con un color rojo utilizando OpenGL. Es una excelente forma de comprobar que nuestra configuración del entorno gráfico funciona correctamente.

A continuación se presenta el código fuente del programa y su análisis detallado:

hello window

#include <glad/glad.h>  // Carga de funciones OpenGL
#include <GLFW/glfw3.h> // Manejo de ventanas y entrada
#include <iostream>     // Salida de texto a consola

Estas tres cabeceras son fundamentales: glad.h para inicializar funciones OpenGL modernas, glfw3.h para crear y gestionar la ventana, y <iostream> para imprimir información del monitor.

Inicialización y función de dibujo

void init(GLFWwindow* window){
}

void display(GLFWwindow* window){
    glClear(GL_COLOR_BUFFER_BIT);       
    glClearColor(1.0f, 0.0f, 0.0f, 1.0f);
}

• La función init está preparada para futuras inicializaciones, como la carga de shaders o configuración de buffers.

• La función display establece el color de fondo (rojo) y limpia el color buffer, lo cual borra la pantalla cada vez que se dibuja un nuevo frame.

Función principal

int main() {

    // Initialize GLFW, terminate program if failed
    if (!glfwInit()) {exit(EXIT_FAILURE);}

    // Set window properties
    glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 4);                  
    glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);                  
    glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);  
    glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE);

Se inicia GLFW. Si falla, el programa termina.

Estas instrucciones configuran una ventana con OpenGL versión 4.3 en modo core, lo cual exige el uso de funciones modernas (sin funciones obsoletas).

Creación de ventana

    const GLFWvidmode* mode = glfwGetVideoMode(glfwGetPrimaryMonitor());
    GLFWwindow* window = glfwCreateWindow(mode->width, mode->height, " 01_hello_window ", nullptr, nullptr);

Aquí se crea una ventana a pantalla completa con la resolución nativa del monitor principal. También se imprime información útil del modo de video:

    glfwMakeContextCurrent(window);

    if(!gladLoadGLLoader((GLADloadproc)glfwGetProcAddress)){
        std::cout << "failed to initialize GLAD " << std::endl;
        return -1;
    }

Se establece el contexto OpenGL actual y se inicializa GLAD, que permite usar todas las funciones de OpenGL que necesitemos (por ejemplo, glClearColor, glGenBuffers, etc.).

Ciclo principal

    while (!glfwWindowShouldClose(window)) {
        display(window);          
        glfwPollEvents();        
        glfwSwapBuffers(window); 
    }

• display() limpia la pantalla con color rojo.

• glfwPollEvents() procesa eventos del sistema como teclado o mouse.

• glfwSwapBuffers() intercambia los framebuffers para mostrar la imagen renderizada.

Resultado

Al ejecutar este programa, deberías ver una ventana a pantalla completa (o modo ventana si modificas el código) con un fondo completamente rojo. Si ves esto, ¡felicitaciones! Tu pipeline básico de OpenGL está funcionando correctamente.

Este primer acercamiento a OpenGL marca el inicio de un recorrido fascinante por el desarrollo gráfico en tiempo real. Hemos creado una ventana, establecido el contexto de OpenGL y generado un color de fondo simple, sentando así las bases sobre las que construiremos conceptos más avanzados como shaders, buffers y geometría 3D. A medida que avancemos, profundizaremos en el funcionamiento interno de la GPU y exploraremos técnicas modernas que nos permitirán aprovechar al máximo su poder de cómputo. Te invito a continuar con los siguientes tutoriales, donde desglosaremos el pipeline gráfico y daremos vida a nuestras primeras escenas interactivas.

English version of this article. click here.

Durante muchos años, ingenieros y científicos han investigado los procesos de la visión con el objetivo de lograr que una computadora “vea”, lo cual no es una tarea sencilla. Mientras los seres humanos percibimos el mundo en tres dimensiones, los sistemas de visión artificial capturan la realidad a través de sensores como cámaras, obteniendo como resultado una representación bidimensional del entorno: una imagen.

“Una imagen puede definirse como una función bidimensional f(x,y), donde x y y son coordenadas espaciales (del plano), y la amplitud de f en cualquier par de coordenadas (x,y) se denomina intensidad o nivel de gris de la imagen en ese punto.”
— Gonzalez & Woods, Digital Image Processing

La imagen digital está compuesta por un número finito de elementos dispuestos en una matriz de tamaño n × n. Cada uno de estos elementos, conocidos como píxeles, posee una posición específica y un valor que representa la intensidad en ese punto.

Sin embargo, la mera captura de una imagen no garantiza comprensión por sí misma. Para que pueda ser útil en tareas concretas es necesario transformar esa matriz de intensidades en información significativa. Es aquí donde entran en juego el procesamiento de imágenes y la visión por computadora, como etapas fundamentales dentro de un sistema que busca interpretar y actuar sobre el mundo visual.

Aunque no existe una frontera clara entre el procesamiento de imágenes y la visión por computadora —pues ambos comparten principios, métodos y herramientas—, una revisión de sus etapas puede ayudarnos a entender mejor cómo se relacionan y qué papel cumplen dentro de los sistemas de percepción artificial.

El punto de partida suele ser la adquisición y el procesamiento de los datos crudos capturados por sensores, típicamente cámaras. En esta fase inicial, conocida como procesamiento de imágenes, se trabaja directamente con la información capturada para mejorar su calidad visual o corregir defectos. El objetivo es transformarla en una versión más útil para análisis posteriores. Técnicas como el realce de contraste, la reducción de ruido, la corrección de distorsiones ópticas o la restauración de imágenes degradadas forman parte de esta etapa, en la que la salida es otra imagen, generalmente más clara o informativa que la original.

Una vez procesada la imagen, se da paso a una segunda etapa: el análisis estructural, que busca extraer información significativa. Aquí se realizan operaciones como la segmentación de la imagen —es decir, dividirla en regiones u objetos de interés— y la extracción de características relevantes como contornos, formas, colores o texturas. Estas características se representan y describen de manera que puedan ser entendidas por un sistema automatizado. Este análisis proporciona una base estructurada sobre la cual se pueden realizar tareas más complejas.

Finalmente, entramos en el dominio de la visión por computadora, cuyo propósito es emular la capacidad humana de comprender e interpretar el entorno visual. A diferencia del procesamiento, que solo transforma la imagen, y del análisis, que organiza sus componentes, en esta etapa se busca comprender el contenido visual mediante el uso de algoritmos de inteligencia artificial y aprendizaje automático. La visión por computadora permite realizar tareas como la clasificación de objetos, el reconocimiento facial, la detección de movimiento y la toma de decisiones basada en lo que “ve” el sistema. En esencia, se trata de construir sistemas que no solo perciban, sino que también razonen e interactúen con su entorno de forma inteligente.

Aplicación Práctica del Reconocimiento de Imágenes

Imagina que se te asigna la tarea de registrar la fecha de una gran cantidad de cheques. Hacerlo manualmente sería tedioso e implicaría una inversión enorme de tiempo. pero como eres seguidor de este blog has aprendido técnicas de procesamiento de imágenes y visión por computadora, por lo que decides automatizar la tarea mediante un sistema de reconocimiento de dígitos capaz de interpretar la fecha directamente a partir de la imagen de cada cheque.

El primer paso consiste en adquirir la imagen del cheque mediante una cámara o escáner. Dado que el interés está centrado únicamente en la fecha —específicamente en los dígitos que la componen—, extraemos la región donde esta se encuentra. Este recorte permite enfocarse en el área de interés, lo que reduce la complejidad del proceso de segmentación y facilita que cada dígito pueda ser tratado como una imagen independiente.

Antes de poder pasar estas imágenes a un modelo de clasificación, es necesario asegurarse de que cumplan con ciertos requisitos técnicos . Por ejemplo, los dígitos deben tener un tamaño uniforme (comúnmente 28x28 píxeles), un buen contraste entre el fondo y el número, ademas estar libres de ruido visual que pueda interferir con el análisis para la clasificacion, para lograrlo es necesario aplicar preprocesamiento como la binarización, la inversión de colores y operaciones morfológicas, que eliminan imperfecciones y realzan la estructura de los dígitos.

Con las imágenes ya limpias y normalizadas, se procede a la etapa más importante del sistema: el reconocimiento automático. La extracción de características se realiza mediante técnicas clásicas, utilizando algoritmos diseñados manualmente, como descriptores de contorno o transformadas matemáticas. No obstante, en este caso se emplea una solución moderna y considerablemente más potente: una red neuronal convolucional (CNN, por sus siglas en inglés).

Las CNN tienen la capacidad de aprender directamente de los datos, sin requerir la especificación explícita de qué buscar en la imagen. Lo hacen mediante una arquitectura en la que se aplican filtros convolucionales que recorren la imagen para detectar patrones locales, como bordes o líneas. Estas operaciones permiten que la red capture progresivamente, a través de distintas capas, características cada vez más complejas: desde trazos básicos hasta formas específicas asociadas a los números. A diferencia de los enfoques clásicos, este modelo aprende de manera automática qué rasgos son relevantes para distinguir un dígito del 0 al 9.

Una vez completado el entrenamiento del modelo, utilizando un conjunto de datos representativo (como el conocido dataset MNIST, que contiene miles de ejemplos de dígitos manuscritos), el sistema está listo para realizar predicciones. En este punto del proceso, se proporciona al modelo una imagen correspondiente a un dígito previamente segmentado del cheque. La red neuronal analiza sus características visuales y devuelve la clase que considera más probable, es decir, el número que dicho dígito representa

Al combinar las predicciones de todos los dígitos, el sistema reconstruye la fecha completa, formateándola en una representación estándar como "AAAA-MM-DD". De esta manera, hemos construido un flujo automatizado que, a partir de una imagen, es capaz de identificar con precisión la fecha de emisión de un cheque, replicando una tarea visual humana mediante una cadena integrada de procesamiento de imágenes, análisis estructural y visión por computadora.

Principales areas de aplicación

Inspección industrial.
En la industria manufacturera, el procesamiento de imágenes permite automatizar la inspección visual de productos, detectando defectos con una precisión mucho mayor que la inspección humana. Estos sistemas son ampliamente usados en sectores como el automotriz, farmacéutico y de semiconductores, donde se comparan piezas reales con modelos de referencia para identificar imperfecciones, componentes faltantes o errores de ensamblaje.

Análisis de documentos y reconocimiento óptico.
Las tecnologías de reconocimiento óptico de caracteres (OCR) han transformado el manejo de documentos. Permiten desde la lectura automática de direcciones postales hasta el escaneo y verificación de billetes y documentos legales. También hacen posible la lectura de matrículas en sistemas de peaje o seguridad vial, así como la decodificación de códigos QR en entornos comerciales.

Transporte inteligente.
La visión por computadora ha revolucionado el sector del transporte. Cámaras instaladas en calles y vehículos analizan el flujo vehicular, detectan infracciones, miden la ocupación de carriles y ayudan a regular los semáforos. En los automóviles modernos, permiten funciones como la detección de peatones, el seguimiento de carriles y el aparcamiento autónomo, siendo una piedra angular de los sistemas de conducción asistida.

Seguridad y vigilancia.
En el ámbito de la seguridad, estas tecnologías permiten la identificación de personas mediante reconocimiento facial, la detección de objetos peligrosos en aeropuertos, y el monitoreo continuo de espacios públicos o privados. Los sistemas de video vigilancia inteligentes pueden incluso analizar patrones de movimiento o identificar comportamientos anómalos en tiempo real.

Teledetección.
La observación remota del planeta a través de satélites y drones genera una enorme cantidad de datos visuales. El procesamiento de imágenes se utiliza aquí para monitorear la deforestación, estimar la humedad del suelo, localizar depósitos minerales o seguir el cambio climático. Gracias a estas imágenes multiespectrales, es posible estudiar el impacto humano sobre el entorno con gran detalle.

Imágenes científicas y médicas.
En medicina y ciencia, las imágenes son una herramienta clave para explorar lo invisible. Desde resonancias magnéticas y tomografías en hospitales hasta imágenes microscópicas en biología, estas técnicas permiten diagnosticar enfermedades, guiar cirugías o estudiar organismos a nivel celular. En muchos casos, los análisis se apoyan en algoritmos de segmentación, registro y clasificación automática de estructuras.

Robótica y sistemas autónomos.
Los robots industriales y móviles utilizan visión por computadora para interactuar con su entorno. Pueden identificar piezas, ensamblar componentes, navegar por un espacio o seguir a una persona. En entornos más complejos, como los vehículos autónomos, estas tecnologías son esenciales para mapear el entorno, evitar obstáculos y tomar decisiones en tiempo real.

Más allá del análisis estructural y numérico, el procesamiento de imágenes también converge con aspectos estéticos y expresivos. Aunque muchas de sus técnicas fueron concebidas con fines científicos o industriales, hoy también son herramientas clave en aplicaciones creativas. Por ejemplo, el mejoramiento de imágenes no solo busca resaltar bordes o eliminar ruido, sino que puede utilizarse para realzar la belleza de un retrato mediante la detección y optimización de rasgos faciales. Asimismo, técnicas como la transferencia de estilo permiten fusionar el contenido de una imagen con la apariencia visual de una obra artística, logrando resultados visuales que combinan arte e inteligencia artificial.

Además, estas capacidades visuales son fundamentales en entornos inmersivos como la realidad virtual, donde es necesario reconstruir y mejorar escenas visuales en tiempo real para generar experiencias visuales más envolventes y realistas. Este cruce entre visión computacional y creatividad demuestra que, lejos de ser un campo rígido, el procesamiento de imágenes también abre caminos hacia lo subjetivo, lo artístico y lo sensorial.

Procesar y comprender imágenes va mucho más allá de una simple tarea técnica; es una forma de acercarnos a cómo vemos y entendemos el mundo. Desde mejorar una imagen capturada por una cámara hasta permitir que una máquina reconozca patrones visuales o incluso genere arte, este campo une precisión matemática con creatividad. Sus aplicaciones abarcan desde la medicina hasta la realidad virtual, pasando por expresiones artísticas donde la estética y la inteligencia artificial se combinan. A medida que la tecnología avanza, también lo hacen nuestras posibilidades de crear sistemas que no solo procesen imágenes, sino que también las interpreten, las embellezcan y, en cierto sentido, las comprendan.

Gonzalez, R. C., & Woods, R. E. (2008). Digital image processing (4th ed.). Pearson.

Birchfield, S. (2016). Image processing and analysis. Cengage Learning.

Puedes encontrar el código fuente en el siguiente repositorio.