Please Add QHY600 Camera Mode to the FITS header

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


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.

Ken, I will answer shortly with a comprehensive explanation. I need to fire up the observatory. Give me about 20 minutes.

Steve Hoffman


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 disagree. QHYCCD Mode setting absolutely affect image processing. If you are a member of CN, I’d be glad to discuss the issue there.


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.


Agreed. But being human I cannot without fail put this information into the FIT file name.

The FIT will never accurate lt reflect the settings needed for calibration without it.

I suspect other camera makers may implement this feature down the road also.



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.


You’re right.

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.

Why not include mode names or numbers in file names? This is far easier and faster than looking up modes in FIT headers.


I’m investigation the feasibility of this… I have spotted a list of what actually might be mode names in the ASCOM contract. Maybe…

1 Like

you, Ken. I have included the screenshot of a FITS header created with another vendors software for informational purposes. I hope it’s helpful.


I have this work done… A few notes:

  • 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”.

I’ll release this today.

1 Like

Thank you Ken.


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.

32-bit: Dropbox - Sequence Generator (32-bit).exe - Simplify your life
64-bit: Dropbox - Sequence Generator (64-bit).exe - Simplify your life

I will test and turn around the results with 4 hours. It is 20:00UTC now.

Thanks Ken!!

Ken I was using the Voyager QHY driver. I changed the Voyager camera driver to ASCOM.QHYCCD driver and the desired setting was not in the FITS header.

Using your x.870 version the desired setting was not in the FITS header.

I want to do some more extensive testing before I give up. I will have an answer within 24 hours.