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.

Messages - gvanhau

Pages: 1 2 3 [4] 5 6 ... 23
General / Re: Star Colour Fringing Problem
« on: 2016 February 01 06:57:33 »
I've looked at the images in the first post, and I can see there is as you also say, an elogantion of all stars in the same angle of the color fringing.
In the color image, if you take a close look, yo can also see fringing in the smaller stars, It is less visible because it is also dimmer.
I think there is little that Juan can do about it.
In my opinion, the only rigth thing to do is to enhance the capture.

Of course, there are some tricks that can be done. For instance, you could try motion blur in deconvolution, but at the end, the best is to solve the problems at the root.


General / Re: Invalid Memory Read Errors--PLEASE Respond!!!
« on: 2016 January 26 11:26:05 »

Are you using the latest PixInsight version?
In previuos versions, some proceses caused invalid memory access (to some users including me), but I've not experienced this in the latests build.
I also read somewhere in the forum about an incompatibility with some DELL computer utilities, but no sure if this is your case.


General / Re: Help ! Getting crazy with Master Offset...
« on: 2016 January 21 07:38:32 »
If I Understand it correctly:  If you calibrate your images using a master offset (I asume master bias?) you are getting a almost black image, but if you dont use the master bias result is ok?

If so, I think that some how you are substracting master bias twice.
There are several options to calibrate your images, and you have to be consistent with one of them.

For example:

you can do:   
                    integrate bias-> master bias
                    calibrate flats: flat - master bias -> calibrated flat (Im assuming here that flats are very short exposures)
                    integrate calibrated flats -> master flat
                    integrate darks (wo calibration) -> master dark
                    calibrate lights : (light - master dark) / master flat == calibrated ligt.

but you can also:
                    integrate bias-> master bias
                    calibrate flats: flat - master bias -> calibrated flat (Im assuming here that flats are very short exposures)
                    integrate calibrated flats -> master flat
                    calibrate darks : dark - master bias -> clibrated dark
                    integrate  calibrated darks -> master dark
                    calibrate lights : (light - master dark  - master bias) / master flat == calibrated ligt.

If you see, in the first case, I dont subtract master bias from light, because it is already included in the master dark.

So, in order to help you,  it would be necesary that you show the whole calibration process, icluding how you created each of the masters.


This is what The fits standard says about it: Units

The fragment you have excerpted is not part of the FITS standard. I have found it in A User's Guide for the Flexible Image Transport System (FITS), published in 1998. The current FITS standard is version 3.0, released 2008 July 10.

May be no the official text, but if it is referenced at the official site, I assume it is valid  you can follow the link at the official page (see red link in image )


5.3. IEEE-754 floating point

Transmission  of  32-  and  64-bit  floating-point data  within  the FITS format shall use  the  ANSI / IEEE-754  standard  (IEEE1985). BITPIX = -32 and BITPIX = -64 signify 32- and 64-bit IEEE floating-point numbers, respectively; the absolute value of BITPIX is used for computing the sizes of data structures. The full IEEE set of number forms is allowed for FITS interchange, including all special values.
The BLANK keyword should not be used when BITPIX = -32 or -64; rather, the IEEE NaN should be used  to  represent an  undefined value.  Use  of  the BSCALE and BZERO keywords is not recommended.
The bold emphasis is mine.
It is not recommended, because it was originally intended to allow fractional data when there was no floating point. It is not forbiden!!
The problem is if you don scale the floating point, using the apropiate exponent, then you should use at least use bscale to acomodate the values.
The point here is that PixInsight changes the data by not scaling the values and/or by not outputing the correct exponent.


Even if I know beforehand that this discussion is hopeless,  see the attached image taken from the fits standard PDF.

Since BUNIT is not writen by PixInsight,  and BSCALE is not writen by pi in floating point and that  BSCALE=1 by default  and also 1 in PixInsight 32 bit integer output,  I want to know why PixInsight fits floating point output is at such different scale comparing to PixInsight  32 bit integer fits format.
For me they slould be the same value, or at least the same magnitude, even if at integer values you may have a rounding or truncation due to overflow or underflow.
We are talking about the same image, the same BUNIT(default), the same BSCALE so the formula BZERO+BSCALE x array_value should yeald the same physical_value.



This is for Juan:

What units are used by PixInsight for saving images in floating point?

This is what The fits standard says about it: Units

  The units named in the IAU (1988) Style Guide are recommended for array and keyword values, with the exception of measurements of angles. This set of units includes the SI units and additional units that are standard in astronomy, for example, magnitudes. Using BUNIT and TUNITn keywords will remove any confusion; similarly, the comment field following CTYPEn keywords can be used to specify the units. Fractional units should not be used. If, for example, for space reasons, temperatures must be listed in the file in units of tens of degrees, the units specified by BUNIT should be degrees, and scaling (section should be used to transform from the file values to physical values. Always explicitly describe non-standard units. A copy of the IAU Style Guide recommendations is available on the IAU World Wide Web site, currently at



Maxim does the following:
"One shortcoming of the FITS standard is that the 16-bit number format is signed, producing a range of -32768 to +32767. The range of data from many cameras is 0 to 65535. To overcome this problem, MaxIm DL subtracts 32768 from each pixel prior to saving. The FITS standard requires that the BZERO and BSCALE keywords be used when the value in the array is not the physical value; MaxIm DL sets BZERO to 32768 and BSCALE to 1. Other applications that interpret these keywords correctly should automatically add 32768 to the image pixels, resulting in a correct image display. This default behavior can be overridden using the File menu Settings command."

And this is just what the fits standard suggest including an example for it:
"Proposals to add 16- and 32-bit unsigned integer types have been discussed from time to time, but a consensus in favor of these proposals has not developed. Data with the numerical range corresponding to unsigned integers can be included in a FITS file by using signed integers and then scaling, for example, setting BZERO equal to 32768 (2^15) for 16-bit integers."


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 / Re: Registration failure - what causes this?
« on: 2016 January 05 07:38:04 »
It is difficult to answer WO a look to the images.
If could be that Hot pixels are recognized as stars.
You can tweak a litle the star detection parameters (roundnes) in order to facilitate the matching, however dont expect great ressults if stars are trailed.


General / Re: flat frames for DSLR
« on: 2015 December 30 10:45:11 »

When taking flats with my DSLR's I normally use AV setting.
This way the Camera evalutes the correct expo for flat frames.


General / Re: Erosion Filter?
« on: 2015 December 28 11:56:56 »
Hello Steve

You could try the following:
Frist make a star mask:  take for noise threshold the aproximate background level of your image; for scale take about 5 or 6;  set structure grouths to 0; For smoothness use about 8; check contours; leave the rest as default and apply.
This should give you a mask of donuts arrount most of the stars.
Apply the mask to your image.
Now, with The morfological process, use a structure about 5 or 7 and select circle shape.
Select erosion, select iterations according to the effect you want.
Select amount to a small value (0.1 to 0.3)
Apply (try first on a preview).

This should reduce your stars ..... and allow space to enhance the DSO.


General / Re: More trouble with DSLR Flats
« on: 2015 December 28 10:41:04 »

I'm seeing that your master flat is a color image?
As far as I know, the calibration should be done w/o debayering.
So, master flat, Master Dark and Master Bias are Gray CFA images.
You shoud only debayer just before star alignment.


General / Re: Flat overcompensating
« on: 2015 December 16 04:52:47 »

General / Re: donut disaster
« on: 2015 November 30 07:50:03 »
Hello Dave

I've found a method that usually helps me when Flat frames are doing overcorrection or under correction (meanly a scaling problem).

The trick consist on doing a linear fit between a half calibrated light frame and the master flat.
I will write e tutorial on this as soon as I have the time, but the procedure is as follows:

If your frames are mono do the following:
1.- thake one of the light frames before calibration.
2.- using pixel math substract the the master Dark (and master Bias) from the choosen light.
3.- now apply a linear fit to your master Flat using as reference the image resulting form 2
4.- use the new master flat (resulting fom 3) in your normal calibration of lights.

If your frames are osc (bayer color)
Then the procedure is similar, but you have first to split the light frame, Master Dark,, Master Bias and Master flat into 4 individual images (using splitcfa) apply the procedure to the four parts and recombine the four resulting flats parts into one full flat and use this result in your normal calibration.

Note this does not hep if during the session the dust has moved, it only helps if there is a scaling problem.
I dont know yet why this is hapening, but for me it helps.


Pages: 1 2 3 [4] 5 6 ... 23