XML Keys

R

rumen

Member
Hello everybody,
I am one of the core developers of INDIGO framework and I am adding XISF support in Ain INDIGO Imager and Ain Viewer, but I see some things that look a bit strange to me and decided to ask :)
So:
1. Bayer pattern filters:
The documentation says it is stored in "ColorFilterArray" node like this:

<ColorFilterArray pattern="GRBG" width="2" height="2" name="GRBG Bayer Filter" />

However Pixinsight stores it in "Property" node with attribute id="PCL:CFASourcePattern" like this:

<Property id="PCL:CFASourcePattern" type="String">RGGB</Property>

on the other hand when XISF is a converted FITS, the CFA is not copied to either of these nodes but is only stored as "FITSKeyword":

<FITSKeyword name="BAYERPAT" value="'GRBG '" comment="Bayer color pattern"/>

So I am a bit confused why there are (at least) three sources to look for to figure out the CFA.

2. When the image is Debayered and stored as RGB image the "PCL:CFASourcePattern" is still present. Why is it preserved as it is irrelevant once debayered? Not of a big deal because I check if the image color space is "Gray" and has the CFA set and only then debayer it but still this information is irrelevant for color spaces other than "Gray".

3. Sometimes the value is stored as a a node content like:
<Property id="PCL:CFASourcePattern" type="String">RGGB</Property>
or
<Property id="Instrument:Camera:Name" type="String">ASI 2600 MM</Property>

and in other cases as a node attribute:
<Property id="Instrument:Telescope:FocalLength" type="Float32" value="0.024"/>
or
<ColorFilterArray pattern="GRBG" width="2" height="2" name="GRBG Bayer Filter" />

There are many examples for this, but the most confusing part being "Property" node, sometimes the value is the node content and other one of the node attributes.

Can you guys shed some light on the topic?
Thank you!
 
Oh and one more thing:
"Instrument:Camera:Name", "Instrument:Telescope:FocalLength", "Instrument:Sensor:Temperature" look like a second tree with root "Instrument" embedded in the XML tree. Is there any reason for not making "Instrument" a branch of "Image" or it is not intended to be an embedded tree?

Do not get me wrong I am asking because I want to organize my code better :) now it seems to work but not well structured because I do not see the big picture.
 
@Juan Conejero please could you comment on extraction of the CFA pattern? I'm also writing some software to parse XISF files, and the variant I've seen most commonly is the "PCL:CFASourcePattern" method of describing the pattern that @rumen describes above (and with nothing else in the XISF).

However I've also read elsewhere on the forum that you say values in the PCL namespace shouldn't be relied on and may be subject to change. Is there a definitive list of things that should be checked when reading a XISF file to make sure any CFA pattern in the file is found? It seems like a pretty basic thing to want to know about a file.
 
The ColorFilterArray core XISF element should be generated by encoders storing mosaiced raw data directly in XISF format, such as image acquisition applications. Our XISF implementation supports this element, and there is a corresponding dedicated PCL class, although our standard preprocessing pipelines still don't use it because, as far as I know, acquisition software has never implemented it. This will change soon in one of the next versions of PixInsight to provide a more complete reference XISF implementation.

Our RAW format support module generates the following image properties:

PCL:CFASourcePattern
PCL:RawCFASourcePattern
PCL:CFASourcePatternName
PCL:sRGBConversionMatrix

These properties are generated to support our standard preprocessing pipeline. We use the PCL namespace because these are private properties not intended to be used by third-party software. Our RAW module loads and decodes proprietary digital camera formats using the LibRAW library. In other words, we don't acquire the raw CFA data we are storing in XISF format, so we can opt for a private set of image properties tightly adapted to our specific needs within our implementation. This is not a violation of the XISF specification in any way, but again, we'll write standard ColorFilterArray properties, along with our private ones, in the next version of our RAW module (and will remove them in the Debayer module).
 
Please see the official announcement of PixInsight's latest build, 1604, which solves this problem. The ColorFilterArray XISF element is now supported by the PixInsight core application and is fully compatible with our standard image preprocessing pipelines.

Note, however, that we are not generating ColorFilterArray elements. This is because these elements must only be generated by raw data providers, such as image acquisition applications, not by image processing applications, where CFA data is only used internally to generate preprocessed (and hence demosaiced) image data. This will be clarified in the next XISF specification.
 
You must log in or register to reply here.
Back
Top