Loading AA images into other software

[Forum_2016]

As I discovered, there are some AA images which will not load correctly into other image processing software. The problem is due to the BZERO FITS keyword and how the pixel values in the image represent the raw pixels recorded by the camera.

When AA saves an image to disk, it first scans the pixels to see if any are greater than 32767. If so then it will subtract 32768 from all of the pixels and add the FITS keyword BZERO with a value of 32768 to the FITS header. This is because the FITS standard does not support unsigned 16 bit integers (0 - 65535), but instead uses signed 16 bit integers (-32768 to + 32767). For example, a raw pixel value of 40,000 would be saved in the fits file as 7,232. When reading this image the pixel value has BZERO added to it to get back to the raw pixel value: 7,232 + BZERO (32768) = 40,000. Raw pixel values less than 32768 are saved in the image file as negative numbers.

BZERO = 32768.0
Raw Pixel Image Pixel
0 -32768
1000 -31768
32768 0
60000 27,232

Raw pixel = image pixel + BZERO (32768)


BUT, if there are no pixels greater than 32767 in the image then AA does not add the BZERO keyword to the header AND does not rescale the pixel values. In other words, the pixel value in the image file is the same as the raw pixel value from the camera. Technically BZERO = 0 in this case and there is no need to change the pixel values in the image:

BZERO = 0
Raw Pixel Image Pixel
0 0
1000 1000
30000 30000

Raw pixel = image pixel + BZERO (0)

Unfortunately, some other image processing programs assume a 16 bit FITS image have the pixels offset by 32768 which means those programs ALWAYS add 32768 to the image pixel value. The AA image which has not been offset now looks like this in the other program:

BZERO (none in the header)
Image Pixel --> Raw Pixel
0 32768
1000 33768
30000 62768

This will cause all kinds of problems in the other software.

But there is an easy fix in AA:

1. Check the AA image for the keyword BZERO (Edit|FITS Header).

2. If you find the keyword BZERO then the image will load correctly into all other image processing programs.

3. If you do not find BZERO then zoom into the image maximum size and move to the lower left corner of the image.

4. Position the cursor to the far lower left of the image and right click mouse and select Edit pixels.

5. You will now see in dark gray the value of each of the pixels with a black border around pixel 0,0.

6. Using the edit box, change the pixel value to 35000 and click OK.

7. Save the image. AA will now see a value greater than 32767 and will rescale all the pixel values and add the BZERO keyword.

You can now load the image into all other image processing programs.

NOTE: you can also write a script to do this automatically.

It would be better if AA would always add the BZERO keyword and rescale the pixel values, but the above method will solve the problem of using any AA image in all other image processing programs.

[Forum_2016]

There is also another way to change a pixel value:

1. Load the image,

2. Select Edit|Pixels

3. A box will appear to select the pixel, default is 0,0, click OK

4. Change the pixel to 35,000 and click OK

5. Save the image

[Forum_2016]

A couple of additional points:

1. The image must be a 16 bit data format. If it is 32 bit then it will not work. Check the keyword: BITPIX at the top of the header.

2. You have to replace the image and not create a new one. If a new image is created it will reformat the data to 32 bit. This won't work.

For example, after preprocessing be sure to save the image first before changing the pixel. And after changing the pixel be sure to save it under the original name and not create a new image.

Note that if a camera creates a BIAS frame or a Dark frame and no pixels are greater than 32767 then these images cannot be loaded into other software without this change. There is an easy way to create a BIAS or DARK frame:

1. Load any image.

2. Select: Arithmetic|Formula.

3. Clear the contents of the edit box and enter a number (e.g., 100). You then have for the formula v = 100.

4. Click OK, this will set all pixels to the value 100.

5. Save as a new image (e.g., SimulatedDark).

Try loading the simulated dark into other software and you may note problems.

Now, change one pixel to 35000 and save it. It will now save as a 16 bit pixel with BZERO set. It will now work in other programs.

[Forum_2016]

Hello, OK, but you should contact the author of the other software to fix its bug. There is only one FITS standard and everybody must follow it. In the FITS standard 2.1b the keyboard BZERO is optional, and if not given its default value is 0.0.
See:
http://fits.gsfc.nasa.gov/fits_documentation.html

Astroart is 100% compatible with it.
Another solution for quick export to other software if TIFF, if FITS is not properly supported by the other software.

[Forum_2016]

There may be a contradiction in the specification. Using AA I open an image and using Arithmetic|formula, I set all pixels to the value 1024 and save the image under a new name. When I open this image in AA it shows all the pixels are 1024, which is correct.

When I open the image using a binary editor and look at how the pixels were saved in the file it shows a 0400 (Hex) which is 1024 (decimal). The FITS specification says it only supports unsigned integers in the range -32768 to + 32767, which means 1024 decimal should be stored as 8400 (hex) or 33,792 (decimal).

So the problem comes down to whether the specification actually allows unsigned integers, if not then I think the unsigned 16 bit integer has to be changed to an unsigned 16 bit integer and BZERO adjusted accordingly.

[Forum_2016]

Hello, FITS 16 bit is always signed, unsigned does not exist (as raw data).
So, when the range is 0..32K there are no problems and the data is written as it is.
If instead the image range is 0..64K, then 32K is subtracted from every pixel before saving, so that the range is again -32K..32K and the image fits into signed 16 bit (and BZERO=32768 keyword is added of course).
I also suggest an official FITS viewer: http://fits.gsfc.nasa.gov/fits_viewer.html

[Forum_2016]

I see your point. FITS image files with the keyword BITPIX=16 means the 16 bit pixel values are signed integers. There is no exception to this. Here is a definition of BZERO (http://heasarc.gsfc.nasa.gov/docs/fcg/s ... _dict.html):):

KEYWORD: BZERO
REFERENCE: FITS Standard
STATUS: reserved
HDU: image
VALUE: real
DEFAULT: 0.0
COMMENT: zero point in scaling equation
DEFINITION: This keyword shall be used, along with the BSCALE keyword,
when the array pixel values are not the true physical values, to
transform the primary data array values to the true values using the
equation: physical_value = BZERO + BSCALE * array_value. The value field
shall contain a floating point number representing the physical value
corresponding to an array value of zero. The default value for this
keyword is 0.0.

When AA puts a raw pixel value of 1024 in the FITS image file as the pixel value AND does not include the BZERO offset then this does conform to the standard but limits the ADU range to positive numbers (0 - 32767). And as you pointed out, if the raw pixel range is greater than this then the values are scaled and BZERO is included in the FITS header. So I now understand your logic and agree with you, now to go discuss this with some of the other software companies. Thank you for clarifying this Fabio, excellent work.