Please Add QHY600 Camera Mode camera mode added to the FITS header.
Other software has added it (V). The Modes are…
Photographic Mode
High Gain Mode
Super Fullwell Mode
Extend Fullwell 2CMS
The Four Modes are Selectable in a DropDown List (ReadMode) in the ASCOM QHYCCD Camera
Driver.
It is not clear to me how to add that. The only Mode we have access to is a list of numbers from ASCOM. SGPro does not have any way to correlate those numbers to the names QHY has chosen for them in the driver. As I mentioned in the other post, we can add the number to the FITs header.
What value is provided by having this info in the FITS header? FITS header entries are intended to provide image processing software with information about the image that could affect how the image is processed. None of these new headers provide that type of information. If this is information you would like to have available, consider creating your own “code” (“PH”, ‘HGM’, etc) that you insert into the file name pattern so you can see it at a later date.
I understand the wish for documenting readout mode in the FITS header. In preprocessing, it is essential to use matching calibration files. So this value can be compared, and an error message can be generated in case of discrepance (similar as for gain and offset).
It may very well be true that you would need to adjust your image processing work flow based on those parameters. However, no image processing software will read those entries from the FITS header and automatically adjust how it processes the images.
Just to clarify – the camera does not produce the FITS image. The camera only provides the imaging application with an array of pixel values. It is the imaging application that must convert that pixel array into the final image. AFAIK all current astronomy imaging apps build FITS formatted image files but an imaging app could produce a JPEG or a TIFF or any image format it wanted to. When the imaging app adds the FITS header data to the pixel array values, the FITS header can only contain information the imaging app has access to. The QHY600 parameters you referenced are not a part of the ASCOM standard camera interface.
Yes even just the mode number would be helpful. I too run into this problem of going through my data and having no way at all to tell what mode was used, which is critical to be able to match up with correct calibration frames. Gain and Offset would also be very appreciated to get into the fits as well.
Just an aside… I appreciate being respectful to SGPro as a product on its own forum, but it’s perfectly fine to mention other products by name here.
For the issue at hand: I ended up adding 2 different headers. I felt that in order to be compliant with the intent of the ASCOM camera contract that both readout mode (READOUTM) and the notion of “fast readout” (FREADOUT) must be used together (when available). Many cameras support “fast readout” modes as a standalone feature, but ASCOM indicates that fast readout can be used to indicate a sub-mode when used in conjunction with “readout mode”.
An example would be something like:
Readout Mode 0 Supports Fast Readout and, as a result has hybrid read out modes
0-Fast
0-Normal
Readout Mode 1 Does not support Fast readout and provides no hybrid modes.
In terms of FITS headers:
If a camera supports readout modes, SGPro will query for it and attempt to perform a lookup of the corresponding descriptive name. If the lookup fails, it will simply record the integer value.
If a camera supports “fast readout” it will appear in the FITS header. This may or may not be in addition to “readout modes”.
Ken I tested the change and READOUTM = 'Fast ’ was the result and screenshot is pasted below.
However in the FITS file from Voyager the READOUTM = ‘Extend Fullwell 2CMS’ and this is the desired setting (or an Integer value). I changed the camera’s setting to a different ‘Mode’ and tested your change again and the result was the same.
I am at your disposal for testing or contact my phone.
Im really not sure. I have tested with a couple other ASCOM cameras and re-reviewed the new bits of code and everything looks correct.
Are you using the ASCOM driver in Voyager or maybe the Native driver?
In any case, for a bit of clarity here is a test build that will dump the available readout modes to the logs on connect (and also the readout mode of the camera on connect). In addition, during the writing of each frame, the logs will contain the integer value of the current readout mode from the camera. Ideally you could use that value to lookup the descriptive value in the readout mode list. Hopefully it will help locate the breakdown.