Re: [fitsbits] CRPIX clarification
Jonathan McDowell
Mark,
I was a bit unclear earlier, sorry. I shouldn't try and
reply to email while on vacation!
However, I think the statement that I was making is nothing to do with
your very valid concerns. My point is that we have integer pixel numbers
(P1,P2,...) like (241,32,81) and fractional (real-valued) pixels (X1,X2,...)
like (241.3, 32.1, 81.9). Different software systems use different
schemes to map between these; I have seen both
[A] Xi = Pi Pi = (int)Xi
and
[B] Xi = Pi + 0.5 Pi = (int)(Xi-0.5)
and of course this is an independent choice from the schemes
[F] i = 1,....N
[C] i = 0,....N-1
Some people prefer the latter because then, if you
are [B],[C] then for an NxN image
the 'lower left corner of the lower left pixel' is (0.0,0.0)
and the 'upper right corner of the upper right pixel' is (N,N),
In contrast, with our scheme [A],[F], our images
run from (0.5,0.5) to (N+0.5,N+0.5) when considered as a real-valued
coordinate system, and this is seen as ugly.
You may consider that [A] is implied by the very concept of fractional
pixel coordinates and that no sane person would interpret the standard
to mean [B], but history indicates that this is a fallible assumption.
I guess in your discussion [B] is equivalent to putting the square area
such that the delta function is at one corner of it.
I think you get a wrong interpretation of the data.
On your issues (1) and (2) about the interpolation, I basically agree.
It is true that for the case with both equatorial and galactic coords
on the same image, the world coord loci of a pixel boundary are different
in the the different coord systems so the naive idea that a pixel
is a light bucket on the sky is only valid per-single-WCS etc.
Nevertheless it's a useful concept.
- Jonathan
Eric Greisen
> However, I think the statement that I was making is nothing to do with
> your very valid concerns. My point is that we have integer pixel numbers
> (P1,P2,...) like (241,32,81) and fractional (real-valued) pixels (X1,X2,...)
> like (241.3, 32.1, 81.9). Different software systems use different
> schemes to map between these; I have seen both
> [A] Xi = Pi Pi = (int)Xi
> and
> [B] Xi = Pi + 0.5 Pi = (int)(Xi-0.5)
> and of course this is an independent choice from the schemes
> [F] i = 1,....N
> [C] i = 0,....N-1
>
People may prefer the latter although I cannot see why, but the latter
is WRONG. If people use it then they will LIE to the recipient about
the WCS of their data. The fact that the center of the VOXEL (we are >
2 dimensions a lot) is the reference point of the VOXEL is part of the
WCS papers and has been approved at all levels by the FITS committees.
It was certainly understood from the very beginning of FITS and
explicitly stated at least some places. The argument about this that
appeals to me most is to think if the VOXEL in real space as a cube.
The only point in that cube that does not change under rotations is its
center. In all other cases, if you for example transpose an image, you
will change the "natural" (think left side) reference point of every
pixel on that axis. Since one cannot change the reference point of
projective geometries without regridding the image, this is an
unpleasant concept.
Guys - the correct way to clarify some misunderstandings in the written
standard needs to be determined. BUT, the issue of reference point was
resolved long ago. Let us not reawaken it and destroy the good work we
have done to convey coordinates with data.
Eric Greisen
Jonathan McDowell
Eric, I didn't mean that the other approach was being done in FITS,
I know it was done in some non-FITS astronomy data packages (if I remember
correctly, the ancient Einstein Observatory data system was an
example). I agree that there is only one right way to do it in FITS,
and am merely advocating that we guard against any misinterpretation.
I don't recall any cases in which this has actually been done wrong
with FITS files, although I did have to stomp on some programmers who were
trying to once...
Jonathan
Mark Calabretta
On Thu 2008/05/29 08:45:21 CST, Eric Greisen wrote
in a message to: Jonathan McDowell <j...@head.cfa.harvard.edu>
and copied to: fits...@nrao.edu
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
Mark Calabretta
On Fri 2008/05/30 12:48:46 +1000, Mark Calabretta wrote
in a message to: Jonathan McDowell <j...@head.cfa.harvard.edu>,
Eric Greisen <egre...@nrao.edu>
and copied to: fits...@nrao.edu
>consequently a centre. As I explained previously, in terms of Fourier
>sampling theory what we call an "image" is actually a shah function.
See
http://en.wikipedia.org/wiki/Dirac_comb
http://mathworld.wolfram.com/ShahFunction.html
Steve Allen
> I don't think that we have any significant points of disagreement.
I concur.
We also do not have a set of altered words for Bill Pence to propose
which make it clear that traverse along array indices isn't really
pixels and does not really have units until and unless the WCS says
they do, and that in the case where the coordinate along the array
axis can reasonably be interpreted as a real-valued entity the
data value is intended to correspond to the measured quantity
at the integer values which run from 1 to NAXISj.
I don't have any immediate suggestions which can boil all
of our agreement into concise words.
> 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.
I agree, but I'm not sure how complicated that process would get.
--
Steve Allen <s...@ucolick.org> WGS-84 (GPS)
UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855
University of California Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
Rob Seaman
> We also do not have a set of altered words for Bill Pence to propose
> which make it clear that traverse along array indices isn't really
> pixels and does not really have units until and unless the WCS says
> they do, and that in the case where the coordinate along the array
> axis can reasonably be interpreted as a real-valued entity the data
> value is intended to correspond to the measured quantity at the
> integer values which run from 1 to NAXISj.
This discussion reminds me of the innumerable "which way is up?"
questions in the IRAF mail over the years. The answer goes something
like "the question is meaningless until you display the image".
A couple of points for semantic musing. What does binning of pixels
do to those integer values? (Or decimation, subsampling or block
averaging.) Coordinates (center of the pixel or otherwise) may start
as integer values 0, 1, 2, 3. Bin by two and this turns into 0.5,
2.5, 4.5, ... Also, "measured quantity" isn't really the extent of it
in a world of theory and simulations. It's more like the distinction
between independent and dependent variables.
And many times the WCS is implicit, as with an image display causing
the up/down/left/right wave function to collapse. Call this the
astronomy.net effect. Even in an image completely devoid of metadata,
celestial fiducial marks express an implicit WCS.
Rob
Rob Seaman
Maren Purves
> This discussion reminds me of the innumerable "which way is up?"
> questions in the IRAF mail over the years. The answer goes something
> like "the question is meaningless until you display the image".
unless ...
we had a rather interesting thing happening with one of our
instruments that uses sub-arrays:
Until very recently (this is for an instrument that's been
in operation for about 10 years) the CRPIX etc. coordinates
followed the array (array controller) numbering, which
starts in the top right corner rather than in the
bottom left.
This works for almost everything, the one exception
being if you use a full array flat field (or dark)
for a subarray observation, because you'll get the wrong
quadrant.
Following this I implemented the "up" that the data
reduction expects which is the opposite of what the
array controller thinks, i.e. I had to flip the
coordinate axes (rotate 180), but only for the header,
not for the readout - independent of displaying.
Maren
(UKIRT)
kitty4uhi
Ten 'wow gold ' (http://www.ugamegold.com) Leveling Secrets'wow gold '
(http://www.ugamegold.com) is perhaps one of the biggest games on the
market, with over eight-million subscribers, it certainly is already
the number one MMORPG (Massive Multiplayer Online Roleplaying Game),
the only problem, it seems, is the amount of time it takes to get to
the end of the game via leveling. So without further ado, here’s
ten leveling secrets that should help you level faster than ever.
--
kitty4uhi
Phil Hodge
representation of an image include the table column number as part of
the keyword name. This description agrees with the example in Table 10
of WCS Paper II. It seems to me, however, that several of these
keywords should include the world coordinate axis number rather than the
column number. I checked the "unofficial errata" for Papers I and II
but didn't find any mention of this.
Consider the case of a time-tag table containing columns TIME, X, and Y,
which are respectively the time when a photon was detected and the pixel
coordinates in a 2-D image where it was detected. To use a specific
example, suppose the world coordinates are right ascension and
declination. The reference pixel keywords are TCRPX2 and TCRPX3, giving
the column numbers of the X and Y columns. But shouldn't the keywords
for the world coordinates at the reference pixel be TCRVL1 and TCRVL2
rather than TCRVL2 and TCRVL3 (and similarly for several other
keywords)? The WCS papers say the latter keywords are the ones to use,
but it would be more consistent with the keywords for an image in the
primary array if the former keywords were used.
Phil