- Este cookbook es un proyecto de código abierto que explora algoritmos de procesamiento de video e imágenes mediante diversos estudios de caso y ejercicios prácticos
- Cubre varias áreas de aplicación, como inferencia de video, catálogos de imágenes y búsqueda híbrida de imágenes de moda
- En comparación con otros proyectos, tiene la ventaja de permitir aprender los algoritmos a través de diversos casos reales
- Archivos y notebooks principales
00_quickstart.ipynb: guía de inicio rápido del proyecto01_schema_showcase.ipynb: incluye estudios de caso que muestran varios esquemas de datos02_case_study_drivers_license.ipynb: reconocimiento de licencias de conducir03_case_study_tv_news.ipynb: comprender pantallas de noticias de TV04_visual_grounding.ipynb: exploración de algoritmos de visual grounding. Extracción de JSON dentro de cuadros de imagen05_case_study_image_catalogue.ipynb: análisis de catálogos de productos de moda para reconocer descripciones de productos, categorías, género objetivo y temporada06_fashion_images_hybrid_search.ipynb: estudio de caso de búsqueda híbrida de imágenes de modaadvanced_finetuning_video_inference.ipynb: técnicas avanzadas de ajuste fino para inferencia de video
1 comentarios
Opiniones de Hacker News
Es una idea interesante, pero todavía le falta confiabilidad para usarse en producción. Los modelos OCR tradicionales, cuando no pueden leer el texto, devuelven resultados sin sentido con baja confianza. En cambio, un VLM, cuando no puede leerlo, devuelve con seguridad resultados inventados, y no hay forma de reportar un nivel de confianza. En intentos de reconocimiento de escritura a mano, el VLM inventó nombres y fechas falsas que encajaban con el tono del documento. No hay forma de anclar el modelo al texto fuente
Recientemente se publicó un benchmark open source para evaluar VLM y OCR, y en general los VLM mostraron mejor desempeño que los modelos OCR tradicionales
Ventajas de los VLM:
Ventajas del OCR tradicional:
Hay mucho margen de mejora, pero modelos como Gemini, en particular, son muy competitivos en precisión/costo
Me pregunto por qué todos los servicios OCR muestran solo capturas perfectas de documentos digitales. ¿De verdad hay tanta gente intentando hacer OCR sobre datos digitales? ¿No bastaría con copiar el HTML? Si no son documentos digitales, ¿dónde están las capturas con dobleces, líneas torcidas, gradientes de iluminación, dedos, etc.?
He estado probando vlm-run y definiciones personalizadas de formularios, y funciona sorprendentemente bien con Gemini 2.0 Flash. Entiendo que el costo también es bajo. Se obtienen los mejores resultados con formularios simples o de complejidad media. Formularios que una persona podría procesar con menos de 10 minutos de entrenamiento
Las herramientas OCR hacen bien lo que dice la caja: reconocer caracteres sobre papel. La ventaja de usar modelos de visión-lenguaje es que se puede agregar lógica como: "esto es una cadena, pero ¿parece una marca de tiempo?"
Lo que quiero: escanear/fotografiar documentos (incluidos libros completos), pasarlos a un modelo de lenguaje y obtener un documento Latex que coincida exactamente con el original. Excluyendo defectos de fotocopiadora/cámara y ángulos. Parece que podría existir un modelo de aprendizaje por refuerzo para esto. Debería poder aprender a generar Latex que reproduzca la imagen a nivel de píxel
Hay que usar ambos. Si usas OCR y LLM, y luego correlacionas ambos resultados, la calidad mejora muchísimo. Obtienes no solo comprensión del documento y contexto, sino también cosas como cajas delimitadoras. Estoy creando una app de "nunca volver a llenar formularios" y me gustaría hablar con gente interesada
Puede ser por mi prompt, pero siento que después del embedding de la imagen hay demasiada interpretación. En mi ejemplo, empezó a resumir partes del texto, y lamentablemente lo hizo mal. En una factura con texto mecanografiado, en realidad decía que si la enviabas después de las 2 p. m. del viernes no se publicaría hasta el lunes siguiente, pero lo resumió como que no se publicaría durante 2-3 días hábiles. Eso es bastante distinto. Me pregunto si hay alguna forma de eliminar esa capa. La detección y reconocimiento estructurado de texto en one-shot fue mucho mejor que el OCR básico
Está bien ver que se está trabajando más en esto, pero no entiendo por qué esto tendría que quedar atado al API propietario de alguien. Cambiar de proveedor de modelos y agregar logging básico no es tan doloroso como para justificar incorporar otro proveedor más. Sobre todo cuando se maneja algo sensible como prompts de LLM
¿Cuál es la herramienta OCR por CLI más rápida y precisa? Mi caso de uso es simple: quiero capturar una parte de la pantalla (Flameshot sirve bien para eso) y hacer OCR. Lo necesito para tomar notas mientras hago pair programming por Zoom. Actualmente uso tesseract; es rápido y funciona bien, pero comete errores. Estaría bueno si pudiera distinguir formato tabular y convertirlo a tablas ASCII o Markdown. Probé docling, pero se siente un poco excesivo. Parece lento: necesito extraer texto de una captura muy rápido. Solo probé la configuración por defecto; creo que podría mejorar ajustándolo. ¿Alguien puede compartir su opinión sobre esto? ¡Gracias!