Why can't I stretch this image?

[Linwood]

I am starting to use APPM (Astrophysics Modeling) and it produces a file that I cannot stretch in Pixinsight, as well as providing confusing statistics.

Yet in TSX I can plate solve it, it finds stars, etc (PI platesolve won't work either, says no stars).

The format is unusual, 32 bit integers, but statistics shows floats in PI (e.g. in min/max/median which shouldn't be floats if they are ints in the data).

https://drive.google.com/file/d/1vav403rUKwMJ3NGkTg6kF6uROg6A4JoG/view?usp=sharing

The author of the software said this is a PI issue, not an issue in the file.

Is there someone who understands fits formats that might take a look, see if you understand why it can't do a stretch or find stars in PI? Do I have something set up incorrectly in PI?

The file is from the ASI6200MM Pro with Ascom driver, bin 2, and this is Imagelink (TSX) solution:

******** ASTROMETRIC SOLUTION RESULTS ********
Center RA (2000.0): 01h 24m 47.51s
Center Dec (2000.0): -30° 08' 46.4"
Scale: 2.7840 arcseconds/pixel
Size (pixels): 1597 x 2394
Angular Size: 1° 14' 06" x 1° 51' 05"
Position Angle: 59° 00' from north through east
Mirror Image: Yes
RMS: 0.83 (X: 0.67 Y: 0.49)
Number of Stars Used in Solution: 19 (95%)
FWHM: 1.31 pixels, 3.64 arcseconds

Linwood

File: https://drive.google.com/file/d/1vav403rUKwMJ3NGkTg6kF6uROg6A4JoG/view?usp=sharing

 

[oldwexi]

You have saved your image as signed integer.(this adds 0.5 to all pixel values)
Save it as unsigned and it will work. See attached image.
However, this image can be easily solved and annotated with PI. As the sign creates a leading 1 in the data
you only need to subtract with PixelMath 0.5 (thats the leading bit) from the image and you are ready.
The Tycho stars and the galaxyare nicely labeled
Gerald

 

[Linwood]

Note I didn't save it at all, this is data I'm getting from APPM and the author says the data is valid. I guess what I am asking is whether the image is indeed valid, or if the failure (without math/change) to interpret it is an issue in PI?

Is there a standard that indicates objectively if this is right or wrong?

 

[oldwexi]

I am not the person to find out who is right and who is wrong - or both right ... in this case.
I am for a solution which i delivered.

Looking at the image statistics, it says minimum 0.5000002679 and maximum 0.5000069380 !
Thats typical for saving the image in signed integer. In Astroart for example you can select
save the image signed or unsigned. So i assume the guy from APPM could save with his SW unsigned also and you have less troubles.
And you can solve anyhow in PI without troubles as i did.
By the way why do you use this APPM? What can it do what PI cannot do?
Gerald

 

[Linwood]

Thank you. Yes, I asked the question badly. I didn't really need to process it, I wanted to understand if it was right or not, specifically the headers.

APPM is a pointer model builder for mount control. I was trying to use it and couldn't plate solve (now in retrospect probably for some other reason) so wanted to look at the images. PI is the easiest, grabbed one -- all grey, and the min/max's looked like it was basically all one value, and came up as a float (I'm still hazy why that is 0.5000002679 and not something like 2147483648).

This led to a lot of discussion about why the file from APPM looked vastly different from other programs. Then it finally seemed clear the file was valid, but ... different. I'm trying to understand if it is fundamentally broken or not.

It doesn't really matter whether PI can deal with it, the files produced are only passed back and forth to the plate solver to build the model, not post processed. I was using PI because I trusted it as a viewer. Which led me down the wrong path of thinking the file was somehow bogus. plus there's a lot of image content expertise here.

Thanks for helping.

 

[pfile]

PI converts all FITS files from their native format to a 32-bit floating point format and only uses the range [0.0-1.0], so that's why you see 0.5 plus or minus. it does remember what the file is (so if it was an 16-bit integer fits file, you'll see that the file on the desktop is marked as i16, but you still see the values 0.0-1.0. if you were to multiply the values in an i16 file by 65535 you'd get the original number back.

idk why ray is using signed integers but he probably had a good reason...

rob

 

[Linwood]

Should the FITS header have something different in BZERO maybe? Like 2147483648 to indicate it's signed and zero is half way?