Hi All:
Ok, problem solved. In the MODIS data set I was looking at, the Upper
Left corner is assigned the index [0,0], with the X-axis increasing to
the right, and the Y-axis increasing downwards. As Craig points out,
Transform.pm nominally expects the [0,0] pixel to be at the lower left.
So, either adjusting the FITS header, as Craig suggests, or using a splice
$pdl->slice(':,-1:0')
to swap the rows (as Judd suggested) fixes the problem. Don't forget to
do it again after the transform if you want to put [0,0] back at the
Upper Left corner.
Thanks for all your help,
--greg
Craig DeForest wrote:
Yep, several standards exist, I think mostly because of the
top-to-bottom scan that came to the fore with television receivers -
Farnsworth chose a top-to-bottom scan for his prototype system, and
(like Franklin before him with the sign convention for electric
charge) forever consigned everyone to live with an unfortunate choice
of sign. I still occasionally run across images that need to be
vertically inverted, even in the solar physics community.
The FITS documentation (which seems to grow more complex yearly)
specifies a pixel coordinate system that starts with a FORTRAN-ish
(1,1) at the center of the lower left pixel of the image, so
Transform, Graphics::PGPLOT, and Graphics::PLplot stick to that
orientation (while preserving PDL's more sensible zero-based
indexing). I think that PGPLOT contains an axis-direction option that
lets you flip images over during display, because the sign problem is
so widespread.
Basically, anything with FITS-like headers is implicitly working in
the FITS pixel coordinate system, so if you are using top left as the
origin, I strongly urge converting to bottom left in your FITS headers
-- that is as simple as using a large CRPIX2 and a negative CDELT2,
rather than a small CRPIX2 and a positive CDELT2. (remember that
CRPIX1/CRPIX2 are the location of a datum in the FITS pixel coordinate
system, which relates to array indices in a simple way; CRVAL1/CRVAL2
are the location of that datum in the scientific coordinate system;
and CDELT1/CDELT2/CROTA (or the more modern matrix-element tags)
relate the scale and orientation of the coordinate systems relative to
the datum.)
If you're not using FITS tags, of course you can do what you like! :-)
Cheers,
Craig
On Sep 26, 2007, at 8:53 AM, Judd Taylor wrote:
I always use the top left (therefore, so does PDL::IO::HDF), which is
why I have to do the inversion on that axis. For satellite data, that
convention makes a lot of sense when you start to think about scan lines
scrolling across...
This is not something that is well documented about PDL... which might
explain why there are probably a few different conventions used in PDL
simultaneously.
I think for some I/O, a separate convention can be necessary. For
instance, libpng only allows access as data blobs (using top-left), or
via scan lines (top-left, again).
The low-level HDF library uses that bass ackwards fortran dimension
order (z,y,x), and then probably the top-left (I can't recall at the
moment).
Basically, I took the input data and displayed it as-is, fiddled with it
until it "looked right" (up is up, left is left), and then proceeded
with everything else and it worked.
-Judd
On Wed, 2007-09-26 at 08:01 -0600, Craig DeForest wrote:
Hi, Greg,
Nominally, (0,0) is the center of the lower, left pixel (so that the
lowest, leftmost point in the image is (-0.5,-0.5), given that pixels
are 1x1 squares).
Cheers,
Craig
On Sep 26, 2007, at 7:46 AM, Greg Ederer wrote:
Judd:
For a 2-D array, which corner does Transform.pm expect that point
[0,0] represents? Is it upper left, lower left, upper right, or
lower right hand corner? I think this is where my problem is,
judging from the slicing and mv'ing that seems necessary.
Thanks,
--greg
Judd Taylor wrote:
Greg,
The attached script works for me. See if you get similar
results... You
can just comment out the OrbitalSystems::Logger stuff and replace
with
"print STDERR".
Note however, that it's almost exactly the same as yours, except
a ->mv
(2,0), and a ->slice(":,-1:0") in there (I think the slice is only
required b/c the way I do the dims in PDL::IO::HDF).
Let me know if it works for you.
-Judd
--
____________________________
Judd Taylor
Software Engineer
Orbital Systems, Ltd.
3807 Carbon Rd.
Irving, TX 75038-3415
[EMAIL PROTECTED]
(972) 915-3669 x127
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
