PixInsight Forum

PixInsight => Release Information => Topic started by: Juan Conejero on 2009 April 17 00:20:24

Title: PixInsight 1.5: Prerelease Information
Post by: Juan Conejero on 2009 April 17 00:20:24
[Texto en Español al final]

Hi,

As all of you probably know already, we are working very hard to finish PixInsight 1.5. This new version was initially scheduled for March. The bad news is that, thinking realistically, I don't hope to be able to release it before the end of April; perhaps a bit later. The good news is that this delay is due to a large number of exciting new processing tools and features. So the net result is that PixInsight 1.5 is a much more powerful, versatile and stable image processing platform than what was initially planned. This post is to warm you up with a few screenshots that demonstrate some of the new capabilities that we are preparing for PixInsight 1.5.

New Feature: Virtual Views

PixInsight 1.5 introduces a new and powerful concept: virtual views. A virtual view is an object of the user interface that behaves just like an actual view (a main view or a preview) in some fundamental aspects, even though it isn't actually a real view pertaining to an image window.

In version 1.5, the Real-Time Preview interface can be used as a virtual view. This means that any processing tool is able to work with the internal real-time preview image that is being represented on the screen, irrespective of the process that owns the Real-Time Preview interface at a given moment.

Yes, I know that the above explanation sounds quite a bit confusing, so let's put an example:

http://forum-images.pixinsight.com/legacy/1.5-preview/VirtualViews.jpg

The screenshot above shows the Real-Time Preview interface owned by the CurvesTransformation interface. The real-time preview image being shown is the result of the S-shaped curve being defined. So far everything looks pretty normal. But please look more carefully at the HistogramTransformation and Statistics interfaces. Specifically, pay attention to the fact that the RealTimePreview virtual view has been selected on both tools.

So the histogram and statistical data being shown are being calculated in real-time for the current Real-Time Preview image. As soon as we move a curve point, the following happens:

- The Real-Time Preview image is regenerated to show the result of the current curve.

- The histograms of the resulting Real-Time Preview image are recalculated and drawn on the HistogramTransformation interface. Furthermore, a histogram transformation has been defined, and its effects are calculated and shown on the upper panel of HistogramTransformation.

- The statistics of the resulting Real-Time Preview image are recalculated and printed on the Statistics interface.

And everything happens smoothly in real-time, using all processors available. You'll love this feature 8)

Improved Tool: DynamicBackgroundExtraction

The DBE process can now apply a background correction. It can subtract the generated background model from the target image, or divide the target image by the model. Optionally, the subtraction or division can preserve the existing mean background values, or neutralize them (when the background model is accurate, of course). Here's a screenshot:

http://forum-images.pixinsight.com/legacy/1.5-preview/DynamicBackgroundExtraction.jpg

New Tool: BackgroundNeutralization

The new BackgroundNeutralization tool allows you to achieve a perfect neutral background in just a couple clicks. No more PixelMath required to carry out neutralization operations.

In the following example:

http://forum-images.pixinsight.com/legacy/1.5-preview/BackgroundNeutralization-1.jpg

We have a M17 DSLR image (courtesy of Vicent Peris and José Luis Lamadrid) before background neutralization. Although the overall color is good for the main object, it is obvious that the background has a strong green cast.

BackgroundNeutralization requires a good background reference. A good background reference includes mainly data that actually represents the sky background in the image. In this case, the image has few free sky background regions. Note that we have used the excellent PreviewAggregator script by David Serrano to gather five background areas into a single image, which we have selected to sample the background in the image.

Here is the same image after applying BackgroundNeutralization:

http://forum-images.pixinsight.com/legacy/1.5-preview/BackgroundNeutralization-2.jpg

Note that we have been working with a raw linear image all the time.

New Tool: ColorCalibration

Accurate color calibration made easy. No more PixelMath burden and complex procedures are necessary to accomplish this task: the ColorCalibration tool makes all the dirty work for you, both quickly and accurately.

Here is an example with the same M17 image used before:

http://forum-images.pixinsight.com/legacy/1.5-preview/ColorCalibration-1.jpg

After BackgroundNeutralization (which is a mandatory initial step for the sake of calibration accuracy), the above screenshot shows the ColorCalibration tool being used to calibrate the image by sampling a high number of stars in the image. Note the aggregated images with two and nine previews being used, respectively as the background and white references.

The basic idea behind this procedure is that when a sufficiently large number of stars are sampled, the resulting mean color should be a plausible white reference for overall color correction. For more information on this topic, see this forum discussion:

http://pixinsight.com/forum/viewtopic.php?t=1074

This forum thread has motivated the immediate release of this tool, which had been designed but not planned for version 1.5.

Here is the image after color calibration:

http://forum-images.pixinsight.com/legacy/1.5-preview/ColorCalibration-2.jpg

Note that ColorCalibration can generate a mask with the employed white reference pixels. This is a useful feature to gain tight control over the process.

The feature selection algorithm used to isolate stars as white references (or, more precisely, small-scale structures) is an adaptation of the star detection algorithm that I designed for the StarAlignment tool. It really works very well, as you can see.

ColorCalibration can also work with a view as its white reference image. This is particularly useful to calibrate an image using a nearby galaxy. The integrated light of a nearby galaxy is a plausible white reference, since it contains large samples for all star populations and its redshift is negligible. This method has been proposed by PTeam member Vicent Peris, who has implemented it to calibrate a number of images taken with large telescopes. According to Vicent, ideal calibration galaxies should have the following properties:

- Closer than 50 mpc

- Hubble classifications Sa, Sb, Sc, Scd, SBa, SBb, SBc or SBcd

- Inclination less than 60 degrees

- Integrated intrinsic intergalactic and galactic reddening < 0.5 mag in Johnson B

Here is an example with Vicent's NGC7331 image taken with Calar Alto's 3.5 meter telescope:

The RGB composite image before calibration:
http://forum-images.pixinsight.com/legacy/1.5-preview/ColorCalibration-3.jpg

After BackgroundNeutralization:
http://forum-images.pixinsight.com/legacy/1.5-preview/ColorCalibration-4.jpg

After ColorCalibration:
http://forum-images.pixinsight.com/legacy/1.5-preview/ColorCalibration-5.jpg

New Tool: ImageIntegration

Version 1.5 comes with a first version of the ImageIntegration tool. This tool performs a combination of an unlimited number of FITS files into a single integrated (stacked) image. ImageIntegration is a high-performance tool with the following main features:

- Mean, median, minimum and maximum image combination operations.

- k-Sigma clipping, percentile clipping, min/max, CCD-clip and average sigma clipping rejection algorithms.

- Automatic image scaling and normalization, definable separately for image combination and pixel rejection.

- Generation of pixel rejection maps.

- Exhaustive pixel rejection statistics console output.

- Optional generation of a 64-bit combined image.

Here is an example with 20 raw images of the M81/M82 region by Oriol Lehmkuhl and Ivette Rodríguez:

http://forum-images.pixinsight.com/legacy/1.5-preview/ImageIntegration.jpg

Improved Tool: ATrousWaveletTransform

ATrousWaveletTransform (ATW for short) has been completely redesigned and reimplemented from scratch. This tool had not been revised seriously since its initial implementation in PixInsight LE. ATW is now the state-of-the-art tool that all PixInsight users deserve.

Everything has changed inside ATW, in fact, even if most changes are not directly visible to the user. One of the most important changes is the new deringing algorithm, which has been designed by Vicent Peris, our resident wavelets guru :)

ATW's deringing now works, works always, and works extremely well. Here's an example:

The original image:
http://forum-images.pixinsight.com/legacy/1.5-preview/ATW-deringing-1.jpg

A relatively strong bias applied to the second wavelet layer, no deringing:
http://forum-images.pixinsight.com/legacy/1.5-preview/ATW-deringing-2.jpg

Same bias, deringing enabled:
http://forum-images.pixinsight.com/legacy/1.5-preview/ATW-deringing-3.jpg

Note that there is no dark ringing at all. Similar results can be obtained consistently for all linear and nonlinear images. In this example, we have applied deringing to dark rings exclusively (dark Gibbs artifacts). Ringing can also be controlled for bright artifacts:

Original Lena image:
http://forum-images.pixinsight.com/legacy/1.5-preview/ATW-deringing-4.jpg

Strong bias applied to the second wavelet layer, no deringing:
http://forum-images.pixinsight.com/legacy/1.5-preview/ATW-deringing-6.jpg

Note the bright artifacts on the borders of bright-to-dark discontinuity transitions. For example, the bright ringing artifact on Lena's shoulder is conspicuous. These artifacts virtually disappear with the new deringing algorithm, as can be seen below.

Same bias, deringing applied to dark and bright artifacts:
http://forum-images.pixinsight.com/legacy/1.5-preview/ATW-deringing-5.jpg

Another important improvement in ATW is the new wavelets-based noise reduction algorithms. This is an example with a Leo Trio raw CCD image by PTeam members Oriol Lehmkuhl and Ivette Rodríguez:

Raw RGB composite image, before noise reduction:
http://forum-images.pixinsight.com/legacy/1.5-preview/ATW-noise-reduction-1.jpg

After multiscale noise reduction with ATW:
http://forum-images.pixinsight.com/legacy/1.5-preview/ATW-noise-reduction-2.jpg

Take into account that the above noise reduction has been applied without a protection mask. Pay special attention to the preservation of star colors and subtle details on the main galaxy. Note also that this noise reduction can be applied to linear images, as in the above example. This is an extremely powerful noise reduction algorithm.

Core GUI Improvement: Enhanced Script Editor

The script editor includes now a nice line numbering feature, bookmarks and parenthesis matching:

http://forum-images.pixinsight.com/legacy/1.5-preview/ScriptEditor.jpg

Core GUI Improvement: Redesigned Explorer Windows

The right panel of the Process Explorer window has been redesigned to provide exhaustive information about the capabilities and parameters of each process. This information is intended to facilitate the work of developers on the PixInsight/PCL framework:

http://forum-images.pixinsight.com/legacy/1.5-preview/ProcessExplorer.jpg

The Format Explorer and View Explorer windows have seen similar evolutions:

http://forum-images.pixinsight.com/legacy/1.5-preview/FormatExplorer.jpg
http://forum-images.pixinsight.com/legacy/1.5-preview/ViewExplorer.jpg

By the way, the above screenshot also shows the new file formats supported in PI 1.5: GIF (Graphics Interchange Format), ICO (Windows Icon Format) and MNG (Multiple Network Graphics). Note that GIF and MNG animations are not supported, and that the GIF and MNG format implementations provide read-only support.

New 64-bit Mac OS X Version

PixInsight 1.5 will be available as a 64-bit application for Mac OS X 10.5 and later. Breaking all memory barriers on the Mac!

Of course 32-bit and 64-bit versions will continue being available for Linux, Windows and Mac OS X.

Improved Compatibility with Linux Distributions

No more problems on all (modern) Linux distributions. PixInsight 1.5 runs out-of-the-box on the latest Red Hat, Fedora, Debian, Ubuntu, SUSE and Mandriva Linux distributions.



============================================================================



Hola

Como probablemente sabéis todos vosotros, estamos trabajando muy duro para terminar PixInsight 1.5. Esta nueva versión estaba inicialmente prevista para ser publicada en marzo. La mala noticia es que, pensando de forma realista, no creo que podamos publicarla antes de finales de abril; quizá algo más tarde. La buena noticia es que este retraso obedece a un gran número de nuevas herramientas y características. El resultado es que PixInsight 1.5 es una plataforma de procesasmiento de imágenes mucho más potente, versátil y estable de lo que inicialmente estaba previsto. Este mensaje pretende enseñaros algunas de las nuevas herramientas y funciones que estamos preparando para que tengáis aún más ganas de probar PixInsight 1.5 :)


Nueva Función: Vistas Virtuales

PixInsight 1.5 introduce un nuevo y potente concepto: vistas virtuales. Una vista virtual es un objeto de la interfaz que se comporta como una vista real (una vista principal o una previsualización) en algunos aspectos fundamentales, aunque en realidad no sea una vista perteneciente a una ventana de imagen.

En la versión 1.5, la interfaz Real-Time Preview es capaz de funcionar como una vista virtual. Esto significa que cualquier herramienta de procesamiento puede trabajar con la imagen interna en tiempo real que está siendo representada en pantalla, independientemente del proceso que posea la interfaz Real-Time Preview en un momento concreto.

Sí, sé que la explicación anterior suena algo confusa, así que mejor pongamos un ejemplo:

http://forum-images.pixinsight.com/legacy/1.5-preview/VirtualViews.jpg

Esta copia de pantalla muestra la interfaz Real-Time Preview controlada por la interfaz de CurvesTransformation. La imagen que se está mostrando en tiempo real es el resultado de la curva en forma de S que se está definiendo. Hasta ahora todo parece muy normal. Pero por favor mirad más atentamente a las interfaces de HistogramTransformation y Statistics. Específicamente, prestad atención al hecho de que la vista virtual RealTimePreview ha sido seleccionada en ambas herramientas.

De esta forma, los histogramas y datos estadísticos que se están mostrando están siendo calculados en tiempo real para la imagen actual en Real-Time Preview. Tan pronto como movemos un punto de la curva, ocurre lo siguiente:

- La imagen de Real-Time Preview es generada para mostrar el resultado de la curva actual.

- Los histogramas de la imagen resultante en Real-Time Preview son recalculados y dibujados sobre la interfaz de HistogramTransformation. Más aún: una transformación de histograma ha sido definida, y sus efectos son calculados y mostrados en el panel superior de HistogramTransformation.

- Las estadísticas de la imagen resultante en Real-Time Preview son recalculadas y escritas en la interfaz de Statistics.

Y todo eso ocurre suavemente en tiempo real, utilizando todos los procesadores que haya disponibles. Os va a encantar esta función 8)

Herramienta Mejorada: DynamicBackgroundExtraction

El proceso DBE puede aplicar ahora una corrección del fondo. Puede restar el modelo del fondo generado de la imagen destino, o dividir la imagen destino por el modelo. Opcionalmente, la resta o división puede preservar los valores medios del fondo existentes, o puede neutralizarlos (cuando el modelo del fondo es preciso, por supuesto). Aquí tenemos una copia de pantalla:

http://forum-images.pixinsight.com/legacy/1.5-preview/DynamicBackgroundExtraction.jpg

Nueva Herramienta: BackgroundNeutralization

La nueva herramienta BackgroundNeutralization permite conseguir una fondo perfectamente neutro en sólo un par de clics. Ya no es necesario utilizar PixelMath para llevar a cabo estas operaciones.

En el ejemplo siguiente:

http://forum-images.pixinsight.com/legacy/1.5-preview/BackgroundNeutralization-1.jpg

tenemos una imagen DSLR de M17 (cortesía de Vicent Peris y José Luis Lamadrid) antes de la neutralización del fondo. Aunque el color general es bueno para el objeto principal, es obvio que el fondo tiene una fuerte dominante verde.

BackgroundNeutralization requiere una buena referencia del fondo. Una buena referencia del fondo incluye principalmente datos que realmente representan el fondo del cielo en la imagen. En este caso, la imagen tiene pocas zonas libres de cielo. Como véis hemos usado el excelente script PreviewAggregator por David Serrano para recoger cinco áreas del fondo en una única imagen, que ha sido seleccionada para muestrear el fondo en la imagen.

Aquí está la misma imagen tras aplicar BackgroundNeutralization:

http://forum-images.pixinsight.com/legacy/1.5-preview/BackgroundNeutralization-2.jpg

Como podéis comprobar, hemos estado trabajando todo el tiempo con una imagen lineal.

Nueva Herramienta: ColorCalibration

Calibrar el color con precisión es ahora fácil. Ya no son necesarios complejos procedimientos con PixelMath para llevar a cabo esta tarea: la herramienta ColorCalibration hace todo el trabajo sucio por vosotros, de forma rápida y precisa.

Aquí hay un ejemplo con la misma imagen de M17 utilizada anteriormente:

http://forum-images.pixinsight.com/legacy/1.5-preview/ColorCalibration-1.jpg

Después de BackgroundNeutralization (que es un paso previo obligatorio para poder alcanzar precisión en la calibración), la copia de pantalla anterior muestra cómo la herramienta ColorCalibration está siendo utilizada para calibrar la imagen mediante el muestreo de un alto número de estrellas. Dos y nueve previsualizaciones han sido agregadas para utilizarlas, respectivamente, como referencias del fondo y el balance de blanco.

La idea básica tras este procedimiento es que cuando se muestrea un número suficientemente grande de estrellas, el color promedio resultante debería ser una referencia de blanco plausible para corregir la imagen en conjunto. Para más información sobre este tema, ver esta discusión en el foro:

http://pixinsight.com/forum/viewtopic.php?t=1074

Esta discusión ha motivado la implementación inmediate de esta herramienta, la cual estaba ya siendo diseñada pero no estaba planificada para la versión 1.5.

Aquí está la imagen tras la calibración de color:

http://forum-images.pixinsight.com/legacy/1.5-preview/ColorCalibration-2.jpg

Fijaos en que ColorCalibration puede generar una máscara con los píxeles empleados para calcular la referencia del blanco. Esta función es útil para adquirir un control más estrecho sobre el proceso.

El algoritmo para selección de estructuras empleado para aislar las estrellas como referencias del blanco (o, más propiamente, estructuras de pequeña escala) es una adaptación del algoritmo de detección de estrellas que diseñé e implementé en la herramienta StarAlignment. Realmente funciona muy bien, como podéis comprobar.

ColorCalibration también puede trabajar con una vista como la imagen de referencia del blanco. Esto es particularmente útil para calibrar una imagen utilizando una galaxia cercana. La luz integrada de una galaxia cercana es una referencia de blanco plausible, puesto que contiene grandes muestras de todas las poblaciones estelares y su corrimiento hacia el rojo es despreciable. Este método ha sido propuesto por el miembro del PTeam Vicent Peris, quien lo ha implementado para calibrar varias imágenes adquiridas con grandes telescopios. Según Vicent, las galaxias ideales para calibración deben tener las siguientes propiedades:

- Más cercanas que 50 mpc

- Clasificación de Hubble Sa, Sb, Sc, Scd, SBa, SBb, SBc o SBcd

- Inclinación menor que 60 grados

- Enrojecimiento intrínseco intergaláctico y galáctico integrado menor que 0.5 magnitudes en Johnson B

Aquí hay un ejemplo con la imagen de NGC7331 de Vicent, tomada con el telescopio de 3.5 metros de Calar Alto:

Imagen compuesta RGB antes de la calibración:
http://forum-images.pixinsight.com/legacy/1.5-preview/ColorCalibration-3.jpg

Tras BackgroundNeutralization:
http://forum-images.pixinsight.com/legacy/1.5-preview/ColorCalibration-4.jpg

Tras ColorCalibration:
http://forum-images.pixinsight.com/legacy/1.5-preview/ColorCalibration-5.jpg

Nueva Herramienta: ImageIntegration

La versión 1.5 viene con una primera versión de la herramienta ImageIntegration. Esta herramienta lleva a cabo la combinación de un número ilimitado de archivos FITS en una única imagen integrada (stacked). ImageIntegration es una herramienta de altas prestaciones con las siguientes características principales:

- Operaciones de combinación de imágenes: media, mediana, mínimo y máximo.

- Algoritmos de rechazo de píxeles: k-Sigma clipping, percentile clipping, min/max, CCD-clip y average sigma clipping.

- Escalado y normalización automática de imágenes, definibles separadamente para la combinación de imágenes y el rechazo de píxeles.

- Generación de mapas de rechazo de píxeles.

- Salida por consola de estadísticas exhaustivas de rechazo de píxeles.

- Generación opcional de una imagen integrada de 64 bits.

Aquí tenéis una ejemplo con 20 imágenes raw de la región de M81/M82 por Oriol Lehmkuhl e Ivette Rodríguez:

http://forum-images.pixinsight.com/legacy/1.5-preview/ImageIntegration.jpg

Herramienta Mejorada: ATrousWaveletTransform

ATrousWaveletTransform (ATW para abreviar) ha sido completamente rediseñada y reimplementada partiendo de cero. Esta herramienta no había sido revisada seriamente desde su implementación incial en PixInsight LE. ATW es ahora una herramienta representativa del estado del arte en procesamiento por wavelets, como todos los usuarios de PixInsight merecen.

Todo ha cambiado dentro de ATW, aunque la mayor parte de los cambios no son visibles directamente por el usuario. Uno de los cambios más importantes el el nuevo algoritmo de deringing, que ha sido diseñado por Vicent Peris, nuestro gurú de wavelets residente :)

El nuevo deringing de ATW funciona, funciona siempre, y funciona extremadamente bien. Aquí tenemos un ejemplo:

La imagen original:
http://forum-images.pixinsight.com/legacy/1.5-preview/ATW-deringing-1.jpg

Un bias relativamente fuerte aplicado a la segunda capa de wavelets, sin deringing:
http://forum-images.pixinsight.com/legacy/1.5-preview/ATW-deringing-2.jpg

Mismo bias, con deringing:
http://forum-images.pixinsight.com/legacy/1.5-preview/ATW-deringing-3.jpg

Notad que no hay artefactos oscuros de ringing en absoluto. Se puede obtener resultados similares de forma consistente para todas las imágenes lineales y no lineales. En este ejemplo, hemos aplicado deringing a los anillos oscuros exclusivamente (artefactos oscuros de Gibbs). El ringing se puede controlar también para artefactos brillantes:

Imagen original de Lena:
http://forum-images.pixinsight.com/legacy/1.5-preview/ATW-deringing-4.jpg

Fuerte bias aplicado a la segunda capa de wavelets, sin deringing:
http://forum-images.pixinsight.com/legacy/1.5-preview/ATW-deringing-6.jpg

Hay artefactos brillantes en los bordes de todas las transiciones brillante-oscuro de discontinuidad. Por ejemplo, el artefacto brillante de ringing en el hombro de Lena es muy evidente. Estos artefactos virtualmente desaparecen con el nuevo algoritmo de deringing, como se puede ver a continuación.

Mismo bias, deringing aplicado a artefactos oscuros y brillantes:
http://forum-images.pixinsight.com/legacy/1.5-preview/ATW-deringing-5.jpg

Otra mejora importante en ATW es el nuevo algoritmo de reducción de ruido basado en wavelets. Esto es un ejemplo con una imagen CCD del trío de leo obtenida por los miembros del PTeam Oriol Lehmkuhl e Ivette Rodríguez:

Imagen raw compuesta RGB, antes de la reducción de ruido:
http://forum-images.pixinsight.com/legacy/1.5-preview/ATW-noise-reduction-1.jpg

Tras reducción de ruido multiescala con ATW:
http://forum-images.pixinsight.com/legacy/1.5-preview/ATW-noise-reduction-2.jpg

Tened en cuenta que la reducción de ruido anterior se ha aplicado sin máscara de protección alguna. Prestad atención a la conservación de los colores estelares y de los sutiles detalles en el interior de la galaxia principal. Notad también que esta reducción de ruido se puede aplicar a imágenes lineales, como en el ejemplo anterior. Se trata de un algoritmo de reducción de ruido extremadamente potente.

Mejora en la Interfaz Gráfica: Script Editor Mejorado

El editor de scripts incluye ahora una bonita función de numeración automática de líneas, marcadores de texto y emparejamiento de paréntesis:

http://forum-images.pixinsight.com/legacy/1.5-preview/ScriptEditor.jpg

Mejora en la Interfaz Gráfica: Ventanas de Exploración Rediseñadas

El panel derecho de la ventana Process Explorer ha sido rediseñado para proporcionar información exhaustiva sobre las capacidades y los parámetros de cada proceso. Esta información está orientada a facilitar el trabajo de desarrolladores en el entorno PixInsight/PCL:

http://forum-images.pixinsight.com/legacy/1.5-preview/ProcessExplorer.jpg

Las ventanas Format Explorer y View Explorer han visto evoluciones similares:

http://forum-images.pixinsight.com/legacy/1.5-preview/FormatExplorer.jpg
http://forum-images.pixinsight.com/legacy/1.5-preview/ViewExplorer.jpg

Por cierto, las copias de pantalla anteriores también muestran los nuevos formatos de archivo soportados en PI 1.5: GIF (Graphics Interchange Format), ICO (Windows Icon Format) y MNG (Multiple Network Graphics). Notad que las animaciones GIF y MNG no están soportadas, y que la implementación de los formatos GIF y MNG proporcionan únicamente soporte de sólo lectura.

Nueva versión de 64 bits para Mac OS X

PixInsight 1.5 estará disponible como una aplicación de 64 bits para Mac OS X 10.5 y posterior. ¡Rompemos todas las barreras de memoria en el Mac!

Por supuesto, las versiones de 32 y 64 bits seguirán estando disponibles para Linux, Windows y Mac OS X.

Compatibilidad Mejorada con Distribuciones de Linux

No más problemas en todas las (modernas) distribuciones de Linux. PixInsight 1.5 funciona directamente en on las últimas versiones de Red Hat, Fedora, Debian, Ubuntu, SUSE y Mandriva.
Title: Re: PixInsight 1.5: Prerelease Information
Post by: Thorsten Lockert on 2009 April 17 01:46:42
Can I just say ... wow! This is so cool!

Quote from: "Juan Conejero"
New Tool: ImageIntegration

Version 1.5 comes with a first version of the ImageIntegration tool.

Any plans to integrate the HDRComposition script with this at some point?

Thorsten
Title: PixInsight 1.5: Prerelease Information
Post by: caliu on 2009 April 17 04:10:03
¿Lo podéis explicar en español por favor?
Title: PixInsight 1.5: Prerelease Information
Post by: Pep on 2009 April 17 04:28:34
Pues sí Caliu, se podría poner en español, no sería mala idea.
Title: PixInsight 1.5: Prerelease Information
Post by: Pep on 2009 April 17 04:34:00
Como sugerencia por ejemplo para ATW, cuando tenemos que aplicar los mismos parametros a varias capas, se podría seelcionar de una sola vez las que queramos y aplicar el valor a todas, ya que es tedioso el tener que ir capa a capa introduciendo los mismos valores.
Title: PixInsight 1.5: Prerelease Information
Post by: catalinfus on 2009 April 17 05:21:58
Hi Juan,

I think most of us who use on a regular basis the PI program , will be delighted by the new options and algorithm improvements. Way to go guys!! Congratulations!
The color correction and background calibration tools were needed badly :-). Nice touch with those !!

Now, I will like to know if the ImageIntegration tools will take into account darks/bias/flats or it's just a stacking tool without prior calibration of the image ?
I just hope one day that PI will be a full processing astro software :-))

And second of all...I think plenty of astroimagers are using modded DSLR like Canon/Nikon and find color correction a PIA (at least I'm hoping I'm not the only one who stumbles on that regularly :-)))   )...PixInsight's color correction tool is intended to be used for that with success also?
I find it the missing step between DBE and histogram adjustment after PixelMath was used to subtract background!

BR
Cata
Title: Very impressive!
Post by: Philip de Louraille on 2009 April 17 05:23:38
Can't wait to test many of these new functions.
I was just going to suggest a method to discover and map hot pixels so they can be eliminated (those pesky ones that do not appear when making dark frames but appear on light frames) and the ImageIntegration tool might just do this for me.

Looks very good!
Great work!
Title: PixInsight 1.5: Prerelease Information
Post by: bitli on 2009 April 17 05:51:53
Fantastic. I can't way. Well, in fact I can wait, please take your time to make it solid.

The only annoyance I see is the disappearance of the informal textual information for the processes. In the absence of a comprehensive documentation, it was sometime the only conveniently reachable information, even if lacking in some cases.

Is there another  way to access this information? May there could be a configurable target for a help function (configurable base url with the help target as a parameter), so this could point to a wiki or some other source of text, if somebody feels like creating/maintaining one. Or to some local files if somebody takes local notes.

I understand your are very busy with the development, and video tutorials are greats, but I sometime need a reminder on the general goal and way of working of a function, not just the details of the parameters. Having a configurable target for help could allow other people to contribute to this effort, hopefully without too much coding effort.

Just an idea,
Hope skies are cloudy, so you can work on PI :-)

bitli
Title: PixInsight 1.5: Prerelease Information
Post by: Simon Hicks on 2009 April 17 08:12:02
Now I am really annoyed!  :evil:

These tools answer so many of my processing problems that I will now have to go back and reprocess 2 years worth of images from scratch!!!  :D

The improved DBE, BackgroundNeutralization and the ColourCorrection tools combined with the preview aggregator are things that will make life soooo much better! I can't wait to try them out.  PI just gets better and better.

Thank you Juan and the other PI guys.....keep up the good work.
Title: Re: PixInsight 1.5: Prerelease Information
Post by: David Serrano on 2009 April 17 08:14:46
Quote from: "Juan Conejero"
So the histogram and statistical data being shown are being calculated in real-time for the current Real-Time Preview image.


Great!! In fact, I've missed something like this a couple of times.


Quote from: "Juan Conejero"
BackgroundNeutralization requires a good background reference. A good background reference includes mainly data that actually represents the sky background in the image. In this case, the image has few free sky background regions. Note that we have used the excellent PreviewAggregator script by David Serrano to gather five background areas into a single image, which we have selected to sample the background in the image.


Glad to see the script is useful 8). But I have one question: I bet that aggregated image is pure black in at least half its area. Doesn't that alter the BackgroundNeutralization's work?


Quote from: "catalinfus"
Now, I will like to know if the ImageIntegration tools will take into account darks/bias/flats or it's just a stacking tool without prior calibration of the image ?


I think it's just a plain stacking tool. I have a couple of ideas towards darks/bias/flats/darkflats calibration via JS scripting, and this new tool brings them closer to the outside world. I'll wait for 1.5 to be released and will explore some other features, namely the possibility to access the desktop background and icons, that Juan anticipated here (http://pixinsight.com/forum/viewtopic.php?p=4976#4976).
Title: PixInsight 1.5: Prerelease Information
Post by: Astrocava on 2009 April 17 09:05:15
:shock:

Quote from: "simonhicks"
Now I am really annoyed!  :evil:

These tools answer so many of my processing problems that I will now have to go back and reprocess 2 years worth of images from scratch!!!  :D



Same here!  :evil:

Nice work!  Can't wait to have it.

Sergio
Title: Re: PixInsight 1.5: Prerelease Information
Post by: Juan Conejero on 2009 April 17 10:42:10
Hi Thorsten,

Quote
Quote
Version 1.5 comes with a first version of the ImageIntegration tool.

Any plans to integrate the HDRComposition script with this at some point?


HDRComposition is now being implemented as an independent PixInsight module written in C++. It won't be included with 1.5 though, but as soon as it becomes available, we'll distribute an update to all users.
Title: PixInsight 1.5: Prerelease Information
Post by: Juan Conejero on 2009 April 17 11:03:04
Hi Catalin,

Thanks! :)

Quote
I will like to know if the ImageIntegration tools will take into account darks/bias/flats or it's just a stacking tool without prior calibration of the image ?


ImageIntegration is just what its name says: an image combination (AKA stacking) tool. Our philosophy is usually to provide each processing technique or process as an independent tool. This is for the sake of modularity, which is one of PixInsight's fundamental design principles. There are tools that collate diverse and complex tasks, but they are always in direct connection with a main subject (example: ATrousWaveletTransform).

Image calibration deserves the design and implementation of a specific tool, or better a category with a comprehensive tool set. This is not an easy task, as most people thinks. Calibration involves some difficult problems and is critical to the quality of images. We won't publish a calibration tool until we are sure to offer a minimally significant contribution to existing software. This is our way of doing things.

Quote
I just hope one day that PI will be a full processing astro software :-))


Me too, indeed :) We now have image registration and integration. Only image calibration is between the current state and a reasonably complete solution for astrophotography.

We lack image analysis tools, and a good set of photometric and astrometric analysis tools. The road is long and there are few fuel stations, but our truck is big and we go for the fun ;)

Quote
I think plenty of astroimagers are using modded DSLR like Canon/Nikon and find color correction a PIA (at least I'm hoping I'm not the only one who stumbles on that regularly :-)))   )...PixInsight's color correction tool is intended to be used for that with success also?


Definitely yes! Of course fixing those red-casted beasts isn't the easiest task, but I don't see why the BackgroundNeutralization/ColorCalibration combo can't do an excellent job, if things are done carefully and accurately.
Title: Re: Very impressive!
Post by: Juan Conejero on 2009 April 17 11:21:07
Hi Philip,

Thank you!

Quote
I was just going to suggest a method to discover and map hot pixels so they can be eliminated (those pesky ones that do not appear when making dark frames but appear on light frames) and the ImageIntegration tool might just do this for me.


Yes, if you have a good set of light frames, I think sigma-clipping or percentile clipping rejection (the latter is wonderful when you only have a few images) can remove those annoying hot pixels very well. As we have implemented generation of rejection maps, you can obtain a hot pixel map very easily. I'll love to see how this works with your images, when we release 1.5.
Title: PixInsight 1.5: Prerelease Information
Post by: Foton on 2009 April 17 11:39:23
Impresive. I think we can wait until end of April, even later, to get the new version.

An script to avoid stacking externally to PI should be quite simple using scripts features and the new ImageIntegration function. For sure somebody is going to be working on that.

Thanks Juan !. JLuis.
Title: PixInsight 1.5: Prerelease Information
Post by: Juan Conejero on 2009 April 17 11:53:12
Hi Bitli,

Quote
Fantastic. I can't way. Well, in fact I can wait, please take your time to make it solid.


Thanks! Be sure it will be rock-solid ;)

Quote
The only annoyance I see is the disappearance of the informal textual information for the processes. In the absence of a comprehensive documentation, it was sometime the only conveniently reachable information, even if lacking in some cases.


It hasn't disappeared at all, actually :) Oops! I just forgot to include a screenshot showing how to access process descriptions. Here's is one:

http://forum-images.pixinsight.com/legacy/1.5-preview/ProcessDescription-1.jpg

Processes that provide non-empty descriptions generate a special description tag link on Process Explorer. When you double-click the link, a window pops up showing the information text, as before. The only thing that has changed is the way to access the information, but it's still there :) If I only had time enough as to sit and write good descriptions for all processes...

Note also that all new tools, and many old ones, have now a lot of tool-tip information text that should help to understand most process parameters.

Quote
Having a configurable target for help could allow other people to contribute to this effort, hopefully without too much coding effort.


Of course this is an excellent idea. I am open to know how I can facilitate that kind of contributions (a wiki would be really great IMO), which are extremely welcome :) I'll think on a way to implement what you suggest.

By the way, I forgot to say you thanks for your list of keyboard shortcuts. I should have published it (:oops:) but you anticipated. Well done and thanks! ;)

Quote
Hope skies are cloudy, so you can work on PI :-)


Oh, actually, you don't have to worry about that: I work on PI even during the clearest new moon nights, I must confess... It's years now since my last imaging night. But I'm very very happy each time I see your beautiful images ;)
Title: PixInsight 1.5: Prerelease Information
Post by: vicent_peris on 2009 April 17 11:54:28
Quote from: "catalinfus"
And second of all...I think plenty of astroimagers are using modded DSLR like Canon/Nikon and find color correction a PIA (at least I'm hoping I'm not the only one who stumbles on that regularly :-)))   )...PixInsight's color correction tool is intended to be used for that with success also?


Hello,

yes, without doubt ColorCalibration will do the same work as in the NGC7331 image for DSLR images. In fact, for the same object, there is no reason for thinking that a CCD image will be better calibrated than a DSLR one. I will upload some example with one of my DSLR images...


Regards,
Vicent.
Title: Re: PixInsight 1.5: Prerelease Information
Post by: Juan Conejero on 2009 April 17 11:57:56
Hey David,

Quote
Glad to see the script is useful 8). But I have one question: I bet that aggregated image is pure black in at least half its area. Doesn't that alter the BackgroundNeutralization's work?


It is indeed *very* useful as a gatherer of subimages :)

Black pixels are automatically rejected (ignored, actually) by both BackgroundNeutralization and ColorCalibration, so there's no problem at all with them ;)

Quote
I'll wait for 1.5 to be released and will explore some other features, namely the possibility to access the desktop background and icons, that Juan anticipated


Keep your fingers warm, you'll have these things ready for testing in a few days ;)
Title: PixInsight 1.5: Prerelease Information
Post by: Harry page on 2009 April 17 13:47:14
Hi Juan

Good to see some much needed tools and look forward to being able to use it!


When you have finished ver 1.5   I am sure we can come up with a list for 1.6


Regards Harry
Title: PixInsight 1.5: Prerelease Information
Post by: ManoloL on 2009 April 17 17:27:49
Quote from: "vicent_peris"


yes, without doubt ColorCalibration will do the same work as in the NGC7331 image for DSLR images. In fact, for the same object, there is no reason for thinking that a CCD image will be better calibrated than a DSLR one. I will upload some example with one of my DSLR images...


Regards,
Vicent.


Hola Vicent:

¿Será un problema el hecho que relato en
  http://pixinsight.com/forum/viewtopic.php?t=1085
En esencia las imágenes apiladas con DSS pueden tener los máximos en los alrededores de 0.996, cada canal con valores ligeramente distintos, y no en 1.00000.

Saludos.
Title: PixInsight 1.5: Prerelease Information
Post by: Juan Conejero on 2009 April 17 19:57:02
Hola Manolo

Quote
¿Será un problema el hecho que relato en http://pixinsight.com/forum/viewtopic.php?t=1085


En absoluto (y por cierto, perdón por habérseme pasado ese mensaje tuyo).

El hecho de que DSS produzca valores máximos diferentes de la unidad es irrelevante aquí. De hecho, es más bien un buen síntoma, que indica que ningún píxel está saturado en tu imagen. El hecho de que tus imágenes raw sí estuvieran cortadas en 1 inicialmente no es tampoco algo sorprendente. Piensa que al haber promediado un conjunto de n imágenes cada píxel es el promedio de n píxeles originales, con lo cual un píxel final sólo puede valer 1 si da la casualidad de que todos los píxeles originales valen 1 en las mismas coordenadas, lo cual es improbable.

Los valores máximos o la relación entre ellos no van a afectar a los algoritmos utilizados en ColorCalibration. Estos algoritmos son extremadamente robustos, y realizan el muestreo de los datos independientemente para cada canal de color.

Ahora bien, lo que no es recomendable es utilizar ninguna de las opciones de "calibración" o "ecualización" de los valores del fondo disponibles en DSS, si después vas a utilizar nuestro BackgroundNeutralization. Hay dos razones principales. Una es que al hacer esto estamos duplicando tareas, lo cual sólo puede conducir a degradar los datos. Otra es que en DSS estas operaciones aplican transformaciones no lineales, si no estoy equivocado. En PixInsight, tanto BackgroundNeutralization como ColorCalibration aplican estrictamente transformaciones lineales.
Title: PixInsight 1.5: Prerelease Information
Post by: catalinfus on 2009 April 17 19:57:37
Hi Juan and Vicent,

hehehehe...I just realized now that I read a little in diagonal the mail in the morning :-)
Indeed the problem that you solve now in 2 steps using Background Neutralization + Color Correction...was the hardest to fix in case of modded DSLR. The NGC 7331 example is REALLY what I needed ...
The problem that I faced is when I have done DBE without equalizing color channels  and the background got very well color corrected but the nebulas/globular/galaxy that are out of backgr corrected area, remained with a red color shift...
I just can't wait to have 1.5 and reprocess all my images :-)!

All my best!!!

P.S. I'm still waiting for the sun.... :-))))))[/quote]
Title: PixInsight 1.5: Prerelease Information
Post by: ManoloL on 2009 April 18 07:23:13
Hola de nuevo Juan:

¿Y no nos puedes adelantar algún módulo tal como los de BackgroundNeutralization y ColorCalibration, para entretenernos en estos días lluviosos y dar un repaso a nuestras imágenes aparcadas a la espera de estas utilidades?
Tengo la sospecha de que si no lo has hecho es que no funcionan con la V1.4

Saludos.
Title: PixInsight 1.5: Prerelease Information
Post by: ManoloL on 2009 April 18 08:48:00
Quote from: "Juan Conejero"


Ahora bien, lo que no es recomendable es utilizar ninguna de las opciones de "calibración" o "ecualización" de los valores del fondo disponibles en DSS, si después vas a utilizar nuestro BackgroundNeutralization. Hay dos razones principales. Una es que al hacer esto estamos duplicando tareas, lo cual sólo puede conducir a degradar los datos. Otra es que en DSS estas operaciones aplican transformaciones no lineales, si no estoy equivocado. En PixInsight, tanto BackgroundNeutralization como ColorCalibration aplican estrictamente transformaciones lineales.


Hola de nuevo Juan:
Yo que por ahora vengo calibrando, registrando y apilando con DSS tengo eso claro en lo que se refiere al ajuste de canales RGB, pero como suelo apilar con Sigma-Clipping (casi es un milagro que no se me meta algún avión en todos los encuadres) me han aconsejado que utilice la Calibración de Fondo Por Canal.

La documentación del programa (DSS) dice:

-Con la opción de Calibración de Fondo Por Canal el fondo de cada canal es ajustado en forma separada para coincidir con el fondo de la imagen de referencia.

-Con la Calibración de Canales RGB los tres canales rojo, verde y azul de cada archivo light son normalizados al mismo valor de fondo que corresponde al mínimo de los tres valores medios (uno por cada canal) calculado a partir de la imagen de referencia.
Además de crear imágenes compatibles (amigables con el apilado) esta opción tambien crea un fondo gris neutral. El efecto secundario es que la saturación general de la imagen apilada es relativamente bajo (estilo escala de gris).

Es importante seleccionar una de estas opciones cuando se utilizan los métodos Kappa-Sigma Clipping o el Kappa-Sigma Clipping Median para asegurarse que las imágenes a ser apiladas tienen todas el mismo valor de fondo.

Yo descarté la Calibración de Canales RGB, pues estaba claro que sus efectos deterioraban las posibilidades de ajustar posteriormente los colores con Pixi.  Pero a la vista de tu respuesta me asalta la duda de si también la opción que uso afecta al posterior tratamiento de la imagen con PixInsight.
De ser esto así, la única salida que tengo para seguir usando DSS para calibrar, dado que es un programa de todo o nada, que no permite obtener solo las imágenes calibradas, seria realizar el apilado guardando las imágenes intermedias registradas. Luego prescindiría de la imagen apilada y podría utilizar las intermedias, en formato FIT, para apilarlas con la nueva herramienta ImageIntegration.
Title: PixInsight 1.5: Prerelease Information
Post by: Juan Conejero on 2009 April 18 10:16:08
[Summary in English below]

Hola Manolo

Aquí hay varias cosas distintas. Yo me refería al ajuste de canales RGB para conseguir un fondo neutro.

Otra cosa muy distinta es la normalización de las imágenes durante la integración. Esto último no es que sea recomendable, es que es absolutamente imprescindible. Lo que en nuestro ImageIntegration se llama normalization (normalización), en DSS se llama calibración de fondo. Bueno, no es exactamente lo mismo porque nosotros hacemos más cosas aparte de compatibilizar los fondos de las imágenes, pero en cuanto a la función que se desempeña se trata del mismo concepto.

Copio la información pertinente desde la documentación de DSS en Inglés (en la traducción al Español he visto algunas inexactitudes importantes):

Quote
Background Calibration

The Background Calibration consists in normalizing the background value of each picture before stacking it.

The background value is defined as the median value of all the pixels of the picture.

Two options are available.

* With the Per Channel Background Calibration option the background for each channel is adjusted separately to match the background of the reference frame.
   
* With the RGB Channels Calibration the three red, green and blue channels of each light frame are normalized to the same background value which is the minimum of the three medians values (one for each channel) computed from the reference frame. On top on creating compatible images (stacking wise) this option is also creating a neutral gray background. A side effect is that the overall saturation of the stacked image is quite low (grayscale look).

It is important to check one of these options when using Kappa-Sigma Clipping or Kappa-Sigma Clipping Median methods to ensure that the pictures being stacked have all the same background value.


El último párrafo es crucial. Al realizar la integración (apilado) de un conjunto de imágenes utilizando un algoritmo de rechazo de píxeles como sigma clipping, lo que pretendemos es excluir (rechazar) los valores de píxel que son identificados como outliers (perdón, no recuerdo cómo se dice técnicamente esto en Español ahora), es decir, valores que no son (estadísticamente) representativos del verdadero valor de un píxel en la imagen. Ejemplos típicos son una traza de avión o satélite, o un rayo cósmico.

Pero para que el algoritmo de rechazo de píxeles funcione correctamente, es necesario que todas las imágenes tengan valores compatibles entre sí. En el caso de sigma clipping, lo que queremos es que la curva del histograma que formamos con una pila de píxeles a partir del conjunto de imágenes que estamos integrando presente un único pico (o sea, que sea unimodal) y tenga la mínima dispersión de valores posible. Menos gráficamente, se pretende minimizar la distancia media entre todos los valores de píxel en las mismas coordenadas. De lo contrario, la desviación estándar deja de ser una estimación representativa de la dispersión real, la mediana deja de ser una buena estimación del valor central, y sigma clipping funciona mucho peor que un simple promedio de las imágenes sin rechazo. La normalización (o calibración del fondo en DSS) sirve precisamente para conseguir compatibilizar las imágenes en este sentido.

Cuestión distinta es cómo se realiza la normalización. Nosotros aplicamos transformaciones estrictamente lineales, que es como se tiene que hacer este trabajo, en nuestra opinión. La normalización que se aplica para el rechazo de píxeles no tiene por qué aplicarse necesariamente después durante la integración (por ejemplo, para calcular la media de los píxeles que sobreviven al rechazo); al menos en nuestro caso esto es opcional. Cuando publiquemos la 1.5 haremos nuevos videotutoriales en los que explicaremos cómo funciona ImageIntegration y cómo hay que realizar la normalización.

Con respecto a DSS, mi recomendación en principio es que selecciones la primera opción, es decir "Per Channel Background Calibration", y que realices la neutralización del fondo después en PI con BackgroundNeutralization (cuando 1.5 esté publicada, claro :) ).

=========================================================

Summary in English -- Manolo asked about background calibration procedures applied in DeepSkyStacker, and their repercussion for subsequent processing in PixInsight, specifically with the new BackgroundNeutralization and ColorCalibration tools available in the upcoming 1.5 version. My recommendation is to apply the "Per Channel Background Calibration" option when integrating images with sigma clipping rejection. Instead of using the "RGB Channels Calibration" option, my advice is to use the new BackgroundNeutralization tool available in PI 1.5.

When we integrate (stack) a set of images using a pixel rejection algorithm, such as sigma clipping for example, we pursue to exclude (reject) those pixel values that are identified as outliers, or values that are not (statistically) representative of the true value of a given pixel in the image. Typical examples are planes, satellites and cosmic rays.

But, for a pixel rejection algorithm to work correctly, all images being integrated must have compatible pixel values. In the case of sigma clipping for example, we want the histogram curve formed with a stack of pixels from the set of integrated images to show a unique peak (unimodal distribution) with the minimum possible dispersion. Less graphically, we want to minimize the mean distance between all pixel values at the same image coordinates. If this condition is not met, the standard deviation can't be a good estimate of the actual dispersion of values, the median can't be a good estimate of the actual central value, and then sigma clipping works much worse than a simple average of images without rejection. Normalization (or background calibration in DSS) is intended precisely to achieve compatibility between images, in the sense that we have just explained.
Title: PixInsight 1.5: Prerelease Information
Post by: twade on 2009 April 18 22:44:27
Juan,

These will all be fantastic additions to an already awesome program.  I especially look forward to using the BackgroundNeutralization and ColorCalibration tools.  As someone who is slightly red/green colored blind, I'll put it to good use. :D

I also look forward to using ImageIntegration.  I've always had a question about the best way to combine all the images once their outlying pixels have been rejected.  It appears we have several choices as mentioned in the quote below:

 
Quote
Mean, median, minimum and maximum image combination operations.


When working with light frames, which method is best?  I would think one would want to use all available frames.  This would obviously rule out median, minimum, and maximum since a single pixel would be chosen from the appropriate frame to generate the new image.  As a result, mean would likely be a better candidate for light frames, right?  Not being a mathematical genius, I'm not sure if mean truly takes advantage of all the frames either.  Perhaps, you could enlighten me?  What little knowledge I possess in the world of image integration, I would think the best solution is in the form of a sum.  Are there any plans to have a Sum as a choice in PixInsight?  I would think this would be the best way to ensure you are taking advantage of all the available data; however, it does have the disadvantage of increasing noise, especially in the background.  Does anybody else have any opinion on the best way to combine light frames?  I just don't want to be using a method that doesn't take advantage of my hard earned data.

Thanks,

Wade
Title: PixInsight 1.5: Prerelease Information
Post by: Juan Conejero on 2009 April 19 01:20:24
Hi Wade,

Thank you!

Quote
Does anybody else have any opinion on the best way to combine light frames? I just don't want to be using a method that doesn't take advantage of my hard earned data.


Mean combination (averaging pixels) provides the highest SNR improvement. The median, minimum and maximum operations can be used in special cases, but as a general rule, always use mean combination to integrate light frames.

Quote
Are there any plans to have a Sum as a choice in PixInsight?


A straight sum of pixels has two problems:

- The sum can easily yield values outside the available numeric range. When that happens, we have to choose between (1) truncate out-of-range values, which means a loss of data, or (2) rescale the resulting image, which means a loss of dynamic range. Both options are very ugly.

- Even if the result doesn't overflow, by summing pixels we are not improving the SNR significantly, since both the signal and the noise are accumulated in the same way.

Mean combination improves the SNR because the noise, having a random distribution, tends to cancel out since its mean is equal for all pixels, while the signal tends to stay invariant as it is the same in all images.
Title: PixInsight 1.5: Prerelease Information
Post by: twade on 2009 April 19 01:31:16
Juan,

Thanks for the excellent explanation.

I do have one more question.  When using mean, how does the "target build up" as you combine more images.  For example, do you generally build up the same amount of signal taking twenty 5-minute exposures as you do taking ten 10-minute exposures?  If this is true, I'm having a hard time visualizing how this can be since all twenty 5-minute individual exposures will have 1/2 the signal as each of the 10-minute exposures.  I just don't see how you can build up to the 10-minute exposure signal by using a mean value.  It seems to me, the 10-min exposures will capture more photons in the extremely faint regions of the target; whereas, the 5-min exposures may never capture such a photon at all.  Is this logic incorrect?  Have I missed something?

Thanks,

Wade
Title: Sum vs Mean
Post by: Jack Harvey on 2009 April 19 17:56:13
Although we always use mean, one of the SSRO members continues the discussion:

Quote
  ah...now i see the pixi point -- yes, mean combine DOES do what they say, but they don't talk about any actions AFTER the mean combine...if you stretch AFTER MEAN combining, you wind up with the same data as if you summed


Some comments?
Title: PixInsight 1.5: Prerelease Information
Post by: Nocturnal on 2009 April 19 18:05:34
If you do a linear stretch then you could end up with the same data, yes. Given that we work with 32 bit floats between 0 and 1 it makes little sense to do linear stretches.
Title: PixInsight 1.5: Prerelease Information
Post by: Jack Harvey on 2009 April 19 18:10:47
Agree
Title: PixInsight 1.5: Prerelease Information
Post by: Nocturnal on 2009 April 19 18:12:43
I should add that as long as you're not loosing any data summing reduces noise just as much as averaging. After all averaging is nothing more than summing and then dividing by the number of elements. The division does not change noise it merely re-scales the numbers back to the range of numbers we started with. Since PI works with a range of 0-1 anyway the whole difference between summing and averaging blurs. Both would result in the same data once rescaled to 0-1.
Title: PixInsight 1.5: Prerelease Information
Post by: georg.viehoever on 2009 April 19 22:11:25
Hello,

I think some prefer to use median instead on mean because the median is robust against temporary artifact such as planes, flares, insects, ... . Is that correct?

Georg
Title: PixInsight 1.5: Prerelease Information
Post by: vicent_peris on 2009 April 19 22:21:05
Quote from: "georg.viehoever"
Hello,

I think some prefer to use median instead on mean because the median is robust against temporary artifact such as planes, flares, insects, ... . Is that correct?

Georg



Yes, but you lose a lot of signal to noise ratio. I think is better to use a rejection algorithm combined with an average.


Vicent.
Title: PixInsight 1.5: Prerelease Information
Post by: Nocturnal on 2009 April 19 22:26:02
More sophisticated algorithms look at the stddev for the pixel and then decide on how to average them. If the stddev is low mean/average can be used. If it's high it uses median. Some folks do dithering and median combine to get rid of hot/cold pixels. I think it's better to get rid of them with a hot pixel map and then combining the resulting clean frames with mean or sigma/kappa.
Title: PixInsight 1.5: Prerelease Information
Post by: Juan Conejero on 2009 April 19 23:12:46
The key word here is rescaling. Of course, what you say is true: if you add a set of images and then rescale the sum to fit all the data to the available range ([0,1] in the case of PI), then the result is the same (ignoring changes in the redistribution of the data throughout the available dynamic range) as if you divide the sum by the number of images.

Consider a simplified version of the image formation equation:

I = S + N

where I is the image, S represents the (degraded) signal and N is the additive noise term. Assuming that all images in a set are of the same subject, follow the same response curve (for example, all of them are linear), are properly registered, and have the same exposure, we agree that S is approximately constant for all images (actually it isn't constant due to the fact that S is a degraded version of the input image, formed by the convolution of the input image with a point spread function due to atmospheric turbulence, instrumental limitations, etc.). We know also that N, the noise, follows a random distribution and is uncorrelated. So for a set of n images we can write, ignoring signal degradation:

I1 = S + N1
I2 = S + N2
I3 = S + N3
.
.
.
In = S + Nn

Then the mean combination M of this set of n images is:

M = n*S/n +  (N1+N2+N3+...+Nn)/n = S + (N1+N2+N3+...+Nn)/n

The formula above tells that the signal remains invariant, irrespective of the number of images. The noise has a random distribution in each image, so its mean across a set of images tends to cancel out. By averaging a set of n images, the signal-to-noise ratio improves with the square root of n. So by averaging two images we get a SNR improvement of sqrt(2) = 1.41, by averaging four images, the SNR improves by a factor of two, and so on.

With PixInsight, it is very easy to design an experiment that demonstrates noise reduction by averaging (or, equivalently, adding/rescaling) a set of images, using the PixelMath and NoiseGenerator tools.

Here is an example. This is the standard Lena image in 32-bit floating point format:

http://forum-images.pixinsight.com/legacy/noise/01.jpg

Let's duplicate it seven times (to get eight identical images), rename them as A, B, ..., H, and add the same amount of Gaussian noise to all images. In this example I have used the NoiseGenerator tool with the help of ImageContainer:

http://forum-images.pixinsight.com/legacy/noise/02.jpg

Here is the result for one of the eight images:

http://forum-images.pixinsight.com/legacy/noise/03.jpg

Now, instead of calculating the mean of the eight images, we'll just add them. To prevent overflow in the summed result, we can divide each image by eight with PixelMath:

http://forum-images.pixinsight.com/legacy/noise/04.jpg

and here is the result:

http://forum-images.pixinsight.com/legacy/noise/05.jpg

Now let's perform the straight addition of the eight images:

http://forum-images.pixinsight.com/legacy/noise/06.jpg

This is a side-to-side comparison of one of the noisy images (before division) and the summed image:

http://forum-images.pixinsight.com/legacy/noise/07.jpg

Of course, the result would be exactly the same if instead of dividing each image by 8 and adding the eight images, we calculated the arithmetic mean directly, with this PixelMath expression:

(A+B+C+D+E+F+G+H)/8

and rescaling disabled. Or, alternatively, we could just add the eight images (without dividing them) and enable rescaling in PixelMath. The result of the three operations is the same:

- Divide by 8 each image and add the 8 images.
- Add the 8 images and divide the sum by 8.
- Add the 8 images and rescale.

The qualitative comparison above tells us that the SNR improvement is quite high. Now let's evaluate the result quantitatively. The following script implements an iterative noise estimation algorithm due to Jean-Luc Starck:

Code: [Select]
/**
 * Evaluation of Gaussian noise by the iterative k-sigma thresholding method.
 *
 * Reference:
 *    J.L. Starck, F. Murtagh, Astronomical Image and Data Analysis, Springer,
 *    1st ed., 2002, pp. 37-38.
 */

// Working array to gather noise at each iteration.
var N = new Array;

/**
 * Image callback routine to extract noise wavelet coefficients.
 *
 * s     is the value of the current sample, which is actually a wavelet
 *       coefficient in the first wavelet layer
 *
 * ks    k*sigma threshold, with k=3 and sigma is the standard deviation of the
 *       noise in the previous iteration.
 */
function GetNoise( x, y, c, s, ks )
{
   if ( Math.abs( s ) < ks )
      N.push( s );
   else
      this.currentSample = 1.0; // tag this coefficient as significant
}

/**
 * Iterative calculation of the standard deviation of Gaussian noise noise.
 * We use k=3 and return an estimate to within 1% accuracy.
 */
function Noise( img )
{
   // Perform a one-layer wavelet transform using a B3 spline scaling function.
   var W = img.aTrousWaveletTransform( [ 1.0/256, 1.0/64, 3.0/128, 1.0/64, 1.0/256,
                                         1.0/64,  1.0/16, 3.0/32,  1.0/16, 1.0/64,
                                         3.0/128, 3.0/32, 9.0/64,  3.0/32, 3.0/128,
                                         1.0/64,  1.0/16, 3.0/32,  1.0/16, 1.0/64,
                                         1.0/256, 1.0/64, 3.0/128, 1.0/64, 1.0/256 ], 1 );
   for ( var i = 0, s0; ; )
   {
      // Standard deviation of the noise for this iteration.
      var s;
      if ( ++i == 1 ) // first iteration?
         s = s0 = W[0].stdDev();
      else
      {
         // Standard deviation of the set of thresholded coefficients.
         s = Math.stddev( N );

         // Return an estimate to within 1% accuracy.
         var converges = (s0 - s)/s0 < 0.01;
         var enough = i == 20;
         if ( converges || enough )
         {
            console.writeln( (converges ? "Convergence reached" :
                                          "*** Warning: No convergence"),
                             " after ", i, " iterations." );
            return 10*s/0.8908; // back to the image space
         }

         s0 = s;
      }

      // Extract the set of noise pixels for the next iteration.
      N.length = 0;
      W[0].forEachSample( GetNoise, 3*s );
      if ( N.length < 2 )
         return 0;
   }
}

function main()
{
   // Get access to the current active image window.
   var window = ImageWindow.activeWindow;
   if ( window.isNull )
      throw new Error( "No active image" );

   console.show();
   console.writeln( "<b>" + window.currentView.fullId + "</b>" );
   console.writeln( "Calculating noise standard deviation..." );
   console.flush();

   // Obtain an estimate of the noise standard deviation for the current view.
   var s = Noise( window.currentView.image );

   // Output results.
   console.writeln( format( "Noise standard deviation = %.8f, N = %u", s, N.length ) );
}

main();


To use the script, create a new JavaScript file with the Script Editor, copy the code and paste it to the new file, then select the image that you want to evaluate, and run the script (press F9). After a few seconds (or minutes if the image is large), the script will write the estimated standard deviation of the noise on the console.

In my experiment with the Lena image, the script has given the following noise estimates:

A: 0.50855925
B: 0.50687131
C: 0.50699363
D: 0.50706419
E: 0.50645103
F: 0.50811908
G: 0.50709520
H: 0.50594039
sum_of_8: 0.20412443

So the achieved signal-to-noise improvement is 2.5 approximately. Our result is slightly worse than the theoretical improvement, which is the square root of eight, 2.83. I think the main reason is the fact that we are working with discrete images. For example, the addition of noise causes a small but irreversible degradation of the signal in each image.
Title: PixInsight 1.5: Prerelease Information
Post by: Juan Conejero on 2009 April 20 00:12:36
Hi Sander,

Quote
More sophisticated algorithms look at the stddev for the pixel and then decide on how to average them. If the stddev is low mean/average can be used. If it's high it uses median.


Yes, I know those methods. I'll explain why I haven't implemented one of these techniques into ImageIntegration.

Consider a set of images and a stack of pixels at the same geometrical position p. Our goal is to reject outlier pixels as accurately as possible. To that purpose, it is crucial to obtain a good estimate of the true pixel value at p.

Now calculate the histogram of the values in the stack. Since we are integrating registered images of the same subject, and we have carried out an initial normalization of the images (so that their values are statistically compatible), the histogram has a strong central tendency (a unique and well formed peak). Then we have:

- If the dispersion of values is high, then the median is a robust estimate of the true value of the pixel at p.

- If the dispersion of values is low, then the median and the mean of the stack are nearly equal, and are both equally good estimates of the true value of the pixel at p.

Hence, we conclude that the median is always the best estimate :) Once we have calculated the median, we can apply an iterative rejection scheme such as k-sigma clipping, min/max, percentile-based clipping, or algorithms based on the properties of CCD detectors. This is what ImageIntegration does.
Title: PixInsight 1.5: Prerelease Information
Post by: vicent_peris on 2009 April 20 08:00:52
Quote from: "Juan Conejero"
Hi Sander,

Quote
More sophisticated algorithms look at the stddev for the pixel and then decide on how to average them. If the stddev is low mean/average can be used. If it's high it uses median.


Yes, I know those methods. I'll explain why I haven't implemented one of these techniques into ImageIntegration.

Consider a set of images and a stack of pixels at the same geometrical position p. Our goal is to reject outlier pixels as accurately as possible. To that purpose, it is crucial to obtain a good estimate of the true pixel value at p.

Now calculate the histogram of the values in the stack. Since we are integrating registered images of the same subject, and we have carried out an initial normalization of the images (so that their values are statistically compatible), the histogram has a strong central tendency (a unique and well formed peak). Then we have:

- If the dispersion of values is high, then the median is a robust estimate of the true value of the pixel at p.

- If the dispersion of values is low, then the median and the mean of the stack are nearly equal, and are both equally good estimates of the true value of the pixel at p.

Hence, we conclude that the median is always the best estimate :) Once we have calculated the median, we can apply an iterative rejection scheme such as k-sigma clipping, min/max, percentile-based clipping, or algorithms based on the properties of CCD detectors. This is what ImageIntegration does.



I think Sander means at time of combining the pixel sets. At p, if the StdDev is high, the resulting value will be Med(p). If low, we will do Avg(p).


Vicent.
Title: PixInsight 1.5: Prerelease Information
Post by: Nocturnal on 2009 April 20 12:41:05
Indeed, that's what I meant.
Title: PixInsight 1.5: Prerelease Information
Post by: Juan Conejero on 2009 April 20 14:44:11
Quote
I think Sander means at time of combining the pixel sets. At p, if the StdDev is high, the resulting value will be Med(p). If low, we will do Avg(p).


The same applies, IMO: assuming that the images have been normalized, the median of each pixel stack is the best estimate of the true pixel value in both cases. So this method is equivalent, in practice, to a median combination. Of course, if the images are not compatible (no normalization), then neither the median nor the mean are good estimates.

In my opinion, the best option is a k-sigma clipping or percentile clipping rejection (depending on the number of images) followed by the arithmetic mean combination of the surviving pixels. I have implemented three additional pixel rejection algorithms: min/max, averaged sigma clipping, and CCD-clip. The first two work well for small sets of images, while the third one requires exact parameters of the detector used (gain and readout noise) and unmodified data (no interpolation and no flat fielding), so it is mainly useful to integrate calibration images. As you can see, I have implemented essentially the same algorithms available in IRAF.
Title: PixInsight 1.5: Prerelease Information
Post by: mmirot on 2009 April 20 15:34:55
The real problem is normalization. You need a good one to get good rejection.
This is not a challange when you skies are clear with stable transparancy.
That is no clouds and not much gradients.
A typical night in my climate will often have good exposures, bad exposures and in between.

On good night you can just normalize the whole image or it's center.

I often have images where 30, 50, 70% of the area is good.  I would think normalizing whole image or even a single background region rejects even the good parts.  




Max
Title: PixInsight 1.5: Prerelease Information
Post by: vicent_peris on 2009 April 20 15:45:28
Quote from: "mmirot"
The real problem is normalization. You need a good one to get good rejection.


The ImageIntegration module uses my normalization algorithms. I have been able to put a sigma of 0.02 on my Lulin image to reject stars, and averaging worked very well on the comet.


Quote from: "mmirot"
This is not a challange when you skies are clear with stable transparancy.
That is no clouds and not much gradients.
A typical night in my climate will often have good exposures, bad exposures and in between.

On good night you can just normalize the whole image or it's center.

I often have images where 30, 50, 70% of the area is good.  I would think normalizing whole image or even a single background region rejects even the good parts.


The problem you refer to is the presence of varying gradients in the image sequence? This is not a problem of good normalization; this is a problem of the images themselves. If you have strong gradients, you must remove them prior to doing a good outlier rejection.

Another option can be to do a first average of the images making small groups. Inside the groups, the gradients will be similar, so outlier rejection will work. At time of averaging the resulting images from each group, you can do an average without outlier rejection.


Vicent.
Title: PixInsight 1.5: Prerelease Information
Post by: mmirot on 2009 April 20 16:22:40
Vincent,

You are correct it is a problem of the images themselves.
Actually, I generally don't have to much LP gradients.

I am really talking about variations in transparency.
I toss out the really bad ones.

I often I find that images a portion of the area has good S/N but the rest is poor.
It has some good data the rest should be rejected.
Most normalzation and data rejection methods don't do much for these images.
Title: PixInsight 1.5: Prerelease Information
Post by: Nocturnal on 2009 April 20 17:15:59
Well I'm glad to hear that sigma-clip with mean is the preferred method as that's what I've been doing with DSS :)
Title: PixInsight 1.5: Prerelease Information
Post by: vicent_peris on 2009 April 20 17:33:45
Quote from: "mmirot"
Vincent,

You are correct it is a problem of the images themselves.
Actually, I generally don't have to much LP gradients.

I am really talking about variations in transparency.
I toss out the really bad ones.

I often I find that images a portion of the area has good S/N but the rest is poor.
It has some good data the rest should be rejected.
Most normalzation and data rejection methods don't do much for these images.


Perhaps our ImageIntegration will do a better work... but I'm not sure about this... If a portion of an image has poor S/N areas, a low sigma will reject noisy pixels. The key is to have a good normalization to be able to lower sufficiently the sigma parameter.

Are you talking about wide field images? Having los S/N inside an image is very strange, IMO.  :?


Vicent.
Title: PixInsight 1.5: Prerelease Information
Post by: mmirot on 2009 April 20 18:17:13
I really look forword to trying it out.
Maybe I can come up with some examples later after I try1.5


It looks like the goal is to have full set of modules for calibration and preprocessing.
I certainly have some ideas along these lines. One module could be devoted just to reviewing and rejecting subframes.


I have used most major programs out there.  Some work better than others.
I have confidence that Team Pixinsight will end up at the head of the rest.
Title: PixInsight 1.5: Prerelease Information
Post by: Juan Conejero on 2009 April 27 23:05:12
Hello all,

More improvements for PI 1.5:

http://forum-images.pixinsight.com/legacy/1.5-preview/ATW-rt-1.jpg

http://forum-images.pixinsight.com/legacy/1.5-preview/ATW-rt-2.jpg

It is damn complex because we need to scale all wavelet layers and their parameters, to adapt the whole process to a possibly downsampled real-time image, so that the result looks as close as possible to what will be obtained on the actual image. It's working well now, but still needs some work. Time to get some sleep! :)
Title: WOW
Post by: Jack Harvey on 2009 April 27 23:49:28
Wow, Now that is exciting and will expedite the use of wavelets adjustments to no end!!!
Title: Re: PixInsight 1.5: Prerelease Information
Post by: Juan Conejero on 2009 May 06 16:21:02
Last-minute news. PI 1.5 supports SVG (Scalable Vector Graphics) generation and rendering, from both the PCL and PJSR development frameworks.

SVG seems to be working flawlessly now. If you want to see an example, point your Firefox/Safari/Opera browser here (sorry, I don't know if MSIE supports SVG) to see a SVG rendition generated with a modified version of Andrés&David's 3DPlot script:

http://pixinsight.com/tmp/3dplot.svg

With Firefox it's very nice because it seems polygon generation in real time.

So PI 1.5 opens the door to vector graphics in PixInsight  8)
Title: Re: PixInsight 1.5: Prerelease Information
Post by: georg.viehoever on 2009 May 06 16:41:26
No SVG in IE8...
Title: Re: PixInsight 1.5: Prerelease Information
Post by: Juan Conejero on 2009 May 06 16:45:25
Quote
No SVG in IE8...

... because SVG is an open standard, perhaps? ;D
Title: Re: PixInsight 1.5: Prerelease Information
Post by: ManoloL on 2009 May 06 18:19:03
Hola Juan:
¿Para cuando la V1.5?

Tengo un montón de trabajo para ImagenIntegration.
Saludos.


Hi Juan:
When the V1.5?
I have a lot of work for the ImagenIntegration.
Regargs

Editado:
Ya he visto que la pregunta esta respondida en otro hilo:

"Definitely it will hit the street this week"

Saludos de nuevo.
Title: Re: PixInsight 1.5: Prerelease Information
Post by: Harry page on 2009 May 08 17:56:46
Hi Juan


The week is running out :o

Harry
Title: Re: PixInsight 1.5: Prerelease Information
Post by: Niall Saunders on 2009 May 08 20:40:08
Hey Guys - give Juan a break  :police:

In fact I did get an email from him, and I am sure that he won't mind me quoting from it . . .
Quote
Indeed I'm having some nightmares to finish 1.5, and it's true that sleep is a luxury that I hardly can afford these days. Definitely I'm going to need a good rest once I release this one...

and

Quote
(I) *must* release 1.5 *this* weekend, or otherwise (I) will get into serious trouble, including wife-related troubles

Personally, I can wait ( but not for TOO long  ;D )

Cheers,
Title: Re: PixInsight 1.5: Prerelease Information
Post by: ManoloL on 2009 May 08 20:55:18
Hola Juan:

La salud es lo primero y dormir un tiempo prudente es esencial para mantenerla.
Si la "cosa" no puede ser esta semana pues será la siguiente.
Pero no debías habernos puesto los dientes tan largos.......... :P :P :P :P
mira luego lo que pasa......... :yell: :yell: :yell: :yell:

Saludos.
Title: Re: PixInsight 1.5: Prerelease Information
Post by: bosch on 2009 May 09 07:02:13
Gracias Juan por mantener al día este fantástico programa. Estoy particularmente esperanzado por el módulo de homogeneización del fondo así como de calibraod del color.

Dentro de las mejoras que introduce la nueva versión no he observado que se hubiera incluido alguas herramientas digamosle que "de edición". Acuérdate de lo del Cut&paste, el poder incluir un cuadro de texto sobre la foto o incluso poder dibujar sobre ella objetos simples como una flecha ara poder destacar la posición de algún objeto. También estaría de lujo el poder incluir un compás para señalar el norte-este en la foto (el dato del cual lo podria obtener de la información que "esconde" el fit). Bueno, no dejan de ser pequeñas chorradas que para los que han entrado en la "secta cometera" agradecerían.

Un saludo y disculpa no haber puesto este mensaje en el apartado de peticiones.
Title: Re: PixInsight 1.5: Prerelease Information
Post by: Jordi Gallego on 2009 May 09 19:05:32
I only can say (with Niall permision):

Hey Guys - give Juan a break  :police:

but also:

Personally, I can wait ( but not for TOO long  ;D )


Juan, mi consejo si me permites darlo: pon una raya ya. No incluyas más potencialidades en la v 1.5, las que nos has comentado son ya tremendas. Toma tu tiempo para acabar la v 1.5 y, por prescripción facultativa, luego tómate un descanso !!!!! ;)

Juan, mi advice if you allow me: stop. Do not add more features to v 1.5. The ones that you already told us are impresive. Take your time to finish v 1.5 , and once finished, take a big rest!!!!!! ;)

Saludos/ Regards
Jordi
Title: Re: PixInsight 1.5: Prerelease Information
Post by: Jack Harvey on 2009 May 09 19:23:34
Juan I agree with Jordi,
Quote
Juan, mi advice if you allow me: stop. Do not add more features to v 1.5. The ones that you already told us are impresive. Take your time to finish v 1.5 , and once finished, take a big rest!!!!!!
  You have a diamond in the rough, finish the final polish later, AFTER a good rest!
Title: Re: PixInsight 1.5: Prerelease Information
Post by: Juan Conejero on 2009 May 10 08:04:19
Hi guys,

Thank you all for your nice words and support. I'm working hard but don't worry, I'm well and the work is being made well too. Everything is working now except the ports to Windows and Mac OSX. The latter is a bit complicated, but just a routinary task, compared to the rest.

If there are no further problems (I see no reason), version 1.5 should be published within Monday/Tuesday. Sorry, I couldn't publish it this week... so I ought you one beer --although I'd recommend a good Spanish wine, of course ;).
Title: Re: PixInsight 1.5: Prerelease Information
Post by: ManoloL on 2009 May 10 08:31:32
although I'd recommend a good Spanish wine, of course ;).

Hola Juan:
En la comida de hoy me tomaré un par de vasitos de Rioja a tu salud.
Muchas gracias por tus esfuerzos.
Saludos.
Title: Re: PixInsight 1.5: Pre Release Information
Post by: Harry page on 2009 May 10 13:13:54
Hi Juan


I told my wife that I had some urgent software testing to do this weekend ;D  , Now She says I can paint the conservatory instead :sad:

Not to worry though Absence makes the heart Fonder  :)


Regards Harry
Title: Re: PixInsight 1.5: Prerelease Information
Post by: Jack Harvey on 2009 May 10 13:29:07
Harry  In all fairness to the wife I hope you put in the same time on the Conservatory as you would have with the software testing<G>.
Title: Re: PixInsight 1.5: Prerelease Information
Post by: Juan Conejero on 2009 May 13 00:32:13
Hi there! Still alive! ;D

PixInsight 1.5 is now available for Linux and Windows, Core and PCL packages, 32-bit and 64-bit versions, at the software distribution interface:

http://pixinsight.com/dist/

Look for files uploaded on May 12 and May 13.

Unfortunately, the Mac OSX version is not yet available. I'm having a lot of problems with Qt 4.5.1 on Mac OSX (I really hate to say this, but 4.5.1 for OSX is one of the worst versions of Qt I've ever seen -- yes, all the examples work fine, but a complex app. like PI is just unusable when compiled with Qt 4.5.1). Tomorrow I'll work hard to get all problems fixed, but if I can't achieve a usable application I'll revert PI 1.5 to use Qt 4.4.3 on Mac OSX, which works like a charm. However, this means that we'll have no 64-bit version for Mac OSX... at least not for now :'(

Anyway, tomorrow PI 1.5 will be officially announced. This notice is a courtesy toward you PI Forum members ;)

Hope you'll like it. PI 1.5 isn't everything I intended it to be, but I think it's quite good. Enjoy! 8)
Title: Re: PixInsight 1.5: Prerelease Information
Post by: Jack Harvey on 2009 May 13 00:46:10
Juan  Thanks for all your hard work.  Hope the Mac OS system works out but either way I will be happy.
Title: Re: PixInsight 1.5: Prerelease Information
Post by: Nocturnal on 2009 May 13 01:01:50
Woohoooo!
Title: Re: PixInsight 1.5: Prerelease Information
Post by: Niall Saunders on 2009 May 13 09:47:08
Congratulations Juan !!

Looking forward to downloading and testing the latest version.

One thought - in my deBayer script, should I 'get rid of' all the v1.4 'workarounds', or should I introduce code to detect the 'version' of the PI 'core', and introduce "if ( version_xxx ) { ... } else { ... }" code ?

Obviously, what I now need to do is to make sure that I don't over-write my scripts when I install the new version - now that really would leave me mad !!!!!

Cheers
Title: Re: PixInsight 1.5: Prerelease Information
Post by: David Serrano on 2009 May 13 09:57:10
Congrats Juan ;)

One thought - in my deBayer script, should I 'get rid of' all the v1.4 'workarounds'

That's what I've done in the past, when the Settings class was added to the JS engine. Updated my script and marked it as "Requires at least PixInsight version 42".
Title: Re: PixInsight 1.5: Prerelease Information
Post by: Niall Saunders on 2009 May 13 10:45:03
Hi David, thanks for that.

Unfortunately, I will now have to wait until I get back to my main PC before I can look at the 'Settings' class options - do you have a sample code snippet at hand that you could upload?

What I need is for Juan to compile v1.5 for the iPhone, so that I can edit and test my scripts 'on the move' !!!

Any chance Juan? After all, you seem to be becoming a 'Grand Master' of Apple Operating Systems  ::)  ::)  ::) (or, as we Windoze users like to refer to them, "Smoke and Mirrors - OS" !)

Cheers,
Title: Re: PixInsight 1.5: Prerelease Information
Post by: Juan Conejero on 2009 May 13 12:35:46
Thank you all!

Quote
One thought - in my deBayer script, should I 'get rid of' all the v1.4 'workarounds', or should I introduce code to detect the 'version' of the PI 'core', and introduce "if ( version_xxx ) { ... } else { ... }" code ?

In theory everybody should be using v1.5 within a few weeks on all platforms, so you could just replace the workarounds with new code. Anyway you can use conditional directives:

Code: [Select]
#iflt __PI_VERSION__ "01.05"
// ... code for v1.4.x
#endif

Quote
Obviously, what I now need to do is to make sure that I don't over-write my scripts when I install the new version - now that really would leave me mad !!!!!

Of course!!! To everybody: On Windows, always save your scripts on a folder OUTSIDE your PI installation. That is, on a folder NOT UNDER C:\PCL (or your installation folder if you changed the default setting on installation). The reason is obvious: the Windows installer ERASES the whole PI installation folder before installing a new version. The uninstaller also erases the previous version completely. And of course, always make backup copies of your scripts.

So Niall, the first thing you should do when you get back to your computer is to make backup copies of all your scripts before installing v1.5.
Title: Re: PixInsight 1.5: Prerelease Information
Post by: Juan Conejero on 2009 May 13 12:47:45
Quote
What I need is for Juan to compile v1.5 for the iPhone, so that I can edit and test my scripts 'on the move' !!!

Hahaha, that's just what I need: another platform  :laugh:  :o

Quote
(or, as we Windoze users like to refer to them, "Smoke and Mirrors - OS" !)

Despite they will never publicly acknowledge it, all windozers dream of something like the Aladdin lamp effect on their Vistas and XPs >:D Do you agree, Sander?  ;D
Title: Re: PixInsight 1.5: Prerelease Information
Post by: Juan Conejero on 2009 May 13 12:54:30
Well, after an "interesting, so to say" morning trying to crack Qt 4.5.1, I finally have reverted PI 1.5 on Mac OSX to use Qt 4.4.3. This means that we have no 64-bit version for the Mac with this release. Sad, but despite that, PI 1.5 x86 works extremely well on OSX. It's definitely my favorite version (and it's a Linux super-addict who's telling this).

The installation files for OSX are uploading right now, so the official release will happen this evening.

Of course, I'll keep trying to get Qt 4.5.1 working (reasonably, at least). It might be something in my code that is causing problems with the new Qt version, but the fact that the same code works without flaws on all versions of Linux and Windows says the contrary, loud and clear...
Title: Re: PixInsight 1.5: Prerelease Information
Post by: David Serrano on 2009 May 13 13:08:45
Unfortunately, I will now have to wait until I get back to my main PC before I can look at the 'Settings' class options - do you have a sample code snippet at hand that you could upload?

Settings is unrelated to your problem, it was just some additional info on when did I do that ;).

Anyway, for sample code, look at the MaskedStretchTransform script, which is included in PixInsight for a couple of versions now.
Title: Re: PixInsight 1.5: Prerelease Information
Post by: Nocturnal on 2009 May 13 13:46:35
Quote
Of course!!! To everybody: On Windows, always save your scripts on a folder OUTSIDE your PI installation. That is, on a folder NOT UNDER C:\PCL (or your installation folder if you changed the default setting on installation). The reason is obvious: the Windows installer ERASES the whole PI installation folder before installing a new version. The uninstaller also erases the previous version completely. And of course, always make backup copies of your scripts.

This is not quite correct, fortunately. On this machine modules were being developed under \pcl and after installing 1.5 the sources are still there. I always stick my changes in CVS before wrapping up for the day so even if things had gotten blown away I would have been fine. At the same time uninstallers should NEVER touch files they didn't put there themselves. Just doing an rm -rf /pcl is out of the question.

Now to recompile my modules.
Title: Re: PixInsight 1.5: Prerelease Information
Post by: Harry page on 2009 May 13 18:28:14
Hi Juan

Thanks for the new version , looks very cool 8)

You might have to give us a hint on some of the new features ???

Regards Harry
Title: Re: PixInsight 1.5: Prerelease Information
Post by: Jack Harvey on 2009 May 13 18:58:44
Juan  This is spectacular.  Have played with a cople of tools and am really impressed.  Using the Mac OS ver.  THe Color Calibration tool with a singe click really improved one of my old images!  I have not been able to see the changes in the histogram tool when I am using Curves and Preview.  I move the curve and I see the preview smoothly change but no change on the histo tool?

Also the ability to have live preview on the wavelets is going to be very powerful letting you dial in the amounts in real time!  Really COOOL!
Title: Re: PixInsight 1.5: Prerelease Information
Post by: Harry page on 2009 May 13 19:35:26
Hi Jack

You have to select real time preview in the histogram view box ;)


Regards Harry
Title: Re: PixInsight 1.5: Prerelease Information
Post by: Jack Harvey on 2009 May 13 20:05:25
By Jove I've Got it!  Thanks and a really cool tool.

BTW how did the painting of the conservatory work out<G>
Title: Re: PixInsight 1.5: Prerelease Information
Post by: Harry page on 2009 May 13 20:14:05
Hi Jack

Some very nice tools indeed ( Ok juan no need for log stretch in the STF)

Did I mention I have not finished building it yet, For some reason my wife wants some glass in it ! :D

regards Harry