Es construir una escena común donde el CBCT, el escáner intraoral, las fotografías y el informe dejan de vivir separados.
El caso caos dental completo, en un fichero que dice de qué está hecho.
Unified Oral Scene
El problema
Un caso completo son tres cosas sueltas: STL del escáner intraoral, cientos de DICOM del CBCT e informes en PDF.
Cada pieza abre en un programa distinto y habla su propio sistema de coordenadas.
La relación entre ellas vive en la cabeza de quien lo miró o dentro de un software propietario.
Dónde cae este CBCT respecto a este escaneo, a qué diente se refiere este hallazgo, qué deriva de una medida y qué deriva de una inferencia. No viaja con los datos.
Un .uos es esas piezas más las relaciones entre ellas, en un solo fichero.
-
01
Relación invisible
El registro entre CBCT, escaneo y hallazgos se queda fuera.
-
02
Software como memoria
El contexto queda encerrado en sesiones propietarias.
-
03
Rehacer al reenviar
Laboratorio, clínica y revisor reconstruyen la escena otra vez.
-
04
Procedencia débil
STL, DICOM y PDF no declaran qué depende de qué.
3D Gaussian Splatting
3DGS representa una evolución en cómo funcionan los gráficos 3D tradicionales hechos de polígonos.
El 3D Gaussian Splatting es una técnica revolucionaria de representación volumétrica. En lugar de una malla de triángulos dura, representa la escena utilizando millones de gaussianas 3D.
Qué lleva cada gaussiana
Cada gaussiana es una pequeña mancha o elipsoide flotando en el espacio.
Al superponer millones de manchas de diferentes tamaños y colores, se forma una imagen 3D fotorrealista.
Una gaussiana del 3DGS estándar guarda color y opacidad: lo justo para dibujar. Las nuestras guardan además de dónde salió cada cosa. Y hay dos clases, porque miden cosas distintas.
Las de apariencia llevan el color medido del paciente, tomado de sus fotografías corona a corona y por tercios, más la oclusión y el relieve, separados del color para que una lectura de tono no se contamine de iluminación.
Las de densidad llevan density: la atenuación de rayos X que midió el CBCT, con el rango que la convierte a Hounsfield. Y origen, que dice si ese punto lo vio el escáner o el CBCT: uno mide la corona en micras, el otro ve la raíz bajo la encía.
Las dos llevan region_id, el código FDI de la pieza: enciende un diente entero sin necesitar ninguna superficie. Es inferencia, y el fichero lo declara.
Lo que dice el informe no va aquí. Un hallazgo, un número de raíces, un conducto: el informe los da por diente, no por punto del espacio. Repartirlos entre un millón y medio de gaussianas sería fabricar resolución que nadie midió.
La gaussiana lleva la llave, no la copia: gaussiana → region_id → informe
La solución
Un caso entero, expresado como un twin 3DGS clínico.
La solución no es convertir todos los ficheros a otro fichero más.
El centro del sistema es un TwinSnapshot: dice qué se midió, qué agente lo produjo, de qué fichero viene y con qué confianza debe interpretarse. La boca deja de ser una carpeta y pasa a ser una escena trazable.
El modelo 3DGS guarda posición, forma, densidad radiológica, apariencia cuando existe, origen de la medida y región FDI cuando la segmentación la conoce.
No todo se mete en todas partes: la densidad vive por punto, el color en superficie y los hallazgos clínicos por diente.
Lo medido y lo inferido no se mezclan: un DICOM, una malla, una foto o una observación clínica conservan su procedencia, y cualquier resultado de modelo queda marcado como derivado, con confianza y posibilidad de revisión humana.
Un espacio común
CBCT, IOS, fotos e informe se registran sobre la misma escena. El escáner aporta la corona, el CBCT aporta volumen y raíz, y el informe se ancla por pieza FDI.
Dato con procedencia
Cada valor conserva origen, agente, confianza y derivación. Un registro automático, una medida directa y una inferencia clínica no aparentan tener la misma autoridad.
Salida reversible
Desde el twin se regeneran STL, PLY y renders multivista con error medido. El sistema no sustituye los formatos clínicos: los recompone desde una escena verificable.
Para quién es
El mismo caso cambia de valor según quién lo abre: clínica, laboratorio e investigación leen el mismo fichero, pero no buscan lo mismo.
Clínica
El caso se entrega entero: escáner, CBCT, fotos, informe y la transformada que los relaciona, en un fichero que se abre en un navegador.
Laboratorio
Recibe la pieza a imprimir con su contexto, y la trazabilidad de qué se midió y qué se supuso.
Investigación
Un conjunto de .uos es un corpus con procedencia: se sabe qué es medida y qué es inferencia sin abrir los ficheros.
Pipeline
Cuatro fuentes clínicas entran en paralelo y salen como un twin 3DGS, exportable y medido.
CBCT · IOS · informe · fotos
El caso llega como modalidades que no se hablan: DICOM, STL/OBJ, PDF/TXT e imágenes JPG, PNG o HEIC.
Cuatro agentes traducen a contrato
mesh-agent, cbct-agent, report-agent e image-agent leen sus fuentes, calculan sha256, eliminan EXIF y escriben procedencia por valor.
El marco deja de vivir en una sesión
Dos fusiones geométricas registran escáner↔escáner e IOS↔CBCT. El segmentation-agent añade region_id por gaussiana y la fusión semántica cuelga los hallazgos del informe de códigos FDI.
registro IOS↔CBCT medido sobre paciente real: 0,452 mm
Una escena clínica consultable
El TwinSnapshot reúne campo gaussiano, superficie, fotos, observaciones regionales y provenance. Lo medido, lo inferido y lo pendiente quedan separados.
Cuatro salidas, todas verificadas
export-agent regenera STL, field-export-agent escribe PLY, render-export-agent produce PNG multivista y composite-export-agent genera una arcada imprimible.
el pipeline entrada → twin → fichero está probado de punta a punta
Visor web + revisión humana
El caso se abre en navegador, muestra odontograma y capas clínicas, y activa HITL cuando la confianza cae por debajo del umbral.
Agentes en el desarrollo
El pipeline de arriba lo ejecutan agentes. Este repositorio también se construyó con ellos.
research-agent
Harness de revisión de código
Revisión automática y control de calidad dentro del flujo, no como paso opcional al final.
Guardarraíles ejecutables
Un data guard bloquea el commit si intenta versionar datos clínicos o artefactos de compilación. No es una norma en un CONTRIBUTING que nadie lee: es un hook que para el commit.
Dos meses de una persona con agentes, no de un equipo. La revisión automática y los guardarraíles son lo que permite sostener a la vez un repositorio con datos de paciente y una especificación pública.
UOS, el formato
Un caso dental es hoy tres cosas sueltas. UOS es esas tres cosas más las relaciones entre ellas, en un fichero.
Un escáner intraoral, un CBCT y un informe llegan en tres sistemas de coordenadas distintos. La relación no viaja con los datos. Cuando el caso pasa al laboratorio o a otra clínica, esa relación hay que rehacerla.
UOS es un contenedor abierto que no recodifica nada: referencia los formatos nativos intactos y declara las relaciones. Un ZIP sin comprimir con un manifiesto por delante, que un navegador abre sin instalar nada y sin subir nada a ningún servidor.
Cada relación lleva su error
El registro entre CBCT y escáner es un objeto de primera clase: la matriz 4×4, el método, el residuo y quién lo verificó. En el caso real, 0,666 mm y «sin verificar» — y el visor está obligado a decirlo.
Una alineación automática que nadie ha mirado y una firmada por un clínico no son lo mismo.
Lo medido y lo inferido no se mezclan
Todo lo que sale de un modelo vive solo bajo derived/, con su capa regulatoria y el hash de los pesos. Borrar ese directorio deja un .uos válido y completo.
Distribuir el caso donde el módulo de IA no está habilitado no requiere reexportar el caso.
Nada se edita, todo se versiona
Modificar un caso es escribir una versión nueva que apunta al hash de la anterior. Quien lo recibe puede comprobar si cambió y respecto a qué, sin fiarse de quien se lo envió.
El contenedor no solo tiene estructura: comprueba que lo que afirma coincide con los bytes del fichero.
Ampliable sin permiso
Una modalidad nueva —carga bacteriana por sitio, fuerza de mordida, periodontograma— entra declarando un asset, un marco, una extensión y un descriptor.
Un lector que no la conozca abre el caso igual y puede decir qué dejó sin leer.
Especificación completa publicada, con esquema JSON y validador. Cualquiera puede implementar un lector.
Reversibilidad
La salida imprimible —un STL/3MF mejorado— no se guarda como una segunda verdad: se regenera desde el caso.
Prueba de ida y vuelta
El contenedor no pide confianza estética: vuelve a emitir ficheros abiertos y después los compara contra lo que declaró.
112.067
220.085
183,2
1,92
Comparación declarada
Si se puede regenerar, se puede auditar.
| Salida | Qué se compara | ¿Coincide? |
|---|---|---|
| PLY | posiciones, color, FDI, medido | idéntico en los 112.067 vértices |
| STL | triángulos y color RGB555 | idéntico en los 220.085 |
| 3MF | paleta, vértices y triángulos | idéntico byte a byte |
El modelo de capas
Abierto no significa «nuestro formato, publicado».
Geometría en glTF, apariencia en la extensión KHR_gaussian_splatting de Khronos, numeración en ISO-3950, mapeo a FHIR declarado. Ninguna extensión propia marcada como obligatoria: extensionsRequired va vacío a propósito, así que un visor que no conozca la nuestra abre el caso igual.
La extensión de Khronos es Release Candidate, aún no ratificada.
Especificación abierta e implementación de referencia abierta; los módulos clínicos van encima y fuera del spec. Nadie adopta un contenedor que pertenece a un competidor.
Capa
Módulos clínicos
segmentación · medidas · revisión
producto · propietario — fuera del spec
Capa
Implementación de referencia
pipeline de agentes · visor web
abierta
Capa
Especificación UOS
manifiesto · esquema · validador
abiertaEn la página las tres van apiladas de arriba abajo en ese orden, con la propietaria arriba y la spec como base.
Experimentos
Notebooks publicables del repo: spikes de validación técnica, no resultados clínicos.
Teeth3DS+ · sin GPU
01 · Malla dental → splatting clásico
Baseline con VTK: carga mallas reales, genera un campo de densidad por splatting clásico, serializa al contrato y caracteriza el dataset completo. No es 3DGS entrenado; es el banco de pruebas de la tubería.
01-vtk-3dgs-poc.ipynb · 600 escaneos · 24 casos en la cadena completa.
Teeth3DS+ · sin GPU
02 · Visor interactivo VTK
Complemento visual del 01: abre una ventana nativa para rotar, hacer zoom y comparar malla, nube de puntos y campo VTK sobre cualquier caso del dataset. Sirve para inspeccionar anatomías, no para producir una figura.
02-vtk-interactive-viewer.ipynb · requiere entorno gráfico.
Teeth3DS+ · sin GPU
03 · Vistas sintéticas con poses exactas
Genera el input del 3DGS moderno sin COLMAP: imágenes RGB, intrínsecos, matrices cámara→mundo y nube inicial. La pose no se estima: sale exacta del render sintético y se verifica por reproyección.
03-synthetic-views-for-3dgs.ipynb · 2.880 vistas · 20 casos · error de reproyección 0,0000 px.
Teeth3DS+ · GPU
04 · Entrenamiento 3DGS con gsplat
Entrena gaussianas anisótropas contra las vistas del 03 y mide en vistas retenidas que el modelo no vio. La salida se exporta a PLY y se conecta con el contrato del twin.
04-train-3dgs-gsplat.ipynb · 8 casos entrenados · vistas retenidas.
Teeth3DS+ · sin GPU
05 · Vistas sintéticas densas
Repite el generador de vistas con una rejilla más fina: 528 vistas por caso. Convive con el paquete del 03 para comparar si más cobertura angular mejora realmente la reconstrucción.
05-synthetic-views-dense.ipynb · 528 vistas/caso · 20 casos.
Teeth3DS+ · GPU
06 · 3DGS denso con receta de referencia
Entrena con L1+SSIM, densificación, poda y armónicos esféricos de grado 2. La receta sube el PSNR retenido frente a la versión simple y deja medido el coste de más capacidad.
06-train-3dgs-dense.ipynb · 528 vistas/caso · ~145k gaussianas finales.
Bite2Text · GPU
07 · Escáner real → Blender → 3DGS
Lleva un STL real de Bite2Text al contrato con el mesh-agent, extrae color regional de fotos con el image-agent, renderiza 1.600 vistas en Blender y entrena un campo 3DGS evaluado en holdout.
07-bite2text-blender-3dgs.ipynb · 1 caso · 1.600 vistas · holdout 31,5 dB.
Histora · GPU
09 · Registro por diente
Prueba si merece la pena registrar cada diente por separado: segmentación FDI, transferencia de etiquetas, referencia leave-one-out, control nulo y negativos de promediar transformaciones o medir escala.
09-per-tooth-registration-experiment.ipynb · el resultado privado se resume sin publicar datos del paciente.
Teeth3DS+ · GPU
Point Transformer · Segmentación FDI
Prototipo del segmentation-agent: segmentación por punto, agregación punto→diente y ablaciones multi-semilla. El hallazgo importante no es un modelo concreto, sino que hace falta descriptor local.
exercise-point-transformer-teeth3ds.ipynb · 600 mallas · 3 semillas.
Qué no hace todavía
Lo que todavía no hace. Escrito ahora que el paper está cerrado, así que la lista es honesta.
Un caso, no un estudio clínico.
Todo lo que medimos sale de un paciente real completo. Suficiente para demostrar que el flujo funciona de extremo a extremo; insuficiente para afirmar nada sobre precisión clínica media. Hace falta una serie.
El Gaussian Splatting todavía no limpia la radiografía.
Era una de nuestras hipótesis: usar el campo gaussiano para reducir el ruido del CBCT. Descompusimos el campo en capas por densidad y medimos la mejora: quedó por debajo del umbral que nos habíamos fijado, así que revertimos el cambio en vez de venderlo. La hipótesis sigue viva; lo que falta es entrenar con las proyecciones originales, no con el volumen ya reconstruido.
El color llega hasta donde llegan las fotos.
Cubrimos el 97,2 % de la superficie con color medido del paciente. El resto son zonas que la cámara no vio. No lo rellenamos inventando: se marca como no medido, y se distingue en el propio fichero.
La segmentación por diente no está resuelta.
Hoy exportamos la arcada como una malla compuesta, no como 32 piezas independientes. Es la pieza que más bloquea al resto: sin ella no hay medidas por diente automáticas.
Falta el dato biológico.
Bacterias, pH, fuerza de mordida. El formato ya tiene sitio reservado para ellos y así se diseñó desde el principio, pero todavía no hemos integrado ningún equipo que los mida.
No es un producto sanitario.
Es investigación. No está certificado, no diagnostica y no sustituye el criterio de nadie.
Preguntas
¿Sustituye al STL?
No. Lo envuelve. El STL sigue saliendo por el otro lado, y sale mejor que el que entró, porque se regenera desde la escena ya registrada.
¿Dónde están los ficheros originales del paciente?
Fuera. Un .uos nunca los lleva dentro: guarda su huella digital para poder demostrar de dónde vino cada cosa, pero los datos crudos se quedan donde el centro los custodie. Es una decisión de diseño, no una limitación.
¿Es un formato abierto?
La especificación es pública y se apoya en estándares existentes (glTF, la extensión de Gaussian Splatting de Khronos, DICOM, FDI). Abierto significa que otro puede escribir su propio lector con el documento delante; no significa que ya haya un comité detrás.
¿Puedo añadir información que no habíais previsto?
Sí, y es la parte importante. El formato tiene un mecanismo de extensiones: cada añadido declara si un lector puede ignorarlo sin romperse. Así entrarán las bacterias mañana sin invalidar los ficheros de hoy.
¿Qué pasa si abro un .uos nuevo con un programa viejo?
Lo lee, avisa de lo que ha ignorado y no vuelve a guardarlo. Preferimos que un lector antiguo se declare incapaz de reescribir antes que perder información en silencio.
¿Se puede modificar lo que ya está guardado?
No se sobrescribe: se añade. Cada versión queda encadenada a la anterior, así que se puede ver quién añadió qué y cuándo, y volver atrás. Lo que un algoritmo propone se guarda aparte de lo que un profesional ha verificado, y se puede quitar entero sin tocar el resto.
¿Y la privacidad?
El caso viaja seudonimizado y los metadatos de las fotos se eliminan en la propia entrada al sistema, automáticamente.
¿Quién ha hecho esto?
Una persona con agentes, durante dos meses, en colaboración con la clínica. No un equipo.
Demo
Un caso real abierto en tu navegador, sin registro y sin subir nada.
{{PENDIENTE: caso .uos de ejemplo publicable — sin dato identificativo}}
El visor no arranca solo. Cuando exista el contenedor, se cargará aquí bajo demanda explícita.