On 4/13/2010 2:40 PM, Craig DeForest wrote: > I agree with Judd on this. In fact, nowadays I'm regretting not > subclassing PDL for the FITS header stuff -- it seemed natural to > just assume that there might be a FITS header there, but these days > it seems it would be better to have a PDL::FITS class that carries the > header around and updates it on slicing, etc. A subclass would enable > much of the coordinate system magic in PDL::Transform to be more > novice-friendly. (For what it's worth, you can always fall back to > pixel coordinates in PDL::Tranform::map, by feeding it the "pix=>1" > option...)
Hindsight is 20-20, but would you really rather give up some years of convenient FITS programming with PDL? :-) I've needed to use pix=>1 for my PDL::Transform experiments but it would be nice to have some sort of scientific coordinate standard for PDL so everything would not have to be a big mess of explicit transformations. > More generally, a PDL::WCS subclass, or something of that sort, that had > a format-agnostic metadata header, might be a nice way to go (for > using proj > stuff and FITS stuff together), even if it just converts everything to a > particular internal working format. Dominic Zarro did something similar > to that with the MAP object used by the SolarSoft IDL package, and of > course > Proj and StarLink have working WCS style formats too. I like the idea of a common, 90% solution supported via the existing hdr formalism. It has the advantages of potentially better performance, easier migration of the existing FITS code, and an intrisic support for the various scientific coordinates by PDL proper and not just a subclass. As an example, consider the PDL::Complex type which only works if you use it and I'm not sure to what extent all the tests pass with complex piddles. =-Chris _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
