This is a re-post from a recent slack discussion
I don't think JuliaImages will try to break the "an image is AbstractArray{<:Colorant} " contract because we've proved that it's so convenient to build orthogonality and thus support generic codes in a very efficient way. For image data that doesn't fit into the AoS (RGBRGBRGB) memory layout, an approach to fit into the JuliaImages type design is to provide a thin array wrapper for it.
For instance:
IndirectArray for indexed image
StructArray wraps SoA data as AbstractArray{<:Colorant}
SparseArray from SparseArrayKit wraps a dict-based data for sparse image
By following this design, we can ensure that our toolbox at least works for those special image types. And if performance is a concern, we add specialized methods to provide an optimized implementation for them via multiple dispatches.
we need to figure out the missing utilities by adding a few examples, e.g., imresize on the indexed image can be an interesting yet simple example.