×

INDI Library v2.0.7 is Released (01 Apr 2024)

Bi-monthly release with minor bug fixes and improvements

Issue with fits header and image trains, I think

  • Posts: 643
  • Thank you received: 62
Hi!

Slightly marginal to the main issue here - but I do not get the CRVAL keywords. Here's a fits header from a spectroscopy image from the day before yesterday:

SIMPLE = T / file does conform to FITS standard
BITPIX = 16 / number of bits per data pixel
NAXIS = 2 / number of data axes
NAXIS1 = 5544 / length of data axis 1
NAXIS2 = 1000 / 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
ROWORDER= 'TOP-DOWN' / Row Order
INSTRUME= 'QHY CCD QHY183M-9b51164' / CCD Name
TELESCOP= 'Losmandy Gemini' / Telescope name
OBSERVER= 'Unknown ' / Observer name
OBJECT = 'S UMa ' / Object name
EXPTIME = 9.000000E+02 / Total Exposure Time (s)
CCD-TEMP= -1.060E+01 / CCD Temperature (Celsius)
PIXSIZE1= 2.400000E+00 / Pixel Size 1 (microns)
PIXSIZE2= 2.400000E+00 / Pixel Size 2 (microns)
XBINNING= 1 / Binning factor in width
YBINNING= 1 / Binning factor in height
XPIXSZ = 2.400000E+00 / X binned pixel size in microns
YPIXSZ = 2.400000E+00 / Y binned pixel size in microns
FRAME = 'Light ' / Frame Type
IMAGETYP= 'Light Frame' / Frame Type
FOCALLEN= 2.000E+03 / Focal Length (mm)
APTDIA = 2.000E+02 / Telescope diameter (mm)
FOCUSPOS= 545 / Focus position in steps
FOCUSTEM= 2.000E+01 / Focuser temperature in degrees C
SCALE = 2.475600E-01 / arcsecs per pixel
SITELAT = 5.554806E+01 / Latitude of the imaging site in degrees
SITELONG= 1.336472E+01 / Longitude of the imaging site in degrees
AIRMASS = 1.104260E+00 / Airmass
OBJCTAZ = 5.775624E+01 / Azimuth of center of image in Degrees
OBJCTALT= 6.488416E+01 / Altitude of center of image in Degrees
OBJCTRA = '12 44 01.98' / Object J2000 RA in Hours
OBJCTDEC= '61 08 45.22' / Object J2000 DEC in Degrees
RA = 1.910082E+02 / Object J2000 RA in Degrees
DEC = 6.114589E+01 / Object J2000 DEC in Degrees
PIERSIDE= 'WEST ' / West, looking East
EQUINOX = 2000 / Equinox
DATE-OBS= '2023-04-01T19:45:43.205' / UTC start date of observation
COMMENT Generated by INDI
GAIN = 1.000E+01 / Gain
OFFSET = 2.000E+01 / Offset
END
1 year 4 weeks ago #91712

Please Log in or Create an account to join the conversation.

  • Posts: 126
  • Thank you received: 2
Jasem,

Just ran a quick test. The CGX is in the Snoop line. Took an image with a real CMOS and the FITS header was missing lots of data.
Modified the equipment list to substitute a Tel Sim. The Tel Sim was in the Snoop line. Same camera. FITS header now has the missing data.

As I posted earlier this was working in Jan 2023 using the same equipment I'm using now, i.e., same mount, same camera.

I hope to take some pictures in the next couple of nights where I do some plate solving to see if that has any effect.

Your analysis was a good one. I would have been very pleased if that solved the problem.

Thanks,
Bob
1 year 4 weeks ago #91714

Please Log in or Create an account to join the conversation.

  • Posts: 126
  • Thank you received: 2
Jasem,

Just ran another quick test to verify earlier findings. If I connect directly from my control room to equipment in the dome, bypassing SM, then the FITS headers are good using CGX mount and ZWO CMOS.

Bob
1 year 4 weeks ago #91715

Please Log in or Create an account to join the conversation.

+ Client: KStars on PC
+ Server: INDI Web Manager running CGX + ZWO on StellarMate

So you have a remote profile on PC and connecting remotely to StellarMate using these setting above, correct?
1 year 4 weeks ago #91716

Please Log in or Create an account to join the conversation.

  • Posts: 126
  • Thank you received: 2
Correct.

Running kubuntu on PC with Kstars/Ekos in control room.
Connect to SM in dome via Cat5.
SM connects to telescope, camera, dome, focuser, filter wheel.
1 year 4 weeks ago #91717

Please Log in or Create an account to join the conversation.

  • Posts: 126
  • Thank you received: 2
BLUF - Good FITS header seems to be assured if telescope dimensions inserted in mount option page.

I hope you can make sense of all this.

Before I begin, let's define a "good header" where we get site location, RA/Dec of object, correct focal length (adjusted for any Barlow / FR) etc and the all important comment near the end that says "generated by INDI." Bad headers don't have this.

When last we spoke, I could not get a good header when simply slewing to an object and taking data with the primary camera. Currently, my primary camera is attached to a spectrometer. An SX Lodestar is embedded in the spectrometer and is my guider. Went out last night to take some "real" data and see what I could determine. I slew to Dubhe and, lo and behold, the header from the main camera is good. I have no idea why things are now working. I changed profile to track with PHD2 to do some spectroscopy work and the headers were bad as had happened before. The unpleasant surprise was when I changed profile again to use the internal Ekos tracker and headers from the main camera were once again bad.

I still don't know why this happens. I noticed last night that, when I looked at the Lodestar Options page, it has the scope parameters corrected for the FR and the Scope green light is on. That same page on the primary (ZWO) camera is all zeros and no green light. I went out this morning for some more troubleshooting and main camera headers were still bad. The scope parameters in the FITS header (diameter and FL) were zero.

At this point I'm just throwing stuff at the wall (spitballing we call it -- don't know how that translates into other languages). In the Mount options page there are fields where one can set the scope parameters (diam and FL) for the main and guide cameras. At the moment they were zero. So I inserted the correct numbers, took a picture with the main camera, and now the header was good. The scope parameters in the header reflected what I had inserted in the Mount options page. It wasn't just the scope parameters, it was the Az/El, RA/Dec, "generated by INDI" -- all those things in a good header. If I changed a number in the Mount options page, that number was immediately reflected in the FITS header. However, the scope parameters in the main camera options page were still zero; no green light. And the Lodestar options page saw no change to its scope values. I went to the image chain page and changed the FR value for both the main and guide camera. The option page for the Lodestar reflected that change immediately as did the scope values in the guide FITS header.

So, at the moment, the main camera seems to be getting its scope parameters from the mount options page. The guide camera (Lodestar) is getting its scope parameters from the secondary image chain. In order to get the correct, adjusted for FR number for the main camera, define a second configuration in the scope options page with the FR effect included.

But wait, there's more. I went playing with the simulators and things are reversed. The main camera Options page shows the scope parameters as defined in the image chain with a green light. The sim guide camera shows zero values for scope parameters.
1 year 3 weeks ago #91879

Please Log in or Create an account to join the conversation.

  • Posts: 126
  • Thank you received: 2
The good news is that, once you correctly populate the scope parameters in the Mount Options page, tracking done using PHD2 now has good FITS headers.

So, I think I'm done with this topic in that I'm getting everything I can expect. There is still the quandary as to why my primary camera gets it scope parameters from the Mount Options page while my secondary, pointing camera get its info from the image train, while tests using simulators show the exact opposite.
1 year 3 weeks ago #91933

Please Log in or Create an account to join the conversation.

Those fields in Mount Ekos module were already removed in KStars... if you're using KStars 3.6.4 or even 3.6.3 they shouldn't be there, they're set by the optical train system.

1 year 3 weeks ago #91936
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 126
  • Thank you received: 2
Jasem,

I was referring to the options page in the INDI Control Panel. (Control Panel / Telescope / Options)

Bob
1 year 3 weeks ago #91979

Please Log in or Create an account to join the conversation.

  • Posts: 643
  • Thank you received: 62
Hi!

I'm reconnecting to this with reference to the keywords CRVAL. Robert, in one of your posted FITS-headers, these keywords are present. Not in the others. I do NOT get these keywords (I'd would have been nice though). How come they are in one of your headers? Do you still get them?

How about the rest of you - anyone getting these keywords? I did not think they were added at all by EKOS.

Magnus
1 year 1 week ago #92305

Please Log in or Create an account to join the conversation.

  • Posts: 126
  • Thank you received: 2
Magnus,

I saw your post last night while I was taking some spec data. I use a Lodestar as my guiding camera while my primary camera is gathering spectra. I was pointing at rather bright objects so I had not done a plate solve. When I took a picture with the Lodestar and looked at the FITS header, the header had the usual items you would expect, but no CRVAL, etc.

So I did a plate solve and then took another pic with the Lodestar. Now I had all kinds of stuff as you can see below.

CRVAL1 = 326.69596952 / CRVAL1
CRVAL2 = 49.319472474 / CRVAL2
RADECSYS= 'FK5 ' / RADECSYS
CTYPE1 = 'RA---TAN' / CTYPE1
CTYPE2 = 'DEC--TAN' / CTYPE2
CRPIX1 = 188. / CRPIX1
CRPIX2 = 145. / CRPIX2
SECPIX1 = 2.0837599675 / SECPIX1
SECPIX2 = 2.011334871 / SECPIX2
CDELT1 = 0.00057882221321 / CDELT1
CDELT2 = 0.00055870413083 / CDELT2
CROTA1 = 9.3594641181 / CROTA1
CROTA2 = 9.3594641181 / CROTA2

Probably you and I would both like to see that data in our primary camera header when doing spec work but that's not likely to happen. When I go back to doing variable star work where my primary (ZWO) camera does plate solving, I'm expecting to see these kinds of details.

I see you have a Star'Ex. Did you build that using 3D printing? I've looked at the instructions on how to do it but I've never done 3D printing and I figure this is something I could really botch.
1 year 1 week ago #92319

Please Log in or Create an account to join the conversation.

  • Posts: 643
  • Thank you received: 62
Hi!

Yes, it would be very good if the CRVAL keyword where in the fits header - for example, SpecINTI relies on this for computing atmospheric extinction.

I was surprised to see it in your header, because I was under the impression that Ekos did not produce it at all. Now, looking through my own photometric images, I do find it there too. But not in my spectra. For photometry, the main camera does the platesolve, for spectroscopy, I have a separate "positioning guide scope" doing it - in its own imaging train. So I do not use the guider for platesolve, never worked for me due to small FOV with my C8 and C11.

What version of Kstars do you run? I'm using 3.6.4 stable on Stellarmate.

Concerning the StarEx: I have indeed printed it myself, and also the Lowspec that I use (first bought one second hand but decided I wanted to print it myself). After beginning with 3D-printing I actually no longer understand how to do amateur astronomy without a printer :) jokes aside, it takes some time to acquire skill sufficient to print a good spectrograph but it is not very difficult. But if you don't want to print, there are commercial sources that can print for you. Or maybe some other amateur - ask on the Sol'Ex mailing list :) What kind of spectroscope du you currently use?

Magnus
1 year 1 week ago #92322

Please Log in or Create an account to join the conversation.

Time to create page: 0.595 seconds