Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - gvanhau

Pages: [1] 2 3 ... 5
General / LarsonSekanina coordinates not saved in proyect
« on: 2019 October 28 14:53:46 »

I was just re taking the processing of my solar images of the las solar eclipse (july 2)
Since it has passed some time y wanted to revise some of the parameters stored in some process icons.

I found out that center coordinates of the LarsonSecanina process where 0.
In order to verify, I entered the coordinates, saved the project  then loaded it again and coordinates where cero again.



General / Probable bug in last imagesolver update
« on: 2017 September 18 17:25:57 »
I got this message when trying to solve an image:

Processing script file: C:/Program Files/PixInsight/src/scripts/AdP/ImageSolver.js
* Using an automatically calculated limit magnitude of 14.88.
** Warning [162]: C:/Program Files/PixInsight/src/scripts/AdP/ImageSolver.js, line 2490: reference to undefined property this.solvercfg
*** Error [222]: C:/Program Files/PixInsight/src/scripts/AdP/ImageSolver.js, line 2490: TypeError: this.solvercfg is undefined


Since the last update, where image registration and image integration are now using multiple cpu cores, I am getting random PI crashes.
Sometimes it chashes wit few procesed images, other times it crashes after processing lots of images.
After each crash, PI is aborted and has to be started again.

I could reproduce this issue in two different computers using windows 10.

I like the performace increase of both proceses, so hopefully this bug is solved asp. 


Bug Reports / MaskedStrech unable to auto strech (to dark image)
« on: 2016 February 13 09:53:02 »
This is new to me;  I've never had problems with this.

I attached screenshot  of PI, where you can see the console output, the error message and the image I'm processing.


General / Question about persistence of swap files
« on: 2016 February 09 04:34:44 »
I've seen the following behavior using PixInsight Integration module:

If I add some more pictures to the image integration module, the first images (from previous integration) run very quick, but the new added pictures take some time, because there is some math applied to them.
I may be wrong, but I remember having seen in the console, that values for previous images were taken from swap??
Some times, this happens even if I load a saved proyect, and the previous integration was done a few days ago.

Now my question is:  are swap files recorded together with projects? or what is the logic behind this behavior?


Bug Reports / PI SWAP file error, could not save proyect SOLVED
« on: 2016 February 07 13:50:57 »

I got the attached message when I wanted to save my proyect.
I am using the latest version (

I checked the path in windows, there was plenty of space in drive c: there were no issues in writing to nor reading from the drive, etc.

After the error, there was no way to save the proyect... even creating a new one.
I could open every image and every process Icon in the workspace, why did it need the swap file?
I saved the process icons and images individually, and then had to build a new  proyect by scratch.  In that action, I lost the whole process history.


I've been analyzing a lot of documentation about the fits format, the way PixInsight handles it and some issues around it.

I was surprised  when surfing in the web, came around with a statement like "How the default PixInsight rescaling affects color." from the  AstroPhotographer Bob Franke, but after contacting him, realized that the problem he found was real.

I also read this thread  which is very interesting because there is a mention to the problems related to fits format  and the PI underlying [0,1] scaling.

The main problem is that while the world (everyone except PixInsight) reads fits floating point data as absolute values, PixInsight interpret them as relative values (ie relative to white point and black point).
Remember that Fits Means Flexible Image Transport System, and that Images consist of pixels and that each pixel is represented by one or more intensities (and not a relative values).
So when the boundaries are not established like in fixed point formats the internal scaling procedure of PixInsight fails, and we get issues as the stated by Bob Franke.

PixInsight invented a work around to solve the read issue, forcing the user to introduce a range in format explorer, and so allowing a correct scaling of the data, but this has its own issues:

If for example in format explorer I set  the range values to 0 and 65536,  then reading of (some) foreign images performs ok. I tested this with Bob's images and the color scaling problem disappeared. But what if that was not the correct range? 
Even worse:  with this setting now PixInsigth own generated images, are also read and scaled in the 0,65536 range, and they now appear almost completely black because they were written in the 0-1 range.  Imagine the mess having for each image to manipulate the read range in order to get them read ok, imagine if you have a script reading and writing images....

There is also the write issue:  all fits floating point data is written by PixInsight in 0-1 range (absolute) so, if you read any image in PixInsight and then write it to a floating point fits file, the data is altered.
All floating point fits format images written by PixInsight are read as almost pure black in other programs. I tested this with images which where stretched and ready for printing and got almost black results in other programs.


General / Are we now enforced to use the XISF format?
« on: 2015 October 27 20:30:39 »

I have set in global preferences that my default format is .fit
Even so, on (some?) proceses like splitcfa that do not allow to select output format they are writing .xisf even if input is .fit.

I dont like .xisf not because it is bad, but because it is incompatible with any other graphic software out there.


Running an old script, Y got this error:
line 44: ReferenceError: HDRWaveletTransform is not defined

Is there a replacement for this function in newer releases?


I have a formula I want to apply to a image, but the formula is based on 16bit integer math.
for instance y=0.0104x + 2032.

Since images are converted to 0-1 scale in PixInsight, I'm a little confused.


This is a minor detail, and only represents a problem when trying to move icons near the border of the workplace.
The effect is: you pick a icon in the workplace to move it to another place, the mouse cursor appears to move a little faster than the icon and when you drop the icon, it places it at the icon position, not at the mouse position, but if the mouse trespasses the border of the workplace to place the icon near the border, it does not allow it.
This does not always occur, but is frecuent. The work around is to pick the icon again and move again...

I use the last available version, all patches installed and platform is windows 10 x64.

Update: I attached two images taken with my cellphone to ilustrate this,  in both I marked the Icon I'm draging and the pos of the mouse cursor.


General / Grid Pattern in Images after Dynamic crop
« on: 2015 July 31 20:05:27 »

I was generating a star mask and was getting a very strange grid pattern in the background of the resulting mask.
First I tried modifying the parameters to see if it had to do whit them, but no matter what parameters, the grid pattern was there...
Then It came into my mind that it could be the image that had this pattern hidden into it.

In order to find it out, I applied a pixelmath  to the image, consisting of a discrimination of pixels by level (if pix<Value then 0 else 1)
When the value was somewhat lower than the background level, the pattern appeared.

I then reversed one by one the process, and checked if PixelMath still generated the pattern, and so it was until the very first stage on processing:

After the initial integration, and the Dynamic Crop the pattern appeared.
Before the dynamic crop, the pattern was not there.

I attached the image after integration, the image applying the dynamic crop, The image after applying Pixel math and a star mask of the same image.

I just tested the different interpolation algorithms, and in only happens using bilinear and Bicubic Spline.

Edit 2:
I now tested this also on an image of another camera with  sony chip and got same result  the posted images are with KAF8300 chip.


General / Strange result with Pixel math
« on: 2015 June 10 18:44:48 »

I was trying to follow Vicent Peris tutorial to enhance a rgb image with Ha
When doing the math, I found some strange results of pixel math:

when I compute (RGB_R/(Ha+0.000001))*Ha  the result is almost the original RGB_R image,
but when I compute C= RGB_R/(Ha+0.000001)  and then compute C*Ha, I get a distinct image.
It seems that there is a round off somewhere when storing the result of the first calc, even  if force to use 64 bit images
No rescaling is used.

on attached image top left is R,  Top right is result
bottom left is Ha   bottom right is continuum



I got this message when saving this very simple project.


Bug Reports / Issue with option in image container
« on: 2015 March 23 13:53:38 »

I was testing NKV's new module to convert CFA to RGB.
During the run I disabled the option "never overwrite originals" in the image container because this time I wanted that originals were overwritten.
This option did not work, it detected the original file and replaced the output  file name apending a 01 or 001 to it.


Pages: [1] 2 3 ... 5