<div dir="ltr"><div><div>Hi Mark, <br><br></div>I can't help but wonder why the 'nnn' part of 'XXXXXnnn' was not allowed to be a non-negative base-36 number in the first place. Maybe there was some reason, perhaps even voiced at the time this extension type was being defined, but I can't think of what it would be. That would have allowed for 46656 columns, which is obviously still a limitation but less so than what we currently have. Were I to waive a magic wand to fold this idea into the current (4.0 Draft) Standard, I think what would need to change is the definitions of the TFIELDS keyword (non-negative base-36 integer), and the TFORMn keyword (allow for 'n' to be non-sequential but still increasing within the file). Or am I missing something? <br><br></div>-Dick Shaw<br><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 7, 2017 at 9:45 AM, <span dir="ltr"><<a href="mailto:fitsbits-request@listmgr.nrao.edu" target="_blank">fitsbits-request@listmgr.nrao.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send fitsbits mailing list submissions to<br>
<a href="mailto:fitsbits@listmgr.nrao.edu">fitsbits@listmgr.nrao.edu</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://listmgr.nrao.edu/mailman/listinfo/fitsbits" rel="noreferrer" target="_blank">https://listmgr.nrao.edu/<wbr>mailman/listinfo/fitsbits</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:fitsbits-request@listmgr.nrao.edu">fitsbits-request@listmgr.nrao.<wbr>edu</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:fitsbits-owner@listmgr.nrao.edu">fitsbits-owner@listmgr.nrao.<wbr>edu</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of fitsbits digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. BINTABLE convention for >999 columns (Mark Taylor)<br>
2. Re: BINTABLE convention for >999 columns (Rob Seaman)<br>
3. Re: BINTABLE convention for >999 columns (Demitri Muna)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Fri, 7 Jul 2017 12:09:15 +0100 (BST)<br>
From: Mark Taylor <<a href="mailto:M.B.Taylor@bristol.ac.uk">M.B.Taylor@bristol.ac.uk</a>><br>
To: <a href="mailto:fitsbits@listmgr.nrao.edu">fitsbits@listmgr.nrao.edu</a><br>
Subject: [fitsbits] BINTABLE convention for >999 columns<br>
Message-ID:<br>
<<a href="mailto:alpine.LRH.2.20.1707071059380.5525@andromeda.star.bris.ac.uk">alpine.LRH.2.20.<wbr>1707071059380.5525@andromeda.<wbr>star.bris.ac.uk</a>><br>
Content-Type: text/plain; charset=US-ASCII<br>
<br>
Dear fitsbits,<br>
<br>
I am considering a convention for storing table data in FITS files<br>
where the number of columns exceeds the 999 limit implicitly imposed<br>
by the standard BINTABLE extension type. I have running code for<br>
this (available on request) and plan to incorporate it in future<br>
releases of STIL/STILTS/TOPCAT so that people can work with wide<br>
tables in FITS while using those tools. People using software<br>
that is unaware of this convention would still see a legal BINTABLE<br>
but not the later columns.<br>
<br>
I'm posting the details here in case people want to comment,<br>
or point out some major problem with the idea that I might have<br>
overlooked, or tell me that there's already a convention for<br>
this out there that I should be using instead. Otherwise, please<br>
feel free to ignore this post. I'm not requesting that any<br>
other software implements this, though if anyone wants to I<br>
certainly don't object.<br>
<br>
Mark<br>
<br>
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .<br>
<br>
Extended column convention for FITS BINTABLE<br>
------------------------------<wbr>--------------<br>
<br>
The BINTABLE extension type as described in the FITS Standard<br>
(FITS Standard v3.0, sec 7.3) requires table column metadata<br>
to be described using 8-character keywords of the form XXXXXnnn,<br>
where XXXXX represents one of an open set of mandatory, reserved<br>
or user-defined root keywords up to five characters in length,<br>
for instance TFORM (mandatory), TUNIT (reserved), TUCD (user-defined).<br>
The nnn part is an integer between 1 and 999 indicating the<br>
index of the column to which the keyword in question refers.<br>
Since the header syntax confines this indexed part of the keyword<br>
to three digits, there is an upper limit of 999 columns in<br>
BINTABLE extensions.<br>
<br>
Note that the FITS/BINTABLE format does not entail any restriction on<br>
the storage of column *data* beyond the 999 column limit in the data<br>
part of the HDU, the problem is just that client software<br>
cannot be informed about the layout of this data using the<br>
header cards in the usual way.<br>
<br>
In some cases it is desirable to store FITS tables with a column<br>
count greater than 999. Whether that's a good idea is not within<br>
the scope of this discussion.<br>
<br>
To achieve this, I propose the following convention.<br>
<br>
Definitions:<br>
<br>
- 'BINTABLE columns' are those columns defined using the<br>
FITS BINTABLE standard<br>
<br>
- 'Data columns' are the columns to be encoded<br>
<br>
- N_TOT is the total number of data columns to be stored<br>
<br>
- Data columns with (1-based) indexes from 999 to N_TOT inclusive<br>
are known as 'extended' columns. Their data is stored<br>
within the 'container' column.<br>
<br>
- BINTABLE column 999 is known as the 'container' column<br>
It contains the byte data for all the 'extended' columns.<br>
<br>
Convention:<br>
<br>
- All column data (for columns 1 to N_TOT) is laid out in the data part<br>
of the HDU in exactly the same way as if there were no 999-column<br>
limit.<br>
<br>
- The TFIELDS header is declared with the value 999.<br>
<br>
- The container column is declared in the header with some<br>
TFORM999 value corresponding to the total field length required<br>
by all the extended columns ('B' is the obvious data type, but<br>
any legal TFORM value that gives the right width MAY be used).<br>
The byte count implied by TFORM999 MUST be equal to the<br>
total byte count implied by all extended columns.<br>
<br>
- Other XXXXX999 headers MAY optionally be declared to describe<br>
the container column in accordance with the usual rules,<br>
e.g. TTYPE999 to give it a name.<br>
<br>
- The NAXIS1 header is declared in the usual way to give the width<br>
of a table row in bytes. This is equal to the sum of<br>
all the BINTABLE columns as usual. It is also equal to<br>
the sum of all the data columns, which has the same value.<br>
<br>
- Headers for Data columns 1-998 are declared as usual,<br>
corresponding to BINTABLE columns 1-998.<br>
<br>
- Keyword XT_ICOL indicates the index of the container column.<br>
It MUST be present with the integer value 999 to indicate<br>
that this convention is in use.<br>
<br>
- Keyword XT_NCOL indicates the total number of data columns encoded.<br>
It MUST be present with an integer value equal to N_TOT.<br>
<br>
- Metadata for each extended column is encoded with keywords<br>
of the form XXXXXaaa, where XXXXX are the same keyword roots<br>
as used for normal BINTABLE extensions, and aaa is a 3-digit<br>
value in base 26 using the characters 'A' (0 in base 26) to<br>
'Z' (25 in base 26), and giving the 1-based data column index<br>
minus 999. The sequence aaa MUST be exactly three characters<br>
long (leading 'A's are required). Thus the formats for data<br>
columns 999, 1000, 1001, etc are declared with the keywords<br>
TFORMAAA, TFORMAAB, TFORMAAC etc.<br>
<br>
- This convention MUST NOT be used for N_TOT<=999.<br>
<br>
The resulting HDU is a completely legal FITS BINTABLE extension.<br>
Readers aware of this convention may use it to extract column<br>
data and metadata beyond the 999-column limit.<br>
Readers unaware of this convention will see 998 columns in their<br>
intended form, and an additional (possibly large) column 999<br>
which contains byte data but which cannot be easily interpreted.<br>
<br>
This convention can therefore allow encoding of tables with data<br>
column counts N_TOT up to 998+26^3 = 18574.<br>
<br>
An example header might look like this:<br>
<br>
XTENSION= 'BINTABLE' / binary table extension<br>
BITPIX = 8 / 8-bit bytes<br>
NAXIS = 2 / 2-dimensional table<br>
NAXIS1 = 9229 / width of table in bytes<br>
NAXIS2 = 26 / number of rows in table<br>
PCOUNT = 0 / size of special data area<br>
GCOUNT = 1 / one data group<br>
TFIELDS = 999 / number of columns<br>
XT_ICOL = 999 / index of container column<br>
XT_NCOL = 1204 / total columns including extended<br>
TTYPE1 = 'posid_1 ' / label for column 1<br>
TFORM1 = 'J ' / format for column 1<br>
TTYPE2 = 'instrument_1' / label for column 2<br>
TFORM2 = '4A ' / format for column 2<br>
TTYPE3 = 'edge_code_1' / label for column 3<br>
TFORM3 = 'I ' / format for column 3<br>
TUCD3 = 'meta.code.qual'<br>
...<br>
TTYPE998= 'var_min_s_2' / label for column 998<br>
TFORM998= 'D ' / format for column 998<br>
TUNIT998= 'counts/s' / units for column 998<br>
TTYPE999= 'XT_MORECOLS' / label for column 999<br>
TFORM999= '813I ' / format for column 999<br>
TTYPEAAA= 'var_min_u_2' / label for column 999<br>
TFORMAAA= 'D ' / format for column 999<br>
TUNITAAA= 'counts/s' / units for column 999<br>
TTYPEAAB= 'var_prob_h_2' / label for column 1000<br>
TFORMAAB= 'D ' / format for column 1000<br>
...<br>
TTYPEAHW= 'var_prob_w_2' / label for column 1203<br>
TFORMAHW= 'D ' / format for column 1203<br>
TTYPEAHX= 'var_sigma_w_2' / label for column 1204<br>
TFORMAHX= 'D ' / format for column 1204<br>
TUNITAHX= 'counts/s' / units for column 1204<br>
END<br>
<br>
This general approach was suggested by William Pence on the FITSBITS<br>
list in June 2012<br>
(<a href="https://listmgr.nrao.edu/pipermail/fitsbits/2012-June/002367.html" rel="noreferrer" target="_blank">https://listmgr.nrao.edu/<wbr>pipermail/fitsbits/2012-June/<wbr>002367.html</a>),<br>
and by Francois-Xavier Pineau (CDS) in private conversation in 2016.<br>
The details have been filled in by Mark Taylor (Bristol).<br>
(F-X favours a different mechanism for encoding the extended<br>
column metadata).<br>
<br>
--<br>
Mark Taylor Astronomical Programmer Physics, Bristol University, UK<br>
<a href="mailto:m.b.taylor@bris.ac.uk">m.b.taylor@bris.ac.uk</a> <a href="tel:%2B44-117-9288776" value="+441179288776">+44-117-9288776</a> <a href="http://www.star.bris.ac.uk/~mbt/" rel="noreferrer" target="_blank">http://www.star.bris.ac.uk/~<wbr>mbt/</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 7 Jul 2017 05:51:17 -0700<br>
From: Rob Seaman <<a href="mailto:seaman@lpl.arizona.edu">seaman@lpl.arizona.edu</a>><br>
To: <a href="mailto:fitsbits@listmgr.nrao.edu">fitsbits@listmgr.nrao.edu</a><br>
Subject: Re: [fitsbits] BINTABLE convention for >999 columns<br>
Message-ID: <<a href="mailto:9cfd2764-bf73-4c2f-d111-a15e3a2ccaca@lpl.arizona.edu">9cfd2764-bf73-4c2f-d111-<wbr>a15e3a2ccaca@lpl.arizona.edu</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
Why not simply split such tables into two+ extensions and join as needed?<br>
<br>
Rob<br>
<br>
--<br>
<br>
<br>
On 7/7/17 4:09 AM, Mark Taylor wrote:<br>
> Dear fitsbits,<br>
><br>
> I am considering a convention for storing table data in FITS files<br>
> where the number of columns exceeds the 999 limit implicitly imposed<br>
> by the standard BINTABLE extension type. I have running code for<br>
> this (available on request) and plan to incorporate it in future<br>
> releases of STIL/STILTS/TOPCAT so that people can work with wide<br>
> tables in FITS while using those tools. People using software<br>
> that is unaware of this convention would still see a legal BINTABLE<br>
> but not the later columns.<br>
><br>
> I'm posting the details here in case people want to comment,<br>
> or point out some major problem with the idea that I might have<br>
> overlooked, or tell me that there's already a convention for<br>
> this out there that I should be using instead. Otherwise, please<br>
> feel free to ignore this post. I'm not requesting that any<br>
> other software implements this, though if anyone wants to I<br>
> certainly don't object.<br>
><br>
> Mark<br>
><br>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .<br>
><br>
> Extended column convention for FITS BINTABLE<br>
> ------------------------------<wbr>--------------<br>
><br>
> The BINTABLE extension type as described in the FITS Standard<br>
> (FITS Standard v3.0, sec 7.3) requires table column metadata<br>
> to be described using 8-character keywords of the form XXXXXnnn,<br>
> where XXXXX represents one of an open set of mandatory, reserved<br>
> or user-defined root keywords up to five characters in length,<br>
> for instance TFORM (mandatory), TUNIT (reserved), TUCD (user-defined).<br>
> The nnn part is an integer between 1 and 999 indicating the<br>
> index of the column to which the keyword in question refers.<br>
> Since the header syntax confines this indexed part of the keyword<br>
> to three digits, there is an upper limit of 999 columns in<br>
> BINTABLE extensions.<br>
><br>
> Note that the FITS/BINTABLE format does not entail any restriction on<br>
> the storage of column *data* beyond the 999 column limit in the data<br>
> part of the HDU, the problem is just that client software<br>
> cannot be informed about the layout of this data using the<br>
> header cards in the usual way.<br>
><br>
> In some cases it is desirable to store FITS tables with a column<br>
> count greater than 999. Whether that's a good idea is not within<br>
> the scope of this discussion.<br>
><br>
> To achieve this, I propose the following convention.<br>
><br>
> Definitions:<br>
><br>
> - 'BINTABLE columns' are those columns defined using the<br>
> FITS BINTABLE standard<br>
><br>
> - 'Data columns' are the columns to be encoded<br>
><br>
> - N_TOT is the total number of data columns to be stored<br>
><br>
> - Data columns with (1-based) indexes from 999 to N_TOT inclusive<br>
> are known as 'extended' columns. Their data is stored<br>
> within the 'container' column.<br>
><br>
> - BINTABLE column 999 is known as the 'container' column<br>
> It contains the byte data for all the 'extended' columns.<br>
><br>
> Convention:<br>
><br>
> - All column data (for columns 1 to N_TOT) is laid out in the data part<br>
> of the HDU in exactly the same way as if there were no 999-column<br>
> limit.<br>
><br>
> - The TFIELDS header is declared with the value 999.<br>
><br>
> - The container column is declared in the header with some<br>
> TFORM999 value corresponding to the total field length required<br>
> by all the extended columns ('B' is the obvious data type, but<br>
> any legal TFORM value that gives the right width MAY be used).<br>
> The byte count implied by TFORM999 MUST be equal to the<br>
> total byte count implied by all extended columns.<br>
><br>
> - Other XXXXX999 headers MAY optionally be declared to describe<br>
> the container column in accordance with the usual rules,<br>
> e.g. TTYPE999 to give it a name.<br>
><br>
> - The NAXIS1 header is declared in the usual way to give the width<br>
> of a table row in bytes. This is equal to the sum of<br>
> all the BINTABLE columns as usual. It is also equal to<br>
> the sum of all the data columns, which has the same value.<br>
><br>
> - Headers for Data columns 1-998 are declared as usual,<br>
> corresponding to BINTABLE columns 1-998.<br>
><br>
> - Keyword XT_ICOL indicates the index of the container column.<br>
> It MUST be present with the integer value 999 to indicate<br>
> that this convention is in use.<br>
><br>
> - Keyword XT_NCOL indicates the total number of data columns encoded.<br>
> It MUST be present with an integer value equal to N_TOT.<br>
><br>
> - Metadata for each extended column is encoded with keywords<br>
> of the form XXXXXaaa, where XXXXX are the same keyword roots<br>
> as used for normal BINTABLE extensions, and aaa is a 3-digit<br>
> value in base 26 using the characters 'A' (0 in base 26) to<br>
> 'Z' (25 in base 26), and giving the 1-based data column index<br>
> minus 999. The sequence aaa MUST be exactly three characters<br>
> long (leading 'A's are required). Thus the formats for data<br>
> columns 999, 1000, 1001, etc are declared with the keywords<br>
> TFORMAAA, TFORMAAB, TFORMAAC etc.<br>
><br>
> - This convention MUST NOT be used for N_TOT<=999.<br>
><br>
> The resulting HDU is a completely legal FITS BINTABLE extension.<br>
> Readers aware of this convention may use it to extract column<br>
> data and metadata beyond the 999-column limit.<br>
> Readers unaware of this convention will see 998 columns in their<br>
> intended form, and an additional (possibly large) column 999<br>
> which contains byte data but which cannot be easily interpreted.<br>
><br>
> This convention can therefore allow encoding of tables with data<br>
> column counts N_TOT up to 998+26^3 = 18574.<br>
><br>
> An example header might look like this:<br>
><br>
> XTENSION= 'BINTABLE' / binary table extension<br>
> BITPIX = 8 / 8-bit bytes<br>
> NAXIS = 2 / 2-dimensional table<br>
> NAXIS1 = 9229 / width of table in bytes<br>
> NAXIS2 = 26 / number of rows in table<br>
> PCOUNT = 0 / size of special data area<br>
> GCOUNT = 1 / one data group<br>
> TFIELDS = 999 / number of columns<br>
> XT_ICOL = 999 / index of container column<br>
> XT_NCOL = 1204 / total columns including extended<br>
> TTYPE1 = 'posid_1 ' / label for column 1<br>
> TFORM1 = 'J ' / format for column 1<br>
> TTYPE2 = 'instrument_1' / label for column 2<br>
> TFORM2 = '4A ' / format for column 2<br>
> TTYPE3 = 'edge_code_1' / label for column 3<br>
> TFORM3 = 'I ' / format for column 3<br>
> TUCD3 = 'meta.code.qual'<br>
> ...<br>
> TTYPE998= 'var_min_s_2' / label for column 998<br>
> TFORM998= 'D ' / format for column 998<br>
> TUNIT998= 'counts/s' / units for column 998<br>
> TTYPE999= 'XT_MORECOLS' / label for column 999<br>
> TFORM999= '813I ' / format for column 999<br>
> TTYPEAAA= 'var_min_u_2' / label for column 999<br>
> TFORMAAA= 'D ' / format for column 999<br>
> TUNITAAA= 'counts/s' / units for column 999<br>
> TTYPEAAB= 'var_prob_h_2' / label for column 1000<br>
> TFORMAAB= 'D ' / format for column 1000<br>
> ...<br>
> TTYPEAHW= 'var_prob_w_2' / label for column 1203<br>
> TFORMAHW= 'D ' / format for column 1203<br>
> TTYPEAHX= 'var_sigma_w_2' / label for column 1204<br>
> TFORMAHX= 'D ' / format for column 1204<br>
> TUNITAHX= 'counts/s' / units for column 1204<br>
> END<br>
><br>
> This general approach was suggested by William Pence on the FITSBITS<br>
> list in June 2012<br>
> (<a href="https://listmgr.nrao.edu/pipermail/fitsbits/2012-June/002367.html" rel="noreferrer" target="_blank">https://listmgr.nrao.edu/<wbr>pipermail/fitsbits/2012-June/<wbr>002367.html</a>),<br>
> and by Francois-Xavier Pineau (CDS) in private conversation in 2016.<br>
> The details have been filled in by Mark Taylor (Bristol).<br>
> (F-X favours a different mechanism for encoding the extended<br>
> column metadata).<br>
><br>
> --<br>
> Mark Taylor Astronomical Programmer Physics, Bristol University, UK<br>
> <a href="mailto:m.b.taylor@bris.ac.uk">m.b.taylor@bris.ac.uk</a> <a href="tel:%2B44-117-9288776" value="+441179288776">+44-117-9288776</a> <a href="http://www.star.bris.ac.uk/~mbt/" rel="noreferrer" target="_blank">http://www.star.bris.ac.uk/~<wbr>mbt/</a><br>
><br>
> ______________________________<wbr>_________________<br>
> fitsbits mailing list<br>
> <a href="mailto:fitsbits@listmgr.nrao.edu">fitsbits@listmgr.nrao.edu</a><br>
> <a href="https://listmgr.nrao.edu/mailman/listinfo/fitsbits" rel="noreferrer" target="_blank">https://listmgr.nrao.edu/<wbr>mailman/listinfo/fitsbits</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Fri, 7 Jul 2017 09:45:21 -0400<br>
From: Demitri Muna <<a href="mailto:demitri.muna@gmail.com">demitri.muna@gmail.com</a>><br>
To: Mark Taylor <<a href="mailto:m.b.taylor@bristol.ac.uk">m.b.taylor@bristol.ac.uk</a>><br>
Cc: <a href="mailto:fitsbits@listmgr.nrao.edu">fitsbits@listmgr.nrao.edu</a><br>
Subject: Re: [fitsbits] BINTABLE convention for >999 columns<br>
Message-ID: <<a href="mailto:8A1AC488-6528-4C3A-A0D2-1226C6390F21@gmail.com">8A1AC488-6528-4C3A-A0D2-<wbr>1226C6390F21@gmail.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Hi,<br>
<br>
I agree with Rob here; the simplest solution is to spread the data into two or more extensions. It's not a lot of work for the end user to concatenate the columns into a single data structure if that is preferable for some reason. Creating a new convention that is not part of the FITS standard *does* create a lot of work for many people. While you may be able to create a technically valid FITS file, this proposal is not in the spirit of how FITS files are to be read. This proposal literally redefines the meaning of the mandatory "TFIELDS" header from the "number of columns in the table" to "number of columns in the table, except if there are other keywords, then in that case look elsewhere for this information".<br>
<br>
On Jul 7, 2017, at 7:09 AM, Mark Taylor <<a href="mailto:m.b.taylor@bristol.ac.uk">m.b.taylor@bristol.ac.uk</a>> wrote:<br>
<br>
> I'm posting the details here in case people want to comment,<br>
> or point out some major problem with the idea that I might have<br>
> overlooked, or tell me that there's already a convention for<br>
> this out there that I should be using instead. Otherwise, please<br>
> feel free to ignore this post. I'm not requesting that any<br>
> other software implements this, though if anyone wants to I<br>
> certainly don't object.<br>
<br>
I don't think it's as simple as that. It's one thing to implement this in the software you support, but there are other FITS viewers/readers (Astropy and cfitsio being the main ones, whatever IDL routines there are, not to mention Nightlight). I think it would be wrong for the other programs to implement this without it being part of the standard, and I think it's a bad idea to fork the standard with a custom implementation. Feelings about standards aside, this provides for a bad user experience. It's a legitimate question/frustration for a user to wonder why some columns appear in one program and not many others, especially when the file claims to be a FITS file.<br>
<br>
I agree that there are limitations in the FITS format, but I strongly suggest that the only way forward for this idea is to propose it (or something similar) as part of the official FITS format or else use multiple extensions.<br>
<br>
Cheers,<br>
Demitri<br>
<br>
<br>
<a href="http://nightlightapp.io" rel="noreferrer" target="_blank">http://nightlightapp.io</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://listmgr.nrao.edu/pipermail/fitsbits/attachments/20170707/cd9361c6/attachment.html" rel="noreferrer" target="_blank">http://listmgr.nrao.edu/<wbr>pipermail/fitsbits/<wbr>attachments/20170707/cd9361c6/<wbr>attachment.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
______________________________<wbr>_________________<br>
fitsbits mailing list<br>
<a href="mailto:fitsbits@listmgr.nrao.edu">fitsbits@listmgr.nrao.edu</a><br>
<a href="https://listmgr.nrao.edu/mailman/listinfo/fitsbits" rel="noreferrer" target="_blank">https://listmgr.nrao.edu/<wbr>mailman/listinfo/fitsbits</a><br>
<br>
<br>
------------------------------<br>
<br>
End of fitsbits Digest, Vol 117, Issue 1<br>
******************************<wbr>**********<br>
</blockquote></div><br></div></div></div></div></div>