cannot reverse an AstroImage, not sure if this is a problem within this package or a dimensional data issue

julia> img = load("https://fits.gsfc.nasa.gov/samples/FOCx38i0101t_c0f.fits")

julia> reverse(img, dims=1)
ERROR: UndefKeywordError: keyword argument data not assigned
Stacktrace:
 [1] setdims
   @ ~/.julia/packages/DimensionalData/JmqYO/src/Dimensions/primitives.jl:311 [inlined]
 [2] reverse(A::AstroImageMat{Float32, Tuple{X{DimensionalData.Dimensions.LookupArrays.Sampled{Int64, Base.OneTo{Int64}, DimensionalData.Dimensions.LookupArrays.ForwardOrdered, DimensionalData.Dimensions.LookupArrays.Regular{Int64}, DimensionalData.Dimensions.LookupArrays.Points, DimensionalData.Dimensions.LookupArrays.NoMetadata}}, Y{DimensionalData.Dimensions.LookupArrays.Sampled{Int64, Base.OneTo{Int64}, DimensionalData.Dimensions.LookupArrays.ForwardOrdered, DimensionalData.Dimensions.LookupArrays.Regular{Int64}, DimensionalData.Dimensions.LookupArrays.Points, DimensionalData.Dimensions.LookupArrays.NoMetadata}}}, Tuple{}, Matrix{Float32}, Tuple{X{DimensionalData.Dimensions.LookupArrays.Sampled{Int64, Base.OneTo{Int64}, DimensionalData.Dimensions.LookupArrays.ForwardOrdered, DimensionalData.Dimensions.LookupArrays.Regular{Int64}, DimensionalData.Dimensions.LookupArrays.Points, DimensionalData.Dimensions.LookupArrays.NoMetadata}}, Y{DimensionalData.Dimensions.LookupArrays.Sampled{Int64, Base.OneTo{Int64}, DimensionalData.Dimensions.LookupArrays.ForwardOrdered, DimensionalData.Dimensions.LookupArrays.Regular{Int64}, DimensionalData.Dimensions.LookupArrays.Points, DimensionalData.Dimensions.LookupArrays.NoMetadata}}}}; dims::Int64)
   @ DimensionalData ~/.julia/packages/DimensionalData/JmqYO/src/array/methods.jl:298
 [3] top-level scope
   @ REPL[9]:1

Everyone's favorite DS9/IRAF feature!

This feature would allow some way of defining the image scale according to IRAF's z-scale. This method requires some simple statistics and fitting and should return a minimum and maximum color.

Example Usage

using AstroImages
img = load("image.fits")
cmin, cmax = zscale(img, args...)

plot(img, cmin=cmin, cmax=cmax)

References

• DS9 source code
• A hard to parse written description
• astropy

AstroImage loads the 1st HUD from the fits file given by default. If the first one is not of image type an error occurs. Eg: euve.fits
I suggest a patch to iterate over the fits file to find the first valid Image type file and use it as default or raise some suitable error to notify user if there is no such Image type file.

issue moved here from JuliaAstro/FITSIO.jl#90

Besides integration with Images.jl (issue #1), it may be useful to have integration with Plots.jl (or whatever will be the next-gen plotting package in Julia). This can be achieved with plot recipes. If there are WCS coordinates, they could be automatically used as tics on the axes.

There's a poor interaction between dimensions which should be broadcastable but which are not equal. For example:

julia> using AstroImages

julia> dark = AstroImage(zeros(1, 10, 10));

julia> raw = AstroImage(ones(5, 10, 10));

julia> calib = raw .- dark
ERROR: DimensionMismatch: Found both lengths 5 and 1 for X

this is inconvenient for working with collapsed frames (e.g., master dark frame).

I am not been able to modify the color map with implot.
I would expect the following lines to display the image with colormap ice.
Whatever the cmap provided, the image is displayed with magma.

using AstroImages, Plots
file = "Image.fits"
img = AstroImage(file)
implot(img, cmap=:ice)

I am able to display with a different colormap using imview

p = imview(img, cmap=:ice)
plot(p, frame=:none)

this displays with cmap=:ice as expected.

Is this an issue or me misusing implot ?

This issue is intended as a continuation of JuliaAstro/FITSIO.jl#18

optical FITS, NAXIS = 2, dimensions 24900 x 26620, 2.5GB FITS file, the following code runs out of memory:

using AstroImages
#] pkg> add https://github.com/JuliaAstro/AstroImages.jl

using FITSIO
using Plots

dir = "/home/chris/ダウンロード"
file = "e20121211_0010500001_dp_sf_st_mos.fits"

fitspath = string(dir, "/", file)
println("loading ", fitspath)
fits = load(fitspath)

img = AstroImage(fits)
plot(img)

The FITS file can be downloaded from

http://surveys.roe.ac.uk/wsa/cgi-bin/siap.cgi?extNum=2&file=djoser:/disk39/wsa/products/mosaics/20121211_v10/e20121211_0010500001_dp_sf_st_mos.fit

Then the file extension needs to be changed from .fit to .fits .

Ideas/Wishlist for AstroImages

As discussed on the JuliaAstro call, I'm interested in developing out AstroImages further. The following is a sort of wishlist of what I would want in such a package. I'm aware several of these features like plot recipes already exist in this package, but I've included them below anyways for completeness.
The purpose of all of this is just to start a discussion and summarize what the community would want.

In terms of previous work in this space, there are to my knowledge:

• AstroImages.jl (of course)
• EasyFits
• DirectImages
• CCDReduction (edit: thanks @mileslucas)

Basics

• Very easy to use: loading and displaying images should be fast and self-explanatory
• It should be possible to display very large images
• Seamless support of multi-dimensional cubes (4+ dimensions) and multiple FITS extensions.
• It should be possible to work with multi-extension cubes as easily as normal cubes

Array types

• We should try and be agnostic to the type of array we wrap in an AstroImage.
• For example, we should support views, static arrays, CuArrays, distributed arrays, etc.

Integration with Images.jl ecosystem

• One of the key features of Images is the use of data types like normed UInt8 to store normalized data in the range [0,1] in 8 bits and color types on the elements to trigger displaying images.
• This approach works well but IMO astronomers will expect their data to stay in the format they load from e.g. FITS files: Ints, Float32s, etc. and isn't often normalized.
• Especially since we will want to handle spectra data as e.g. tagged axes rather than an RGB element type (N.B. this doesn't mean we can't have nice functions to compose RGB images)
• I think it's better to follow the approach this package already uses: create views into the data as e.g. Gray when needed and otherwise preserve the element type.
• Ideally we want our images type to work when passed into any of the Images functions and preserve the wrapper type

FITS Headers

• Headers are a balancing act between convenience and performance.
• We need easy, first class access to header data and comments
• Headers should be preserved through function calls that create new images
• IMO headers should always be copied when new AstroImages are created by applying functions to existing images, unless using a view(). Views should of course still have headers but refer to the parent array.
• We need to support large numbers of headers and changing the headers should not lead to heavy compiler latency, so I think headers should not be stored in a fully type stable way e.g. as named tuples.
• At the same time, we want downstream analysis packages to be able to use values stored in headers performantly
• IMO the best compromise is storing header data in an OrderedDict{Symbol,T} where T is a small union of allowable header types. Perhaps something like Union{Bool,Int,Float32,InlineString128}. Hopefully this will allow the compiler to make reasonably fast code using values stored in headers(?). This might take experimentation.
• One question is if headers should be accessible as properties on the AstroImage. For example: img.totexp=5. This is really convenient but we'll still need another syntax for accessing header comments.
• What I settled on in my experiments was the following:
  img[<:Union{Number,Vector}] for indexing into the image
  img[:head1] for accessing a header value
  img[:head1, /] for accessing a comment (but this may be too punny)
  img.head1 as a shortcut syntax for accessing a header value.
  I implemented this syntax in DirectImages after the discussion we had at JuliaAstro/FITSIO.jl#128 and it has felt very natural. Feedback welcome though.

Axes and WCS

• This section trickier for me as I have less experience here.
• For me personally, I need to be able to use images with relative offset axes so that e.g. [0,0] is the "centre" of the image
• How best should this combine with Unitful and UnitfulAngles?

Displaying Images

• display() of an AstroImages should show an image very quickly without needing Plots or Makie.
• We can do this leveraging the Images support for displaying images by making a view of e.g. Gray(). I have a demo where colormaps can also be used to display an image in e.g. magma very efficiently by using RGB().
• We should have a function like imshow that displays images with more customization, e.g. colorschemes, clipping. I prototyped this and found displaying a large image with full color this way was >10x faster than through plots. E.g. 1600x1600 takes about 150ms.
• IMO scaling like z-scale or log should just be functions users apply to the array before passing to display functions instead of e.g. keyword arguments
• We should also have support for plot()ing images of course.
  • In fact, it's more efficient to plot() an array of Gray for example than making a big heatmap. Hopefully we could leverage such an imshow function to make plotting large images efficient automatically.
• plot should be WCS aware vs imshow that just shows the pixel data.
• Ideally we should also support Makie

External Image Viewing Integration

• For interactive viewing, there is no need to reinvent the wheel. We should have lightweight functions for sending images to programs like DS9
• There is already https://github.com/JuliaAstro/SAOImageDS9.jl and ideas for more features here JuliaAstro/SAOImageDS9.jl#4
• And ds9show from DirectImages.jl
• It might be possible to use shared memory to show large images.
• Is it better to integrate here, or keep this in SAOImageDS9.jl?

colorview(C, channels...) is much more efficient than C.(channels...) to create a colour Array, as this just reinterprets the input arrays. However, the returned value isn't simply Array{Gray{Float64},2}, so this would probably require reworking the AstroImage data type.

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.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

I've been making some plots and noticed that the gridcolor argument for implot only seems to function for the default colour map. In this case it seems like the grid lines end up the same colour as the lower extreme of the colour map.