Re: APPM with ASI6200 and TSX Imagelink - bogus image data


Ray Gralak
 

Ø  But… why the rather unusual, 32 bit format?

 

ASCOM Camera drivers return a two-dimensional array of 32-bit integer values. Although I don’t think any cameras exceed 16-bit values, that doesn’t mean no future camera ever will.

 

So, I hope this leads you to conclude that APPM’s ASCOM camera client works and does not set all the values in your images to 32767?

 

-Ray

 

From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of ap@...
Sent: Monday, August 2, 2021 12:56 PM
To: main@ap-gto.groups.io; Bratton, Ray (ray@...)
Subject: Re: [ap-gto] APPM with ASI6200 and TSX Imagelink - bogus image data

 

@Ray Gralak:

 

  • I think your analysis is bad. If I load the image into CCDStack the image obviously is not all one level.
  • Here’s a screenshot:

 

The screen shot resolution got munged by Google, I assume it shows SolveNow-2021-08-02-140042.fit.  I don’t have access to that program, but I think I now understand some things better. Thanks.

 

The file from APPM has some differences in FITS headers that are confusing, for example it shows the data as BITPIX 32 and oddly has flipped orientation (landscape to portrait).  The latter should not be an issue, but the former and BZERO set to 0 may be, since the same ASCOM camera on TSX shows BITPIX 16, BZERO 32768.

 

Now those settings may be proper for whatever was done to the data, but I think something in there confuses pixinsight.  Fits Liberator does show statistics (see below). So the interpretation may be a Pixinsight issue.

 

Though it does beg the question: Is there a reason you choose to store 16 bit DN’s in 32 bit format?   (That’s obviously not a driver thing since it’s the same driver).  Is that contributing to the file size issues?

 

I did go back to a file that to me looks wrong, but should have been a real image of some part of the sky as I closed down the first night.  To me in Pixinsight it is not visible, but I tried a all sky, no-scale, plate solve in TSX and it worked.  It did not work that night from APPM, but maybe I had something wrong in the plate solve page. Regardless, whatever format difference is present, Imagelink seems to accept it, so my failure to solve may originate from settings I had wrong.  So I need to try again with real nighttime.  If anyone is curious I attached it (but at 15mb not sure it will make it through).

 

I’ll inquire at Pixinsight why it can’t preview stretch that image.  Or solve it – I tried the same plate solve there and it said “no stars found”.  So it really isn’t reading it correctly.

 

But… why the rather unusual, 32 bit format?

 

Linwood

 

 

Join main@ap-gto.groups.io to automatically receive all group messages.