Qué es y qué no es
Banco LUT revisa el archivo, no la imagen. Abre un .cube, mide cómo se comporta la transformación que contiene, y te dice si tiene defectos de fabricación típicos: curvas que retroceden, recorte de información en las sombras o las luces, valores fuera de rango. Además compara dos LUTs entre sí y puede reparar un tipo específico de defecto.
Todo ocurre dentro del navegador. Los archivos no se suben a ningún servidor: se leen localmente y se procesan ahí mismo. El análisis es local; el catálogo verificado y el asistente requieren la versión servida por HTTPS.
Lo que esta herramienta no hace
- No juzga si un look es bueno. Un LUT puede estar técnicamente impecable y ser feo, o tener recorte agresivo a propósito y ser exactamente lo que buscabas.
- No mira tu material. Mide el transporte de color sobre valores conocidos; no ve tu plano, tu piel, tu cielo.
- No reemplaza la revisión sobre imagen real en un monitor calibrado. Es el paso previo: descarta que el problema esté en el archivo antes de que empieces a dudar de tus ojos.
- No mide tu monitor. Para eso hace falta un instrumento físico y un programa de calibración.
Dicho de otra forma: si un degradado se ve raro, Banco LUT te dice si la culpa es del LUT. Si el LUT está limpio, el problema está en otro lado y ya sabes dónde no buscar.
Empezar en un minuto
- Carga un LUT en la ranura A. Es el archivo que quieres revisar. Aparecen su tamaño, su dominio y su huella de contenido.
- Mira el panel Diagnóstico. Una lectura sin alertas significa que esas pruebas no detectaron problemas; no certifica calidad ni ausencia de defectos. Revisa las explicaciones de cada hallazgo.
- Si algo salió marcado, busca la curva. El tramo problemático aparece resaltado en rojo sobre el gráfico, así que ves exactamente en qué zona tonal está.
- Si quieres comparar, carga un segundo LUT en la ranura B. Se activa la comparación ΔE y puedes colorear el cubo 3D por diferencia.
- Si el diagnóstico encontró una curva que retrocede, pulsa Reparar. Verás cuánto cambió y podrás descargar el
.cubecorregido. - Genera el reporte si necesitas dejar constancia de la revisión.
Si no entiendes algún número
El panel Asistente, arriba de todo, traduce el reporte completo a lenguaje llano. Recibe exactamente los mismos números que ves en pantalla — nada oculto — y puedes hacerle preguntas puntuales.
Carga e identidad del archivo
Se leen LUTs 3D en formato .cube (Adobe/IRIDAS), de tamaño N³ entre 2 y 129, con o sin DOMAIN_MIN y DOMAIN_MAX. Si el archivo declara un tamaño que no coincide con la cantidad de filas que trae, la app lo avisa en vez de fallar en silencio.
Por qué se calcula una huella
El formato .cube no tiene ningún campo de identidad: no lleva versión, ni autor, ni fecha, ni identificador. TITLE es opcional, no es único y se edita con un editor de texto. Eso significa que decir «revisé el LUT y está bien» no prueba nada: no hay forma de saber después si el archivo que tienes en la mano es el mismo que se revisó.
Por eso Banco LUT calcula una huella del contenido al cargar:
- Servido por HTTPS
- SHA-256 sobre los bytes del archivo, mediante Web Crypto del navegador. Coincide exactamente con lo que devuelve
sha256sumen una terminal, así que cualquiera puede verificarla por su cuenta. - Sin contexto seguro
(file://ohttp://simple) - Si Web Crypto no está disponible, se recurre a dos pasadas de FNV-1a de 32 bits sobre los bytes. Esto no es el FNV-1a de 64 bits canónico —usa otra base— y por tanto no se puede reproducir con ninguna herramienta externa: sirve para notar que un archivo cambió entre dos revisiones tuyas, no como prueba verificable por terceros. Para un registro que deba resistir escrutinio, abre la página por HTTPS.
La app siempre dice cuál de las dos usó, en pantalla y en el reporte. Nunca presenta una como la otra.
Verificar una huella desde la terminal
Si el resultado coincide con el del reporte, el archivo es bit por bit el mismo que se revisó. Válido solo para la huella SHA-256; la alterna no es comparable con herramientas externas.
Esta idea no es invento nuestro: es lo que la industria hace con el material de cámara mediante ASC MHL, que registra hash, tamaño, fechas, herramienta y autor como cadena de custodia. No existe la costumbre equivalente para archivos de LUT, pero el mecanismo es el mismo y no cuesta nada.
Curva diagonal (eje de grises)
Muestra qué le hace el LUT a un gris neutro a lo largo de todo el rango: entra un valor donde R = G = B, y se grafica lo que sale en cada canal. La línea punteada gris es la identidad — la transformación que no hace nada. Cuanto más se aleje una curva de esa diagonal, más fuerte es la intervención en ese rango tonal.
Es la vista que más rápido te dice el carácter del LUT:
- Curvas por encima de la identidad en las luces y por debajo en las sombras: contraste añadido (curva en S).
- Los tres canales separados entre sí: viraje de color, y la separación te dice en qué zona tonal.
- Un tramo plano pegado a 0 o a 1: recorte.
- Un tramo que baja: defecto. Ahí la app pinta una banda roja y escribe qué canal retrocede.
Cuando aplicas una reparación, la curva corregida se dibuja encima en blanco punteado, así ves el antes y el después en el mismo gráfico.
Nube de puntos 3D
Se toma una grilla regular de entradas —el cubo RGB sin transformar— y se dibuja cada punto en la posición de su color de salida. El armazón de alambre marca dónde estaría el cubo si el LUT no hiciera nada: la distancia entre el armazón y la nube es la deformación que aplica tu LUT.
- Arrastrar
- rotar; al soltar conserva inercia
- Rueda del mouse
- acercar y alejar
- Resolución de muestreo
- 9³ a 21³ puntos, en el panel de carga. Más resolución es más detalle y más carga de cálculo.
- Colorear por ΔE
- con un LUT B cargado, cada punto se pinta según cuánto difiere entre A y B: verde poca diferencia, rojo mucha
- Marcar nodos sin distinción
- pinta en rojo los nodos donde un paso entero de la grilla de entrada no mueve la salida ni un código de 10 bits en ninguno de los tres canales, y atenúa el resto. Traduce el porcentaje de pérdida de distinción a una posición en el volumen: si se agrupan en la esquina negra, el LUT cierra sombras; si aparecen en una arista de color, cierra ese color.
El modo ΔE es la forma más rápida de ver dónde difieren dos LUTs. Una nube toda verde con una zona roja aislada te dice que las dos versiones son casi idénticas salvo en una región de color concreta — mucho más útil que un promedio.
Pliegue y corte del cubo
Este es el control que responde a una pregunta distinta de todas las demás: ¿hay orientación invertida en las muestras? Este control no demuestra que cada salida tenga una sola entrada. Una reflexión puede ser invertible pese a tener determinante negativo.
Importa porque un LUT puede pasar limpiamente los dos controles de monotonicidad y aun así estar roto. Los tres canales pueden crecer, cada uno a lo largo de su propio eje, y bastar con que la mezcla entre canales invierta la orientación del volumen para que el LUT se pliegue sobre sí mismo. En imagen eso se ve como reversión de tono —un color que al aumentar se vuelve hacia atrás— o como una banda dura en una zona concreta del espectro, y no lo explica el recorte.
Cómo se mide
Para cada celda se evalúa el jacobiano del interpolante trilineal en sus ocho esquinas y su centro. El determinante se normaliza por los pasos del dominio físico de entrada:
El signo es lo que importa:
- det > 0
- la celda conserva su orientación — normal, sea cual sea la fuerza de la transformación
- det ≈ 0
- la celda se aplasta: el volumen se comprime casi a cero. Es exactamente lo que produce el recorte, y ya se informa como pérdida de distinción. No se cuenta como pliegue, y la app lo separa a propósito para que las dos cifras no se confundan.
- det < 0
- la orientación local de la muestra está invertida. Por sí solo, este signo no prueba falta de inyectividad.
La detección es local y muestreada: puede encontrar inversiones, pero su ausencia no certifica inyectividad local ni global. Puede omitir inversiones entre muestras y no detecta solapamientos entre regiones distantes. Una celda con alguna muestra negativa se cuenta una sola vez; las celdas con muestras casi singulares se cuentan aparte si no tuvieron muestra negativa.
De dónde sale el umbral
Se marca orientación invertida cuando det < -0.001 y casi singular cuando |det| ≤ 0.001. Es una tolerancia operativa propia, no una norma ni una garantía de detección. La precisión decimal del archivo, el paso de la grilla y la transformación afectan al error numérico: los archivos .cube no tienen todos la misma cantidad de decimales. Una inversión menor que este umbral puede quedar sin marcar.
El corte: ver el pliegue
La cifra dice cuántas celdas y de qué magnitud. El panel Corte del cubo dice dónde y de qué forma. Se fija uno de los tres ejes de entrada en un nodo y se dibuja lo que el LUT hace con el plano de los otros dos: cada nodo va a donde el LUT lo manda, y se unen los vecinos. La retícula tenue del fondo es la identidad, para tener referencia.
- Eje fijo
- cuál de los tres se mantiene constante. Un pliegue puede estar en una zona que un eje no atraviesa: si la cifra dice que hay pliegue y el corte no lo muestra, cambia de eje o mueve la posición.
- Posición
- en qué nodo se corta, del 0 al último
- Vectores de desplazamiento
- flechas desde donde estaba cada nodo hasta donde acabó. Es la transformación dibujada como campo: se lee de un vistazo hacia dónde empuja el LUT cada región.
El corte proyecta dos canales de salida. Dos líneas pueden cruzarse en esa proyección y seguir separadas en el tercer canal; el cruce visual no demuestra que dos entradas compartan el mismo RGB de salida.
De dónde viene esta idea
El corte dibujado como malla deformada, los vectores de desplazamiento y el recorte marcado sobre el volumen no son invención nuestra: están en el LUT Cube Analyzer de Mononodes, una herramienta gratuita y muy buena que resuelve por la vía visual buena parte de lo que aquí se resuelve midiendo. Lo que añadimos es la medición: allí el pliegue se ve, aquí además se cuenta, se ubica, se contrasta contra un umbral con su justificación y entra en el reporte. Vale la pena usar las dos.
Diagnóstico
Tres controles sobre los nodos reales del archivo. Cada uno informa el valor medido junto al criterio con que se evaluó, nunca un veredicto pelado.
Monotonicidad
En una transformación tonal creciente esperamos que la salida no disminuya al aumentar la entrada. Banco mide descensos por canal y sobre la diagonal de grises. Son señales que requieren interpretación: una transformación cromática puede descender por diseño y un descenso no demuestra por sí solo banding ni duplicación del RGB completo.
Se informan dos lecturas distintas, y conviene entender por qué son dos:
- Sobre la rampa de grises
- Se muestrea la diagonal del cubo en 256 pasos y se cuenta una caída cada vez que la salida baja más de
0.001. Es la lectura que puedes ver en el gráfico de curva, con el tramo marcado en rojo. - En todo el cubo
- Se recorre, por cada canal, cada línea paralela a su propio eje de entrada, sobre los nodos crudos del archivo, con tolerancia
0.0001. Cubre colores que la diagonal no atraviesa. Se informa cuántos pasos retroceden y en cuántas líneas de lasN²del cubo.
La reparación siempre trabajó sobre el cubo completo. La segunda lectura existe para que el diagnóstico cubra exactamente el mismo terreno que la corrección toca — de otro modo la app podía dar por sano un archivo que iba a modificar.
Pérdida de distinción
Recortar no es tener valores en 0 o en 1 — es perder distinción: que dos entradas diferentes salgan idénticas. La diferencia importa por partida doble. Un LUT identidad tiene muchísimos nodos con algún canal exactamente en 0 o en 1, en toda la cara del cubo, y no recorta nada. Y al revés: un pie levantado que aplana las sombras en 0.02 destruye tanto detalle como uno que las cierra en 0, aunque nunca toque el cero.
Por eso el criterio no es el nivel, sino el cambio: un tramo se cuenta como colapsado cuando la salida se mueve menos de un valor de código a 10 bits (1/1023) a lo largo de al menos el 2% del rango de entrada — en cualquier nivel. Se informa dónde empieza, dónde termina y en qué valor se aplanó.
Sobre eso se construyen dos lecturas más:
- Negro o blanco puro en los tres canales. La salida solo es negro puro donde los tres canales están a cero a la vez, así que el punto conjunto es el menor de los tres, no el mayor.
- El rango del cubo sin cambio apreciable, recorriendo el cubo entero: qué proporción de los pasos entre nodos vecinos mueve la salida menos de 1/1023. Detecta colapso también fuera del eje de grises.
Valores fuera de 0–1
Cuenta nodos con algún canal por debajo de 0 o por encima de 1. No es un error de por sí: es esperable y correcto en LUTs pensados como paso intermedio hacia un espacio de trabajo más amplio, donde conservar valores fuera de rango es justamente lo que evita perder información. Se informa como dato, sin marca de alerta.
Vista previa antes / después
Aplica el LUT píxel a píxel sobre una imagen y la muestra junto a la original. Tres fuentes posibles: una imagen tuya, unas barras técnicas generadas (rampa de grises más barras de color primarias y secundarias), o la carta ColorChecker sintética.
Las barras técnicas son útiles para ver de un vistazo si el LUT introduce escalones o cambios bruscos en la rampa; la carta, para leer el corrimiento de color sobre matices reconocibles.
Comparación A / B
Con dos LUTs cargados se mide cuánto difiere el resultado, color por color, con ΔE CIE76 sobre L\*a\*b\*. La app usa uno de dos modos y siempre dice cuál:
Con dominios asimétricos, la comparación muestreada usa una caja envolvente por eje y limita la entrada al borde de cada LUT fuera de su dominio. El eje de grises de la comparación usa 257 muestras con R=G=B en la intersección común; si no existe, no se informa una cifra. Las rampas individuales recorren el intervalo escalar envolvente con extensión constante al borde: no implican cobertura de todo el dominio asimétrico.
Modo nativo — comparación de nodos
Cuando los dos LUTs comparten tamaño de cubo y dominio, cada nodo de A tiene su correspondiente en B, así que se comparan directamente sobre los valores del archivo. No interviene la interpolación. El resultado es exacto, reproducible, y no cambia si mueves la resolución de muestreo.
Modo muestreado — cuando no hay otra opción
Si difieren en tamaño o dominio no existe esa correspondencia uno a uno, y hay que evaluar ambos LUTs en una grilla común, interpolando. Entonces las cifras dependen de la resolución elegida, y la app lo advierte explícitamente.
- ΔE máximo
- el punto donde más difieren. Dice si hay alguna zona problemática.
- ΔE promedio
- la diferencia típica en todo el cubo. Dice si difieren en general o solo en un rincón.
- ΔE en eje de grises
- solo sobre neutros. Es donde el ojo detecta antes una desviación de color.
Un máximo alto con un promedio bajo es la firma de un problema localizado. Un promedio alto es una diferencia de fondo entre los dos LUTs.
Las cifras se colorean con las bandas que publica Light Illusion para la calibración con ColourSpace: por debajo de ΔE 1 en verde, entre 1 y 2.3 en ámbar, por encima de 2.3 en rojo. El valor 2.3 procede de Mahy, Van Eycken y Oosterlinck (1994), que lo midieron como diferencia apenas perceptible para CIELAB.
La codificación de salida la eliges tú, y de ella dependen todas las cifras
Un .cube no declara en qué codificación están sus valores de salida: pueden ser sRGB, Rec.709 con BT.1886, gamma 2.2, o log de cámara. Para convertir a L\*a\*b\* hay que decodificar primero, y para decodificar hay que asumir una curva. El selector del panel de carga es esa asunción, y queda registrada en el reporte.
Si eliges «log u otra», la app deja de pintar las bandas perceptuales y lo dice: sobre valores log no se calcula ΔE. Solo se conserva la diferencia RGB cruda, que no es una medida perceptual.
El punto de blanco de la conversión es D65, coherente con sRGB y Rec.709. Los 24 valores de referencia de ColorChecker que usa la app son sRGB, ya adaptados a D65 en la fuente, así que no hay ninguna conversión de iluminante pendiente entre ambas lecturas. Lo que sí es otra tabla, y no debe mezclarse con esto, son las mediciones espectrales de esa misma carta bajo D50 con observador 2°.
Carta ColorChecker — corrimiento
Los 24 valores sRGB de referencia de la ColorChecker Classic se pasan por el LUT A y se muestra cada parche antes y después, con el ΔE del corrimiento. Los valores vienen de la tabla de Danny Pascale (BabelColor), la misma fuente que usa el paquete de tablas de medición de Sala de Color.
Sirve para leer qué le hace el LUT a colores reconocibles: si los tonos de piel se van a naranja, si los verdes se desaturan, si los neutros se tiñen. Un ΔE promedio alto no es una falla — un look con carácter mueve los colores, para eso está.
Reparación
Cuando el diagnóstico encuentra que una curva retrocede, aparece la opción de corregirlo. El panel dice antes qué canal está afectado y en qué tramo, para que sepas qué se va a tocar.
Cómo funciona
Se usa regresión isotónica, mediante el algoritmo PAVA (pool adjacent violators), que ajusta una secuencia a la secuencia no-decreciente más cercana en mínimos cuadrados. Se aplica por eje: para el canal R se recorren todas las líneas paralelas al eje de entrada R, y lo mismo para G y B en los suyos.
Propiedades del ajuste por línea:
- Si una línea completa ya es monótona, no cambia. Un tramo monótono dentro de una línea con descensos sí puede cambiar al fusionarse bloques vecinos.
- El cambio que introduce es el mínimo posible bajo el criterio de mínimos cuadrados.
- Preserva la media y no inventa valores fuera del rango original.
En el archivo de prueba usado para desarrollarla —un 33³ con un defecto localizado— la corrección tocó el 3% de los valores con un ΔE promedio de 0.01 respecto del original. No es una cifra general: depende enteramente de cuán extendido esté el defecto.
Lo que la reparación no hace
Hace no decrecientes las líneas de cada canal sobre su propio eje en los nodos. Esto no garantiza la monotonicidad de la diagonal RGB ni ausencia de inversiones del Jacobiano. No reconstruye la intención original. No sabe qué valor «debería» haber estado ahí; solo sabe cuál es el más cercano que respeta la monotonicidad. Si el LUT salió de una conversión matemática o de un script, conviene además arreglar el origen: aquí estás tapando el síntoma.
Y no se ofrece siempre. Monotonía creciente es propiedad de una transformación tonal, no de cualquier transformación de color: un negativo, una emulación de copión o una rotación de tono de 180° descienden por diseño. A un LUT así la regresión isotónica lo aplanaría entero a un valor constante — quedaría monótono y sería inservible. Por eso la app se niega a reparar cuando el descenso afecta a más de la mitad de las líneas del cubo o cuando la caída más fuerte supera 0.1: estos límites son precauciones propias; no permiten distinguir con certeza una intención creativa de un defecto.
Después de reparar
- Descargar .cube reparado — el archivo corregido, listo para usar.
- Analizar el reparado como LUT A — lo adopta en la app para seguir revisándolo.
- Descartar reparación — vuelve al original.
- Superponer en la curva — dibuja la versión corregida sobre la original.
El archivo que cargaste nunca se modifica: la reparación trabaja siempre sobre una copia.
Asistente y navegación · Beta 1.0
La guía local permite empezar, continuar, comparar y buscar ayuda con errores sin activar DeepSeek. Ofrece botones a paneles reales según las LUTs cargadas y la salida declarada. Ningún botón de navegación repara, aplica o exporta una LUT.
Para preguntas libres, activa el acceso Beta. Puedes consultar antes de cargar un archivo; el asistente sabrá que todavía no hay mediciones. Elige Breve, Detalle técnico o Paso a paso. Se usa DeepSeek V4 Flash sin razonamiento extendido, para priorizar la respuesta interactiva. Los modos de explicación no cambian el modelo.
DeepSeek recibe la pregunta, el estado de navegación, el informe numérico disponible y hasta diez mensajes recientes. No recibe imágenes ni archivos .cube. Sólo una consulta explícita usa la API. Una pregunta sin sesión permanece escrita; puedes activar el acceso y enviarla después. Detener cancela la espera de respuesta.
La conversación permanece en esta pestaña y se borra al recargar, cambiar las condiciones de revisión o empezar de nuevo. No hay cuentas individuales ni pagos en esta Beta. La IA explica resultados y límites; no calcula nuevos valores certificados, no inspecciona visualmente tus imágenes y no ejecuta correcciones creativas. Reparación conserva su función numérica específica y genera una copia por decisión del usuario.
Referencias de fabricantes
El catálogo permite cargar en A o B ARRI LogC3/LogC4, Sony s709 para dos gamuts diferentes, RED IPP2 contraste bajo/altas suaves, Blackmagic Gen 5 Video/Extended Video y Panasonic V709. Los archivos conservan su huella y procedencia; RED y Blackmagic se obtuvieron de copias locales de Resolve. Cargar una referencia exige declarar de nuevo una salida común compatible antes de usar ΔE. Panasonic declara niveles legales: no interpretes esos códigos como salida plena sin verificar su adaptación. Apple Log y Apple Log 2 siguen pendientes.
Abre Sala de color para desarrollar o modificar un look; vuelve a Banco con original y variante cuando quieras comprobarlos. No existe un orden obligatorio y los archivos no se transfieren automáticamente entre pestañas.
Reporte de la revisión
El registro que acompaña a una entrega. La forma está copiada de lo que hace el oficio en control de calidad de broadcast y en gestión de looks en rodaje, donde el reporte viaja junto al archivo entregado. Cuatro partes:
- Identidad de lo revisado — nombre, tamaño, dominio y huella de contenido de cada LUT.
- Los números medidos junto al umbral aplicado, nunca un pasa/no-pasa suelto.
- Evidencia visual ubicada en el dato — la curva con el tramo marcado, el cubo, los 24 parches antes y después.
- Procedencia — herramienta, versión, fecha ISO con zona horaria.
Se exporta en dos formatos, que es lo que hacían todas las herramientas del oficio que se revisaron al diseñar esto:
- HTML
- autocontenido, con las imágenes incrustadas. Se abre en cualquier navegador, se imprime a PDF y se adjunta a una entrega.
- JSON
- los mismos datos estructurados, para archivar, comparar entre versiones o alimentar otro proceso.
Métodos y fórmulas
Interpolación
Para evaluar el LUT en cualquier punto que no caiga exactamente sobre un nodo se usa interpolación trilineal: se toman los ocho nodos que rodean el punto y se mezclan según su distancia en los tres ejes.
Lo que no depende de esto: el recorrido del cubo y la comparación en modo nativo leen los nodos crudos del archivo, sin interpolar. Esas dos lecturas son las autoritativas; la curva de la rampa es orientativa.
De sRGB a L\*a\*b\*
Tres pasos estándar, con las constantes de IEC 61966-2-1 y CIE:
Comprobación: el rojo sRGB puro (255, 0, 0) da L\* 53.24, a\* 80.09, b\* 67.20 — los valores de referencia publicados.
Diferencia de color
Es CIE76, la distancia euclídea en L\*a\*b\*. Se eligió por ser transparente y verificable a mano. Existen fórmulas perceptualmente mejores —CIE94, CIEDE2000— que corrigen la desigual sensibilidad del ojo en distintas zonas del espacio; si en algún momento hace falta esa precisión, es un cambio acotado, pero implicaría revisar las bandas de interpretación, que están publicadas para el criterio con que se usan aquí.
Regresión isotónica (PAVA)
Resultado: la secuencia no-decreciente más cercana al original en mínimos cuadrados.
Recorte
Comprobación: un LUT identidad da 0.00% de rango aplastado y ningún punto de corte. Un LUT construido para destruir el 20% inferior lo reporta en 18.8%, que es ese 20% cuantizado a la grilla de nodos.
Umbrales: cuál viene de dónde
Cada cifra con la que la app decide pintar algo de verde o de ámbar sale de algún lado. Estas son todas, y cuáles son criterio propio:
| Control | Umbral | Origen | |
|---|---|---|---|
| ΔE — dentro del objetivo | < 1.0 | Light Illusion, guía de calibración 3D LUT de ColourSpace (objetivo de calibración de pantalla, no de percepción sobre imagen) | publicado |
| ΔE — margen de tolerancia | 1.0 – 2.3 | ídem; el 2.3 procede de Mahy et al. (1994) | publicado |
| ΔE — fuera de tolerancia | > 2.3 | ídem | publicado |
| Pliegue — determinante por celda | < −0.001 | margen sobre el ruido que introduce el redondeo a seis decimales del .cube: medido, ese redondeo mueve el determinante hasta 3.2·10⁻⁴ en 65³ |
propio |
| Aplastamiento — determinante por celda | |det| ≤ 0.001 | ídem; se separa del pliegue porque un volumen aplastado es recorte, no inversión | propio |
| Caída — rampa de grises | > 0.001 | margen para absorber el ruido que introduce la interpolación al muestrear entre nodos | propio |
| Caída — cubo completo | > 0.0001 | más ajustado porque se leen nodos crudos del archivo, sin interpolación de por medio | propio |
| Tramo colapsado | < 1/1023 | un valor de código a 10 bits: por debajo de eso, el tramo no se distingue en una señal de 10 bits | propio |
| Extensión mínima de un colapso | ≥ 2% | por debajo se considera ruido y no se reporta | propio |
| Detección de extremo (0 o 1) | ± 0.0001 | tolerancia numérica de igualdad | propio |
| Rango del cubo sin cambio, en ámbar | ≥ 8% | criterio de esta herramienta; no encontré cifra profesional citable | propio |
| Reparación: descenso demasiado extendido | > 50% de líneas | criterio propio para distinguir una inversión deliberada de un defecto local | propio |
| Reparación: descenso demasiado profundo | > 0.1 | ídem; un punto de control mal puesto produce caídas de milésimas | propio |
| Muestreo de la rampa neutra | 256 / 512 pasos | resolución de análisis, no un umbral de decisión | propio |
Los marcados como propios siempre muestran el número crudo al lado, para que puedas aplicar tu propio criterio en vez del nuestro.
Límites conocidos
- Solo LUTs 3D
.cube. No lee 1D, ni.3dl, ni.clf, ni CDL. CLF, además, sí tiene identificador propio y metadatos — si trabajas con él, buena parte del problema de identidad que aquí resolvemos con una huella ya viene resuelto en el formato. - La monotonicidad se evalúa por líneas rectas del cubo, cada canal a lo largo de su propio eje de entrada. Ese control garantiza una cosa concreta: que el diagnóstico cubra exactamente el mismo terreno que toca la reparación. No garantiza que el LUT sea sano en un sentido más amplio. En particular no examina cómo varía un canal respecto de los otros dos ejes, que es buena parte de lo que hace un LUT 3D. De eso se ocupa ahora el control de pliegue, que es independiente de este: véase Pliegue y corte del cubo.
- ΔE CIE76. Sobrestima diferencias en algunas zonas del espacio, sobre todo en saturados. Para comparar dos versiones del mismo LUT es perfectamente adecuado; para juicios finos de fidelidad, CIEDE2000 sería mejor.
- La vista previa adapta codificaciones conocidas a sRGB. La fuente del navegador es de 8 bits; declara entrada y salida compatibles. Con salida desconocida no se muestra el resultado ni se calcula ΔE. No es una medición del monitor y la IA no recibe imágenes.
- La comparación entre LUTs de distinto tamaño es aproximada. No es una limitación evitable: sin correspondencia entre nodos hay que interpolar. La app lo declara en pantalla y en el reporte para que la cifra no se lea como exacta.
- El detector de pliegue mide orientación, no suavidad. Encuentra las celdas donde el volumen se invierte, que es lo que rompe la invertibilidad. No mide cuán brusca es una transición que no llega a invertirse: un LUT puede tener un escalón feo, perfectamente visible como banda, con el determinante positivo en todo el recorrido. Para eso siguen valiendo el ojo y una carta de degradados.
- El pliegue se muestrea dentro de cada celda. Se evalúa el jacobiano del interpolante trilineal en ocho esquinas y centro. Puede haber inversiones entre muestras o solapamientos distantes que esta prueba no detecta; ausencia de alertas no certifica inyectividad.
- La reparación no arregla un pliegue. PAVA actúa canal por canal sobre su propio eje; la orientación del volumen depende de la mezcla entre canales. Un LUT reparado puede quedar monótono y seguir plegado, y la app lo advierte en el panel de reparación cuando ocurre.
- Solo lee
.cube3D. Ni 1D, ni.3dl, ni.clf, ni CDL, ni LUT de moldeado (shaper) acompañando a uno 3D. - La huella sin contexto seguro no es criptográfica ni reproducible fuera de la app. Detecta cambios accidentales entre revisiones tuyas; no resiste manipulación deliberada ni la puede comprobar un tercero. Para un registro que deba resistir escrutinio, abre la página por HTTPS y obtendrás SHA-256 verificable con
sha256sum. - La codificación de salida es una asunción, no un dato. El
.cubeno la declara. Todas las cifras de ΔE dependen de la que elijas en el panel de carga, y con «log u otra» dejan de tener lectura perceptual. - El panel de ColorChecker y la vista previa evalúan valores de display. Si el LUT espera entrada log, no es su dominio de trabajo y esos dos paneles no dicen nada útil sobre él.
- En modo muestreado, el ΔE máximo es una cota inferior, no el máximo real: la grilla puede no caer sobre el punto peor. La app lo rotula así en ese modo y no le aplica bandas de color.
- La reparación no valida contra una referencia. Hace la curva monótona; que el resultado sea el look correcto lo decides tú comparando.
Tres flujos de trabajo
Verificar una conversión propia contra una de referencia
El caso de una conversión log-a-Rec.709 derivada por cuenta propia que quieres contrastar con la que exporta DaVinci Resolve.
- Carga tu conversión como LUT A y la exportada de Resolve como LUT B.
- Comprueba que la comparación diga modo nativo. Si ambos son 33³ lo será, y las cifras son exactas. Si Resolve te exportó otro tamaño, la app pasará a modo muestreado y avisará: en ese caso vale la pena reexportar al mismo tamaño para poder comparar sin interpolación de por medio.
- Lee el ΔE en el eje de grises primero: si ahí ya hay desviación, el problema es de curva de transferencia, no de gamut.
- Activa colorear por ΔE en el cubo y rota. Si la diferencia se concentra en una región de color, es asunto de primarios; si está repartida, es la curva.
- Genera el reporte y guárdalo junto a los dos archivos. Las huellas dejan constancia de qué versiones exactas comparaste.
Revisar un LUT que te entregaron
- Cárgalo como LUT A y mira el diagnóstico.
- Si hay caídas, localízalas en la curva y decide: ¿lo devuelves para que lo rehagan, o lo reparas y sigues?
- Si hay recorte, comprueba en la vista previa con barras técnicas cuánto se pierde realmente.
- Pide al asistente una lectura si necesitas explicárselo a alguien que no es técnico.
Corregir un LUT con un defecto de fabricación
- Confirma en el diagnóstico que se trata de monotonicidad y no de recorte — son problemas distintos y solo el primero se repara solo.
- Pulsa Reparar monotonicidad y revisa cuánto cambió: si el ΔE respecto del original es muy alto, el defecto era grande y conviene revisar el origen.
- Marca superponer en la curva para ver la corrección sobre la original.
- Descarga el
.cubereparado y genera el reporte: queda registrado qué se corrigió, con qué método y cuánto se movió.
Referencias
Formato APA, 7.ª edición. Fuentes de los datos de referencia, los métodos y los umbrales publicados que usa la herramienta.
Adobe Systems Incorporated e IRIDAS. (2013). Cube LUT specification, version 1.0.
Advanced Data Management Subcommittee, American Society of Cinematographers. (2022). ASC Media Hash List (ASC MHL), version 1.0. https://cdn.theasc.com/ASCMHL_Specification_v1.0.pdf
Academy of Motion Picture Arts and Sciences. (s. f.). Common LUT Format (CLF) specification. ACES Documentation. https://docs.acescentral.com/clf/specification/
Comisión Electrotécnica Internacional. (1999). IEC 61966-2-1: Multimedia systems and equipment — Colour measurement and management — Part 2-1: Colour management — Default RGB colour space — sRGB.
European Broadcasting Union. (2017). EBU QC data model description, v3.0. https://tech.ebu.ch/docs/other/qc/EBU-QC-data_model_description_v3_0.pdf
Light Illusion. (s. f.). ColourSpace — 3D LUT calibration guide. https://lightillusion.com/3d_lut_guide.html
Mononodes. (s. f.). LUT Cube Analyzer [herramienta en línea]. https://mononodes.com/lut-cube-analyzer/ — origen de la idea del corte dibujado como malla deformada, los vectores de desplazamiento y el marcado del recorte sobre el volumen.
Mahy, M., Van Eycken, L., & Oosterlinck, A. (1994). Evaluation of uniform color spaces developed after the adoption of CIELAB and CIELUV. Color Research & Application, 19(2), 105–121.
Pascale, D. (2006). RGB coordinates of the Macbeth ColorChecker. The BabelColor Company. https://babelcolor.com/index_htm_files/RGB%20Coordinates%20of%20the%20Macbeth%20ColorChecker.pdf
Unión Internacional de Telecomunicaciones. (2018). Report ITU-R BT.2380-2: Television colorimetry elements. https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2380-2-2018-PDF-E.pdf
Nota sobre el estado del oficio
No existe una práctica documentada ni un estándar para inspeccionar un archivo .cube arbitrario y dejar constancia de esa revisión. Sí existe un régimen de conformidad para motores de LUT —la batería de pruebas de CLF, con archivos legales e ilegales, imagen de referencia y tolerancias publicadas— y sí existe la norma de entregar un reporte de verificación en calibración de monitores y en control de calidad de broadcast. Lo que hace Banco LUT toma la forma de esas prácticas vecinas; no cumple ninguna norma existente porque, hasta donde alcanzó la investigación hecha para construirlo, esa norma no está escrita.