juliaastro/fitsio.jl

Flexible Image Transport System (FITS) file support for Julia

fitsio.jl's Issues

Integration with Plots.jl

Besides integration with Images.jl, it may be useful to have integration with Plots.jl. This can be achieved with plot recipes. I recently used them in Measurements.jl, they're pretty cool. If there are WCS coordinates, they could be automatically used as tics on the axes.

Key not found when reading from binary table

I'm having trouble reading a column from a binary table. The file is from this URL. I'm new to FITS, so apologies in advance if I'm missing something basic.

I would like to read the RROWS column. It is present:

psf_filename = "psField-003900-6-0269.fit"
psf_fits = FITS(psf_filename);
read_header(psf_fits[b + 1])
# ...other fields...
# TFORM7  =                 '1J' / PIXDATATYPE
# TTYPE7  =              'RTYPE' / type
# TFORM8  =             '1PE(0)' / FLOAT
# TTYPE8  =              'RROWS' / rows_fl32
# TFORM9  =                 '1J' / INT
# TTYPE9  =              'RROW0' / row0
# TFORM10 =                 '1J' / INT
# TTYPE10 =              'RCOL0' / col0
# ....

And I can read other fields:

read(psf_fits[b + 1], "RNROW")
#4-element Array{Int32,1}:
#  51
#  51
#  51
#  51

But I cannot read RROWS:

read(psf_fits[b + 1], "RROWS")
# ERROR: key not found: -42
#  in read at /home/rgiordan/.julia/v0.3/FITSIO/src/hdutypes.jl:72

Any idea what might be going wrong?

Conversion between FITSHeader and String

How can we convert a FITSHeader in a String format and vice-versa?
It would be great to modify a Header by making a WCSTransform object, making the changes and then saving that to original FITS file.
Using to_header from WCS.jl, we can get the header in string format but how can I write that to a FITSHeader?

Obtain eltype without reading the array

Since images have the element type in the header (and this is something that CFITSIO converts to a Julia type), it should be possible to obtain the element type of an image HDU using something like this :

julia> FITS("V_kw.fits", "r") do f
           eltype(f[1])
       end

Currently this returns Any, but a suitable method may be added to return the correct element type.

Base.Uint8 is deprecated, use UInt8 instead

With Julia 0.4 (the release candidate) I'm getting a lot of warnings about Uint8/UInt8 from just a few lines of FITSIO.jl. For example,

WARNING: Base.Uint8 is deprecated, use UInt8 instead.
in fits_hdr2str at /home/travis/.julia/v0.4/FITSIO/src/libcfitsio.jl:410
WARNING: Base.Uint8 is deprecated, use UInt8 instead.
in fits_hdr2str at /home/travis/.julia/v0.4/FITSIO/src/libcfitsio.jl:410
WARNING: Base.Uint8 is deprecated, use UInt8 instead.
in fits_hdr2str at /home/travis/.julia/v0.4/FITSIO/src/libcfitsio.jl:410
WARNING: Base.Uint8 is deprecated, use UInt8 instead.
in fits_hdr2str at /home/travis/.julia/v0.4/FITSIO/src/libcfitsio.jl:410
WARNING: Base.Uint8 is deprecated, use UInt8 instead.
in fits_hdr2str at /home/travis/.julia/v0.4/FITSIO/src/libcfitsio.jl:410
WARNING: Base.Uint8 is deprecated, use UInt8 instead.
WARNING: Base.Uint8 is deprecated, use UInt8 instead.
in fits_hdr2str at /home/travis/.julia/v0.4/FITSIO/src/libcfitsio.jl:410
WARNING: Base.Uint8 is deprecated, use UInt8 instead.
in fits_hdr2str at /home/travis/.julia/v0.4/FITSIO/src/libcfitsio.jl:410
WARNING: Base.Uint8 is deprecated, use UInt8 instead.
in wcspih at /home/travis/.julia/v0.4/WCSLIB/src/libwcs_h.jl:518
WARNING: Base.Uint8 is deprecated, use UInt8 instead.
in wcspih at /home/travis/.julia/v0.4/WCSLIB/src/libwcs_h.jl:518
WARNING: Base.Uint8 is deprecated, use UInt8 instead.
WARNING: Base.Uint8 is deprecated, use UInt8 instead.
in wcspih at /home/travis/.julia/v0.4/WCSLIB/src/libwcs_h.jl:518
WARNING: Base.Uint8 is deprecated, use UInt8 instead.

tag a new version?

Hello all,

I don't want to be too much of a bother, but I need a new tag of FITSIO.jl that includes #66 to use as a lower limit for LibHealpix.jl. Is there any chance of having a new version tagged in the not-so-distant future?

Thanks!

Deal with square brackets in filename

This works in python but not julia:

In [1]: from astropy.io import fits

In [2]: import numpy as np

In [3]: fits.writeto("abc[12].fits", np.ones((2,2)))

In [4]: fits.getdata("abc[12].fits")
Out[4]: 
array([[1., 1.],
       [1., 1.]])

and

julia> using FITSIO

julia> FITSIO.fitsread("abc[12].fits")
ERROR: While processing file `abc[12].fits`: parse error in input file URL

Cannot open compressed file

I cannot open a zipped FITS file (astropy has no problem, though).

julia> using FITSIO, PyCall

julia> download("https://www.spacetelescope.org/static/projects/fits_liberator/datasets/eagle/502nmos.zip", "502nmos.zip")
"502nmos.zip"

julia> py"""import astropy
       print(astropy.__version__)
       """
3.2.3

julia> pf = pyimport("astropy.io.fits")
PyObject <module 'astropy.io.fits' from '/Users/miles/.pyenv/versions/3.7.4/Python.framework/Versions/3.7/lib/python3.7/site-packages/astropy/io/fits/__init__.py'>

julia> pf.open("502nmos.zip")
2-element Array{PyObject,1}:
 PyObject <astropy.io.fits.hdu.image.PrimaryHDU object at 0x1469b0390>
 PyObject <astropy.io.fits.hdu.table.TableHDU object at 0x1469ad0d0>

julia> FITS("502nmos.zip")
ERROR: While processing file `502nmos.zip`: error uncompressing image
Stacktrace:
 [1] error(::String) at /Applications/Julia-1.4.app/Contents/Resources/julia/lib/julia/sys.dylib:?
 [2] fits_assert_ok at /Users/miles/.julia/packages/FITSIO/BavHZ/src/libcfitsio.jl:206 [inlined]
 [3] fits_open_file(::String, ::Int64) at /Users/miles/.julia/packages/FITSIO/BavHZ/src/libcfitsio.jl:281
 [4] FITS(::String, ::String) at /Users/miles/.julia/packages/FITSIO/BavHZ/src/FITSIO.jl:109 (repeats 2 times)
 [5] top-level scope at REPL[33]:1
 [6] eval(::Module, ::Any) at /Applications/Julia-1.4.app/Contents/Resources/julia/lib/julia/sys.dylib:?
 [7] eval_user_input(::Any, ::REPL.REPLBackend) at /Applications/Julia-1.4.app/Contents/Resources/julia/lib/julia/sys.dylib:?
 [8] run_backend(::REPL.REPLBackend) at /Users/miles/.julia/packages/Revise/AMRie/src/Revise.jl:1023
 [9] top-level scope at none:0

relevant manifest info:

Details

  [525bcba6] FITSIO v0.14.0
  [438e738f] PyCall v1.91.4

URL input

Can we stream data in via a url?

e.g.

using FITSIO
url = "https://dr14.sdss.org/optical/spectrum/view/data/format=fits/spec=lite?plateid=1323&mjd=52797&fiberid=12"
f = FITS(url)

If we can't stream it, can we at least let the above look like this->

using FITSIO
url = "https://dr14.sdss.org/optical/spectrum/view/data/format=fits/spec=lite?plateid=1323&mjd=52797&fiberid=12"
# This happens behind the scenes when user calls FITS(url)
f = FITS(download(url))

TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

getindex(FITS, String) does not work

In version 0.16 this getindex method stopped working (works in 0.15):

FITSIO.jl/src/fits.jl

Line 111 in ac1e773

function getindex(f::FITS, name::AbstractString, ver::Int=0)

It gives the following stacktrace:

  UndefVarError: fits_movnam_hdu not defined
  Stacktrace:
   [1] getindex(::FITSIO.FITS, ::String, ::Int64) at /home/runner/.julia/packages/FITSIO/KYCVW/src/fits.jl:113
   [2] getindex at /home/runner/.julia/packages/FITSIO/KYCVW/src/fits.jl:112 [inlined]

The fits_movnam_hdu function is indeed used here:

FITSIO.jl/src/fits.jl

Line 113 in ac1e773

fits_movnam_hdu(f.fitsfile, name, ver)

But I cannot find it defined anywhere in the FITSIO.jl repo. Was it just removed at some point? Everything is fine with version 0.15.

Tag a new version

It's been a year since the previous release. There have been a few PRs merged in the interim, tagging a new release might be worth it?

fits_get_colnum should be case-sensitive

It seems that fits_get_colnum is set-up to be always case insensitive.
I know a fair number of astronomical catalogs that use case-sensitive column names.
The Gaia DR2 catalog (as offered on CDS ViZieR) released yesterday is one of them (e.g. the b_Teff and B_Teff columns).
It would be great to make it case sensitive by default.
thanks

Add tests for named HDUs

Ref #141 and #142

Compressed FITS images with >3 dimensions fail to read

I am able to open compressed FITS files with 1-3 dimension image data. However, for files with data cubes with more than 3 dimensions, trying to read the "image" produces ERROR: error uncompressing image.

Minimal example:

using FITSIO

img = FITS("test2d.fits", "w")
dc  = FITS("test4d.fits", "w")

data = rand(Int16, 10000)

write(img, reshape(data, (100, 100)))
write(dc,  reshape(data, (10, 10, 10, 10)))

close(img)
close(dc)

run(`fpack test2d.fits`)
run(`fpack test4d.fits`)

compressed_img = FITS("test2d.fits.fz")
compressed_dc  = FITS("test4d.fits.fz")

works = read(compressed_img[2])
fails = read(compressed_dc[2])

Ability to set wcsprm values in Julia

I'd like to be able to safely modify wcsprm structs (as returned by WCSLIB.jl's wcspih function) in julia. For example, I'd like to be able to set the crpix field (the pixel reference point) when I subset an image.

However, the field is a C pointer:

julia> blob[1].wcs.crpix Ptr{Float64} @0x000000000f550a50

...so the only way to modify it is the aptly-named unsafe_store!. This isn't great -- for example, this seems to mean that deepcopy of types containing a wcsprm object doesn't actually deeply copy the object.

Is there any hope for changing some of these fields to julia values rather than C pointers?

[PkgEval] FITSIO may have a testing issue on Julia 0.3 (2014-08-16)

PackageEvaluator.jl is a script that runs nightly. It attempts to load all Julia packages and run their tests (if available) on both the stable version of Julia (0.3) and the nightly build of the unstable version (0.4). The results of this script are used to generate a package listing enhanced with testing results.

On Julia 0.3

• On 2014-08-15 the testing status was Tests pass.
• On 2014-08-16 the testing status changed to Tests fail, but package loads.

Tests pass. means that PackageEvaluator found the tests for your package, executed them, and they all passed.

Tests fail, but package loads. means that PackageEvaluator found the tests for your package, executed them, and they didn't pass. However, trying to load your package with using worked.

This issue was filed because your testing status became worse. No additional issues will be filed if your package remains in this state, and no issue will be filed if it improves. If you'd like to opt-out of these status-change messages, reply to this message saying you'd like to and @IainNZ will add an exception. If you'd like to discuss PackageEvaluator.jl please file an issue at the repository. For example, your package may be untestable on the test machine due to a dependency - an exception can be added.

Test log:

>>> 'Pkg.add("FITSIO")' log
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 4541k  100 4541k    0     0  4082k      0  0:00:01  0:00:01 --:--:-- 4083k
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for gfortran... gfortran
checking whether we are using GNU Fortran... 
yes
cfitsio: == Adding wrapper support for GNU Fortran... 
 done
... truncated ...
a - zlib/inftrees.o
a - zlib/trees.o
a - zlib/uncompr.o
a - zlib/zcompress.o
a - zlib/zuncompress.o
a - zlib/zutil.o
a - f77_wrap1.o
a - f77_wrap2.o
a - f77_wrap3.o
a - f77_wrap4.o
/bin/cp -a libcfitsio* /home/idunning/pkgtest/.julia/v0.3/FITSIO/deps/usr/lib
/bin/cp fitsio.h fitsio2.h longnam.h drvrsmem.h /home/idunning/pkgtest/.julia/v0.3/FITSIO/deps/usr/include
/bin/cp cfitsio.pc /home/idunning/pkgtest/.julia/v0.3/FITSIO/deps/usr/lib/pkgconfig
INFO: Cloning cache of FITSIO from git://github.com/JuliaAstro/FITSIO.jl.git
INFO: Installing BinDeps v0.3.0
INFO: Installing FITSIO v0.4.0
INFO: Installing SHA v0.0.2
INFO: Installing URIParser v0.0.2
INFO: Building FITSIO
INFO: Attempting to Create directory /home/idunning/pkgtest/.julia/v0.3/FITSIO/deps/downloads
INFO: Downloading file ftp://heasarc.gsfc.nasa.gov/software/fitsio/c/cfitsio3360.tar.gz
INFO: Done downloading file ftp://heasarc.gsfc.nasa.gov/software/fitsio/c/cfitsio3360.tar.gz
INFO: Attempting to Create directory /home/idunning/pkgtest/.julia/v0.3/FITSIO/deps/src
INFO: Attempting to Create directory /home/idunning/pkgtest/.julia/v0.3/FITSIO/deps
INFO: Directory /home/idunning/pkgtest/.julia/v0.3/FITSIO/deps already created
INFO: Attempting to Create directory /home/idunning/pkgtest/.julia/v0.3/FITSIO/deps/src/cfitsio
INFO: Changing Directory to /home/idunning/pkgtest/.julia/v0.3/FITSIO/deps/src/cfitsio
INFO: Package database updated
INFO: METADATA is out-of-date a you may not have the latest version of FITSIO
INFO: Use `Pkg.update()` to get the latest versions of your packages

>>> 'using FITSIO' log

>>> test log

ERROR: type: ccall: expected Symbol, got Array{Any,1}
 in include at ./boot.jl:245
 in include_from_node1 at loading.jl:128
 in process_options at ./client.jl:285
 in _start at ./client.jl:354
 in _start_3B_1699 at /home/idunning/julia03/usr/bin/../lib/julia/sys.so
while loading /home/idunning/pkgtest/.julia/v0.3/FITSIO/test/runtests.jl, in expression starting on line 11

>>> end of log

Discourage and eventually deprecate "low-level" API

In the long term, I think it will become a nightmare having the dual interface that currently exists in this package. Instead, we should ensure that the high-level interface has all the functionality and performance possible in the low-level interface and eventually deprecate the low-level interface for public use. (I've been putting off having this discussion because it might be contentious, but it will be better to resolve sooner rather than later!)

Obviously there are still gaps in the high-level interface, the most glaring of which is support for tables. I'm currently working on a PR to support tables in the high-level interface (at least at the level available in the low-level interface). The other thing I can think of off the top of my head is a way to get "raw" header values as strings.

What else is missing from the high-level interface, in terms of either functionality or performance? If you're currently using the low-level API, could you switch?

TypeError: apply_type: in Array, expected Type{T}

I get the error below when I try to load FITSIO with Julia (Version 0.4.0-dev+4603). Is FITSIO compatible with Julia 0.4?

julia> using FITSIO
WARNING: int32(x) is deprecated, use Int32(x) instead.
 in depwarn at ./deprecated.jl:40
 in int32 at deprecated.jl:29
 in include at ./boot.jl:250
 in include_from_node1 at ./loading.jl:132
 in include at ./boot.jl:250
 in include_from_node1 at ./loading.jl:132
 in reload_path at ./loading.jl:156
 in _require at ./loading.jl:68
 in require at ./loading.jl:51
ERROR: LoadError: LoadError: TypeError: apply_type: in Array, expected Type{T}, got Tuple{DataType,DataType,DataType}
 in anonymous at no file:463
 in include at ./boot.jl:250
 in include_from_node1 at ./loading.jl:132
 in include at ./boot.jl:250
 in include_from_node1 at ./loading.jl:132
 in reload_path at ./loading.jl:156
 in _require at ./loading.jl:68
 in require at ./loading.jl:51
while loading /home/jeff/.julia/v0.4/FITSIO/src/cfitsio.jl, in expression starting on line 461
while loading /home/jeff/.julia/v0.4/FITSIO/src/FITSIO.jl, in expression starting on line 70

Modifying an image in a FITS file

Is there a way to modify image data in a .fits file without touching anything else?

I have a .fits file that contains image data as well as several extensions (tables). I want to replace the image data while keeping everything else (headers/extensions etc.) unchanged. Is there a way to do it?

Right now, I'm creating a new file and copying all the extensions to it:

hdul_data = FITS("input.fits")

# Load the image data
image_data = read(hdul_data[1])

# Modify data
image_data[10, 10] = 42

# Save the data array into the output fits file
data_out = FITS("output.fits", "w");

for hdu in hdul_data
  if typeof(hdu)==FITSIO.ImageHDU
    # Write the image to output file
    write(data_out, image_data; header=header_data)
  elseif typeof(hdu)==FITSIO.TableHDU
    # Copy the table into the output file
    table_data = Dict{String,Array}()

    for colname in FITSIO.colnames(hdu)
      col_data = read(hdu, colname)
      table_data[colname] = col_data
    end

    header = read_header(hdu)
    ext_name = header["EXTNAME"]
    write(data_out, table_data; hdutype=FITSIO.TableHDU, header=header, name=ext_name)
  end
end

This is not ideal, because I'm not sure if the new file will be exactly the same as the old one (except for the changed image). I would prefer to just modify the image data. These are example of how this could be done in Python and Fortran.

Python example:

from astropy.io import fits

hdul_data = fits.open("data.fits")

# Load the image data
image_data = hdul_data["PRIMARY"].data

# Change image data
image_data[5,5]=123

# Save the data array into the output fits file
hdul_data.writeto("output.fits")

Fortran example (cfitsio):

! Get an unused Logical Unit Number to use to open the FITS file.
call ftgiou(unit_data,status)

! Open the FITS file, with read-only access.
readwrite=0
call ftopen(unit_data,filename_data,readwrite,blocksize,status)

! Load the image data
group=1
nullval=0
call ftg2di(unit_data, group, nullval, max_x, naxes_data(1), naxes_data(2), image_data, anynull, status)

! Modify the image
image_data(10,10) = 42

! Create the output fits file
! -------------
 
! Get an unused Logical Unit Number to use to create the FITS file.
call ftgiou(unit_output, status)

! Create the output file
blocksize=1
call ftinit(unit_output, filename_output, blocksize, status)

! Copy the entire data file to the output file
call ftcpfl(unit_data, unit_output, 1, 1, 1, status)

! Move back to the primary array
call ftmahd(unit_output, 1, hdutype, status)

! Save the data array into the output fits file
group=1
nullval=0
call ftp2di(unit_output, group, max_x, naxes_data(1), naxes_data(2), image_data, status)

Dependency compatibility bounds are too loose

At present the compat entries are

FITSIO.jl/Project.toml

Lines 11 to 12 in a9a14fb

	BinaryProvider = "≥ 0.4.0"
	julia = "≥ 1.0.0"

Perhaps we should shift to the caret bounds from the inequalities? In any case the julia registry places an upper bound on the julia version, but apparently it doesn't on the other dependencies.

https://github.com/JuliaRegistries/General/blob/d001c9bc98ddb251e2c025257d3c8d94ab032fa7/F/FITSIO/Compat.toml#L7-L8

ERROR: FITSFile not defined

With the FITSIO package installed and Pkg.update() done, I get the following error on Kubuntu 15.04. Not sure what's going on...

Julia Version 0.3.2, x86_64-linux-gnu
julia> using OIFITS
Warning: could not import FITSIO.fits_get_errstatus into OIFITS
ERROR: FITSFile not defined
in eval at ./no file
in include212 at /usr/bin/../lib/x86_64-linux-gnu/julia/sys.so
in include_from_node11801 at /usr/bin/../lib/x86_64-linux-gnu/julia/sys.so
in include212 at /usr/bin/../lib/x86_64-linux-gnu/julia/sys.so
in include_from_node11801 at /usr/bin/../lib/x86_64-linux-gnu/julia/sys.so
in include212 at /usr/bin/../lib/x86_64-linux-gnu/julia/sys.so
in include_from_node11801 at /usr/bin/../lib/x86_64-linux-gnu/julia/sys.so
in reload_path at ./loading.jl:152
in _require at ./loading.jl:67
in require at ./loading.jl:52
while loading /home/baron/.julia/v0.3/OIFITS/src/fix-fitsio.jl, in expression starting on line 127
while loading /home/baron/.julia/v0.3/OIFITS/src/oifile.jl, in expression starting on line 17
while loading /home/baron/.julia/v0.3/OIFITS/src/OIFITS.jl, in expression starting on line 51

Test strings that should contain only ASCII characters with isascii

PR #72 dropped support for Julia 0.4, and with it Compat.ASCIIString was replaced with String. This type doesn't guarantee there are only ASCII character in the string, there may be places where this should be enforced, isascii can be used for this.

Add PrimaryHDU

Currently, we have the following HDUs:

julia> subtypes(HDU)
3-element Array{Any,1}:
 ASCIITableHDU
 ImageHDU     
 TableHDU

However the FITS expects at least one other type, "Primary HDU", see https://fits.gsfc.nasa.gov/fits_primer.html.

One example of FITS file with a Primary HDU has been reported at JuliaAstro/AstroImages.jl#9: EUVEngc4151imgx.fits. FITSIO.jl shows the following table:

julia> using FITSIO

julia> file = download("https://fits.gsfc.nasa.gov/samples/EUVEngc4151imgx.fits")
"/tmp/julia6zY8AX"

julia> FITS(file)
File: /tmp/julia6zY8AX
Mode: "r" (read-only)
HDUs: Num  Name             Type   
      1                     Image  
      2    ds               Image  
      3    sw_night         Image  
      4    mw               Image  
      5    lw               Image  
      6    ds_limits        Table  
      7    sw_night_limits  Table  
      8    mw_limits        Table  
      9    lw_limits        Table

instead Astropy reports:

>>> from astropy.io import fits
>>> fits.open("/tmp/julia6zY8AX").info()
Filename: /tmp/julia6zY8AX
No.    Name      Ver    Type      Cards   Dimensions   Format
  0  PRIMARY       1 PrimaryHDU      62   ()      
  1  ds            1 ImageHDU        72   (512, 512)   int16   
  2  sw_night      1 ImageHDU        78   (2048, 300)   int16   
  3  mw            1 ImageHDU        78   (2048, 300)   int16   
  4  lw            1 ImageHDU        78   (2048, 300)   int16   
  5  ds_limits     1 BinTableHDU     71   3R x 3C   [8A, 1E, 1E]   
  6  sw_night_limits    1 BinTableHDU     71   2R x 3C   [12A, 1E, 1E]   
  7  mw_limits     1 BinTableHDU     71   2R x 3C   [12A, 1E, 1E]   
  8  lw_limits     1 BinTableHDU     71   2R x 3C   [12A, 1E, 1E]

writemode with fits_open_file

It seems writemode is not supported with fits_open_file. I get an error message when closing a fits file after writing a column to an existing file as follows.

julia> f=fits_open_file("test.fits")   
FITSFile(Ptr{Nothing} @0x0000000001885840)
julia> fits_write_col(f,24,1,1,dat)   
julia> fits_close_file(f)
ERROR: cannot write to readonly file

The function fits_open_file does not accept 0 or 1 for read/write mode as in cfitsio.

Add support for reading and writing complex arrays by reinterpreting the elements as pairs of floating point ones

This is more of a discussion that I wanted to have, as I often have to work in Fourier space where arrays are complex. Since complex arrays are usually laid out contiguously in memory, it's possible to write them to FITS files by reinterpreting them as floating point arrays where the first dimension is doubled in size. Such arrays may also be read in by reinterpreting them as Complex ones of the correct type. Is this a feature that might be implemented? In that case I might consider submitting a PR.

What I currently use for complex arrays is something like floatarr = collect(reinterpret(Float64,complexarr) before writing to FITS. This involves an extra collection --- and hence allocation --- that is unnecessary. It appears solving the write is straightforward by expanding the type dispatched upon from Array{T} to Union{Array{T},Base.ReinterpretArray{T}}. I haven't looked into the read part yet. I was wondering if this appears sensible, or if there is something that I'm missing.

Feature tracker

This is an issue to track some obvious features that should be added. My guess is that they will be added gradually over time as needed, but in a backwards-compatible manner.

General

• Iterator protocol for FITS type: enabling for hdu in FITS(...)
• Improve appearance of show() for FITS and HDU types. [#38]

Headers

• Read a single keyword value without the comment, like read_key(hdu, key)[1].

Images

• Write to a subset of the image: write(hdu, data; start=(100, 200))
• Read to already-allocated array: read!(hdu, data), read!(hdu, 1:20, 1:30, data)
• Read/write tile-compressed images.

Tables

• Read and write variable length table columns [#36]
• Method to get column names in table (DataFrames extends Base.names but that has a different definition; maybe use colnames) [#93]
• Method to get number of rows in table (extend Base.length)
• Relax write method to write(::FITS, ::Dict{Any, Vector}) (raise runtime error if any dictionary key is not ASCII)
• Read ranges of table rows: read(hdu, "COLNAME", 1:10)
• Read arbitrary table rows: read(hdu, "COLNAME", [1, 3, 6, 10])
• Read to already-allocated arrays: read!(hdu, "COLNAME", data)
• Append rows to a table
• Insert columns into a table
• Read/write bit columns (into BitArrays?)
• Iterate over table rows?
• Read multiple columns simultaneously (requires low-level tinkering, byteswapping)

FITSIO doesn't seem to check if CFITSIO is already installed.

It always seems to try to download and build CFITSIO.

Should table hdus implement the Tables.jl "interface"?

Personally, when working with a FITS table, I generally immediately put the relevant cols into a DataFrame. This would make that easier, make it possible to simply save tables as CSV, etc.

If you think this is a good idea, I can look into doing it myself.

Method to get column names in a FITS table

I was surprised that this doesn't already exist, but it's straightforward to add.

Column names are already determined as part of show(::IO, ::TableHDU) and show(::IO, ::ASCIITableHDU). One would just have to pull out some of that code into a separate function.

colnames might be a good function name for this. DataFrames extends Base.names for this purpose, but the definition of Base.names is, I think, inconsistent with this usage.

Pkg.add() on Windows fails.

When I tried to add the package on a windows machine the install fails. It doesn't copy cfitsio.dll to the /lib directory. I put it there and did a Pkg.build() and everything worked.

Here's the output from the console:

julia> Pkg.add("FITSIO")
INFO: Cloning cache of FITSIO from git://github.com/JuliaAstro/FITSIO.jl.git
INFO: Installing FITSIO v0.8.3
INFO: Building FITSIO

PowerShell[.exe] [-PSConsoleFile | -Version ]
[-NoLogo] [-NoExit] [-Sta] [-Mta] [-NoProfile] [-NonInteractive]
[-InputFormat {Text | XML}] [-OutputFormat {Text | XML}]
[-WindowStyle <style>] [-EncodedCommand ]
[-File ] [-ExecutionPolicy ]
[-Command { - | [-args ]
| [] } ]

PowerShell[.exe] -Help | -? | /?

-PSConsoleFile
Loads the specified Windows PowerShell console file. To create a console
file, use Export-Console in Windows PowerShell.

-Version
Starts the specified version of Windows PowerShell.
Enter a version number with the parameter, such as "-version 2.0".

-NoLogo
Hides the copyright banner at startup.

-NoExit
Does not exit after running startup commands.

-Sta
Starts the shell using a single-threaded apartment.
Single-threaded apartment (STA) is the default.

-Mta
Start the shell using a multithreaded apartment.

-NoProfile
Does not load the Windows PowerShell profile.

-NonInteractive
Does not present an interactive prompt to the user.

-InputFormat
Describes the format of data sent to Windows PowerShell. Valid values are
"Text" (text strings) or "XML" (serialized CLIXML format).

-OutputFormat
Determines how output from Windows PowerShell is formatted. Valid values
are "Text" (text strings) or "XML" (serialized CLIXML format).

-WindowStyle
Sets the window style to Normal, Minimized, Maximized or Hidden.

-EncodedCommand
Accepts a base-64-encoded string version of a command. Use this parameter
to submit commands to Windows PowerShell that require complex quotation
marks or curly braces.

-File
Runs the specified script in the local scope ("dot-sourced"), so that the
functions and variables that the script creates are available in the
current session. Enter the script file path and any parameters.
File must be the last parameter in the command, because all characters
typed after the File parameter name are interpreted
as the script file path followed by the script parameters.

-ExecutionPolicy
Sets the default execution policy for the current session and saves it
in the $env:PSExecutionPolicyPreference environment variable.
This parameter does not change the Windows PowerShell execution policy
that is set in the registry.

-Command
Executes the specified commands (and any parameters) as though they were
typed at the Windows PowerShell command prompt, and then exits, unless
NoExit is specified. The value of Command can be "-", a string. or a
script block.

If the value of Command is "-", the command text is read from standard
input.

If the value of Command is a script block, the script block must be enclosed
in braces ({}). You can specify a script block only when running PowerShell.exe
in Windows PowerShell. The results of the script block are returned to the
parent shell as deserialized XML objects, not live objects.

If the value of Command is a string, Command must be the last parameter
in the command , because any characters typed after the command are
interpreted as the command arguments.

To write a string that runs a Windows PowerShell command, use the format:
    "& {<command>}"
where the quotation marks indicate a string and the invoke operator (&)
causes the command to be executed.

-Help, -?, /?
Shows this message. If you are typing a PowerShell.exe command in Windows
PowerShell, prepend the command parameters with a hyphen (-), not a forward
slash (/). You can use either a hyphen or forward slash in Cmd.exe.

EXAMPLES
PowerShell -PSConsoleFile SqlSnapIn.Psc1
PowerShell -version 2.0 -NoLogo -InputFormat text -OutputFormat XML
PowerShell -Command {Get-EventLog -LogName security}
PowerShell -Command "& {Get-EventLog -LogName security}"

# To use the -EncodedCommand parameter:
$command = 'dir "c:\program files" '
$bytes = [System.Text.Encoding]::Unicode.GetBytes($command)
$encodedCommand = [Convert]::ToBase64String($bytes)
powershell.exe -encodedCommand $encodedCommand

INFO: Attempting to Create directory C:\Users\User.julia\v0.4\FITSIO\deps\downloads
INFO: Downloading file ftp://heasarc.gsfc.nasa.gov/software/fitsio/c/cfitsio_MSVC_64bit_DLL_3370.zip
INFO: Done downloading file ftp://heasarc.gsfc.nasa.gov/software/fitsio/c/cfitsio_MSVC_64bit_DLL_3370.zip
INFO: Attempting to Create directory C:\Users\User.julia\v0.4\FITSIO\deps\src
INFO: Attempting to Create directory C:\Users\User.julia\v0.4\FITSIO\deps
INFO: Directory C:\Users\User.julia\v0.4\FITSIO\deps already created

7-Zip [64] 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18

Processing archive: C:\Users\User.julia\v0.4\FITSIO\deps\downloads\cfitsio_MSVC_64bit_DLL_3370.zip

Extracting cfitsio.dll
Extracting cfitsio.lib
Extracting FPack.exe
Extracting Funpack.exe
Extracting TestProg.exe
Extracting fpackguide.pdf
Extracting fitsio.h
Extracting License.txt
Extracting longnam.h
Extracting README.win
Extracting testprog.std
Extracting testprog.tpt
Extracting testprog.out
Extracting testprog.c

Everything is Ok

Files: 14
Size: 2161783
Compressed: 1078860
INFO: Attempting to Create directory C:\Users\User.julia\v0.4\FITSIO\deps\usr\lib
INFO: Changing Directory to C:\Users\User.julia\v0.4\FITSIO\deps\src
===============================[ ERROR: FITSIO ]================================

LoadError: could not spawn cp cfitsio.dll 'C:\Users\User\.julia\v0.4\FITSIO\deps\usr\lib\cfitsio.dll': no such file or directory (ENOENT)
while loading C:\Users\User.julia\v0.4\FITSIO\deps\build.jl, in expression starting on line 55

====================================================[ BUILD ERRORS ]====================================================

WARNING: FITSIO had build errors.

• packages with build errors remain installed in C:\Users\User.julia\v0.4
• build the package(s) and all dependencies with Pkg.build("FITSIO")
• build a single package by running its deps/build.jl script

INFO: Package database updated
INFO: METADATA is out-of-date — you may not have the latest version of FITSIO
INFO: Use Pkg.update() to get the latest versions of your packages

Higher-level interface

I'm interested in putting a little work into a higher-level interface for FITSIO, something akin to esheldon/fitsio. If you look at that package, I think the equivalent thing in Julia would be to define types for HDUs such as TableHDU, ImageHDU, and ASCIITableHDU. This would allow you to define indexing operations on the data of an HDU, such as:

f = fits_open_file("data.fits")
f[1]  # returns an HDU instance.
f[1][25:35, 10:20]  # returns a subpatch of the data in the HDU

However, this design seems a little weird to me, because the HDU types would have the same pointer as the main FITSFile instance, and would have to move the current HDU to the correct extension before doing any operation. (Maybe that's not so bad?) It doesn't seem like you can have index notation without defining such types. I guess the alternative would be to have methods like

fitsread(f, 1, 25:35, 10:20)

Any thoughts?

[PkgEval] FITSIO may have a testing issue on Julia 0.4 (2014-08-16)

PackageEvaluator.jl is a script that runs nightly. It attempts to load all Julia packages and run their tests (if available) on both the stable version of Julia (0.3) and the nightly build of the unstable version (0.4). The results of this script are used to generate a package listing enhanced with testing results.

On Julia 0.4

• On 2014-08-15 the testing status was Tests pass.
• On 2014-08-16 the testing status changed to Tests fail, but package loads.

Tests pass. means that PackageEvaluator found the tests for your package, executed them, and they all passed.

Tests fail, but package loads. means that PackageEvaluator found the tests for your package, executed them, and they didn't pass. However, trying to load your package with using worked.

This issue was filed because your testing status became worse. No additional issues will be filed if your package remains in this state, and no issue will be filed if it improves. If you'd like to opt-out of these status-change messages, reply to this message saying you'd like to and @IainNZ will add an exception. If you'd like to discuss PackageEvaluator.jl please file an issue at the repository. For example, your package may be untestable on the test machine due to a dependency - an exception can be added.

Test log:

>>> 'Pkg.add("FITSIO")' log
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
 83 4541k   83 3806k    0     0  2815k      0  0:00:01  0:00:01 --:--:-- 2815k
100 4541k  100 4541k    0     0  3280k      0  0:00:01  0:00:01 --:--:-- 3278k
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for gfortran... gfortran
checking whether we are using GNU Fortran... 
yes
cfitsio: == Adding wrapper support for GNU Fortran... 
 done
... truncated ...
a - zlib/infback.o
a - zlib/inffast.o
a - zlib/inflate.o
a - zlib/inftrees.o
a - zlib/trees.o
a - zlib/uncompr.o
a - zlib/zcompress.o
a - zlib/zuncompress.o
a - zlib/zutil.o
a - f77_wrap1.o
a - f77_wrap2.o
a - f77_wrap3.o
a - f77_wrap4.o
/bin/cp -a libcfitsio* /home/idunning/pkgtest/.julia/v0.4/FITSIO/deps/usr/lib
/bin/cp fitsio.h fitsio2.h longnam.h drvrsmem.h /home/idunning/pkgtest/.julia/v0.4/FITSIO/deps/usr/include
/bin/cp cfitsio.pc /home/idunning/pkgtest/.julia/v0.4/FITSIO/deps/usr/lib/pkgconfig
INFO: Installing BinDeps v0.3.0
INFO: Installing FITSIO v0.4.0
INFO: Installing SHA v0.0.2
INFO: Installing URIParser v0.0.2
INFO: Building FITSIO
INFO: Attempting to Create directory /home/idunning/pkgtest/.julia/v0.4/FITSIO/deps/downloads
INFO: Downloading file ftp://heasarc.gsfc.nasa.gov/software/fitsio/c/cfitsio3360.tar.gz
INFO: Done downloading file ftp://heasarc.gsfc.nasa.gov/software/fitsio/c/cfitsio3360.tar.gz
INFO: Attempting to Create directory /home/idunning/pkgtest/.julia/v0.4/FITSIO/deps/src
INFO: Attempting to Create directory /home/idunning/pkgtest/.julia/v0.4/FITSIO/deps
INFO: Directory /home/idunning/pkgtest/.julia/v0.4/FITSIO/deps already created
INFO: Attempting to Create directory /home/idunning/pkgtest/.julia/v0.4/FITSIO/deps/src/cfitsio
INFO: Changing Directory to /home/idunning/pkgtest/.julia/v0.4/FITSIO/deps/src/cfitsio
INFO: Package database updated

>>> 'using FITSIO' log

>>> test log
ERROR: type: ccall: expected Symbol, got Array{Any,1}
 in include at ./boot.jl:245
 in include_from_node1 at loading.jl:128
 in process_options at ./client.jl:285
 in _start at ./client.jl:354
 in _start_3B_3500 at /home/idunning/julia04/usr/bin/../lib/julia/sys.so
while loading /home/idunning/pkgtest/.julia/v0.4/FITSIO/test/runtests.jl, in expression starting on line 11


>>> end of log

Standard header comment duplicated on re-save

When I write to a new FITS file using a FITSHeader object extracted from a previously opened FITS file, the comment block

COMMENT   FITS (Flexible Image Transport System) format is defined in 'Astronomy
COMMENT   and Astrophysics', volume 376, page 359; bibcode: 2001A&A...376..359H

is duplicated. For example:

julia> using FITSIO

julia> # Create a dummy file

julia> hdr = FITSHeader(["HELLO"], ["World"], [""]); data = rand(10,10);

julia> FITS("helloworld.fits", "w") do file
           write(file, data, header=hdr)
       end

shell> dfits helloworld.fits
====> file helloworld.fits (main) <====
SIMPLE  =                    T / file does conform to FITS standard
BITPIX  =                  -64 / number of bits per data pixel
NAXIS   =                    2 / number of data axes
NAXIS1  =                   10 / length of data axis 1
NAXIS2  =                   10 / length of data axis 2
EXTEND  =                    T / FITS dataset may contain extensions
COMMENT   FITS (Flexible Image Transport System) format is defined in 'Astronomy
COMMENT   and Astrophysics', volume 376, page 359; bibcode: 2001A&A...376..359H
HELLO   = 'World   '
END

julia> # Read in the header of the dummy file

julia> hdr2 = FITS("helloworld.fits", "r") do file
           read_header(file[1])
       end
SIMPLE  =                    T / file does conform to FITS standard
BITPIX  =                  -64 / number of bits per data pixel
NAXIS   =                    2 / number of data axes
NAXIS1  =                   10 / length of data axis 1
NAXIS2  =                   10 / length of data axis 2
EXTEND  =                    T / FITS dataset may contain extensions
COMMENT   FITS (Flexible Image Transport System) format is defined in 'Astronom
COMMENT   and Astrophysics', volume 376, page 359; bibcode: 2001A&A...376..359H
HELLO   =              'World'

julia> # Write a new file with the old header

julia> FITS("helloagain.fits", "w") do file
           write(file, data, header=hdr2)
       end

shell> dfits helloagain.fits
====> file helloagain.fits (main) <====
SIMPLE  =                    T / file does conform to FITS standard
BITPIX  =                  -64 / number of bits per data pixel
NAXIS   =                    2 / number of data axes
NAXIS1  =                   10 / length of data axis 1
NAXIS2  =                   10 / length of data axis 2
EXTEND  =                    T / FITS dataset may contain extensions
COMMENT   FITS (Flexible Image Transport System) format is defined in 'Astronomy
COMMENT   and Astrophysics', volume 376, page 359; bibcode: 2001A&A...376..359H
COMMENT   FITS (Flexible Image Transport System) format is defined in 'Astronomy
COMMENT   and Astrophysics', volume 376, page 359; bibcode: 2001A&A...376..359H
HELLO   = 'World   '
END

I also note that the string representation of the FITSHeader object cuts off the final "y" in the first COMMENT card.

Raw header for WCSLIB

I'm looking into getting WCS information out of FITS image files, and it seems like the preferred function to use is wcspih, which, in WCSLIB.jl at least, requires a raw ASCII FITS header. I think this can only be accessed with the now private Libcfitsio.fits_hdr2str function.

I think this could also be done with wcsprm, but I haven't been able to find clear enough documentation about exactly which header key values should go into which arguments to do this with confidence.

Do you have thoughts about whether there is a better way to do this, or whether maybe the raw header string should be available to users for this reason?

License clash? (MIT/GPL)

I see that FITSIO.jl has been released under the MIT license. However, the purpose of the code is to provide a link to the CFITSIO library, which is covered by the GPL (see http://heasarc.nasa.gov/docs/software/fitsio/c/f_user/node9.html).

Given the viral nature of the GPL, wouldn't this require that FITSIO.jl be released under the GPL too? The CFITSIO license states that "…any software that uses the CFITSIO library (which in turn uses the gzip code) must conform to the provisions in the GNU General Public License".

I know that different opinions exist on this topic (see http://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works), but I wanted to know the author's position regarding this delicate issue.

(By the way: I am not a fan of the GPL, as I hate its viral nature. As a matter of fact, http://heasarc.nasa.gov/docs/software/fitsio/c/f_user/node9.html states that CFITSIO has been released under the GPL because it links to some GPL'ed code from zlib and AIPS. But I think it is important to fix this kind of issues.)

Integration with Images.jl?

I notice there's no integration with Images.jl here, and I'm curious about the reasons. If Images.jl doesn't actually offer anything of value to you, what would it take to make it useful? (I'm not saying I expect that it already has every algorithm you'd ever need, but I'd be equally surprised if there's nothing of value---if so, that's clearly a deficiency in Images.jl.) If Images.jl's I/O architecture isn't compatible with your needs, again it would be interesting to know what would need to be done to make it work. Images.jl is currently being used by the computer-vision and biomedical imaging folks, but I'm not aware of any astronomy people, and it would be great to make sure your needs are also met.

For I/O integration, see docs here:
https://github.com/timholy/Images.jl/blob/master/doc/extendingIO.md
The hope would be that a couple of stub functions in a file starting with using FITSIO would allow easy integration. If you need more sophisticated control over I/O than Images currently offers, well, that would be something we could talk about.

supporting Julia v0.6 and lower?

Now that Julia v0.7-alpha is out the door, we should be looking to update FITSIO.jl for the latest version. However, Julia v1.0 is supposed to be unchanged from v0.7 (just dropping deprecation warnings). Therefore, this seems to be a sensible place to drop support for earlier versions and focus on 1.0+, which should hopefully be a stable platform for a number of years.

As an added bonus, FemtoCleaner will do a lot of the work for us if we're willing to drop support for v0.6 and lower.

Personally, I think we should tag one more version that includes the latest changes on v0.6 and then push forward on v0.7 only.

Thoughts?

Overloading getproperty instead of getindex?

Now that JuliaLang/julia#24960 has been merged, it's possible to do fancy things with a.b syntax. I think it could make sense to use this feature in FITSIO.jl, so that fields can be accessed with the more natural syntax fits.field, rather than fits[:field]. What do you think?

It should be easy to deprecate the old syntax in favor of the new one, however I fear that all this will require Julia 0.7.

Is `FITSIO` compatible with `SharedArrays` ?

Hello,

I have a parallel code that exploits the module SharedArrays but when I try to write a SharedArray into a FITS file, I get the following error message:

ERROR: LoadError: MethodError: no method matching write(::FITS, ::SharedArray{Float64,1})
Closest candidates are:
  write(::FITS, !Matched::Array{String,1}, !Matched::Array{T,1} where T; units, header, hdutype, name, ver, varcols) at /home/users/federico.incardona/.julia/packages/FITSIO/BavHZ/src/table.jl:361
  write(::FITS, !Matched::Array{T,N} where N; header, name, ver) where T at /home/users/federico.incardona/.julia/packages/FITSIO/BavHZ/src/image.jl:166
  write(::FITS, !Matched::Dict{String,V} where V; units, header, hdutype, name, ver, varcols) at /home/users/federico.incardona/.julia/packages/FITSIO/BavHZ/src/table.jl:409
  ...
Stacktrace:
 [1] top-level scope at none:0
 [2] include at ./boot.jl:326 [inlined]
 [3] include_relative(::Module, ::String) at ./loading.jl:1038
 [4] include(::Module, ::String) at ./sysimg.jl:29
 [5] exec_options(::Base.JLOptions) at ./client.jl:267
 [6] _start() at ./client.jl:436
in expression starting at /gpfs/home/users/federico.incardona/julia_parallel_prova.Jl:31

So, is it possible to add a method to make FITSIO compatible with SharedArrays ?

Make HDU types parametric

Would it make sense to make the HDU concrete types parametric? E.g., ImageHDU{T, N}, with T the data type and N the number of dimensions of the underlying data array. This should also make read(...) type stable.

Ideally we could do something similar for the tables, but it's less clear how to encode the information, as they depend also on the specific column

Julia package fetcher installed wrong FITSIO version

Hello,

I report here an issue I had with FITSIO installation and reported to Stackoverflow. My Julia version seems incompatible with FITSIO since it automatically installed the wrong FITSIO package. I had to manually force the URL to download the correct one. Maybe the problem comes from my Julia version, I just let you know the issue.

Kind regards

Problem with FITSIO high level interface

I have had problems with reading the header of an M31 Andromeda FITS file - which was part of my wife's S177 UK Open University Astronomy project - using the HIGH level routines

The file is from the http://www.spacetelescope.org (NASA/ESA Hubble Space Telescope) so has reasonably parentage :

http://www.spacetelescope.org/static/projects/fits_liberator/datasets/m31/f001a066.zip

using FITSIO
cd ("S177")

f001a = FITS("f001a066.fits")
file: f001a066.fits
mode: r
extnum exttype extname
1 image_hdu

size(f001a[1])
(7055,7055)

data = read(f001a[1]);
data[7055,7055]
29976

header = readheader(f001a[1])
ERROR: couldn't parse keyword value: "1.9511305786508E+00,"
in parse_header_val at /Users/malcolm/.julia/v0.3/FITSIO/src/hdutypes.jl:161
in readheader at /Users/malcolm/.julia/v0.3/FITSIO/src/hdutypes.jl:204

The keyword value has a trailing ',' which throws the error in parse_header_val

Using the LOW level API gave no problems:

f001 = fits_open_file("f001a066.fits")
n = fits_get_hdrspace(f001)[1]
for i = 1:n
println(fits_read_keyn(f001,i))
end

Looking at the header from a LOW level data dump, the problem is with the SKEW value but I suspect it is actually the entry above which has no key or value, just a comment, which I suspect is the real culprit

("CROTA1","1.9373114911858E+00","Rotation angle of first axis (deg)")
("CROTA2","1.9373114911858E+00","Rotation angle of second axis (deg)")
("","","Warning: CROTA2 is inaccurate due to considerable skew")
("SKEW","1.9511305786508E+00,","1.9234924037208E+00 /Measure of skew")

A work around in the parse_header_val routine (my hack-- I am a reformed Perl programmer after all) was :

function parse_header_val(my_val::String)
if length(my_val) == 0 return "" end
val = (my_val[end]==',') ? chop(my_val) : my _val
try
return int(val)
etc....

But clearly a fix is better in reader header() to ensure that the values don't have trailing ',' or other nasty characters to begin with.

Can not create an empty FITS file

Currently it is not possible to create an empty fits file, one with minimal header information, something along the lines of what's presented here: esheldon/fitsio#164 (comment). This would be a nice feature to have.

Docs: dictionaries need to be created with Dict()

Hi, we were following the documentation at https://julia-fitsio.readthedocs.io/en/latest/. The last code block is supposed to generate a Dict(). However, we get

julia> data = ["col1"=>[1., 2., 3.], "col2"=>[1, 2, 3]];

julia> write(f, data)
ERROR: MethodError: no method matching bitpix_from_type(::Type{Pair{String,Array{Float64,1}}})
Closest candidates are:
  bitpix_from_type(::Type{UInt8}) at /home/hsgg/.julia/v0.6/FITSIO/src/libcfitsio.jl:140
  bitpix_from_type(::Type{Int16}) at /home/hsgg/.julia/v0.6/FITSIO/src/libcfitsio.jl:140
  bitpix_from_type(::Type{Int32}) at /home/hsgg/.julia/v0.6/FITSIO/src/libcfitsio.jl:140
  ...
Stacktrace:
 [1] fits_create_img(::FITSIO.Libcfitsio.FITSFile, ::Type{Pair{String,Array{Float64,1}}}, ::Array{Int64,1}) at /home/hsgg/.julia/v0.6/FITSIO/src/libcfitsio.jl:735
 [2] #write#3(::Void, ::Void, ::Void, ::Function, ::FITSIO.FITS, ::Array{Pair{String,Array{Float64,1}},1}) at /home/hsgg/.julia/v0.6/FITSIO/src/image.jl:168
 [3] write(::FITSIO.FITS, ::Array{Pair{String,Array{Float64,1}},1}) at /home/hsgg/.julia/v0.6/FITSIO/src/image.jl:166
 [4] macro expansion at ./REPL.jl:97 [inlined]
 [5] (::Base.REPL.##1#2{Base.REPL.REPLBackend})() at ./event.jl:73

We are using julia-0.6.0.

Can the signature of `Libcfitsio.fits_write_key` be widened?

I have a TLONG that I would like to write to the header using Libcfitsio.fits_write_key (the function is mirroring a C routine so I want to use the Libcfitsio interface). At the moment the function only accepts floats and strings (see the link below), but it naively looks like it might have been written with a wider signature in mind.

FITSIO.jl/src/libcfitsio.jl

Lines 347 to 358 in 8f53836

	function fits_write_key(f::FITSFile, keyname::Compat.ASCIIString,
	value::Union{AbstractFloat,Compat.ASCIIString},
	comment::Compat.ASCIIString)
	cvalue = isa(value,Compat.ASCIIString) ? value :
	isa(value,Bool) ? Cint[value] : [value]
	status = Ref{Cint}(0)
	ccall((:ffpky,libcfitsio), Cint,
	(Ptr{Void},Cint,Ptr{UInt8},Ptr{UInt8},Ptr{UInt8},Ref{Cint}),
	f.ptr, cfitsio_typecode(typeof(value)), keyname,
	cvalue, comment, status)
	fits_assert_ok(status[])
	end

Edit: grammar and typos

FITSIO with Julia 1.0

Is the current version v0.11.0 of FITSIO supposed to work under Julia 1.0?
I get the following error when starting FITSIO for the first time:

[ Info: Precompiling FITSIO [525bcba6-941b-5504-bd06-fd0dc1a4d2eb]
ERROR: LoadError: syntax: extra token "ImageHDU" after end of expression
Stacktrace:
[1] include at ./boot.jl:317 [inlined]
[2] include_relative(::Module, ::String) at ./loading.jl:1038
[3] include(::Module, ::String) at ./sysimg.jl:29
[4] top-level scope at none:2
in expression starting at /Users/Bob/.julia/packages/FITSIO/WueGk/src/FITSIO.jl:54

`copy_section` argument order and name

copy_section(hdu, dest, range...) has an argument order reversed from the standard order, where the destination is the first argument. This would be easy to switch and deprecate the old version.

Perhaps the name should be copy_section! or just extend Base.copy!. This is slightly different than Base.copy! because dest::FITS and hdu::ImageHDU are not the same types of things.

[PackageEvaluator.jl] Your package FITSIO may have a testing issue.

This issue is being filed by a script, but if you reply, I will see it.

PackageEvaluator.jl is a script that runs nightly. It attempts to load all Julia packages and run their test (if available) on both the stable version of Julia (0.2) and the nightly build of the unstable version (0.3).

The results of this script are used to generate a package listing enhanced with testing results.

The status of this package, FITSIO, on...

• Julia 0.2 is 'No tests, but package loads.'
• Julia 0.3 is 'No tests, but package loads.'

'No tests, but package loads.' can be due to their being no tests (you should write some if you can!) but can also be due to PackageEvaluator not being able to find your tests. Consider adding a test/runtests.jl file.

'Package doesn't load.' is the worst-case scenario. Sometimes this arises because your package doesn't have BinDeps support, or needs something that can't be installed with BinDeps. If this is the case for your package, please file an issue and an exception can be made so your package will not be tested.

This automatically filed issue is a one-off message. Starting soon, issues will only be filed when the testing status of your package changes in a negative direction (gets worse). If you'd like to opt-out of these status-change messages, reply to this message.

edit BUNIT

Hi!,
If I create a header with the reserved key BUNIT and I save the file,
the key BUNIT is not written in the header of the file. Am I wrong somewhere ?

Thanks in advance