From alice.pasch at orange.fr Thu Sep 1 05:20:37 2016 From: alice.pasch at orange.fr (alice paschal) Date: Thu, 1 Sep 2016 11:20:37 +0200 (CEST) Subject: [AstroPy] Distortion coefficients - FITS Header of an image Message-ID: <1334016614.6385.1472721637578.JavaMail.www@wwinf1d08> Hello, ? With a telescope, I took sky images in tracking ON. These images were saved in FITS format. With MaximDL and PinPoint Atsrometry softwares, we can get the FITS Header of each image, i.e. image data (for instance Observation site, CCD camera, focal length, pixels, right ascension of the image center, declination of the image center, etc). I put an example for you (see below at the end of the message). What I would like to find is a way to take into account distortion coefficients of an image (we can find them in the FITS Header of the image, see below), in order to convert any pixels of the image into world coordinates, and vice versa. I am working with Python. I have found with Astropy some useful functions, like w.wcs_world2pix to convert world coordinates into pixel coordinates. But would you know which distortion coefficients are taken into account in such a function ? The TRi_j distortion coefficients are they taken into account ? Because I could not find any information on them. I have found only papers like the following ones which are on A, B, AP, AB coefficients but not on TR coefficients : http://docs.astropy.org/en/stable/api/astropy.wcs.Sip.html#astropy.wcs.Sip http://irsa.ipac.caltech.edu/data/SPITZER/docs/files/spitzer/shupeADASS.pdf Thank you in advance for your help. Best regards Alice Example of the FITS Header of an image : SIMPLE = T BITPIX = 16 /8 unsigned int, 16 & 32 int, -32 & -64 real NAXIS = 2 /number of axes NAXIS1 = 2184 /fastest changing axis NAXIS2 = 1472 /next to fastest changing axis BSCALE = 1.0000000000000000 /physical = BZERO + BSCALE*array_value BZERO = 0.00000000000000000 /physical = BZERO + BSCALE*array_value DATE-OBS = '2016-08-03T21:53:34' / [ISO 8601] UTC date/time of exposure start EXPTIME = 4.00000000000E+000 / [sec] Duration of exposure EXPOSURE = 4.00000000000E+000 / [sec] Duration of exposure SET-TEMP = -30.000000000000000 /CCD temperature setpoint in C CCD-TEMP = -29.968750000000000 /CCD temperature at start of exposure in C XPIXSZ = 6.7999999999999998 /Pixel Width in microns (after binning) YPIXSZ = 6.7999999999999998 /Pixel Height in microns (after binning) XBINNING = 1 / Binning level along the X-axis YBINNING = 1 / Binning level along the Y-axis XORGSUBF = 0 /Subframe X position in binned pixels YORGSUBF = 0 /Subframe Y position in binned pixels READOUTM = 'Raw ' / Readout mode of image IMAGETYP = 'Light Frame' / Type of image FOCALLEN = 1153.0000000000000 /Focal length of telescope in mm APTDIA = 254.00000000000000 /Aperture diameter of telescope in mm APTAREA = 50670.749319791794 /Aperture area of telescope in mm^2 EGAIN = 0.80000001192092896 /Electronic gain in e-/ADU SBSTDVER = 'SBFITSEXT Version 1.0' /Version of SBFITSEXT standard in effect SWCREATE = 'MaxIm DL Version 6.08 160505 1A3Q6' /Name of software SWSERIAL = '1A3Q6-HWHSQ-A0990-J2QRF-SUTCT-QC' /Software serial number OBJCTRA = '21 28 50.00' / [hms J2000] Target right ascension OBJCTDEC = '-06 44 12.0' / [dms +N J2000] Target declination OBJCTALT = ' 30.8774' / Nominal altitude of center of image OBJCTAZ = '139.4337' / Nominal azimuth of center of image OBJCTHA = ' -2.2794' / Nominal hour angle of center of image SITELAT = '43 45 11' / Latitude of the imaging location SITELONG = '06 55 18' / Longitude of the imaging location JD = 2457604.4121990739 /Julian Date at start of exposure JD-HELIO = 2457604.4179293886 /Heliocentric Julian Date at exposure midpoint AIRMASS = 1.94149884803E+000 / Airmass (multiple of zenithal airmass) OBJECT = ' ' / Target object name TELESCOP = ' ' / Telescope name INSTRUME = 'SBIG STT-3200 3 CCD Camera' / Detector instrument name OBSERVER = ' ' / Observer name NOTES = ' ' FLIPSTAT = ' ' SWOWNER = 'THALES ALENIA SPACE FRANCE' /Licensed owner of software INPUTFMT = 'FITS ' / Format of file from which image was read HISTORY File was processed by PinPoint 6.0.6 at 2016-08-08T11:19:06 DATE = '03/08/16' / [old format] UTC date of exposure start TIME-OBS = '21:53:34' / [old format] UTC time of exposure start UT = '21:53:34' / [old format] UTC time of exposure start TIMESYS = 'UTC ' / Default time system RADECSYS = 'FK5 ' / Equatorial coordinate system RA = '21 28 50.00' / [hms J2000] Target right ascension DEC = '-06 44 12.0' / [dms +N J2000] Target declination FWHM = 3.31912333965E+000 / [pixels] Mean Full-Width-Half-Max of image star ZMAG = 2.22695229625E+001 / Mag zero point for 1 sec exposure EQUINOX = 2000.0 / Equatorial coordinates are J2000 EPOCH = 2000.0 / (incorrect but needed by old programs) PA = 3.58967846401E+002 / [deg, 0-360 CCW] Position angle of plate CTYPE1 = 'RA---TAN' / X-axis coordinate type CRVAL1 = 3.22235640938E+002 / X-axis coordinate value CRPIX1 = 1.09200000000E+003 / X-axis reference pixel CDELT1 = -3.37671457816E-004 / [deg/pixel] X-axis plate scale CROTA1 = 1.03215359918E+000 / [deg] Roll angle wrt X-axis CTYPE2 = 'DEC--TAN' / Y-axis coordinate type CRVAL2 = -6.73039453583E+000 / Y-axis coordinate value CRPIX2 = 7.36000000000E+002 / Y-axis reference pixel CDELT2 = -3.38006539857E-004 / [deg/pixel] Y-Axis Plate scale CROTA2 = 1.03215359918E+000 / [deg] Roll angle wrt Y-axis CD1_1 = -3.37616668483E-004 / Change in RA---TAN along X-Axis CD1_2 = 6.08868227955E-006 / Change in RA---TAN along Y-Axis CD2_1 = -6.08264627773E-006 / Change in DEC--TAN along X-Axis CD2_2 = -3.37951696156E-004 / Change in DEC--TAN along Y-Axis TR1_0 = 1.09199958073E+003 / [private] X-axis distortion coefficients TR1_1 = 2.18399991151E+003 TR1_2 = -6.18827693341E-001 TR1_3 = -1.23992354888E+000 TR1_4 = -1.21460280616E+000 TR1_5 = -1.17006143126E+000 TR1_6 = -2.36278669552E+001 TR1_7 = 8.13968772630E-001 TR1_8 = -1.05987616323E+001 TR1_9 = -2.51664136543E+000 TR1_10 = 7.75126811018E+000 TR1_11 = 1.11725347231E+000 TR1_12 = -1.15863502104E+000 TR1_13 = 2.78034135924E+000 TR1_14 = 5.04818239812E+000 TR2_0 = 7.36000000896E+002 / [private] Y-axis distortion coefficients TR2_1 = -1.38948258924E-003 TR2_2 = 1.47200000121E+003 TR2_3 = -1.74854087048E+000 TR2_4 = 3.06867323249E-001 TR2_5 = -2.74476247742E+000 TR2_6 = -2.95895994527E-001 TR2_7 = -1.76582177998E+001 TR2_8 = 2.41056596524E-001 TR2_9 = -1.34421356097E+001 TR2_10 = 6.81670566601E+000 TR2_11 = -2.72087350085E+000 TR2_12 = -2.86227884736E+000 TR2_13 = 7.12777456134E+000 TR2_14 = 1.02502948504E+001 HISTORY WCS added by PinPoint 6.0.6 at 2016-08-08T11:19:06 HISTORY Matched 142 stars from the Gray GSC-ACT Catalog HISTORY Average residual was 0.42 arc-seconds PLTSOLVD = T / Plate has been solved by PinPoint HISTORY Image data was modified, written back to file. ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart at cadair.com Thu Sep 1 05:28:05 2016 From: stuart at cadair.com (Stuart Mumford) Date: Thu, 1 Sep 2016 10:28:05 +0100 Subject: [AstroPy] Python in Astronomy 2017 Conference Message-ID: <718ae307-c1f6-6727-c0d7-454d6b31e72d@cadair.com> Hello all, The 2017 Python in Astronomy conference will be held on 8th - 12th May 2017 at the Lorentz Center in Leiden, the Netherlands. For more information see http://openastronomy.org/pyastro/2017/. Python in Astronomy 2017 aims to bring a wide variety of people who currently use, develop or teach people about Python packages in the context of all forms of Astronomy. The conference will include presentations, tutorials, unconference sessions, and sprints. As well as building the community around astronomical uses of Python, the conference aims to improve collaboration and interoperability between Python packages and share knowledge on Python packages and techniques. It will also provide training and educational materials for users and developers of Python packages.Participant selection will be made with the goal of growingthe Python in Astronomy community and we particularly encourage requests to attend from junior astronomers and people who are new to contributing to open source software. If you are interested in attending and/or have any questions about the conference, please use this form: https://goo.gl/forms/4Y7CB3mDwB6SqgtH2. Further, please nominate people who you think should might benefit from attending and contributing to Python in Astronomy 2017 using this form: https://goo.gl/forms/4Y7CB3mDwB6SqgtH2 Applications from interested participants will open Sept 12th. Stuart Mumford, on behalf of the 2017 SOC -------------- next part -------------- An HTML attachment was scrubbed... URL: From p3y1i4n at gmail.com Thu Sep 1 09:28:07 2016 From: p3y1i4n at gmail.com (Pey Lian Lim) Date: Thu, 1 Sep 2016 09:28:07 -0400 Subject: [AstroPy] AstroPy Digest, Vol 120, Issue 1 In-Reply-To: References: Message-ID: Re: Derek, on the contrary, I prefer the Google mailing list. I never figured out how to reply properly to a conversation in this list since I only get a digest. Also, it is hard to search and browse. Re: Alice, did you try asking the manufacturer about their WCS convention? On Thu, Sep 1, 2016 at 5:28 AM, wrote: > > Today's Topics: > > 1. Re: PR 3655 (Fortran-style and large exponents in ascii.io) > (Derek Homeier) > 2. Distortion coefficients - FITS Header of an image (alice paschal) > 3. Python in Astronomy 2017 Conference (Stuart Mumford) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 31 Aug 2016 22:57:45 +0200 > From: Derek Homeier > To: Astronomical Python mailing list > Subject: Re: [AstroPy] PR 3655 (Fortran-style and large exponents in > ascii.io) > Message-ID: > <14702044-8E25-423B-BD3B-770F43685CDF at astro.physik.uni- > goettingen.de> > Content-Type: text/plain; charset=utf-8 > > As another follow-up to this story, just in case any of the developers are > still following this list, > is it possible at all to sign up to astropy-dev as a normal mailing list? > The only way right now appears to be with ones Google+ account, which is a > major pain at > this point as Google seems unable to restore access to my original account > (which I haven?t > used in years to be fair), but at the same time refuses to link my > preferred mail address to my > backup account, apparently because it is still linked to the lost original > account? > Maybe I am too old-fashioned to join then, but a plain old mailing list > that does not require a > specific provider would still seem a helpful instrument. > > Cheers, > Derek > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aldcroft at head.cfa.harvard.edu Thu Sep 1 10:46:20 2016 From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas) Date: Thu, 1 Sep 2016 10:46:20 -0400 Subject: [AstroPy] PR 3655 (Fortran-style and large exponents in ascii.io) In-Reply-To: <14702044-8E25-423B-BD3B-770F43685CDF@astro.physik.uni-goettingen.de> References: <2A662C22-9D61-4B73-B90F-C942A71C0EB1@astro.physik.uni-goettingen.de> <37B3CF6D-2455-4D31-B987-4A796B34981B@gmail.com> <35D16723-409F-40BE-90A6-61A3B8109994@astro.physik.uni-goettingen.de> <14702044-8E25-423B-BD3B-770F43685CDF@astro.physik.uni-goettingen.de> Message-ID: Hi Derek, You can use any email address to subscribe to the astropy-dev group and there are many examples of non-google accounts in the current group. Have you tried subscribing with your derek at astro.physik.uni-goettingen.de address? - Tom On Wed, Aug 31, 2016 at 4:57 PM, Derek Homeier < derek at astro.physik.uni-goettingen.de> wrote: > On 12 Jul 2016, at 2:54 am, Derek Homeier goettingen.de> wrote: > > > > On 12 Jul 2016, at 2:36 am, Evert Rol wrote: > >> > >> Probably not. > >> There is the astropy developer mailing list, which is separate to this > mailing list(*), but if you've updated the PR, the astropy maintainers > should get informed automatically. > >> Best I can advice, is to keep your PR up-to-date with the current > master, verify all tests still pass on Github, and wait (or possibly ping > people on GitHub through a comment). > >> The PR will need someone to review it, and a knowledgeable reviewer may > not have found time yet to do that. > >> > > Thanks, I had completely missed the -dev list as it is not on the Scipy > archive! > > I commented on the changes made to pass all CI tests a few weeks ago, so > I > > guess I?m just gonna give it a little more time. > > As another follow-up to this story, just in case any of the developers are > still following this list, > is it possible at all to sign up to astropy-dev as a normal mailing list? > The only way right now appears to be with ones Google+ account, which is a > major pain at > this point as Google seems unable to restore access to my original account > (which I haven?t > used in years to be fair), but at the same time refuses to link my > preferred mail address to my > backup account, apparently because it is still linked to the lost original > account? > Maybe I am too old-fashioned to join then, but a plain old mailing list > that does not require a > specific provider would still seem a helpful instrument. > > Cheers, > Derek > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan12343 at gmail.com Thu Sep 1 10:52:39 2016 From: nathan12343 at gmail.com (Nathan Goldbaum) Date: Thu, 1 Sep 2016 09:52:39 -0500 Subject: [AstroPy] PR 3655 (Fortran-style and large exponents in ascii.io) In-Reply-To: <14702044-8E25-423B-BD3B-770F43685CDF@astro.physik.uni-goettingen.de> References: <2A662C22-9D61-4B73-B90F-C942A71C0EB1@astro.physik.uni-goettingen.de> <37B3CF6D-2455-4D31-B987-4A796B34981B@gmail.com> <35D16723-409F-40BE-90A6-61A3B8109994@astro.physik.uni-goettingen.de> <14702044-8E25-423B-BD3B-770F43685CDF@astro.physik.uni-goettingen.de> Message-ID: On Wed, Aug 31, 2016 at 3:57 PM, Derek Homeier < derek at astro.physik.uni-goettingen.de> wrote: > On 12 Jul 2016, at 2:54 am, Derek Homeier goettingen.de> wrote: > > > > On 12 Jul 2016, at 2:36 am, Evert Rol wrote: > >> > >> Probably not. > >> There is the astropy developer mailing list, which is separate to this > mailing list(*), but if you've updated the PR, the astropy maintainers > should get informed automatically. > >> Best I can advice, is to keep your PR up-to-date with the current > master, verify all tests still pass on Github, and wait (or possibly ping > people on GitHub through a comment). > >> The PR will need someone to review it, and a knowledgeable reviewer may > not have found time yet to do that. > >> > > Thanks, I had completely missed the -dev list as it is not on the Scipy > archive! > > I commented on the changes made to pass all CI tests a few weeks ago, so > I > > guess I?m just gonna give it a little more time. > > As another follow-up to this story, just in case any of the developers are > still following this list, > is it possible at all to sign up to astropy-dev as a normal mailing list? > The only way right now appears to be with ones Google+ account, which is a > major pain at > this point as Google seems unable to restore access to my original account > (which I haven?t > used in years to be fair), but at the same time refuses to link my > preferred mail address to my > backup account, apparently because it is still linked to the lost original > account? > Maybe I am too old-fashioned to join then, but a plain old mailing list > that does not require a > specific provider would still seem a helpful instrument. > It appears this was a transient error on google's side, and is now fixed. I saw some discussion about this on another google mailing list i'm subscribed to. > > Cheers, > Derek > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From derek at astro.physik.uni-goettingen.de Thu Sep 1 11:26:17 2016 From: derek at astro.physik.uni-goettingen.de (Derek Homeier) Date: Thu, 1 Sep 2016 17:26:17 +0200 Subject: [AstroPy] PR 3655 (Fortran-style and large exponents in ascii.io) In-Reply-To: References: <2A662C22-9D61-4B73-B90F-C942A71C0EB1@astro.physik.uni-goettingen.de> <37B3CF6D-2455-4D31-B987-4A796B34981B@gmail.com> <35D16723-409F-40BE-90A6-61A3B8109994@astro.physik.uni-goettingen.de> <14702044-8E25-423B-BD3B-770F43685CDF@astro.physik.uni-goettingen.de> Message-ID: Hi Nathan, Tom, thanks for the assistance! > You can use any email address to subscribe to the astropy-dev group and there are many examples of non-google accounts in the current group. Have you tried subscribing with your derek at astro.physik.uni-goettingen.de address? > The only way right now appears to be with ones Google+ account, which is a major pain at > this point as Google seems unable to restore access to my original account (which I haven?t > used in years to be fair), but at the same time refuses to link my preferred mail address to my > backup account, apparently because it is still linked to the lost original account? > Maybe I am too old-fashioned to join then, but a plain old mailing list that does not require a > specific provider would still seem a helpful instrument. > > It appears this was a transient error on google's side, and is now fixed. I saw some discussion about this on another google mailing list i'm subscribed to. > Looks like the error is still there. The page does not offer any visible option to subscribe, and as soon as I try to post or ?administer my email subscriptions? I am made to login to my Google account, which then offers me only the list of addresses registered with Google for signing up to the forum - which excludes my work mail address for the reasons above. Cheers, Derek From thomas.robitaille at gmail.com Thu Sep 1 12:17:51 2016 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Thu, 1 Sep 2016 17:17:51 +0100 Subject: [AstroPy] PR 3655 (Fortran-style and large exponents in ascii.io) In-Reply-To: References: <2A662C22-9D61-4B73-B90F-C942A71C0EB1@astro.physik.uni-goettingen.de> <37B3CF6D-2455-4D31-B987-4A796B34981B@gmail.com> <35D16723-409F-40BE-90A6-61A3B8109994@astro.physik.uni-goettingen.de> <14702044-8E25-423B-BD3B-770F43685CDF@astro.physik.uni-goettingen.de> Message-ID: You should be able to just send an email to: astropy-dev+subscribe at googlegroups.com Cheers, Tom On 1 September 2016 at 16:26, Derek Homeier wrote: > Hi Nathan, Tom, > > thanks for the assistance! > > > You can use any email address to subscribe to the astropy-dev group and > there are many examples of non-google accounts in the current group. Have > you tried subscribing with your derek at astro.physik.uni-goettingen.de > address? > > > The only way right now appears to be with ones Google+ account, which is > a major pain at > > this point as Google seems unable to restore access to my original > account (which I haven?t > > used in years to be fair), but at the same time refuses to link my > preferred mail address to my > > backup account, apparently because it is still linked to the lost > original account? > > Maybe I am too old-fashioned to join then, but a plain old mailing list > that does not require a > > specific provider would still seem a helpful instrument. > > > > It appears this was a transient error on google's side, and is now > fixed. I saw some discussion about this on another google mailing list i'm > subscribed to. > > > Looks like the error is still there. The page does not offer any visible > option to subscribe, and as > soon as I try to post or ?administer my email subscriptions? I am made to > login to my Google account, > which then offers me only the list of addresses registered with Google for > signing up to the forum - > which excludes my work mail address for the reasons above. > > Cheers, > Derek > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From derek at astro.physik.uni-goettingen.de Thu Sep 1 13:09:28 2016 From: derek at astro.physik.uni-goettingen.de (Derek Homeier) Date: Thu, 1 Sep 2016 19:09:28 +0200 Subject: [AstroPy] PR 3655 (Fortran-style and large exponents in ascii.io) In-Reply-To: References: <2A662C22-9D61-4B73-B90F-C942A71C0EB1@astro.physik.uni-goettingen.de> <37B3CF6D-2455-4D31-B987-4A796B34981B@gmail.com> <35D16723-409F-40BE-90A6-61A3B8109994@astro.physik.uni-goettingen.de> <14702044-8E25-423B-BD3B-770F43685CDF@astro.physik.uni-goettingen.de> Message-ID: <611675AC-B123-45E7-B87E-3C39D87A580A@astro.physik.uni-goettingen.de> On 1 Sep 2016, at 6:17 pm, Thomas Robitaille wrote: > > You should be able to just send an email to: > > astropy-dev+subscribe at googlegroups.com > Thanks, that was precisely the bit of information I was looking for. Also available on https://groups.google.com/group/astropy-dev/subscribe Cheers, Derek From alice.pasch at orange.fr Fri Sep 2 10:50:00 2016 From: alice.pasch at orange.fr (alice paschal) Date: Fri, 2 Sep 2016 16:50:00 +0200 (CEST) Subject: [AstroPy] AstroPy Digest, Vol 120, Issue 1 In-Reply-To: References: Message-ID: <1470836961.14393.1472827800803.JavaMail.www@wwinf1d08> Would you have an email address of the manufacturer please ? Because I thought that I could get a contact with the Astropy email address. ? Thank you Alice ? ? > Message du 01/09/16 15:28 > De : "Pey Lian Lim" > A : astropy at scipy.org > Copie ? : > Objet : Re: [AstroPy] AstroPy Digest, Vol 120, Issue 1 > > Re: Derek, on the contrary, I prefer the Google mailing list. I never figured out how to reply properly to a conversation in this list since I only get a digest. Also, it is hard to search and browse. > > Re: Alice, did you try asking the manufacturer about their WCS convention? > > > On Thu, Sep 1, 2016 at 5:28 AM, wrote: > > Today's Topics: > > ? ?1. Re: PR 3655 (Fortran-style and large exponents in ascii.io) > ? ? ? (Derek Homeier) > ? ?2. Distortion coefficients - FITS Header of an image (alice paschal) > ? ?3. Python in Astronomy 2017 Conference (Stuart Mumford) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 31 Aug 2016 22:57:45 +0200 > From: Derek Homeier > To: Astronomical Python mailing list > Subject: Re: [AstroPy] PR 3655 (Fortran-style and large exponents in > ? ? ? ? ascii.io) > Message-ID: > ? ? ? ? <14702044-8E25-423B-BD3B-770F43685CDF at astro.physik.uni-goettingen.de> > Content-Type: text/plain; charset=utf-8 > > As another follow-up to this story, just in case any of the developers are still following this list, > is it possible at all to sign up to astropy-dev as a normal mailing list? > The only way right now appears to be with ones Google+ account, which is a major pain at > this point as Google seems unable to restore access to my original account (which I haven?t > used in years to be fair), but at the same time refuses to link my preferred mail address to my > backup account, apparently because it is still linked to the lost original account? > Maybe I am too old-fashioned to join then, but a plain old mailing list that does not require a > specific provider would still seem a helpful instrument. > > Cheers, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Derek > _______________________________________________ AstroPy mailing list AstroPy at scipy.org https://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.f.evans at keele.ac.uk Fri Sep 2 11:30:50 2016 From: d.f.evans at keele.ac.uk (Daniel Evans) Date: Fri, 2 Sep 2016 16:30:50 +0100 Subject: [AstroPy] Distortion coefficients - FITS Header of an image Message-ID: I believe he was referring to the manufacturer of your astrometry software (PinPoint), not Astropy. As far as I can tell, the TRi_j entries are not part of the FITS WCS definition, nor are they part of the proposed WCS Distortion representation system. Many of the WCS projections and proposed distortion functions use inputs stored in the header as i_j values, but your header doesn't seem to specify what function the TRi_j values are inputs for. To use the values, you would have to find out what function PinPoint is using for distortion correction. However, I doubt astropy.wcs will be very helpful for using that distortion correction, as it only handles FITS headers following the WCS standard. Regards, Daniel On 2 September 2016 at 15:50, alice paschal wrote: > Would you have an email address of the manufacturer please ? Because I > thought that I could get a contact with the Astropy email address. > > > > Thank you > > Alice > > > > > > > Message du 01/09/16 15:28 > > De : "Pey Lian Lim" > > A : astropy at scipy.org > > Copie ? : > > Objet : Re: [AstroPy] AstroPy Digest, Vol 120, Issue 1 > > > > > Re: Derek, on the contrary, I prefer the Google mailing list. I never > figured out how to reply properly to a conversation in this list since I > only get a digest. Also, it is hard to search and browse. > > > > > Re: Alice, did you try asking the manufacturer about their WCS convention? > > > > > > > > On Thu, Sep 1, 2016 at 5:28 AM, wrote: > > > > Today's Topics: > > > > 1. Re: PR 3655 (Fortran-style and large exponents in ascii.io) > > (Derek Homeier) > > 2. Distortion coefficients - FITS Header of an image (alice paschal) > > 3. Python in Astronomy 2017 Conference (Stuart Mumford) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Wed, 31 Aug 2016 22:57:45 +0200 > > From: Derek Homeier > > To: Astronomical Python mailing list > > Subject: Re: [AstroPy] PR 3655 (Fortran-style and large exponents in > > ascii.io) > > Message-ID: > > <14702044-8E25-423B-BD3B-770F43685CDF at astro.physik.uni- > goettingen.de> > > Content-Type: text/plain; charset=utf-8 > > > > As another follow-up to this story, just in case any of the developers > are still following this list, > > is it possible at all to sign up to astropy-dev as a normal mailing list? > > The only way right now appears to be with ones Google+ account, which is > a major pain at > > this point as Google seems unable to restore access to my original > account (which I haven?t > > used in years to be fair), but at the same time refuses to link my > preferred mail address to my > > backup account, apparently because it is still linked to the lost > original account? > > Maybe I am too old-fashioned to join then, but a plain old mailing list > that does not require a > > specific provider would still seem a helpful instrument. > > > > Cheers, > > Derek > > > > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmwalawender at gmail.com Fri Sep 2 21:03:13 2016 From: jmwalawender at gmail.com (Josh Walawender) Date: Fri, 2 Sep 2016 15:03:13 -1000 Subject: [AstroPy] Distortion coefficients - FITS Header of an image In-Reply-To: <1334016614.6385.1472721637578.JavaMail.www@wwinf1d08> References: <1334016614.6385.1472721637578.JavaMail.www@wwinf1d08> Message-ID: Hi Alice, I?ve run in to a similar problem with distortion coefficients from the same software. I worked with a project which was using ACP for telescope control which would solve astrometry using PinPoint. The problem is that there seems to be no simple standard for describing distortions, so there are/were a few ways to do it. The TRi_j standard didn?t seem to catch on and I don?t think it is supported in astropy (or at least it wasn?t when I was looking in to this a year or two ago) In principle one could write a conversion utility to convert the TRi_j keywords to SIP, but I didn?t want to figure out that calculation and my solution in the end was just to re-solve the WCS using something like astrometry.net (which outputs SIP) rather than try to write that conversion package. Hope this helps. -Josh > On Aug 31, 2016, at 11:20 PM, alice paschal wrote: > > Hello, > > > With a telescope, I took sky images in tracking ON. These images were saved in FITS format. > With MaximDL and PinPoint Atsrometry softwares, we can get the FITS Header of each image, i.e. image data (for instance Observation site, CCD camera, focal length, pixels, right ascension of the image center, declination of the image center, etc). I put an example for you (see below at the end of the message). > > What I would like to find is a way to take into account distortion coefficients of an image (we can find them in the FITS Header of the image, see below), in order to convert any pixels of the image into world coordinates, and vice versa. > I am working with Python. > > I have found with Astropy some useful functions, like w.wcs_world2pix to convert world coordinates into pixel coordinates. But would you know which distortion coefficients are taken into account in such a function ? The TRi_j distortion coefficients are they taken into account ? Because I could not find any information on them. I have found only papers like the following ones which are on A, B, AP, AB coefficients but not on TR coefficients : > > http://docs.astropy.org/en/stable/api/astropy.wcs.Sip.html#astropy.wcs.Sip > http://irsa.ipac.caltech.edu/data/SPITZER/docs/files/spitzer/shupeADASS.pdf > > > Thank you in advance for your help. > > Best regards > > Alice > > > > > Example of the FITS Header of an image : > > SIMPLE = T > BITPIX = 16 /8 unsigned int, 16 & 32 int, -32 & -64 real > NAXIS = 2 /number of axes > NAXIS1 = 2184 /fastest changing axis > NAXIS2 = 1472 /next to fastest changing axis > BSCALE = 1.0000000000000000 /physical = BZERO + BSCALE*array_value > BZERO = 0.00000000000000000 /physical = BZERO + BSCALE*array_value > DATE-OBS = '2016-08-03T21:53:34' / [ISO 8601] UTC date/time of exposure start > > > EXPTIME = 4.00000000000E+000 / [sec] Duration of exposure > EXPOSURE = 4.00000000000E+000 / [sec] Duration of exposure > SET-TEMP = -30.000000000000000 /CCD temperature setpoint in C > CCD-TEMP = -29.968750000000000 /CCD temperature at start of exposure in C > XPIXSZ = 6.7999999999999998 /Pixel Width in microns (after binning) > YPIXSZ = 6.7999999999999998 /Pixel Height in microns (after binning) > > > XBINNING = 1 / Binning level along the X-axis > YBINNING = 1 / Binning level along the Y-axis > XORGSUBF = 0 /Subframe X position in binned pixels > YORGSUBF = 0 /Subframe Y position in binned pixels > READOUTM = 'Raw ' / Readout mode of image > IMAGETYP = 'Light Frame' / Type of image > FOCALLEN = 1153.0000000000000 /Focal length of telescope in mm > APTDIA = 254.00000000000000 /Aperture diameter of telescope in mm > APTAREA = 50670.749319791794 /Aperture area of telescope in mm^2 > EGAIN = 0.80000001192092896 /Electronic gain in e-/ADU > SBSTDVER = 'SBFITSEXT Version 1.0' /Version of SBFITSEXT standard in effect > SWCREATE = 'MaxIm DL Version 6.08 160505 1A3Q6' /Name of software > SWSERIAL = '1A3Q6-HWHSQ-A0990-J2QRF-SUTCT-QC' /Software serial number > > > OBJCTRA = '21 28 50.00' / [hms J2000] Target right ascension > OBJCTDEC = '-06 44 12.0' / [dms +N J2000] Target declination > OBJCTALT = ' 30.8774' / Nominal altitude of center of image > OBJCTAZ = '139.4337' / Nominal azimuth of center of image > OBJCTHA = ' -2.2794' / Nominal hour angle of center of image > SITELAT = '43 45 11' / Latitude of the imaging location > SITELONG = '06 55 18' / Longitude of the imaging location > JD = 2457604.4121990739 /Julian Date at start of exposure > JD-HELIO = 2457604.4179293886 /Heliocentric Julian Date at exposure midpoint > > AIRMASS = 1.94149884803E+000 / Airmass (multiple of zenithal airmass) > OBJECT = ' ' / Target object name > TELESCOP = ' ' / Telescope name > INSTRUME = 'SBIG STT-3200 3 CCD Camera' / Detector instrument name > > OBSERVER = ' ' / Observer name > NOTES = ' ' > FLIPSTAT = ' ' > SWOWNER = 'THALES ALENIA SPACE FRANCE' /Licensed owner of software > INPUTFMT = 'FITS ' / Format of file from which image was read > > HISTORY File was processed by PinPoint 6.0.6 at 2016-08-08T11:19:06 > DATE = '03/08/16' / [old format] UTC date of exposure start > TIME-OBS = '21:53:34' / [old format] UTC time of exposure start > UT = '21:53:34' / [old format] UTC time of exposure start > TIMESYS = 'UTC ' / Default time system > RADECSYS = 'FK5 ' / Equatorial coordinate system > RA = '21 28 50.00' / [hms J2000] Target right ascension > DEC = '-06 44 12.0' / [dms +N J2000] Target declination > FWHM = 3.31912333965E+000 / [pixels] Mean Full-Width-Half-Max of image star > ZMAG = 2.22695229625E+001 / Mag zero point for 1 sec exposure > EQUINOX = 2000.0 / Equatorial coordinates are J2000 > EPOCH = 2000.0 / (incorrect but needed by old programs) > PA = 3.58967846401E+002 / [deg, 0-360 CCW] Position angle of plate > CTYPE1 = 'RA---TAN' / X-axis coordinate type > CRVAL1 = 3.22235640938E+002 / X-axis coordinate value > CRPIX1 = 1.09200000000E+003 / X-axis reference pixel > CDELT1 = -3.37671457816E-004 / [deg/pixel] X-axis plate scale > CROTA1 = 1.03215359918E+000 / [deg] Roll angle wrt X-axis > CTYPE2 = 'DEC--TAN' / Y-axis coordinate type > CRVAL2 = -6.73039453583E+000 / Y-axis coordinate value > CRPIX2 = 7.36000000000E+002 / Y-axis reference pixel > CDELT2 = -3.38006539857E-004 / [deg/pixel] Y-Axis Plate scale > CROTA2 = 1.03215359918E+000 / [deg] Roll angle wrt Y-axis > CD1_1 = -3.37616668483E-004 / Change in RA---TAN along X-Axis > CD1_2 = 6.08868227955E-006 / Change in RA---TAN along Y-Axis > CD2_1 = -6.08264627773E-006 / Change in DEC--TAN along X-Axis > CD2_2 = -3.37951696156E-004 / Change in DEC--TAN along Y-Axis > TR1_0 = 1.09199958073E+003 / [private] X-axis distortion coefficients > TR1_1 = 2.18399991151E+003 > TR1_2 = -6.18827693341E-001 > TR1_3 = -1.23992354888E+000 > TR1_4 = -1.21460280616E+000 > TR1_5 = -1.17006143126E+000 > TR1_6 = -2.36278669552E+001 > TR1_7 = 8.13968772630E-001 > TR1_8 = -1.05987616323E+001 > TR1_9 = -2.51664136543E+000 > TR1_10 = 7.75126811018E+000 > TR1_11 = 1.11725347231E+000 > TR1_12 = -1.15863502104E+000 > TR1_13 = 2.78034135924E+000 > TR1_14 = 5.04818239812E+000 > TR2_0 = 7.36000000896E+002 / [private] Y-axis distortion coefficients > TR2_1 = -1.38948258924E-003 > TR2_2 = 1.47200000121E+003 > TR2_3 = -1.74854087048E+000 > TR2_4 = 3.06867323249E-001 > TR2_5 = -2.74476247742E+000 > TR2_6 = -2.95895994527E-001 > TR2_7 = -1.76582177998E+001 > TR2_8 = 2.41056596524E-001 > TR2_9 = -1.34421356097E+001 > TR2_10 = 6.81670566601E+000 > TR2_11 = -2.72087350085E+000 > TR2_12 = -2.86227884736E+000 > TR2_13 = 7.12777456134E+000 > TR2_14 = 1.02502948504E+001 > HISTORY WCS added by PinPoint 6.0.6 at 2016-08-08T11:19:06 > HISTORY Matched 142 stars from the Gray GSC-ACT Catalog > HISTORY Average residual was 0.42 arc-seconds > PLTSOLVD = T / Plate has been solved by PinPoint > HISTORY Image data was modified, written back to file. > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From p3y1i4n at gmail.com Sat Sep 3 08:44:11 2016 From: p3y1i4n at gmail.com (Pey Lian Lim) Date: Sat, 3 Sep 2016 08:44:11 -0400 Subject: [AstroPy] AstroPy Digest, Vol 120, Issue 4 In-Reply-To: References: Message-ID: A quick search on the Internet brought up this page: http://www.cyanogen.com/help/maximdl/PinPoint_Astrometry.htm Which implies using this support page: http://www.cyanogen.com/support.php Good luck. On Fri, Sep 2, 2016 at 9:03 PM, wrote: > > Would you have an email address of the manufacturer please ? Because I > thought that I could get a contact with the Astropy email address. > > ? > > Thank you > > Alice > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gijsmolenaar at gmail.com Tue Sep 13 10:44:09 2016 From: gijsmolenaar at gmail.com (Gijs Molenaar) Date: Tue, 13 Sep 2016 16:44:09 +0200 Subject: [AstroPy] astropy fits time header Message-ID: Hi! I noticed that when we use astropy Time fits formatting the time formatting looks like this: "2016-08-18T14:10:24.695(UTC)" I think this is actually not according to the fits specification: https://archive.stsci.edu/fits/fits_standard/node87.html#s:tsys I noticed this problem when we tried to parse DATE-OBS of such a fits file, we used to be able to parse it with dateutil.parse, but fits files created with this astropy fits format we can't anymore. Maybe I am wrong? greetings, -- Gijs Molenaar http://pythonic.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From demitri.muna at gmail.com Tue Sep 13 11:02:48 2016 From: demitri.muna at gmail.com (Demitri Muna) Date: Tue, 13 Sep 2016 11:02:48 -0400 Subject: [AstroPy] astropy fits time header In-Reply-To: References: Message-ID: <4F1B6593-EBF1-4D80-906D-4670CFE52CB0@gmail.com> Hi Gijs, On Sep 13, 2016, at 10:44 AM, Gijs Molenaar wrote: > I noticed that when we use astropy Time fits formatting the time formatting looks like this: > > "2016-08-18T14:10:24.695(UTC)" > > I think this is actually not according to the fits specification: > > https://archive.stsci.edu/fits/fits_standard/node87.html#s:tsys > > I noticed this problem when we tried to parse DATE-OBS of such a fits file, we used to be able to parse it with dateutil.parse, but fits files created with this astropy fits format we can't anymore. > > Maybe I am wrong? That format is (almost) correct. First, the definitive source of the FITS specification is here, not at STScI: http://fits.gsfc.nasa.gov/fits_standard.html The documentation says this: > DATE keyword. The value field shall contain a character string giving the date on which the HDU was created, in the form YYYY-MM-DD, or the date and time when the HDU was created, in the form YYYY-MM-DDThh:mm:ss[.sss. . . ], where YYYY shall be the four-digit calendar year number, MM the two-digit month number with January given by 01 and December by 12, and DD the two-digit day of the month. When both date and time are given, the literal T shall separate the date and time, hh shall be the two-digit hour in the day, mm the two-digit number of min- utes after the hour, and ss[.sss. . . ] the number of seconds (two digits followed by an optional fraction) after the minute. Default values must not be given to any portion of the date/time string, and leading zeros must not be omitted. The decimal part of the seconds field is optional and may be arbitrarily long, so long as it is consistent with the rules for value formats of Sect. 4.2. > > The value of the DATE keyword shall always be expressed in UTC when in this format, for all data sets created on Earth. This matches the ISO 8601 date format (yay standards!): https://en.wikipedia.org/wiki/ISO_8601 The exception above is that the string "(UTC)" should *not* be part of the date above. Note that this is the definition for the DATE keyword - anyone can define their own keyword and put whatever format they want, but I'd highly recommend sticking with what's prescribed above, i.e. ISO 8601 in UTC. So it depends on what keyword you are using. It's unfortunate that it says that a string like '14/10/96' is acceptable. I'm writing a FITS viewer and run fitsverify on every file loaded. Incorrect date formatting is one of the most common reasons I see for a file failing a fitsverify analysis. Please note that files that don't pass fitsverify are technically not valid FITS files. https://heasarc.gsfc.nasa.gov/docs/software/ftools/fitsverify/ Demitri _________________________________________ Demitri Muna http://muna.com Department of Astronomy Le Ohio State University My Projects: http://nightlightapp.io http://trillianverse.org http://scicoder.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From gijsmolenaar at gmail.com Tue Sep 13 11:08:50 2016 From: gijsmolenaar at gmail.com (Gijs Molenaar) Date: Tue, 13 Sep 2016 17:08:50 +0200 Subject: [AstroPy] astropy fits time header In-Reply-To: <4F1B6593-EBF1-4D80-906D-4670CFE52CB0@gmail.com> References: <4F1B6593-EBF1-4D80-906D-4670CFE52CB0@gmail.com> Message-ID: 2016-09-13 17:02 GMT+02:00 Demitri Muna : > [...] > > The exception above is that the string "(UTC)" should *not* be part of the > date above. > indeed, I forgot to mention it is the "(UCT)" part that breaks the naive dateutil parsing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From teuben at astro.umd.edu Tue Sep 13 11:20:40 2016 From: teuben at astro.umd.edu (Peter Teuben) Date: Tue, 13 Sep 2016 11:20:40 -0400 Subject: [AstroPy] astropy fits time header In-Reply-To: <4F1B6593-EBF1-4D80-906D-4670CFE52CB0@gmail.com> References: <4F1B6593-EBF1-4D80-906D-4670CFE52CB0@gmail.com> Message-ID: Re: "It's unfortunate that it says that a string like '14/10/96' is acceptable." that's the "once fits, always fits" rule. It's not unfortunate, it's fortunate!! (if not a bit annoying for code writers) the fits verify better not fail on this one. If the DATE is of this old style format, you might also see a TIME keyword. On 09/13/2016 11:02 AM, Demitri Muna wrote: > Hi Gijs, > > On Sep 13, 2016, at 10:44 AM, Gijs Molenaar > wrote: > >> I noticed that when we use astropy Time fits formatting the time formatting looks like this: >> >> "2016-08-18T14:10:24.695(UTC)" >> I think this is actually not according to the fits specification: >> https://archive.stsci.edu/fits/fits_standard/node87.html#s:tsys >> I noticed this problem when we tried to parse DATE-OBS of such a fits file, we used to be able to parse it with dateutil.parse, but fits files created with this astropy fits format we can't anymore. >> Maybe I am wrong? > > That format is (almost) correct. First, the definitive source of the FITS specification is here, not at STScI: > > http://fits.gsfc.nasa.gov/fits_standard.html > > The documentation says this: > >> DATE keyword. The value field shall contain a character string giving the date on which the HDU was created, in the form YYYY-MM-DD, or the date and time when the HDU was created, in the form YYYY-MM-DDThh:mm:ss[.sss. . . ], where YYYY shall be the four-digit calendar year number, MM the two-digit month number with January given by 01 and December by 12, and DD the two-digit day of the month. When both date and time are given, the literal T shall separate the date and time, hh shall be the two-digit hour in the day, mm the two-digit number of min- utes after the hour, and ss[.sss. . . ] the number of seconds (two digits followed by an optional fraction) after the minute. Default values must not be given to any portion of the date/time string, and leading zeros must not be omitted. The decimal part of the seconds field is optional and may be arbitrarily long, so long as it is consistent with the rules for value formats of Sect. 4.2. >> >> The value of the DATE keyword shall always be expressed in UTC when in this format, for all data sets created on Earth. > > This matches the ISO 8601 date format (yay standards!): > > https://en.wikipedia.org/wiki/ISO_8601 > > The exception above is that the string "(UTC)" should *not* be part of the date above. Note that this is the definition for the DATE keyword - anyone can define their own keyword and put whatever format they want, but I'd highly recommend sticking with what's prescribed above, i.e. ISO 8601 in UTC. So it depends on what keyword you are using. It's unfortunate that it says that a string like '14/10/96' is acceptable. > > I'm writing a FITS viewer and run fitsverify on every file loaded. Incorrect date formatting is one of the most common reasons I see for a file failing a fitsverify analysis. Please note that files that don't pass fitsverify are technically not valid FITS files. > > https://heasarc.gsfc.nasa.gov/docs/software/ftools/fitsverify/ > > Demitri > > _________________________________________ > Demitri Muna > http://muna.com > > Department of Astronomy > Le Ohio State University > > My Projects: > http://nightlightapp.io > http://trillianverse.org > http://scicoder.org > > > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From demitri.muna at gmail.com Tue Sep 13 11:33:18 2016 From: demitri.muna at gmail.com (Demitri Muna) Date: Tue, 13 Sep 2016 11:33:18 -0400 Subject: [AstroPy] astropy fits time header In-Reply-To: References: <4F1B6593-EBF1-4D80-906D-4670CFE52CB0@gmail.com> Message-ID: <80CEFB8F-1F61-4AFE-A5FA-22BB8EC6EA84@gmail.com> Hi Peter, On Sep 13, 2016, at 11:20 AM, Peter Teuben wrote: > Re: "It's unfortunate that it says that a string like '14/10/96' is acceptable." > > that's the "once fits, always fits" rule. It's not unfortunate, it's fortunate!! (if not a bit annoying for code writers) > the fits verify better not fail on this one. If the DATE is of this old style format, you might also see a TIME keyword. Can you clarify this? Are you saying that the "old style" was part of the specification and is no longer? That seems unlikely - FITS is the Katamari Damacy of file formats. fitsverify is written by Bill Pence (as in "ciftsio Bill Pence"), so I find it unlikely that it flags something as invalid that is valid. Can you point to a (non-STScI) source that says that '14/10/96' is an acceptable format? Cheers, Demitri _________________________________________ Demitri Muna http://muna.com Department of Astronomy Le Ohio State University My Projects: http://nightlightapp.io http://trillianverse.org http://scicoder.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart at cadair.com Tue Sep 13 11:39:13 2016 From: stuart at cadair.com (Stuart Mumford) Date: Tue, 13 Sep 2016 16:39:13 +0100 Subject: [AstroPy] Applications for Python in Astronomy 2017 Now Open Message-ID: <017e6fbd-d7c7-45e0-8971-07c97c50bef8@cadair.com> Hello all, Applications are now being accepted for the 2017 Python in Astronomy conference. The conference will be held on 8th - 12th May 2017 at the Lorentz Center in Leiden, the Netherlands. Applications to attend Python in Astronomy 2017 are now open until December 9th 2016: Application Form . The Python in Astronomy conferences aim to bring a wide variety of people who currently use, develop or teach people about Python packages in the context of all forms of Astronomy. Participant selection will be made with the goal of growingthe Python in Astronomy community and we particularly encourage requests to attend from junior astronomers and people who are new to contributing to open source software. This conference is neither intended to be an introduction to Python bootcamp nor only for expert-level Python developers, but we do expect all participants to have at least a basic familiarity with Python. Stuart Mumford, SOC Chair Matt Craig Kelle Cruz Daniela Huppenkothen Abigail Stevens Erik Tollerud -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgarwood at nrao.edu Tue Sep 13 11:53:51 2016 From: bgarwood at nrao.edu (Bob Garwood) Date: Tue, 13 Sep 2016 11:53:51 -0400 Subject: [AstroPy] astropy fits time header In-Reply-To: <80CEFB8F-1F61-4AFE-A5FA-22BB8EC6EA84@gmail.com> References: <4F1B6593-EBF1-4D80-906D-4670CFE52CB0@gmail.com> <80CEFB8F-1F61-4AFE-A5FA-22BB8EC6EA84@gmail.com> Message-ID: <57D8210F.8090306@nrao.edu> This is the FITS Y2K agreement approved by the IAU-FWG prior to 2000. It shows that the old style 'DD/MM/YY' remains an acceptable form for dates prior to 2000. http://fits.gsfc.nasa.gov/year2000.html According to the FITS standard document (also at GSFC, see the link in Peter's e-mail) that form should not be used in FITS files produced after 1 January 2000. But it's still valid FITS. Because "once fits, always fits". Bob On 09/13/2016 11:33 AM, Demitri Muna wrote: > Hi Peter, > > On Sep 13, 2016, at 11:20 AM, Peter Teuben > wrote: > >> Re: "It's unfortunate that it says that a string like '14/10/96' is >> acceptable." >> >> that's the "once fits, always fits" rule. It's not unfortunate, it's >> fortunate!! (if not a bit annoying for code writers) >> the fits verify better not fail on this one. If the DATE is of this >> old style format, you might also see a TIME keyword. > > Can you clarify this? Are you saying that the "old style" was part of > the specification and is no longer? That seems unlikely - FITS is > the Katamari Damacy of file formats. fitsverify is written by Bill > Pence (as in "ciftsio Bill Pence"), so I find it unlikely that it > flags something as invalid that is valid. Can you point to a > (non-STScI) source that says that '14/10/96' is an acceptable format? > > Cheers, > Demitri > > _________________________________________ > Demitri Muna > http://muna.com > > Department of Astronomy > Le Ohio State University > > My Projects: > http://nightlightapp.io > http://trillianverse.org > http://scicoder.org > > > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From demitri.muna at gmail.com Tue Sep 13 12:08:37 2016 From: demitri.muna at gmail.com (Demitri Muna) Date: Tue, 13 Sep 2016 12:08:37 -0400 Subject: [AstroPy] astropy fits time header In-Reply-To: <57D8210F.8090306@nrao.edu> References: <4F1B6593-EBF1-4D80-906D-4670CFE52CB0@gmail.com> <80CEFB8F-1F61-4AFE-A5FA-22BB8EC6EA84@gmail.com> <57D8210F.8090306@nrao.edu> Message-ID: On Sep 13, 2016, at 11:53 AM, Bob Garwood wrote: > This is the FITS Y2K agreement approved by the IAU-FWG prior to 2000. It shows that the old style 'DD/MM/YY' remains an acceptable form for dates prior to 2000. > > http://fits.gsfc.nasa.gov/year2000.html > > According to the FITS standard document (also at GSFC, see the link in Peter's e-mail) that form should not be used in FITS files produced after 1 January 2000. But it's still valid FITS. Because "once fits, always fits". Fair enough! It was actually the next paragraph from what I quoted earlier, my apologies. I'll have to keep an eye out for files written after 2000 that use that format to see what fitsverify says. That of course means that it is no longer correct to write files with that date format. Demitri _________________________________________ Demitri Muna http://muna.com Department of Astronomy Il Ohio State University My Projects: http://nightlightapp.io http://trillianverse.org http://scicoder.org From rowen at uw.edu Tue Sep 13 12:17:37 2016 From: rowen at uw.edu (Russell Owen) Date: Tue, 13 Sep 2016 09:17:37 -0700 Subject: [AstroPy] astropy fits time header In-Reply-To: <4F1B6593-EBF1-4D80-906D-4670CFE52CB0@gmail.com> References: <4F1B6593-EBF1-4D80-906D-4670CFE52CB0@gmail.com> Message-ID: <6730C583-AD5F-4586-9624-4818D1BBA25A@uw.edu> To add a bit to what Demitri said: yes DATE (the date at which the HDU was created) is always UTC, but other DATExxxx keywords such as DATE-OBS and DATE-AVG can be in time systems other than UTC. However, you have to specify the time system using the TIMESYS keyword; neither time system nor time zone information can be included in the DATExxxx keyword data. ? Russell > On Sep 13, 2016, at 8:02 AM, Demitri Muna wrote: > > Hi Gijs, > > On Sep 13, 2016, at 10:44 AM, Gijs Molenaar > wrote: > >> I noticed that when we use astropy Time fits formatting the time formatting looks like this: >> >> "2016-08-18T14:10:24.695(UTC)" >> >> I think this is actually not according to the fits specification: >> >> https://archive.stsci.edu/fits/fits_standard/node87.html#s:tsys >> >> I noticed this problem when we tried to parse DATE-OBS of such a fits file, we used to be able to parse it with dateutil.parse, but fits files created with this astropy fits format we can't anymore. >> >> Maybe I am wrong? > > That format is (almost) correct. First, the definitive source of the FITS specification is here, not at STScI: > > http://fits.gsfc.nasa.gov/fits_standard.html > > The documentation says this: > >> DATE keyword. The value field shall contain a character string giving the date on which the HDU was created, in the form YYYY-MM-DD, or the date and time when the HDU was created, in the form YYYY-MM-DDThh:mm:ss[.sss. . . ], where YYYY shall be the four-digit calendar year number, MM the two-digit month number with January given by 01 and December by 12, and DD the two-digit day of the month. When both date and time are given, the literal T shall separate the date and time, hh shall be the two-digit hour in the day, mm the two-digit number of min- utes after the hour, and ss[.sss. . . ] the number of seconds (two digits followed by an optional fraction) after the minute. Default values must not be given to any portion of the date/time string, and leading zeros must not be omitted. The decimal part of the seconds field is optional and may be arbitrarily long, so long as it is consistent with the rules for value formats of Sect. 4.2. >> >> The value of the DATE keyword shall always be expressed in UTC when in this format, for all data sets created on Earth. > > This matches the ISO 8601 date format (yay standards!): > > https://en.wikipedia.org/wiki/ISO_8601 > > The exception above is that the string "(UTC)" should *not* be part of the date above. Note that this is the definition for the DATE keyword - anyone can define their own keyword and put whatever format they want, but I'd highly recommend sticking with what's prescribed above, i.e. ISO 8601 in UTC. So it depends on what keyword you are using. It's unfortunate that it says that a string like '14/10/96' is acceptable. > > I'm writing a FITS viewer and run fitsverify on every file loaded. Incorrect date formatting is one of the most common reasons I see for a file failing a fitsverify analysis. Please note that files that don't pass fitsverify are technically not valid FITS files. > > https://heasarc.gsfc.nasa.gov/docs/software/ftools/fitsverify/ > > Demitri > > _________________________________________ > Demitri Muna > http://muna.com > > Department of Astronomy > Le Ohio State University > > My Projects: > http://nightlightapp.io > http://trillianverse.org > http://scicoder.org > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidnidever at gmail.com Tue Sep 13 15:05:36 2016 From: davidnidever at gmail.com (David Nidever) Date: Tue, 13 Sep 2016 12:05:36 -0700 Subject: [AstroPy] astropy and photutils slow Message-ID: Hi all, I'm pretty new to astropy and to python in general. I've been trying out some of the astropy and photutils photometry tools, but I'm finding that they are running pretty slow. I wanted to double-check that I'm not doing something wrong. Below is an example of running the astropy sigma clipped statistics routine on a fake 2Kx4K image (since I'm working on DECam data). This takes almost 20s to run even though similar statistics using numpy take ~0.1s or so. >>> import numpy as np >>> from astropy.stats import sigma_clipped_stats >>> im = np.random.rand(4096,2048)*10.0+100.0 >>> timeit mean, median, std = sigma_clipped_stats(im, sigma=3.0, iters=5) 1 loop, best of 3: 18.9 s per loop It seems like it might be the use of the numpy masked array module that is slowing things down. Just using the masked array median versus the normal numpy median takes ~30x longer. >>> timeit np.median(im) 10 loops, best of 3: 109 ms per loop >>> timeit np.ma.median(im) 1 loop, best of 3: 2.71 s per loop I'm finding similar speed issues with the photutils routines (e.g. background2D) that I believe also use masked arrays. Is there something I can do to speed things up? Thanks! David -- Dr. David Lee Nidever Survey Data Scientist, NOAO 950 N. Cherry Ave. Tucson, AZ 85719 (520) 318-8368 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephenbailey at lbl.gov Tue Sep 13 16:17:18 2016 From: stephenbailey at lbl.gov (Stephen Bailey) Date: Tue, 13 Sep 2016 13:17:18 -0700 Subject: [AstroPy] astropy and photutils slow In-Reply-To: References: Message-ID: What version of numpy and astropy do you have? (numpy.__version__ and astropy.__version__). As another data point, using numpy/1.11.1 and astropy/1.2.1 I get much faster results than you: On Tue, Sep 13, 2016 at 12:05 PM, David Nidever wrote: > Hi all, > > I'm pretty new to astropy and to python in general. I've been trying out > some of the astropy and photutils photometry tools, but I'm finding that > they > are running pretty slow. I wanted to double-check that I'm not doing > something > wrong. > > Below is an example of running the astropy sigma clipped statistics routine > on a fake 2Kx4K image (since I'm working on DECam data). This takes > almost 20s to run even though similar statistics using numpy take ~0.1s > or so. > > >>> import numpy as np > >>> from astropy.stats import sigma_clipped_stats > >>> im = np.random.rand(4096,2048)*10.0+100.0 > >>> timeit mean, median, std = sigma_clipped_stats(im, sigma=3.0, iters=5) > 1 loop, best of 3: 18.9 s per loop > 1.84s per loop for me. Still slow, but not 18.9s. > It seems like it might be the use of the numpy masked array module that is > slowing things down. Just using the masked array median versus the > normal numpy median takes ~30x longer. > > >>> timeit np.median(im) > 10 loops, best of 3: 109 ms per loop > 103 ms for me; i.e. this isn't just that I have a super fast machine and you have a super slow one. > >>> timeit np.ma.median(im) > 1 loop, best of 3: 2.71 s per loop > 104 ms for me. i.e. with numpy 1.11.1 I don't see a radical difference between masked array or not. Stephen > > I'm finding similar speed issues with the photutils routines (e.g. > background2D) > that I believe also use masked arrays. > > Is there something I can do to speed things up? > > Thanks! > David > > -- > Dr. David Lee Nidever > Survey Data Scientist, NOAO > 950 N. Cherry Ave. > Tucson, AZ 85719 > (520) 318-8368 > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidnidever at gmail.com Tue Sep 13 17:47:40 2016 From: davidnidever at gmail.com (David Nidever) Date: Tue, 13 Sep 2016 14:47:40 -0700 Subject: [AstroPy] astropy and photutils slow In-Reply-To: References: Message-ID: Hi Stephen, This is what I had: In [7]: np.__version__ Out[7]: '1.8.0rc1' In [10]: astropy.__version__ Out[10]: u'1.2.1' and I'm using python 2.7. I upgraded to the newest version and I'm finding a similar performance to what you showed. Thanks! David On Tue, Sep 13, 2016 at 1:17 PM, Stephen Bailey wrote: > What version of numpy and astropy do you have? (numpy.__version__ and > astropy.__version__). > > As another data point, using numpy/1.11.1 and astropy/1.2.1 I get much > faster results than you: > > On Tue, Sep 13, 2016 at 12:05 PM, David Nidever > wrote: > >> Hi all, >> >> I'm pretty new to astropy and to python in general. I've been trying out >> some of the astropy and photutils photometry tools, but I'm finding that >> they >> are running pretty slow. I wanted to double-check that I'm not doing >> something >> wrong. >> >> Below is an example of running the astropy sigma clipped statistics >> routine >> on a fake 2Kx4K image (since I'm working on DECam data). This takes >> almost 20s to run even though similar statistics using numpy take ~0.1s >> or so. >> >> >>> import numpy as np >> >>> from astropy.stats import sigma_clipped_stats >> >>> im = np.random.rand(4096,2048)*10.0+100.0 >> >>> timeit mean, median, std = sigma_clipped_stats(im, sigma=3.0, iters=5) >> 1 loop, best of 3: 18.9 s per loop >> > > 1.84s per loop for me. Still slow, but not 18.9s. > > >> It seems like it might be the use of the numpy masked array module that is >> slowing things down. Just using the masked array median versus the >> normal numpy median takes ~30x longer. >> >> >>> timeit np.median(im) >> 10 loops, best of 3: 109 ms per loop >> > > 103 ms for me; i.e. this isn't just that I have a super fast machine and > you have a super slow one. > > >> >>> timeit np.ma.median(im) >> 1 loop, best of 3: 2.71 s per loop >> > > 104 ms for me. i.e. with numpy 1.11.1 I don't see a radical difference > between masked array or not. > > Stephen > > >> >> I'm finding similar speed issues with the photutils routines (e.g. >> background2D) >> that I believe also use masked arrays. >> >> Is there something I can do to speed things up? >> >> Thanks! >> David >> >> -- >> Dr. David Lee Nidever >> Survey Data Scientist, NOAO >> 950 N. Cherry Ave. >> Tucson, AZ 85719 >> (520) 318-8368 >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> https://mail.scipy.org/mailman/listinfo/astropy >> >> > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > -- Dr. David Lee Nidever Survey Data Scientist, NOAO 950 N. Cherry Ave. Tucson, AZ 85719 (520) 318-8368 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan12343 at gmail.com Tue Sep 13 18:14:26 2016 From: nathan12343 at gmail.com (Nathan Goldbaum) Date: Tue, 13 Sep 2016 17:14:26 -0500 Subject: [AstroPy] astropy and photutils slow In-Reply-To: References: Message-ID: Hi David, On Tue, Sep 13, 2016 at 4:47 PM, David Nidever wrote: > Hi Stephen, > > This is what I had: > > In [7]: np.__version__ > Out[7]: '1.8.0rc1' > > This version indicates to me that you're using the Apple system python (e.g. /usr/bin/python on OSX). I want to strongly encourage you to avoid using the system python, since it's possible to actually break the operating system by using it. In addition, the apple system python in particular has a number of questionable aspects (including a pre-release version of Numpy 1.8.0 out of the box is one example) and this leads to a number of weird issues that can be avoided by simply not using it. Instead, try to install python from a package manager like homebrew or macports or use a self-contained python environment from e.g. Anaconda. -Nathan > In [10]: astropy.__version__ > Out[10]: u'1.2.1' > > and I'm using python 2.7. > > I upgraded to the newest version and I'm finding a similar > performance to what you showed. > > Thanks! > David > > > On Tue, Sep 13, 2016 at 1:17 PM, Stephen Bailey > wrote: > >> What version of numpy and astropy do you have? (numpy.__version__ and >> astropy.__version__). >> >> As another data point, using numpy/1.11.1 and astropy/1.2.1 I get much >> faster results than you: >> >> On Tue, Sep 13, 2016 at 12:05 PM, David Nidever >> wrote: >> >>> Hi all, >>> >>> I'm pretty new to astropy and to python in general. I've been trying out >>> some of the astropy and photutils photometry tools, but I'm finding that >>> they >>> are running pretty slow. I wanted to double-check that I'm not doing >>> something >>> wrong. >>> >>> Below is an example of running the astropy sigma clipped statistics >>> routine >>> on a fake 2Kx4K image (since I'm working on DECam data). This takes >>> almost 20s to run even though similar statistics using numpy take ~0.1s >>> or so. >>> >>> >>> import numpy as np >>> >>> from astropy.stats import sigma_clipped_stats >>> >>> im = np.random.rand(4096,2048)*10.0+100.0 >>> >>> timeit mean, median, std = sigma_clipped_stats(im, sigma=3.0, >>> iters=5) >>> 1 loop, best of 3: 18.9 s per loop >>> >> >> 1.84s per loop for me. Still slow, but not 18.9s. >> >> >>> It seems like it might be the use of the numpy masked array module that >>> is >>> slowing things down. Just using the masked array median versus the >>> normal numpy median takes ~30x longer. >>> >>> >>> timeit np.median(im) >>> 10 loops, best of 3: 109 ms per loop >>> >> >> 103 ms for me; i.e. this isn't just that I have a super fast machine and >> you have a super slow one. >> >> >>> >>> timeit np.ma.median(im) >>> 1 loop, best of 3: 2.71 s per loop >>> >> >> 104 ms for me. i.e. with numpy 1.11.1 I don't see a radical difference >> between masked array or not. >> >> Stephen >> >> >>> >>> I'm finding similar speed issues with the photutils routines (e.g. >>> background2D) >>> that I believe also use masked arrays. >>> >>> Is there something I can do to speed things up? >>> >>> Thanks! >>> David >>> >>> -- >>> Dr. David Lee Nidever >>> Survey Data Scientist, NOAO >>> 950 N. Cherry Ave. >>> Tucson, AZ 85719 >>> (520) 318-8368 >>> >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at scipy.org >>> https://mail.scipy.org/mailman/listinfo/astropy >>> >>> >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> https://mail.scipy.org/mailman/listinfo/astropy >> >> > > > -- > Dr. David Lee Nidever > Survey Data Scientist, NOAO > 950 N. Cherry Ave. > Tucson, AZ 85719 > (520) 318-8368 > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gijsmolenaar at gmail.com Wed Sep 14 04:03:32 2016 From: gijsmolenaar at gmail.com (Gijs Molenaar) Date: Wed, 14 Sep 2016 10:03:32 +0200 Subject: [AstroPy] astropy fits time header In-Reply-To: <6730C583-AD5F-4586-9624-4818D1BBA25A@uw.edu> References: <4F1B6593-EBF1-4D80-906D-4670CFE52CB0@gmail.com> <6730C583-AD5F-4586-9624-4818D1BBA25A@uw.edu> Message-ID: I've opened up a bug report https://github.com/astropy/astropy/issues/5329 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gb.gabrielebrambilla at gmail.com Thu Sep 22 18:30:38 2016 From: gb.gabrielebrambilla at gmail.com (Gabriele Brambilla) Date: Thu, 22 Sep 2016 18:30:38 -0400 Subject: [AstroPy] drizzle on astropy Message-ID: Hi, I would like to see how an image get deformed if I know how its coordinates are deformed. A friend suggested me to look into drizzle in astropy... for example: here I draw a circle import numpy as npimport matplotlib.pyplot as pltfrom math import * plane_side = 500.0 #arcsec y_l, x_l, = np.mgrid[-plane_side:plane_side:1000j, -plane_side:plane_side:1000j] r = np.sqrt(y_l**2 + x_l**2) indexes1 = np.where(r<150.0) indexes2 = np.where(r>160.0) image = r.copy() image[:,:] = 1.0 image[indexes1] = 0.0 image[indexes2] = 0.0 imgplot = plt.imshow(image,cmap="rainbow") plt.colorbar() plt.show() If I want to deform the coordinates like this: y_c = y_lense**3 x_c = x_lense**2 and plot the image distorted. Do you have any hint? Thanks GB -------------- next part -------------- An HTML attachment was scrubbed... URL: From rowen at uw.edu Mon Sep 26 14:37:56 2016 From: rowen at uw.edu (Russell Owen) Date: Mon, 26 Sep 2016 11:37:56 -0700 Subject: [AstroPy] How to read and write keyword with no value with astropy.io.fits? Message-ID: <555E96AF-2B30-4A2A-8E25-9225AE9E86B4@uw.edu> In a FITS header an unknown value can be represented by a keyword with no value (a fact I just learned today and found very surprising). For example: DATE-OBS / this date is not known I was hoping to use this format to represent unknown dates (though it may be unwise if it?s not widely known and supported). How can I write or read such a value with astropy.io.fits? I tried adding a header card with a value of None, but the result was a value of ?? (an empty string). I also found ?Header.add_blank?, but it adds a value without a keyword and I want to do the opposite. Without the ability to easily generate such keywords I have not yet tried reading them. I also have to do this with cfitsio. For writing cfitsio offers fits_write_key_null, which looks like the right thing. The reading routines all set a variable pointer, so I?m guessing they will set that to NULL for reading such a key, though I have not tried it yet. If anyone knows, I?d love to hear about it. ? Russell From tim.jenness at gmail.com Mon Sep 26 14:59:10 2016 From: tim.jenness at gmail.com (Tim Jenness) Date: Mon, 26 Sep 2016 11:59:10 -0700 Subject: [AstroPy] How to read and write keyword with no value with astropy.io.fits? In-Reply-To: <555E96AF-2B30-4A2A-8E25-9225AE9E86B4@uw.edu> References: <555E96AF-2B30-4A2A-8E25-9225AE9E86B4@uw.edu> Message-ID: On Mon, Sep 26, 2016 at 11:37 AM, Russell Owen wrote: > In a FITS header an unknown value can be represented by a keyword with no > value (a fact I just learned today and found very surprising). For example: > > DATE-OBS / this date is not known > > DATE-OBS= / this date is not known (without the "=" it's a standard COMMENT. With "=" it's header with an undefined value). -- Tim Jenness -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.robitaille at gmail.com Tue Sep 27 07:00:10 2016 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Tue, 27 Sep 2016 12:00:10 +0100 Subject: [AstroPy] How to read and write keyword with no value with astropy.io.fits? In-Reply-To: References: <555E96AF-2B30-4A2A-8E25-9225AE9E86B4@uw.edu> Message-ID: Hi Russell, Does this mean that the following: In [8]: header = fits.Header() In [9]: header['DATE-OBS'] = None,'this date is now known' In [10]: header Out[10]: DATE-OBS= '' / this date is now known should ideally be returning: In [10]: header Out[10]: DATE-OBS= / this date is now known ? Just to make sure I understand, what is the downside of having the empty quotes? Cheers, Tom On 26 September 2016 at 19:59, Tim Jenness wrote: > > > On Mon, Sep 26, 2016 at 11:37 AM, Russell Owen wrote: >> >> In a FITS header an unknown value can be represented by a keyword with no >> value (a fact I just learned today and found very surprising). For example: >> >> DATE-OBS / this date is not known >> > > DATE-OBS= / this date is not known > > (without the "=" it's a standard COMMENT. With "=" it's header with an > undefined value). > > -- > Tim Jenness > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > From tim.jenness at gmail.com Tue Sep 27 14:21:11 2016 From: tim.jenness at gmail.com (Tim Jenness) Date: Tue, 27 Sep 2016 11:21:11 -0700 Subject: [AstroPy] How to read and write keyword with no value with astropy.io.fits? In-Reply-To: References: <555E96AF-2B30-4A2A-8E25-9225AE9E86B4@uw.edu> Message-ID: On Tue, Sep 27, 2016 at 4:00 AM, Thomas Robitaille < thomas.robitaille at gmail.com> wrote: > Hi Russell, > > Does this mean that the following: > > In [8]: header = fits.Header() > > In [9]: header['DATE-OBS'] = None,'this date is now known' > > In [10]: header > Out[10]: DATE-OBS= '' / this date is now known > > should ideally be returning: > > In [10]: header > Out[10]: DATE-OBS= / this date is now known > > I think so. Python None is conceptually similar to FITS null. > ? Just to make sure I understand, what is the downside of having the > empty quotes? > > It's the same as asking why None exists at all in python. When you assign None to the header you are not declaring a type. You are saying that the entire value is undefined. Defaulting to an empty string means you are also stating that the header is a string. Verification tools that are checking types will fail if the header is meant to contain a number, but can pass if the value is also allowed to be undefined. If you put a string in for undefined then that is confusing. Pence et al 2010 in section 4.2.1 makes clear that: DATE-OBS= '' DATE-OBS= ' ' DATE-OBS= Have three distinct meanings: null string, empty string, typeless undefined value (except where the standard explicitly states the type of that keyword). Of course, as soon as you make astropy FITS compliant, people will have code that breaks because they have written it to assume empty string and undefined value are equivalent. Does astropy handle the undefined case at all at the moment? -- Tim Jenness -------------- next part -------------- An HTML attachment was scrubbed... URL: From demitri.muna at gmail.com Tue Sep 27 15:22:43 2016 From: demitri.muna at gmail.com (Demitri Muna) Date: Tue, 27 Sep 2016 15:22:43 -0400 Subject: [AstroPy] How to read and write keyword with no value with astropy.io.fits? In-Reply-To: References: <555E96AF-2B30-4A2A-8E25-9225AE9E86B4@uw.edu> Message-ID: On Sep 27, 2016, at 2:21 PM, Tim Jenness wrote: > Of course, as soon as you make astropy FITS compliant, people will have code that breaks because they have written it to assume empty string and undefined value are equivalent. Which is the correct behavior. :) Demitri _________________________________________ Demitri Muna http://muna.com Center for Cosmology and AstroParticle Physics & Department of Astronomy Le Ohio State University My Projects: http://nightlightapp.io http://trillianverse.org http://scicoder.org From rkackley at naoj.org Tue Sep 27 23:29:23 2016 From: rkackley at naoj.org (Russell Kackley) Date: Tue, 27 Sep 2016 17:29:23 -1000 Subject: [AstroPy] IRAF geomap and geotran equivalent in AstroPy? Message-ID: I have some code that uses the IRAF geomap and geotran tasks via the pyraf interface. I would like to replace those IRAF tasks with something from AstroPy, if possible. I searched the AstroPy mailing list archives to see if anyone had a suggestion for an AstroPy replacement for those two tasks. Back in June 2010, Juan Catalan asked if AstroPy had something equivalent to geomap and geotran. https://mail.scipy.org/pipermail/astropy/2010-June/000971.html However, I didn't see a reply that suggested an AstroPy equivalent for the IRAF tasks. Does anyone on the list have a suggestion for an AstroPy replacement of geomap and/or geotran? Thanks. -- Russell Kackley Subaru Telescope Hilo, Hawaii -------------- next part -------------- An HTML attachment was scrubbed... URL: