Implementación preliminar de auto-star-profile-transform.js

[Maxi]

Lo he hecho y si sigue el mismo problema  :roll:

De todos modos gracias David, haber si en la proxima versión puedo probar esta herramienta que parece prometer mucho  :wink:

saludos

[C. Sonnenstein]

Lo he hecho y si sigue el mismo problema

La consola arroja error, ¿al ejecutar el script te salió una interface con parámetros de ajuste? Veo que has guardado el script en el directorio C:\PCL\... Quizás esto tenga algo que ver... prueba ponerlo en C:\PCL\src\scripts

Bueno, por las pruebas que llevo haciendo con diversas imágenes de cielo profundo, estamos viendo que hay bastantes cosas todavía por pulir. En imágenes con film el script funciona realmente muy bien, las estrellas conservan su tamaño original a pesar del incremento de la MTF, evitando además que se pierda saturación de color incluso en los objetos no estelares . Pero en imágenes CCD y DSLR, aunque conseguimos practicamente el mismo efecto en las estrellas, los objetos no estelares tienden a aplanarse, incluso si disminuimos drásticamente el número de iteraciones. Esto es debido a que tras cierto tiempo, la máscara se vuelve demasiado brillante y necesitaremos añadir un parámetro definible desde la interfaz de usuario que consista en poder aplicar un punto de recorte en las sombras de la máscara (o en las luces si pensamos en la luminancia invertida), de manera que en la imagen final los medios tonos no se vean pues afectados. Claro que siempre es posible aplicar luego un pequeño ajuste de curvas, pero es algo que estamos intentando evitar...

Por otro lado, no siempre conseguimos siempre que la mediana resultante sea exactamente la que define el usuario desde la interfaz. A menudo el error es de algo más del 10%... Esto es algo que David va a intentar subsanar de cara a la siguiente versión, así que estar atentos .

Otro aspecto que queremos incluir en el script es la normalización del espacio RGB a la hora de calcular la luminancia, de forma que no sea necesario siempre hacerlo globalmente sobre la imagen.

Y por último, ya que durante el proceso la MTF se aplica de forma iterativa, vamos a hacer que el script funcione también con formatos de archivo en 64-bit (en el código actual solo es posible ejecutarlo a 32-bit) evitando que se puedan producir errores de redondeo, especialmente si se incrementa mucho el número de iteraciones.

[David Serrano]

Buen resumen .

Veo que has guardado el script en el directorio C:\PCL\... Quizás esto tenga algo que ver... prueba ponerlo en C:\PCL\src\scripts

Podría, pero no sé no sé. He corregido algunas cosas relativas a esto de los Settings (básicamente: ahora ya hace lo que debería ) pero eso no debería hacer que ya te funcionara en tu caso, Maxi. Ni idea de lo que pasará...

A menudo el error es de algo más del 10%... Esto es algo que David va a intentar subsanar de cara a la siguiente versión, así que estar atentos .

Aviso, va a ser leeeeentooooo . El script hará una copia de la imagen, la reducirá drásticamente de tamaño (a una anchura de 640 o por ahí) y le hará el proceso entero varias veces, con máscaras y todo, para tantear el valor de mtf correcto. Una vez hallado, descartará esta imagen temporal y repetirá todo una vez más con la imagen inicial.

vamos a hacer que el script funcione también con formatos de archivo en 64-bit

Esto es una chorradita pequeña que en principio ya he cambiado .

[Maxi]

De todos modos gracias a todos y sobre todo a ti David por el curro que te estas pegando  :wink:

Saludos

[Jordi Gallego]

Hola,

En las pocas pruebas que pude hacer ayer constato todo lo comentado ya por Carlos:

-el aplanamiento de las nebulosas es un hecho y si se puede mejorar tal y como indica Carlos aplicando un recorte a la(s) máscaras pues sería estupendo. Si embargo, tengo un pelícano a medio procesar y como el mismo Carlos indica un pequeño ajuste de curvas mejora bastante la cosa  :wink:

- con la imagen del pelícano confirmo la pequeña deriva del target:  buscando 0.125 he obtenido valores entre 0.144 y 0.142, aunque tambien es verdad un pequeño recorte de las sombras (0.03% de los pixels) deja el pico en 0.125. Conociéndo su comportamiento, esta cuestión no parece un problema grave para el usuario

- como curiosidad he estirado la imagen de forma convencional y de forma iterativa y con la ayuda de otra herramienta informática he medido el FWHM medio de todas las estrellas de la image (más de 3000): en el estirado clásico  he encontrado 6,75 pixels, mientras que en la versión iterativa (20 pasadas), aparte de una mejora notabilisima en el perfil y en el mantenimiento del color estelar, el FWHM era de 5,76!

- por último decir que es una verdadera gozada correr el script con la ventana de histogramas abierta y ver como va moviéndose el histograma hacia la derecha tras cada iteración

Saludos y gracias todos los que estais trabajando en todo esto :wink:
Jordi

[Juan Conejero]

En primer lugar quiero felicitaros por el excelente trabajo que estáis haciendo. Me gusta mucho la idea de este ajuste iterativo, y estoy seguro de que se le puede sacar mucha punta.

A menudo el error es de algo más del 10%...

Aviso, va a ser leeeeentooooo Wink. El script hará una copia de la imagen, la reducirá drásticamente de tamaño (a una anchura de 640 o por ahí) y le hará el proceso entero varias veces, con máscaras y todo, para tantear el valor de mtf correcto. Una vez hallado, descartará esta imagen temporal y repetirá todo una vez más con la imagen inicial.

Une solution force brute, mon amie :lol:

Si el error cometido es sólo del orden de un 10%, podrías aplicar un ajuste final de medios tonos sin máscara para forzar el valor de la mediana deseado. Puedes usar una rutina basada en búsqueda binaria como haces ahora para buscar el valor de mtf. ¿Qué te parece?

[Juan Conejero]

vamos a hacer que el script funcione también con formatos de archivo en 64-bit

Esto es una chorradita pequeña que en principio ya he cambiado .

Trabajar en 64 bits puede ser conveniente, sobre todo si se hacen muchas iteraciones. Yo lo pondría como una opción (como en PixelMath por ejemplo), aunque por defecto trabajaría en 32 bits. Otra posibilidad es trabajar con enteros de 32 bits, que nos dan un rango nada despreciable de 2^32 valores discretos. Con 32 bits en punto flotante no debemos esperar más de 2*10^6 valores (que no está nada mal, por otra parte), teniendo en cuenta que el proceso completo es complicado y da muchas oportunidades para que los errores por redondeo hagan de las suyas.

[David Serrano]

Bueno, ya tengo la 0.4 lista. He de decir que no estoy nada satisfecho con su rendimiento. El problema principal que veo es que el programa insiste, como ya he mencionado en un mensaje anterior, en guardar un "swap file" con la máscara (creo) y esto, al generar operaciones de lectura/escritura contra disco, aunque realmente se realicen totalmente en el caché, provoca que la velocidad de la ejecución sea drásticamente más lenta de lo que podría. Y lo hace incluso aunque trabaje con una imagen realmente pequeña (300 píxels de ancho).

Pienso que no es una cosa que haga HistogramTransform, tal como creía antes, dado que el código fuente de este proceso está disponible y una pequeña búsqueda que he hecho no dio resultados. Debe de ser algo interno de Pixi. No he visto nada que me llamara la atención en GlobalPreferences.

Otro problema gordo es que el entorno se queda con un montón de imágenes creadas y ocultas, que aparecen en el View Selector (el desplegable de abajo a la izquierda). Sin embargo, al ejecutar un pequeño script que hice para investigar esto mismo, desaparecieron todas. Sospecho que PixInsight no las está borrando cuando debe a) por error, o b) como una medida de optimización (favorecer el uso de CPU aunque esto redunde en un mayor consumo de memoria). Si esto es un problema o no, es algo que sólo Su Santidad nos puede revelar.

Más: la salida de todos los HT's aparece por la consola de forma aparentemente irremediable. Ya que tenemos ese ruido, no me he matado a quitar mi información de depuración, tal como solía hacer hasta ahora. Total, unos numeritos más por aquí y por allá no creo que vayan a molestar nada .

En el lado bueno, los errores de mediana observados han mejorado ostensiblemente: 0.12% en una ocasión y 0% en otras dos 8). Supongo que esto nos permite modificar el valor de epsilon y hacerlo menos exigente; jugaré con ello.

También he ampliado el número máximo de iteraciones posible, porque me parece que alguno le va a dar uso ;^). Ahora se puede darle hasta 200. Sin embargo, tal y como está el panorama, darle más de 5 no creo que sea muy buena idea.

Ah, y un detalle más que casi se me olvida: esta versión necesita el archivo ResizeMode.jsh que Juan nos mostró aquí.

Con respecto al ajuste final de curvas, Mr. Sonnenstein dice que eso es algo que estamos intentando evitar. Yo de procesado ni papa, así que me limito a lo mío, que es quemar ordenadores .

Y en referencia a trabajar en 32 flotante, 32 entero o 64... ¿tendría que encargarse el script de hacer la conversión de formato? Supongo que sí, óptimamente usando SampleFormatConversion, verdad?

El script con la 0.4 lo encontraréis en un mensaje previo dentro de este mismo hilo, concretamente este.

Para la 0.5 le pondré unos cambios en el código de Settings siguiendo las recomendaciones recién aparecidas en otro hilo .

[David Serrano]

Estoy centrando mis esfuerzos (mentales de momento, he dejado el javascript enfriando un ratito, que ya le salían burbujitas y eso no es bueno) en reducir el número de pasadas necesarias para hallar el valor de mtf correcto.

Lo que está claro es que si el usuario escoge, digamos, 15 iteraciones y la búsqueda binaria emplea, pongamos, 10 pasadas en encontrar el valor de mtf adecuado, vamos a ejecutar HistogramTransform 10 * 15 = 150 veces sobre la imagen, con sus máscaras y tal. Debido a este asunto de los swap files, 150 veces sencillamente no puede ser.

Así que he estado cavilando un rato en cómo mejorar la búsqueda para disminuir ese 10 del ejemplo anterior, y de momento creo que tengo un 3 . Invariante además, es decir, siempre van a ser 3 (actualmente pueden ser 10, 8, 12...). Se trata de probar 3 valores de mtf arbitrarios, ver las medianas resultantes, y extrapolar usando una función cuadrática para obtener el valor deseado. Al final, aquel libro de algoritmos en Perl que me leí hace tiempo, ha servido para algo más que Perl .

Ejemplo: tenemos una imagen cuya mediana es 0.009 y el usuario quiere obtener una de 0.111. Hacemos 3 pasadas de todo el proceso usando 3 valores de mtf y obtenemos estas medianas:

Code: [Select]

MTF      Mediana
0.45 --> 0.080
0.35 --> 0.160
0.30 --> 0.330

Según aquel libro decía, existe una única función cuadrática que pasa por estos 3 puntos. El problema se reduciría a hallar los 3 coeficientes de esa función (copiando del libro y traduciendo de Perl a Javascript ) y luego buscar en esa curva el valor de mtf. Esto ya sí que puede hacer 500 pasadas si quiere, puesto que es un proceso estrictamente numérico (igual que el propio cálculo de mtf en las versiones 0.2 y 0.3 de este script). También se podría probar una función exponencial, pero sería algo más rudimentario puesto que ya no copiaría de un libro, sino que sería un tanteo tal como hice una vez a mano (es decir, un tanteo para hallar la ecuación y otro para buscar el valor de mtf en ella).

La mediana obtenida no va a ser tan exacta como ahora, pero pienso que un error del 5% es bastante aceptable, y de todas formas cuento con que sea menor. Quizá ya antes de la 0.4 no era tan alto como creíamos, debido a esto del rescale del PixelMath (aquí). Quizá también se podría hallar sólo 2 valores en lugar de 3, y usar una función lineal pero supongo que entonces el error ya se nos iría de las manos.

Así, volviendo al principio, tendríamos 3 pasadas del algoritmo * 15 iteraciones especificadas por el usuario = 45 ejecuciones de HT. Y el usuario tendría que especificar nada menos 50 iteraciones para alcanzar el 150 de antes, lo cual ya es un valor respetable.

¿Qué os parece?

(Edit: "valor" --> "error" en el penúltimo párrafo)

[Juan Conejero]

Bien, por fin tengo tiempo para ver qué es lo que estáis haciendo por aquí   :twisted:

El problema principal que veo es que el programa insiste, como ya he mencionado en un mensaje anterior, en guardar un "swap file" con la máscara (creo) y esto, al generar operaciones de lectura/escritura contra disco, aunque realmente se realicen totalmente en el caché, provoca que la velocidad de la ejecución sea drásticamente más lenta de lo que podría.

Nada de eso. El verdadero cuello de botella de este script es el cálculo de la luminancia. Para comprobarlo, sólo tienes que monitorizar este cálculo en la función get_luma y, ya de paso, también en get_median:

Code: [Select]

   this.get_luma = function (view) {
        view.image.statusEnabled = true;
        view.image.extractLuminance (luma = new Image);
        return luma;
    }

    // obtains luma, then its median.
    this.get_median = function (view) {
        var l = this.get_luma (view);
        l.statusEnabled = true;
        stats.generate (l);
        return stats.median;
    }

El estado de Image.statusEnabled determina si se muestra por la consola información de progreso para todas las transformaciones y rutinas numéricas de Image. En este caso, como podrás comprobar, la mayor parte del tiempo se está invirtiendo en calcular la luminancia de todos los píxeles de la imagen. El tiempo de proceso invertido en HistogramTransform, aun teniendo en cuenta la generación de archivos de intercambio, es secundario por no decir marginal.

Una posible solución, aunque no demasiado "sana" en mi opinión, sería sustituir la luminancia por el canal V de HSV o I de HSI, cuyo cálculo es trivial. En breve habrá un objeto RGBColorSystem en el runtime de JS, que será el equivalente a su homónimo en PCL. Entonces todas las transformaciones entre espacios de color se ejecutarán por código nativo. Yo de todas formas probaría con el I de HSI, que se parece bastante, según se mire, a la luminancia en sRGB. En breves momentos subo una rutina que calcula el I para una imagen.

[Juan Conejero]

Como adelantaba, aquí está una rutina para calcular la intensidad (componente I de HSI) en vez de la luminancia en este script.

Sin embargo, no os hagáis ilusiones: es peor el remedio que la enfermedad, ya que ésta es más lenta que Image.extractLuminance(). Y es que me temo que estamos pidiendo demasiado a un lenguage interpretado...

Pongo la rutina aunque sólo sea por su valor didáctico:

Code: [Select]

  this.get_I = function( view )
   {
      if ( view.image.colorSpace == ColorSpace_Gray )
         return new Image( view.image );

      function get_I_sample( x, y, c, s, img )
      {
         var R = img.sample( x, y, 0 );
         var G = img.sample( x, y, 1 );
         var B = img.sample( x, y, 2 );
         this.currentSample = 0.5*(Math.min( R, G, B ) + Math.max( R, G, B ));
      }

      var I = new Image( view.image.width, view.image.height );
      I.statusEnabled = true;
      I.initializeStatus( "Extracting intensity", view.image.bounds.area );
      I.forEachSample( get_I_sample, view.image );
      return I;
   }

get_I() sería un reemplazo para la actual get_luma(). Sin embargo, como he dicho, get_I() es bastante más lenta, así que no hay caso.

[Juan Conejero]

existe una única función cuadrática que pasa por estos 3 puntos. El problema se reduciría a hallar los 3 coeficientes de esa función

Efestivi Wonder (Bra). La idea es buena, y además me parece que hasta te va a funcionar. En cualquier caso, vale la pena probarlo.

Una sugerencia: trata por todos los medios de no extrapolar. O sea, no busques un valor fuera del intervalo definido por los tres puntos de tu tabla de interpolación. Más bien, si puedes, trata de tener cierta holgura alrededor del punto que buscas. La razón es que con una interpolación cuadrática estás suponiendo que la curva de medianas es una parábola, lo cual no va a ser "cierto" más que para un intervalo relativamente pequeño en torno al mínimo de la curva.

Para conseguir evitar la extrapolación, asegúrate de calcular los tres puntos de la tabla a distancias suficientes entre sí. Tal vez sería una buena idea prever un mecanismo de corrección que pudiera repetir el cálculo de la tabla a distancias mayores y/o mejor centrada respecto del punto buscado, si éste se te escapa.

Como es evidente que esto se va a convertir en un módulo (jejeje), no descartes emplear un algoritmo de interpolación más refinado (= diferente de interpolación polinómica). Los splines cúbicos me vienen a la cabeza, así de repente, no sé por qué será...  :roll:  :wink:

Ah, y otra cosa. Sigo insistiendo en que un último ajuste de medios tonos sin enmascarar para alcanzar la mediana buscada con total precisión sería muy conveniente, en mi opinión.

[David Serrano]

Más bien, si puedes, trata de tener cierta holgura alrededor del punto que buscas.

¿Por qué es mejor tener holgura? ¿No sería mejor intentar aproximarse mucho con estas tres estimaciones? Así, la interpolación sería también más exacta.

Para conseguir evitar la extrapolación, asegúrate de calcular los tres puntos de la tabla a distancias suficientes entre sí.

Sí... pero eso me obligaría a elegir un criterio arbitrario para elegir esos puntos, y estoy seguro de que los usuarios tarde o temprano encontrarán una combinación de imagen+objetivos que se salga de los valores elegidos. No quiero restringir al usuario a la hora de hacer lo que quiera, y si lo que quiere es quemar la imagen con este programa, o por el contrario dejarla totalmente negra, debería ser capaz de hacerlo.

Como es evidente que esto se va a convertir en un módulo (jejeje), no descartes emplear un algoritmo de interpolación más refinado (= diferente de interpolación polinómica). Los splines cúbicos me vienen a la cabeza, así de repente, no sé por qué será...  :roll:  :wink:

Jeje, a la yugular eh? Y ya van dos! (la otra es "Y es que me temo que estamos pidiendo demasiado a un lenguage interpretado... " jejeje, que te creías que no la iba a pillar xD). Con respecto a los splines, estoy totalmente a cero en ese tema. Sé que es una cosa muy chula que existe y que es capaz de hacer pasar una curva por todos los puntos que queramos, pero nada más.

---

Estas últimas horas he estado intentando encontrar un mecanismo para que los 3 valores a partir de los cuales calculamos la función cuadrática (o spline o bananas :^P) no sean totalmente aleatorios, elegidos en un momento del tiempo y planchados en el script como números mágicos. Ugh...

Le he hecho muy pocas pruebas (apenas con dos imágenes) pero me parece que como propuesta preliminar, merece la pena ponerla por aquí. Aviso, esto es artesanía pura, que sólo estudié hasta los 20 y repitiendo cursos... (*)

Partimos de dos valores: la mediana actual de la imagen (MA), y la mediana que queremos como objetivo (MO). Haciéndole un par de cosquillitas a estos números, obtenemos una primera aproximación de MTF bastante buena a mi juicio:

Code: [Select]

Pepito = 1 + MO/MA
MTF = 1 / Pepito

Aplicando con este valor obtenemos una imagen cuya mediana, dividida entre MA, nos da un valor parecido a Pepito. Usaremos la diferencia entre este valor y el Pepito real, para probar un nuevo valor de MTF. Repetimos una segunda vez y ya tenemos 3 MTFs.

He aquí los números reales de una de las pruebas. Tenemos una imagen con mediana 0.0025, y pongamos que queremos 0.0800:

Pepito = 1 + 0.0800/0.0025 = 1 + 32.0000 = 33.0000
MTF = 1 / 33.0000 = 0.0303

Aplicando un histogramita (una sola iteración y sin máscara, que las pruebas van a mano) obtenemos una imagen con mediana 0.0956. ¡Nada lejos del 0.0800 deseado! A ver cómo ha cambiado nuestro Pepito:

Nuevo Pepito = 0.0956/0.0025 = 38.2400

Como nos hemos pasado con la mediana, Pepito también es mayor que el original. La diferencia entre ellos es 5.2400. Para alterar el valor de MTF, he decidido sumarle una milésima de esta diferencia:

Nueva MTF = MTF previa + (38.2400 - 33.0000) / 1000 = 0.0355

Aplicando, obtenemos una imagen con mediana 0.0771. Más cerca todavía y, lo que es más importante, menor que la buscada. Ya tenemos un valor mayor y uno menor, lo que significa que la MTF real ya la tenemos cazada.

Nuevo Pepito = 0.0771/0.0025 = 30.8400
Nueva MTF = MTF previa + (30.8400 - 33.0000) / 1000 = 0.0334

Y aquí tenemos 3 valores para MTF. ¿Alguien ha aguantando hasta aquí? Os dije que era artesanía...

Al probar en otra imagen, parte de esta montaña de inventos se vino abajo . Básicamente no conseguí una mediana a ambos lados del objetivo, lo que significa que el valor real de MTF estaba más allá. Cambiando el cociente 1000 por un 500 (es decir, alterando MTF en dos milésimas en lugar de una) casi lo pillo, pero aún se me quedó fuera. Poniéndole 200 (5 milésimas) supongo que me pasaré 3 pueblos, pero al menos creo que puedo estar seguro de tenerlo cazado. Y al fin y al cabo, serán 3 milésimas de pueblo lo que me pase.

Hala, a ver a quién se le han quedado los :shock:j:shock:s más grandes...


(*) Realmente no he estudiado en toda mi vida, pero eso :^P.

[Carlos Milovic]

Reconozco que no lei el mensaje atentamente, asi que puede que te diga algo repetido (sorry, estoy con prisa). Para las estimaciones de los 3 puntos te puede servir:

1.- MTF = 0.5 Ningun cambio. Este seria un punto de "anclaje".
2.- MTF = Mediana actual. Esto convertiria el valor de la mediana en 0.5. Es algo grosero, pero es un buen punto a usar.
3.- Ahora puedes usar cualquier proporcion entre ambas como el 3er punto. Como generalmente la mediana se deja con un valor entre el valor actual y 0.5, el promedio seria un buen punto de partida.


De todas maneras, creo que una interpolacion cuadratica no es suficiente... pero bueno, ya tienes con que partir.

[David Serrano]

Lo siento, no soy capaz. He vuelto a poner la 0.3 en su sitio. Que la disfrutéis.