[Solved] Fits header after importing into Astropixel is inaccurate

@gmillerok1 I have an ASI6200MM (mono, like you. There also is a color version.) as well. The FITS header of the images gets written by the software, not by the camera. So, what software do you shoot with? I use ASIAir and the FITS header of one of my recent lights looks like this:

You can see that in my case GAIN is set to 100. Can you open one of those lights in your screenshot in APP by double clicking the file and take a screenshot of the FITS header as APP shows it? Thanks!

SkyXPro is used to obtain the images. The header is correct in the fits file-just not Astropixel. I don't know where that disconnect is coming from.

The fits headers for L frames and color filter frame is not the same with the last lines in both as follows:

LFrame:

OFFSET = 1 / camera offset
GAINRAW = 100 / Your gain value (integer)
HIERARCH Bandwidth setting = 60 / Your gain value (integer)
GAINADU = 0.246657639741898 / e/ADU
OBJECT = 'M31 '
RA = '00 41 52.3'
DEC = '+41 18 45'

RedFrame

OFFSET = 1 / camera offset
GAINRAW = 50 / Your gain value (integer)
HIERARCH Bandwidth setting = 60 / Your gain value (integer)
GAINADU = 0.438626199960709 / e/ADU
OBJECT = 'M31 '
GAIN = 1
RA = '00 42 06.04'
DEC = '+41 23 06.0'

Note that "GainRaw" is correct in both, but the L frame has no"GAIN" line, and the Red filtered header has a "GAIN" line. So Astropixel reads the L frame as 0 and the Red filtered frame as 1. This is true for the RGB/HA frames as well.

It would appear Astropixel is not reading "GAINRAW" correctly, but picking up the "GAIN" line where it exists, and 0 where it does not. Obviously, this is not something I can resolve. I've emailed support but have not heard anything back. I should have run the trial version thorougly before I made this purchase. I wonder if they give refunds if this cannot be fixed?

@gmillerok1 Let me contact Mabula and ask him about this. Please give me a day or so to obtain an answer. 

Thank you!/Gerald

Hi Gerald @gmillerok1,

Thank you very much for sharing this issue.

First of all, I can easily fix this and add GAINRAW to tags in the header that needs to be used... but clearly the GAINRAW tag is not in the FITS specification and it is likely that your capture software is the only one that is using it. So the problem is created by your capture software doing things outside of FITS specification to start with.

It would appear Astropixel is not reading "GAINRAW" correctly, but picking up the "GAIN" line where it exists, and 0 where it does not. Obviously, this is not something I can resolve.

Indeed, the current version does not "know" GAINRAW since it is not in the specification and we never encountered it. We read GAIN and EGAIN if available.

To support your capture software and use GAINRAW as GAIN i need 1 FITS frame so I can implement it correctly. I need to know if there is a tag that indicates the software that created the FITS file like SWCREATE.

Do you know what GAIN then means in your files if we are supposed to use GAINRAW as GAIN? It is really messy I think, but we can solve it, no doubt 😉

Can you upload 1 FITS file with the GAINRAW tag in there?

https://upload.astropixelprocessor.com/

username and password: upload

Please make a folder with your name and issue like: Gerald-GAINRAW so I can find it easily and let me know once uploaded.

Thank you so much-as you don't know how much I want Astropixel to work! I download to files to the "Gerald" folder. One is the L frame and the other a filtered Red frame as the two headers match the header example above. Having the code look for "GAIN" would fix the issue if that term is found rather than "GAINRAW" (or for the string "GAIN***). I am sure "GAINRAW" equals "GAIN" as used in Astropixel.

I do appreciate this fix more than you can imagine.

Gerald

If possible, also mention this to the creators of the capture software. They may also change it to the specification.

I reported it to ZWO who wrote the driver that The SkyXPro uses. I am fairly certain Bisque did not provide or was responsible for the issue but I will followup with them as well.

Hi Gerald,

I have fixed it:

https://www.astropixelprocessor.com/community/release-information/astro-pixel-processor-1-083-2-preparing-release/

"IMPROVED, FITS HEADER, APP will now use the GAINRAW tag to find the GAIN for images shot with TheSKy."

I will try to release this new version with the fix within the next couple of days.

Mabula

Thanks so much! I did post this issue on the Bisque SkyXPro support forum and they may at some point may correct it. If they do and it then fails again, I will let you know. I also contacted ZWO and they are looking into it but believe it is a SkyXPro issue to deal with.

I look very forward using APP. It was able to fix a severe gradient that PI couldn't do. Then the easy click to create HaLRGB was amazing. Thank you so much for the hard work I know you put into this application-it is now my default image processing software from now on. I wish I had known about it sooner!

Thanks again for the fix!

Gerald

 I took images with my ZWO ASI620 with SkyXPro using both ASCOM and the X2 ZWO driver, ASI Studio with it's native driver, MaximDL with the ASCOM driver, and Sharpcap with whatever driver it uses. Each was completely different.

Your feedback has been received by our support team.

TJ Connolly 2022-01-26 11:49 Hi Gerald,  I am passing this along to our software/tech team, in case this is a fits header error on our part.  I believe it is an error with the image capture software though as our headers are accurate with other software.  Another test you can do is, use our free ASIStudios-ASIImg (Free Software) https://astronomy-imaging-camera.com/software-drivers     to capture an image and check the FITS Header.  Please let me know what you find out, and I will keep you in the loop on this as well.  Clear Skies, TJ Connolly Customer Support – Overseas – USA ZWO Astronomy Cameras Homepage :  https://astronomy-imaging-camera.com/ Facebook : User Forum:  https://bbs.astronomy-imaging-camera.com/ ----------------------------------------------------------------- I'm trying to use Astropixel to process images made with my ZWO ASI6200. The last lines in the fits header is as follows: OFFSET = 1 / camera offset GAINRAW = 100 / Your gain value (integer) HIERARCH Bandwidth setting = 60 / Your gain value (integer) GAINADU = 0.246657639741898 / e/ADU OBJECT = 'M31 ' RA = '00 41 52.3' DEC = '+41 18 45' +++ The last lines in frames using a filter is as follows: OFFSET = 1 / camera offset GAINRAW = 50 / Your gain value (integer) HIERARCH Bandwidth setting = 60 / Your gain value (integer) GAINADU = 0.438626199960709 / e/ADU OBJECT = 'M31 ' GAIN = 1 RA = '00 42 06.04' DEC = '+41 23 06.0' ++ Note there are two lines for gain in the filtered frame. GAINRAW and GAIN. In the Luminence frame there is no GAIN line at all. Astropixel is reading these lines and if it does have GAIN it reports gain as 0, and if it finds "GAIN" it reports whatever it is (in the above case, 1). It does not report "GAINRAW" at all. It is not possible to calibrate these files with incorrect fits headers. Please advise how I can use this camera and your driver with this issue. Thank you. Gerald ----------------------------------------------------------------- Hi Gerald, What image capture software are you using? We tested with Astro Pixel Processor, and I personally use Astro Pixel Processor, and do not get an error. If you tell me more about the image capture method and driver used, I will pass this along to our software and tech team to look into, and I will see if there is a fix for the issue. I would also recommend contacting MabulaHaverkamp and asking him about the software and if he has a solution while we look into this. He may know of a quick solution. Clear Skies, TJ Connolly -----------------------------------------------------------------   Thank you for your response. I use SkyXPro exclusively for image capture. I posted the same question on their support site as well as yours. I was not sure who it is that needs to fix this but it sounds like Bisque. The driver I use is the one installed by the ZWO software application.   Mabula is looking into it already. He was the one who suggested I contact both you and Bisque for resolution.   Thank you again for your prompt response to this issue.   Gerald

It may not be the driver at all. I have convinced at least myself it is the capture program that writes the FITS header file.

The reason I suspect it is not is because comparing the identical ASCOM ZWO driver used with the SkyXPro with the FITS header created with MaximDL, if the driver was the issue, both would be identical (one would think).

Yet, they clearly are not. Does this not indicate that it is indeed the capture program creating it when it is saved (which would make sense).

Compare this:

SkyXPro with ASCOM:

ASCOM 1 /SkyXPro

SIMPLE = T / file does conform to FITS standard
BITPIX = 16 / number of bits per data pixel
NAXIS = 2 / number of data axes
NAXIS1 = 9576 / length of data axis 1
NAXIS2 = 6388 / length of data axis 2
EXTEND = T / FITS dataset may contain extensions
COMMENT FITS (Flexible Image Transport System) format is defined in ‘Astronomy
COMMENT and Astrophysics’, volume 376, page 359; bibcode: 2001A&A…376..359H
BZERO = 32768 / offset data range to that of unsigned short
BSCALE = 1 / default scaling factor
TELESCOP= ‘ZWO ‘ / SBIGFITSEXT The model Telescope
SBUUID = ‘{0964582e-c03c-4b50-9c81-58fe6dd1b1ea}’ / Photo UUID
EXPTIME = 3. / SBIGFITSEXT Total exposure time in seconds
SWCREATE= ‘TheSky Version 10.5.0 Build 13210 (64 bit)’ / SBIGFITSEXT Name & vers
COLORCCD= 0 / Non zero if image is from a Bayer color ccd
DISPINCR= 1 / Non zero to automatically display the image in
PICTTYPE= 1 / Image type as index 0= Unknown 1=Light, 2=Bias,
IMAGETYP= ‘Light Frame’ / SBIGFITSEXT Light, Dark, Bias or Flat
XORGSUBF= 0 / SBIGFITSEXT Subframe x upper-left pixel in bin
YORGSUBF= 0 / SBIGFITSEXT Subframe y upper-left pixel in bin
XBINNING= 1 / SBIGFITSEXT Binning factor in width
YBINNING= 1 / SBIGFITSEXT Binning factor in height
CCD-TEMP= 9.4 / SBIGFITSEXT Temperature of the CCD
SITELAT = ‘+35 46 13.50’ / SBIGFITSEXT Latitude of the imaging location
SITELONG= ‘+95 26 26.29’ / SBIGFITSEXT Longitude of the imaging location
LST = ‘+21 10 43.44’ / Local sidereal time
OBSGEO-B= 35.770416 / Latitude of the observation in degrees, North +
OBSGEO-L= -95.440637 / Longitude of the observation in degrees, East +
OBSGEO-H= 220. / Altitude of the observation in meters
INSTRUME= ‘ASCOM Camera’ / SBIGFITSEXT The model camera used.
XPIXSZ = 3.76 / SBIGFITSEXT Pixel width in microns after binnin
YPIXSZ = 3.76 / SBIGFITSEXT Pixel height in microns after binni
READOUTM= ‘Long Exposure Mode’ / Image readout mode
CDS = ‘Long Exposure Mode’ / Camera dependent setting
FOCPOS = 9491. / The focuser position.
FOCTEMP = 0. / The focuser temperature in degrees C.
FOCTMPSC= ‘Focuser (Default)’ / The focuser temperature source.
FILTER = ‘Red ‘ / SBIGFITSEXT The optical filter used to take ima
DATE-OBS= ‘2022-01-26T19:08:16.492’ / SBIGFITSEXT UTC of start exp. in ISO 8601
LOCALTIM= ‘1/26/2022 01:08:16.489 PM STD’ / Local time at exposure start

—-

to THIS:

MaximDL (using ASCOM Driver)

Black level
0.00000
40.3367
White level
0.00
100
200
300
400
500
600
700
800
900
1.00k
Current Point Data
Image 1, Plane 1
X
0px
Y
705px
Value
0
Width 4788px
Height 3194px
Image Statistics
Min 0 Mean 8.65397
Max 13459 Stdev 8.92648
Scaling (Dynamic Range)
Background level
0
Peak level
40.3367
Scaled peak level
10
Exponent
1

Auto Apply
SIMPLE = T
BITPIX = 16 /8 unsigned int, 16 & 32 int, -32 & -64 real
NAXIS = 2 /number of axes
NAXIS1 = 4788 /fastest changing axis
NAXIS2 = 3194 /next to fastest changing axis
BSCALE = 1.0000000000000000 /physical = BZERO + BSCALE*array_value
BZERO = 32768.000000000000 /physical = BZERO + BSCALE*array_value
DATE-OBS= ‘2022-01-26T19:37:09’ /YYYY-MM-DDThh:mm:ss observation start, UT
EXPTIME = 1.0000000000000000 /Exposure time in seconds
EXPOSURE= 1.0000000000000000 /Exposure time in seconds
CCD-TEMP= 16.100000000000001 /CCD temperature at start of exposure in C
XPIXSZ = 7.5199999999999996 /Pixel Width in microns (after binning)
YPIXSZ = 7.5199999999999996 /Pixel Height in microns (after binning)
XBINNING= 2 /Binning factor in width
YBINNING= 2 /Binning factor in height
XORGSUBF= 0 /Subframe X position in binned pixels
YORGSUBF= 0 /Subframe Y position in binned pixels
FILTER = ‘Red ‘ / Filter used when taking image
IMAGETYP= ‘Light Frame’ / Type of image
SITELAT = ’00 00 00′ / Latitude of the imaging location
SITELONG= ’00 00 00′ / Longitude of the imaging location
JD = 2459606.3174652779 /Julian Date at start of exposure
FOCALLEN= 1587.0000000000000 /Focal length of telescope in mm
APTDIA = 127.00000000000000 /Aperture diameter of telescope in mm
APTAREA = 8835.7119126386933 /Aperture area of telescope in mm^2
EGAIN = 0.43862619996070862 /Electronic gain in e-/ADU
SWCREATE= ‘MaxIm DL Version 5.24 130627 0V1R2’ /Name of software that created
the image
SBSTDVER= ‘SBFITSEXT Version 1.0’ /Version of SBFITSEXT standard in effect
OBJECT = ‘Autosave Image’
TELESCOP= ‘ ‘ / telescope used to acquire this image
INSTRUME= ‘ASI Camera (1)’
OBSERVER= ‘ ‘
NOTES = ‘ ‘
FLIPSTAT= ‘ ‘
SWOWNER = ‘Gerald R Miller’ / Licensed owner of software

—

These clearly are NOT the same. And if the drivers were responsible they would be.

Correct?

Gerald

@gmillerok1 Correct. The driver doesn't create the FITS header as has been pointed out to you on the ZWO forum as well 🙂 The capture software does.

@wvreeven Tom Bisque thought otherwise. I have posted my findings there as well. At least this proves it. What is interesting is how every application was completely different. So much for standards.

Posted by: @gmillerok1

@wvreeven Tom Bisque thought otherwise. I have posted my findings there as well. At least this proves it. What is interesting is how every application was completely different. So much for standards.

 

@gmillerok1, clearly it is a bit of a mess between the different applications used.. 🙄 but my fix ensures that if that GAINRAW tag is there... it will be used for the GAIN value. Otherwise, APP will behave as normal and according to standards so I think we are good for now 😉

Apparently, it is a lot more complicated that one can imagine, and it may be dependent on the driver AND the capture and how they work together. With hundreds of drivers and countless applications it is truly a wonder it works at all.

Thanks for quickly resolving this issue, Mabula. I look forward to learning your application and it using for many years to come.

Gerald

Hi Gerald,

Can you try with 1.083.2 if all is okay now? Downloads are at the top of the forum 😉

Mabula

Yes, the GAIN setting now is displayed correctly with the proper gain setting in the image frames loaded at the bottom of the screen in APP. I will test further with calibration and that will take some time and I will confirm that as well after I'm done-but since the value is correct for gain I imagine it will work as well.

Again, thank you so much for resolving this issue so I can use APP for my processing needs.

Gerald

Mabula, I wish to confirm calibration now worked correctly. Thanks again. I still have a lot to learn and look forward to doing so. APP makes imaging fun again rather than work using what I've used in the past.

Gerald

Excellent Gerald @gmillerok1, you are most welcome 🙂 !