A Space & astronomy forum. SpaceBanter.com

Go Back   Home » SpaceBanter.com forum » Astronomy and Astrophysics » FITS
Site Map Home Authors List Search Today's Posts Mark Forums Read Web Partners

[fitsbits] Interpretation of repeat count in binary tables



 
 
Thread Tools Display Modes
  #1  
Old April 1st 08, 04:39 PM posted to sci.astro.fits
William Pence[_2_]
external usenet poster
 
Posts: 44
Default [fitsbits] Interpretation of repeat count in binary tables

Paddy Leahy wrote:
On Mon, 31 Mar 2008, William Pence wrote:
In the example you cite below, the binary table contains 12288 rows of data,
and each row contains 3 vectors, containing 1024 single precision floating
point numbers each. There is no explicit relationship between the vectors
in different rows of the table.


"No explicit relationship" sounds worrying. Does this mean that different
FITS readers can legitimately interpret the same table in different ways?
Or are there some keywords that clarify the relationship between rows?


The mandatory keywords in this case simply define a FITS table that
consists of a sequence of 1024 element vectors. There is no explicitly
defined relationship between the vectors on different rows. Implicitly,
however, the fact that all these vectors have been grouped together into
a single table suggests that they are probably related in some way.
There could be other mission-specific keywords in the header that
explains the relationship.

snip
The TDIMn keyword, if present in this case, would specify the dimensionality
of each individual 1024 element vector in that column. For example, TDIM1 =
'(16,64)', would mean that each vector in column 1 should be interpreted as a
16 x 64 2D array. If there is no TDIMn keyword, then the vector would be
interpreted as a 1024 element 1-D array.


So, let me be clear: a fits reader is asked to return the data from column
2 of a table which has N_row rows and a repeat count of R for column 2.
This should definitely be returned as a 2-D array of (R, N_row) elements,
even if TDIM2 is not present? (Or maybe, given your "no explicit
relationship" comment, as something looser, like a linked list of arrays
of length R?).


It mainly depends on what the application program itself wants to read
from the table. Some applications might read the vectors sequentially
one row at at time in a loop; other applications might ask for all the
vectors at once, as a big array of length = (column vector count) *
(NAXIS2 rows). The application could optionally interpret this as a 2D
array if it desires, but the FITS keywords do not mandate this.

The point being that, I guess because some fits readers are highly
inefficient at reading tables with short rows, it has become common
practice at least in the CMB field to use a repeat count just as a way of
packing data in a way that can be read efficiently. The writer of my
example intended each column to be read as 1 long vector of R*N_row
elements. Is that definitely contrary to the standard?


No it is not contrary to the standard. Projects are free to invent their
own local conventions for storing the data in whatever structure is most
convenient for them. If, however, the intention is to pack 3 1024 x
12288 element 2-D arrays into a binary table, then a more explicit way
to do this would be as follows:

NAXIS1 = 150994944 / width of table (1024*12288*3*4)
NAXIS2 = 1 / table has only 1 row
....
TFIELDS = 3
TFORM1 = '12582912E'
TDIM1 = '(1024,12288)'
TFORM2 = '12582912E'
TDIM2 = '(1024,12288)'
TFORM3 = '12582912E'
TDIM3 = '(1024,12288)'

In this structure, all the elements for each array are contiguous in the
table, which would make it more efficient when reading the whole
2-D array at once.

Bill Pence
--
__________________________________________________ __________________
Dr. William Pence
NASA/GSFC Code 662 HEASARC +1-301-286-4599 (voice)
Greenbelt MD 20771 +1-301-286-1684 (fax)


  #2  
Old April 1st 08, 05:06 PM posted to sci.astro.fits
LC's No-Spam Newsreading account
external usenet poster
 
Posts: 6
Default [fitsbits] Interpretation of repeat count in binary tables

On Tue, 1 Apr 2008, William Pence wrote:

No it is not contrary to the standard. Projects are free to invent their own
local conventions for storing the data in whatever structure is most
convenient for them.


definitely agreed !

If, however, the intention is to pack 3 1024 x 12288
element 2-D arrays into a binary table, then a more explicit way to do this
would be as follows:


NAXIS1 = 150994944 / width of table (1024*12288*3*4)
NAXIS2 = 1 / table has only 1 row
...
TFIELDS = 3


however a far less contrived way would be not to use a binary table, but
either a sequence of 3 image extensions with NAXIS=2 NAXIS1=1024
NAXIS2=12288, or a traditional FITS image with a datacube (NAXIS=3, and
NAXIS1,NAXIS2,NAXIS3=1013,12288,3 or whatever permutation thereof.

After all a 2-d array *is* an image, and is very easily displayed using
an image display program

--
----------------------------------------------------------------------
is a newsreading account used by more persons to
avoid unwanted spam. Any mail returning to this address will be rejected.
Users can disclose their e-mail address in the article if they wish so.
 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
[fitsbits] Interpretation of repeat count in binary tables Paddy Leahy FITS 0 April 1st 08 09:33 AM
[fitsbits] Interpretation of repeat count in binary tables William Pence[_2_] FITS 0 April 1st 08 04:02 AM
[fitsbits] Interpretation of repeat count in binary tables Paddy Leahy FITS 0 March 30th 08 05:39 PM
[fitsbits] Packed binary values Steve Allen FITS 0 April 30th 07 06:28 PM
[fitsbits] Packed binary values William Pence FITS 0 April 30th 07 05:37 PM


All times are GMT +1. The time now is 03:44 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 SpaceBanter.com.
The comments are property of their posters.