I know this has been asked for on multiple occasions, but I couldn’t see any reference to it in the latest BETA?
If I have missed it, my apologies, if not - could we please have this?
We have this on our backlog, but it has not been prioritized and currently has no release date. We can have our minds changed, but with respect to an app that is designed to capture data without the continuous presence of a human, its usefulness seems questionable (i.e. it doesn’t seem to provide any meaningful feedback to the user during the capture process). As such, it is continually prioritized beneath other things that do provide assistance with capture. Maybe there is some part of OSC capture we don’t understand? If there is, it seems like this would be a dire problem for mono imagers though.
Couldn’t you could just add it to the file naming code. It’s not like it’s a variable.
Unless your using more than one camera.
Thanks Ken,
I appreciate there is a never ending to-do list and prioritisation is always a challenging task, so I’ll give it a go to change your mind 
I don’t know the inner working of the ASCOM standards, or the drivers that each of the manufacturers provide, so perhaps there is an underlying issue between the two. I see that ASCOM has a Camera.SensorType property that would indicate the matrix - but I assume if the manufacturer does not define this property, then it’s not available to be read anyway?
So, when it comes to processing the OSC FITS files, the software (in my case, Pixinsight) does not know matrix to apply to the debayer process. This leaves me (us) two choices… To manually tell PI which matrix to use, or to modify the headers to include the keyword. Each time. Every time.
On the face of it, these don’t seem like huge tasks - and they’re not - it’s just very annoying when you forget! And while having a the field to enter the matrix in does not provide any feedback to the user, it does save a headache further down the line.
It’s not asking for any validation or processing on this field (well, other than valid text of 0, 4 or 5 characters), and to ignore it if the Camera.SensorType is provided.
The Capture Software value (CREATOR) doesn’t provide any feedback to the user, neither does the CTYPE1 values - but both of those are in the FITS header…
An additional thought:
If the Camera.SensorType property were to be available, would SG Pro read and insert into the FITS header? If that’s the case, then clearly I can take up with manufacturer (ZWO in my case) and get them to include in their ASCOM driver…
Thanks for listening.
@UlteriorModem - that could be done, but that doesn’t help in the processing of the files further down the line.
Oh, wow… I completely misinterpreted the request. Yes, adding bayer patterns to the FITS files is an easy ask and I can add that pretty soon. In the future, it may be good to allow for some number of custom, user defined fields to be defined, but the easiest thing right now is a new single field.
It’s about time. I requested that feature in July 2019 ( Please include FITS keyword BAYERPAT ) …
Bernd
you’re welcome??
Thanks Ken - much appreciated
Daz
This is a non-standard fits file entry… anyone know the “community standard” for the key name (i.e. what do other workflow apps look for during debayer)?
I seem to remember doing lots of searches and came across a thread on CN - FITS keywords BAYERPAT, BAYOFFX, BAYOFFY etc. - Experienced Deep Sky Imaging - Cloudy Nights - which discusses the BAYERPAT, amongst others.
After coming across that I have used BAYERPAT and it has worked perfectly in PI.
1 Like
There is no such standard FITS keyword. HOWEVER, it has developed to a quasi-standard which is supported by (presumably) all serious astro acquisition and processing software. SGP is an exception in this regard, sadly. The creator of PixInsight is very reluctant to support nonstandard FITS keyword which I comprehend, but he understood that it is a pain when frames of an OSC camera in FITS format do not contain the bayer pattern - in contrast to frames of the same OSC camera in the propriatory raw format (e.g. Canon: CR2 or CR3, Nikon: NEF, Sony: ARW, Fujifilm: RAF, Pentax: PEF or Adobe’s DNG format). Before PixInsight supported the FITS keywords that are mentioned in my original request, we got plenty of issues in the PI forum related to the bayer pattern. This is settled now.
Post #9 of the above cited thread lists the keywords in question: BAYERPAT, XBAYROFF, YBAYROFF, ROWORDER
Related links:
BAYERPAT, XBAYROFF, YBAYROFF (SBIG created these keywords, today Diffraction Limited): FITS File Header Definitions
ROWORDER (with specification of software that supports ROWORDER): Siril:FITS orientation - FreeAstro
You can read more about this topic in section 2.1.2 of my guide, Guide to Preprocessing of Raw Data with PixInsight .
Bernd
A first draft of this was released in the latest beta (available now)
Aha, having read the comment to v4.1.0.750, I understand how you misinterpreted my request. No, I never advocated a debayer function in SGP.
That’s great news! Unfortunately I am currently travelling, but I am curious about it and will try the new beta as soon as I am back home. Thank you.
Bernd
I should note that this needs more testing and it will receive it prior to release, but, in general, the request was pretty isolated and only has a very small chance to destabilize the current beta. For instance, I just found an issue where it’s possible that the Bayer pattern “None” might be written to the header (that has been corrected). Let us know if you see anything amiss.
I see the Bayer Pattern in Settings & Specs in V751 but it doesn’t allow entry of other than the drop-down list. I have a Canon DSLR with GBRG. There is a more complete list in PI when selecting the debayer pattern to process. Or just a type-in would also work.
Kent
The area is supposed to be a combined control where you can either type in what you want or select from a list. I’ll take a look.
Thank you for the update Ken - apologies, have been offline for a while, so not had a chance to play and test!
I will be onto that in the next couple of days - but many thanks again!!
1 Like