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] CRPIX clarification



 
 
Thread Tools Display Modes
  #1  
Old May 30th 08, 03:48 AM posted to sci.astro.fits
Mark Calabretta
external usenet poster
 
Posts: 42
Default [fitsbits] CRPIX clarification


On Thu 2008/05/29 08:45:21 CST, Eric Greisen wrote
in a message to: Jonathan McDowell
and copied to:

Dear Jonathan & Eric,

Guys - the correct way to clarify some misunderstandings in the written
standard needs to be determined. BUT, the issue of reference point was


I don't think that we have any significant points of disagreement. I
was simply responding to your (Jonathan's) statement that "the WCS
corresponds to the center of the pixel", in the particular context of
whether the definition of CRPIXja should have (or should have had) some
words referring to the "centre of the pixel".

My main point is that the WCS definitions should not refer to pixels
or voxels as finite squares, cubes nor anything with an extent and
consequently a centre. As I explained previously, in terms of Fourier
sampling theory what we call an "image" is actually a shah function.
All we need do is agree on a method of indexing the individual delta
functions in that shah function. We call this index the "pixel
coordinate" and we allow it to take fractional values for the purposes
of interpolation (when it makes sense). FITS has chosen a method that
matches these indexes with the way that arrays are indexed in Fortran,
i.e. each delta function is assigned an integral index starting at 1.
This is neither correct nor incorrect, it's simply the way it was done.
It makes implementation easier in Fortran, though in C you have to
remember to offset the array index by 1, and also that the first array
index changes slowest. Thus, distinguishing between pixel coordinates
and array indices allows everyone to agree that F(2,3) and C[2][1]
actually both refer to the delta function with pixel coordinate
(2.0,3.0). The distinction effectively provides one level of
indirection - which is enough to cause one level of misunderstanding!

From what Jonathan says, there are other packages out there that index

the delta functions differently, apparently some start at 0.5 and
others might start at 1.5, though mercifully still incrementing by +1
(also a choice). This is neither correct nor incorrect. However, in
practical terms it is perhaps a surprising choice because it imposes a
fractional offset between this index and the array index that must be
used to store the data.

So far we have enough to do full WCS yet we don't have any pixels, only
the misleadingly-named index that we call the "pixel coordinate".
However, we are still left with the question of providing guidance on
representing FITS data on an image display (as opposed to a contour or
raster map):

1) Bearing in mind the way that TV devices work, each delta function
in the shah function is represented by a finite square in which the
delta function is centred.

This is really the only sensible way to do it. I'm sure it's also
the display convention for the other systems mentioned by Jonathan,
it's just that their fractional indexing scheme confuses things.
(Note that display devices have yet another coordinate system
with (0,0) in the top left corner.)

2) The little squares are laid out side-by-side with no intervening
gaps thus building up a picture. Thus they are referred to as
picture elements or "pixels" for short.

3) The pixels are laid out in row-wise fashion starting from the
bottom left corner of the display. That is, the first NAXIS1
pixels in the data array come out across the bottom of the screen,
the next NAXIS1 pixels are placed above that row, etc.

This allows an image to be transmitted to a recipient and viewed in
the intended orientation. It is particularly relevant for images
that have no associated world coordinate system, such as a photo of
your house or budgie. (However, it better be B&W since FITS has no
formal method of representing colour!)

I think it would be appropriate for the standard to contain the above
information in a section completely separate from the definition of
the WCS keywords.

Regards, Mark
 




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] CRPIX clarification Jonathan McDowell FITS 0 May 29th 08 04:12 PM
[fitsbits] CRPIX clarification Eric Greisen FITS 0 May 29th 08 03:45 PM
[fitsbits] CRPIX clarification Jonathan McDowell FITS 0 May 29th 08 02:18 AM
[fitsbits] CRPIX clarifcation Mark Calabretta FITS 0 May 29th 08 01:15 AM
[fitsbits] CRPIX clarifcation Jonathan McDowell FITS 0 May 27th 08 07:42 PM


All times are GMT +1. The time now is 11:42 AM.


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.