Transposition and 3d data

[mileslucas]

I've been playing around with DS9.jl for a while now and figured a couple things could be addressed.

In particular the way array data is transferred between XPA and Julia permutes each dimension, since Julia is column-ordered. Using PyDS9 through PyCall will correctly orient the data (something in PyCall makes sure arrays show up in python knowing they are column-oriented), but the same image put through DS9.jl will be transposed.

At a low-level, I'm not sure if there is an appropriate way to write things in XPA.jl to make sure when the array pointers are given they are column ordered, if that's even a thing. At a higher level, within this library when set encounters an array, it should permute it appropriately to become row-ordered.

---

I also work with 3d data frequently, and it seems pretty trivial to add the feature here. I've coded up a version that seems to work-

function set(arr::DenseArray{T,3};
             endian::Symbol=:native,
             mask::Bool=false,
             new::Bool=false) where {T<:PixelTypes}
    !new && set("frame delete all"); set("frame new")
    args = String[]
    push!(args, "array")
    if mask; push!(args, "mask"); end
    parr = permutedims(arr, (3, 2, 1))
    set(args..., _arraydescriptor(parr; endian=endian); data=parr)
end

function _arraydescriptor(arr::DenseArray{T,3};
                          endian::Symbol=:native) where {T}
    bp = bitpix_of(T)
    bp != 0 || error("unsupported data type")
    return string("[xdim=",size(arr,1),",ydim=",size(arr,2),",zdim=",size(arr,3),
                  ",bitpix=",bp,",endian=",endian,"]")
end

I'm happy to wrap this up in a PR, but I wanted to discuss the transposition issue first.

[emmt]

For me the fact that Julia arrays are in colum-major order is not an issue, on the contrary, since my team and I have adopted the same convention for all our code (mostly 2D, 3D and 4D image processing) since a long time. I however do understand that this can be an issue for others. The easier fix would be to have a keyword like swap or orient to trigger the permutation of axes.

For other purposes, I have written somewhere some preliminary code that deals with all all possibilities for 2D arrays (there are 8 possibilities for 2D arrays: permute axes or not and reverse each axes or not) with a keyword ident that is an integer (a bitwise combination of options). We could start with that and add 3D axes.

The advantage of having a single integer summarizing all possible transforms is that it is easy to have each user provide a default value for this parameter. Using an environment variable is quite fast:

default_orient() = begin
    val = tryparse(Int, get(ENV, "DS9_ORIENT", ""))
    val === nothing ? 0 : val
end
using BenchmarkTools
ENV["DS9_ORIENT"] = ""
@btime default_orient() # --> 58.697 ns (0 allocations: 0 bytes)
ENV["DS9_ORIENT"] = "9"
@btime default_orient() # --> 87.417 ns (1 allocation: 32 bytes)

Let me know if you would agree with this. In the meantime I will extract the 2D code to provide a starting example.

[emmt]

Something to remember is that coordinates retrieved from DS9 will have to be transformed back if you use different conventions for the array axes than the ones assumed by DS9.

[mileslucas]

I think something more like DS9_ORIENT is either ["row","col"] is appropriate. During the module initialization/configuration, this will get parsed and can be encoded into whatever intermediate format. In addition, a function like default(;opts...) which can update configuration using keyword arguments would be nice, too.