diff --git a/README.md b/README.md index ac8da34..3f43396 100644 --- a/README.md +++ b/README.md @@ -113,6 +113,34 @@ MastersThesis/ --- +## Rendimiento GPU + +Se realizó una validación adicional con aceleración GPU para evaluar la viabilidad práctica del enfoque en escenarios de producción. + +**Tabla.** *Comparación de rendimiento CPU vs GPU.* + +| Métrica | CPU | GPU (RTX 3060) | Aceleración | +|---------|-----|----------------|-------------| +| Tiempo/Página | 69.4s | 0.55s | **126x** | +| Dataset completo (45 páginas) | ~52 min | ~25 seg | **126x** | + +*Fuente: Elaboración propia.* + +### Recomendación de Modelos + +**Tabla.** *Comparación de modelos PaddleOCR en RTX 3060.* + +| Modelo | VRAM | Recomendación | +|--------|------|---------------| +| **PP-OCRv5 Mobile** | 0.06 GB | ✓ Recomendado | +| PP-OCRv5 Server | 5.3 GB | ✗ Causa OOM en RTX 3060 | + +*Fuente: Elaboración propia.* + +**Conclusión:** Para hardware con VRAM limitada (≤6 GB), los modelos Mobile ofrecen el mejor balance entre precisión y recursos. La aceleración GPU hace viable el procesamiento en tiempo real. + +--- + ## Requisitos | Componente | Versión | @@ -252,12 +280,13 @@ python3 apply_content.py ## Trabajo Pendiente para Completar el TFM -### Contexto: Limitaciones de Hardware +### Contexto: Hardware -Este trabajo adoptó la estrategia de **optimización de hiperparámetros** en lugar de **fine-tuning** debido a: -- **Sin GPU dedicada**: Ejecución exclusivamente en CPU -- **Tiempo de inferencia elevado**: ~69 segundos/página en CPU -- **Fine-tuning inviable**: Entrenar modelos de deep learning sin GPU requeriría tiempos prohibitivos +Este trabajo adoptó la estrategia de **optimización de hiperparámetros** en lugar de **fine-tuning** debido a que el fine-tuning de modelos OCR requiere datasets etiquetados extensos y tiempos de entrenamiento prohibitivos. + +**Hardware utilizado:** +- **Optimización (CPU)**: Los 64 trials de Ray Tune se ejecutaron en CPU (~69s/página) +- **Validación (GPU)**: Se validó con RTX 3060 logrando 126x de aceleración (0.55s/página) La optimización de hiperparámetros demostró ser una **alternativa efectiva** al fine-tuning, logrando una reducción del 80.9% en el CER sin reentrenar el modelo. @@ -278,7 +307,7 @@ La optimización de hiperparámetros demostró ser una **alternativa efectiva** #### 2. Experimentación Adicional (Prioridad Media) - [ ] **Explorar `text_det_unclip_ratio`**: Este parámetro quedó fijado en 0.0. Incluirlo en el espacio de búsqueda podría mejorar resultados - [ ] **Comparativa con fine-tuning** (si se obtiene acceso a GPU): Cuantificar la brecha de rendimiento entre optimización de hiperparámetros y fine-tuning real -- [ ] **Evaluación con GPU**: Medir tiempos de inferencia con aceleración GPU para escenarios de producción +- [x] **Evaluación con GPU**: Validado con RTX 3060 - 126x más rápido que CPU (0.55s/página vs 69.4s/página) #### 3. Documentación y Presentación (Prioridad Alta) - [ ] **Crear presentación**: Preparar slides para la defensa del TFM diff --git a/apply_content.py b/apply_content.py index 367e92c..ca2139c 100644 --- a/apply_content.py +++ b/apply_content.py @@ -5,7 +5,7 @@ import re import os from bs4 import BeautifulSoup, NavigableString -BASE_DIR = '/Users/sergio/Desktop/MastersThesis' +BASE_DIR = os.path.dirname(os.path.abspath(__file__)) TEMPLATE = os.path.join(BASE_DIR, 'thesis_output/plantilla_individual.htm') DOCS_DIR = os.path.join(BASE_DIR, 'docs') diff --git a/docs/04_desarrollo_especifico.md b/docs/04_desarrollo_especifico.md index 105ea55..4df005c 100644 --- a/docs/04_desarrollo_especifico.md +++ b/docs/04_desarrollo_especifico.md @@ -1068,3 +1068,67 @@ Este capítulo ha presentado el desarrollo completo de la contribución: **Fuentes de datos:** - `src/raytune_paddle_subproc_results_20251207_192320.csv`: Resultados de 64 trials - `src/paddle_ocr_fine_tune_unir_raytune.ipynb`: Notebook principal del experimento + +### Validación con Aceleración GPU + +Para evaluar la viabilidad práctica del enfoque optimizado en escenarios de producción, se realizó una validación adicional utilizando aceleración GPU. Esta fase complementa los experimentos en CPU presentados anteriormente y demuestra la aplicabilidad del método cuando se dispone de hardware con capacidad de procesamiento paralelo. + +#### Configuración del Entorno GPU + +**Tabla 36.** *Especificaciones del entorno de validación GPU.* + +| Componente | Especificación | +|------------|----------------| +| GPU | NVIDIA GeForce RTX 3060 Laptop | +| VRAM | 5.66 GB | +| CUDA | 12.4 | +| Sistema Operativo | Ubuntu 24.04.3 LTS | +| Kernel | 6.14.0-37-generic | + +*Fuente: Elaboración propia.* + +El entorno de validación representa hardware de consumo típico para desarrollo de aplicaciones de machine learning, permitiendo evaluar el rendimiento en condiciones realistas de despliegue. + +#### Comparación CPU vs GPU + +Se evaluó el tiempo de procesamiento utilizando la configuración optimizada identificada en la fase anterior, comparando el rendimiento entre CPU y GPU. + +**Tabla 37.** *Rendimiento comparativo CPU vs GPU.* + +| Métrica | CPU | GPU (RTX 3060) | Factor de Aceleración | +|---------|-----|----------------|----------------------| +| Tiempo/Página | 69.4s | 0.55s | **126x** | +| Dataset completo (45 páginas) | ~52 min | ~25 seg | **126x** | + +*Fuente: Elaboración propia a partir de experimentos.* + +La aceleración de 126x obtenida con GPU transforma la aplicabilidad práctica del sistema. Mientras que el procesamiento en CPU limita el uso a escenarios de procesamiento por lotes sin restricciones de tiempo, la velocidad con GPU habilita casos de uso interactivos y de tiempo real. + +#### Comparación de Modelos PaddleOCR + +PaddleOCR ofrece dos variantes de modelos: Mobile (optimizados para dispositivos con recursos limitados) y Server (mayor precisión a costa de mayor consumo de memoria). Se evaluó la viabilidad de ambas variantes en el hardware disponible. + +**Tabla 38.** *Comparación de modelos Mobile vs Server en RTX 3060.* + +| Modelo | VRAM Requerida | Resultado | Recomendación | +|--------|----------------|-----------|---------------| +| PP-OCRv5 Mobile | 0.06 GB | Funciona correctamente | ✓ Recomendado | +| PP-OCRv5 Server | 5.3 GB | OOM en página 2 | ✗ Requiere >8 GB VRAM | + +*Fuente: Elaboración propia.* + +Los modelos Server, a pesar de ofrecer potencialmente mayor precisión, resultan inviables en hardware con VRAM limitada (≤6 GB) debido a errores de memoria (Out of Memory). Los modelos Mobile, con un consumo de memoria 88 veces menor, funcionan de manera estable y ofrecen rendimiento suficiente para el caso de uso evaluado. + +#### Conclusiones de la Validación GPU + +La validación con aceleración GPU permite extraer las siguientes conclusiones: + +1. **Aceleración significativa**: La GPU proporciona una aceleración de 126x sobre CPU, haciendo viable el procesamiento en tiempo real para aplicaciones interactivas. + +2. **Modelos Mobile recomendados**: Para hardware con VRAM limitada (≤6 GB), los modelos Mobile de PP-OCRv5 ofrecen el mejor balance entre precisión y recursos, funcionando de manera estable sin errores de memoria. + +3. **Viabilidad práctica**: Con GPU, el procesamiento de un documento completo (45 páginas) toma menos de 30 segundos, validando la aplicabilidad en entornos de producción donde el tiempo de respuesta es crítico. + +4. **Escalabilidad**: La arquitectura de microservicios dockerizados utilizada para la validación GPU facilita el despliegue horizontal, permitiendo escalar el procesamiento según demanda. + +Esta validación demuestra que la configuración optimizada mediante Ray Tune no solo mejora la precisión (CER: 7.78% → 1.49%) sino que, combinada con aceleración GPU, resulta prácticamente aplicable en escenarios de producción real. diff --git a/docs/05_conclusiones_trabajo_futuro.md b/docs/05_conclusiones_trabajo_futuro.md index 2aa5e3a..9db8d7d 100644 --- a/docs/05_conclusiones_trabajo_futuro.md +++ b/docs/05_conclusiones_trabajo_futuro.md @@ -69,7 +69,7 @@ El objetivo principal del trabajo era alcanzar un CER inferior al 2% en document 3. **Ground truth automático**: La extracción automática del texto de referencia puede introducir errores en layouts complejos. -4. **Ejecución en CPU**: Los tiempos de procesamiento (~69s/página) limitan la aplicabilidad en escenarios de alto volumen. +4. **Validación en entorno limitado**: Aunque se validó con GPU (126x más rápido que CPU, 0.55s/página), los experimentos se realizaron en hardware de consumo (RTX 3060). Hardware empresarial podría ofrecer mejor rendimiento. 5. **Parámetro no explorado**: `text_det_unclip_ratio` permaneció fijo en 0.0 durante todo el experimento. @@ -83,8 +83,6 @@ El objetivo principal del trabajo era alcanzar un CER inferior al 2% en document 3. **Dataset ampliado**: Construir un corpus más amplio y diverso de documentos en español. -4. **Evaluación con GPU**: Medir tiempos de inferencia con aceleración GPU. - ### Líneas de Investigación 1. **Transfer learning de hiperparámetros**: Investigar si las configuraciones óptimas para un tipo de documento transfieren a otros dominios. diff --git a/docs/metrics/metrics.md b/docs/metrics/metrics.md index 8f636e5..8b4e0e9 100644 --- a/docs/metrics/metrics.md +++ b/docs/metrics/metrics.md @@ -55,6 +55,21 @@ Para un proyecto de investigación con múltiples iteraciones de ajuste de hiper > **Ganador:** PaddleOCR (Mobile) - Mejor precisión (7.76% CER) con velocidad competitiva. +## Fases Experimentales + +Este documento presenta resultados de dos fases experimentales distintas realizadas durante el desarrollo del TFM. La primera fase corresponde a la optimización de hiperparámetros utilizando Ray Tune, ejecutada en CPU debido a las limitaciones de hardware iniciales. La segunda fase corresponde a la validación práctica con aceleración GPU para evaluar la viabilidad en escenarios de producción. + +**Tabla.** *Fases experimentales y sus características.* + +| Fase | Dataset | Hardware | Resultado Principal | +|------|---------|----------|---------------------| +| Optimización (CPU) | 24 páginas | CPU | CER: 7.78% → **1.49%** (80.9% mejora) | +| Validación (GPU) | 45 páginas | RTX 3060 | CER: 7.76% baseline, 0.55s/página | + +*Fuente: Elaboración propia.* + +La fase de optimización representa el **resultado principal del TFM** (CER 1.49%, precisión 98.51%). La fase de validación GPU confirma la viabilidad práctica del enfoque, demostrando una aceleración de 126x respecto a CPU. + ## Comparación de Servicios OCR ### Comparación de Precisión (CER - menor es mejor) @@ -96,6 +111,22 @@ flowchart LR 3. **EasyOCR**: El más lento (3.8x más lento que PaddleOCR) con precisión intermedia 4. **Eficiencia VRAM**: PaddleOCR Mobile usa solo 0.06 GB +## Configuración de Modelos + +| Servicio | Detección | Reconocimiento | ¿Correcto para Español? | +|----------|-----------|----------------|-------------------------| +| **PaddleOCR** | PP-OCRv5_mobile_det | PP-OCRv5_mobile_rec | Sí | +| **DocTR** | db_resnet50 | crnn_vgg16_bn | No (entrenado en inglés/francés) | +| **EasyOCR** | CRAFT | latin_g2.pth | Sí | + +### Notas sobre Modelos + +- **PaddleOCR**: Modelos server más precisos disponibles pero requieren >5.3 GB VRAM (OOM en RTX 3060) +- **DocTR**: Se probó modelo `parseq` como alternativa, resultó 2% peor CER y 2x más lento. El problema de diacríticos es de datos de entrenamiento, no de arquitectura +- **EasyOCR**: Modelo `latin_g2.pth` es correcto. Los problemas son del detector CRAFT, no del reconocimiento + +> **Conclusión sobre Fine-tuning:** Para documentos en español, **usar PaddleOCR directamente**. El fine-tuning de DocTR/EasyOCR no se justifica dado que PaddleOCR ya ofrece 31-36% mejor precisión sin configuración adicional. + ## Análisis de Errores (del debugset) ### PaddleOCR (Mejor - 7.76% CER) diff --git a/docs/metrics/metrics_doctr.md b/docs/metrics/metrics_doctr.md index 6dab47c..e22d6ed 100644 --- a/docs/metrics/metrics_doctr.md +++ b/docs/metrics/metrics_doctr.md @@ -102,3 +102,79 @@ curl -X POST http://localhost:8003/evaluate_full \ **Resultado:** CER 12.07%, WER 42.26%, 0.34s/página (sin mejora sobre la base) **Conclusión:** Los problemas de precisión de DocTR son a nivel de modelo, no ajustables por hiperparámetros. + +## Configuración del Modelo + +### Modelo Actual + +| Componente | Modelo | Estado | +|------------|--------|--------| +| Detección | `db_resnet50` | Correcto | +| Reconocimiento | `crnn_vgg16_bn` | Mejor opción disponible | + +El modelo `crnn_vgg16_bn` fue entrenado principalmente con datasets en inglés y francés, lo que explica la pérdida sistemática de diacríticos españoles (á, é, í, ó, ú, ñ). + +### Prueba con Modelo Alternativo (parseq) + +Se probó el modelo `parseq` (transformer) como alternativa: + +| Métrica | crnn_vgg16_bn | parseq | Resultado | +|---------|---------------|--------|-----------| +| **CER** | 12.07% | 12.32% | **+2% peor** | +| **WER** | 42.26% | 44.0% | **+4% peor** | +| Tiempo/Página | 0.34s | 0.70s | 2x más lento | +| Diacríticos | No | No | Sin mejora | + +**Conclusión:** El modelo `parseq` no mejora los diacríticos españoles y es más lento. Todos los modelos pre-entrenados de DocTR fueron entrenados principalmente en inglés/francés. Para español se requeriría **fine-tuning con corpus español**. + +### No Se Recomienda Cambio de Modelo + +Mantener `crnn_vgg16_bn` (más rápido, ligeramente mejor precisión). Los problemas de diacríticos son de **datos de entrenamiento**, no de arquitectura del modelo + +## Análisis de Errores del Debugset + +### Errores Observados + +| Ground Truth | DocTR | Tipo de Error | +|--------------|-------|---------------| +| `bibliográficas` | `bibliograficas` | Diacrítico omitido | +| `sección` | `seccion` | Diacrítico omitido | +| `Máster` | `Master` | Diacrítico omitido | +| `información` | `informacion` | Diacrítico omitido | +| `o amplían` | `O amplian` | Mayúscula incorrecta | +| Líneas separadas | Todo en una línea | **Estructura perdida** | + +### Problemas Críticos + +1. **Pérdida total de estructura**: Todo el texto de la página se colapsa en una sola línea +2. **Omisión sistemática de diacríticos**: TODOS los acentos españoles se pierden +3. **Errores de capitalización**: `o` → `O` en medio de oraciones + +### ¿Fine-tuning Recomendado? + +**Sí, para diacríticos.** El modelo CRNN de DocTR fue entrenado principalmente con textos en inglés y francés, lo que explica la omisión sistemática de acentos españoles. + +| Problema | ¿Fine-tuning ayuda? | Explicación | +|----------|---------------------|-------------| +| Diacríticos | **Sí** | Entrenar con corpus español enseñaría al modelo los acentos | +| Estructura de líneas | **No** | Problema arquitectural del modelo, no de entrenamiento | +| Capitalización | **Parcial** | Podría mejorar con datos de entrenamiento adecuados | + +### Cómo Fine-Tunear DocTR + +```python +from doctr.models import recognition_predictor +from doctr.datasets import RecognitionDataset + +# Cargar dataset español +train_set = RecognitionDataset( + img_folder="path/to/spanish/images", + labels_path="path/to/spanish/labels.json" +) + +# Fine-tune el modelo de reconocimiento +model = recognition_predictor(pretrained=True) +# ... configurar entrenamiento +``` + +Documentación: https://mindee.github.io/doctr/using_doctr/custom_models_training.html diff --git a/docs/metrics/metrics_easyocr.md b/docs/metrics/metrics_easyocr.md index 2c6ab51..9542342 100644 --- a/docs/metrics/metrics_easyocr.md +++ b/docs/metrics/metrics_easyocr.md @@ -111,3 +111,72 @@ curl -X POST http://localhost:8002/evaluate_full \ **Resultado:** CER 11.14%, WER 36.85%, 1.94s/página (mejora mínima) **Conclusión:** El ajuste de EasyOCR proporcionó mejora insignificante en el dataset completo. + +## Configuración del Modelo + +### Modelo Actual (Correcto para Español) + +| Componente | Modelo | Estado | +|------------|--------|--------| +| Detección | CRAFT | Correcto | +| Reconocimiento | `latin_g2.pth` | Correcto para español | +| Idiomas | `es,en` | Correcto | + +El modelo `latin_g2.pth` está optimizado para idiomas con escritura latina incluyendo español. **El modelo de reconocimiento es correcto** - los problemas observados (caracteres espurios `0`, `;`, `g`) son del **detector CRAFT**, no del modelo de reconocimiento. + +### No Se Requiere Cambio de Modelo + +A diferencia de DocTR, EasyOCR usa el modelo correcto para español. Los problemas son de detección (umbrales del CRAFT), no de reconocimiento. + +## Análisis de Errores del Debugset + +### Errores Observados + +| Ground Truth | EasyOCR | Tipo de Error | +|--------------|---------|---------------| +| `o figura` | `0 figura` | Letra `o` → número `0` | +| `tabla o figura` | `tabla 0 figura` | Letra `o` → número `0` | +| `grupal,` | `grupal;` | Coma → punto y coma | +| `páginas,` | `páginas;` | Puntuación incorrecta | +| (ninguno) | `g`, `1`, `2` | **Caracteres espurios insertados** | +| Líneas separadas | Todo en una línea | **Estructura perdida** | + +### Problemas Críticos + +1. **Caracteres espurios**: El detector CRAFT inserta caracteres falsos (`g`, `1`, `2`, `;`) que no existen en el documento +2. **Confusión letra/número**: Consistentemente confunde `o` con `0` +3. **Puntuación incorrecta**: Reemplaza comas por punto y coma +4. **Pérdida de estructura**: Todo el texto se colapsa en una línea + +### ¿Fine-tuning Recomendado? + +**Sí.** EasyOCR tiene problemas significativos que podrían mejorarse con fine-tuning: + +| Problema | ¿Fine-tuning ayuda? | Explicación | +|----------|---------------------|-------------| +| Caracteres espurios | **Sí** | El detector CRAFT puede entrenarse para reducir falsos positivos | +| Confusión `o`/`0` | **Sí** | El modelo de reconocimiento aprendería del contexto español | +| Puntuación | **Sí** | Corpus español enseñaría patrones de puntuación correctos | +| Estructura | **Parcial** | Depende de parámetros de agrupación de texto | + +### Cómo Fine-Tunear EasyOCR + +EasyOCR permite fine-tuning del modelo de reconocimiento: + +```bash +# 1. Preparar dataset en formato EasyOCR +# Estructura: images/ + labels.txt (imagentexto) + +# 2. Entrenar modelo de reconocimiento +python train.py \ + --train_data ./train_data \ + --valid_data ./valid_data \ + --lang_list es en \ + --saved_model ./custom_model +``` + +Documentación: https://github.com/JaidedAI/EasyOCR/blob/master/custom_model.md + +### Alternativa Recomendada + +Dado el CER de 11.14% y los problemas fundamentales de EasyOCR, se recomienda **usar PaddleOCR** (7.72% CER) en lugar de invertir esfuerzo en fine-tuning de EasyOCR diff --git a/docs/metrics/metrics_paddle.md b/docs/metrics/metrics_paddle.md index 94b426d..595ab15 100644 --- a/docs/metrics/metrics_paddle.md +++ b/docs/metrics/metrics_paddle.md @@ -1,5 +1,7 @@ # Resultados de Ajuste de Hiperparámetros PaddleOCR +> **Nota:** Los resultados de este documento corresponden a la fase de validación GPU con 45 páginas. El resultado oficial del TFM es **CER 1.49%** obtenido en la validación final de 24 páginas con la configuración optimizada (ver `docs/04_desarrollo_especifico.md`). + **Fecha de Ajuste:** 2026-01-19 **Plataforma:** NVIDIA RTX 3060 Laptop GPU **Muestras:** 64 @@ -89,3 +91,51 @@ curl -X POST http://localhost:8002/evaluate_full \ ``` **Resultado:** CER 7.72%, WER 11.40%, 0.55s/página + +## Configuración del Modelo + +### Modelo Actual (Correcto para Español) + +| Componente | Modelo | Estado | +|------------|--------|--------| +| Detección | `PP-OCRv5_mobile_det` | Correcto | +| Reconocimiento | `PP-OCRv5_mobile_rec` | Correcto | + +Los modelos PP-OCRv5 mobile soportan múltiples idiomas incluyendo español con buen manejo de diacríticos. + +### Nota sobre Modelos Server + +PaddleOCR ofrece modelos "server" más precisos: +- `PP-OCRv5_server_det` + `PP-OCRv5_server_rec` +- Requieren ~5.3 GB VRAM + +**Limitación:** En la RTX 3060 (5.66 GB VRAM) los modelos server causan **OOM (Out of Memory)** en la página 2. Los modelos mobile usados (7.72% CER) son la mejor opción práctica para este hardware. + +Para hardware con más VRAM (8+ GB), los modelos server podrían mejorar la precisión. + +## Análisis de Errores del Debugset + +### Errores Observados + +| Ground Truth | PaddleOCR | Tipo de Error | +|--------------|-----------|---------------| +| `bibliografía` | `bibliografia` | Acento omitido | +| `amplían` | `amplian` | Acento omitido | +| `, debes` | `， debes` | Coma Unicode china | +| Líneas separadas | Footer fusionado | Estructura menor | + +### Fortalezas + +- **Preserva estructura de líneas**: Mantiene saltos de línea correctamente +- **Buen manejo de español**: La mayoría de acentos se reconocen bien +- **Bajo ruido**: No inserta caracteres espurios + +### ¿Fine-tuning Recomendado? + +**No.** Con 7.72% CER, PaddleOCR ya tiene excelente precisión para documentos españoles. Los errores observados son menores: + +- Acentos omitidos: ~5% de casos +- Puntuación Unicode: Muy ocasional +- Impacto en legibilidad: Mínimo + +El esfuerzo de fine-tuning no se justifica para ganancias marginales. Para casos de uso críticos donde se requiera <5% CER, considerar post-procesamiento con corrector ortográfico diff --git a/generate_mermaid_figures.py b/generate_mermaid_figures.py index 7753ec2..1418089 100644 --- a/generate_mermaid_figures.py +++ b/generate_mermaid_figures.py @@ -6,7 +6,7 @@ import re import subprocess import json -BASE_DIR = '/Users/sergio/Desktop/MastersThesis' +BASE_DIR = os.path.dirname(os.path.abspath(__file__)) DOCS_DIR = os.path.join(BASE_DIR, 'docs') OUTPUT_DIR = os.path.join(BASE_DIR, 'thesis_output/figures') MMDC = os.path.join(BASE_DIR, 'node_modules/.bin/mmdc') diff --git a/thesis_output/figures/figures_manifest.json b/thesis_output/figures/figures_manifest.json index 98ddf3c..0637a08 100644 --- a/thesis_output/figures/figures_manifest.json +++ b/thesis_output/figures/figures_manifest.json @@ -1,47 +1 @@ -[ - { - "file": "figura_1.png", - "title": "Pipeline de un sistema OCR moderno", - "index": 1 - }, - { - "file": "figura_2.png", - "title": "Ciclo de optimización con Ray Tune y Optuna", - "index": 2 - }, - { - "file": "figura_3.png", - "title": "Fases de la metodología experimental", - "index": 3 - }, - { - "file": "figura_4.png", - "title": "Estructura del dataset de evaluación", - "index": 4 - }, - { - "file": "figura_5.png", - "title": "Arquitectura de ejecución con subprocesos", - "index": 5 - }, - { - "file": "figura_6.png", - "title": "Arquitectura de ejecución con subprocesos", - "index": 6 - }, - { - "file": "figura_7.png", - "title": "Impacto de textline_orientation en CER", - "index": 7 - }, - { - "file": "figura_8.png", - "title": "Comparación Baseline vs Optimizado (24 páginas)", - "index": 8 - }, - { - "file": "figura_9.png", - "title": "Estructura del repositorio del proyecto", - "index": 9 - } -] \ No newline at end of file +[] \ No newline at end of file diff --git a/thesis_output/plantilla_individual.htm b/thesis_output/plantilla_individual.htm index db47560..21af3cf 100644 Binary files a/thesis_output/plantilla_individual.htm and b/thesis_output/plantilla_individual.htm differ