JuliaImages / JuliaImages/juliaimages.github.io
consistent method dispatch
@johnnychen94 is already working on this.
Since Jan 1, 2020.
- Dominant language
- Julia
- Stars
- 33
- Forks
- 52
- PR merge metrics
- No merged PRs in 30d
Description
This is not a trivial work that can be done in a short time.
I've added some simple but useful traits to ImageCore v0.8.2, which can be used throughout the JuliaImage repos.
For example:
const Gray2dImage = ImageCore.Gray2dImage
function denoise(img::Gray2dImage)
# generic denoise algorithm for Gray 2d images
end
function denoise(img::Gray2dImage{Normed})
# denoise algorithm for Gray 2d images with base type Normed
end
where
# defined in ImageCore but not exported
const GrayLike{T<:Union{Bool, FixedPoint, AbstractFloat}} = Union{T, AbstractGray{T}}
const Gray2dImage{T} = AbstractArray{<:GrayLike{T}, 2}
I can think of three advantages adapting this seems-trivial notation:
- ecosystem-wide consistency on supported input types.
- by reducing manually coding on complex and lengthy type dispatch, codes become easier to read and harder to be messed up
- extensible support to non-array image types by providing an extra abstraction layer(but without definitions of new types). https://github.com/JuliaImages/Images.jl/issues/769
The third becomes possible if we do
const Gray2dImage = Union{ImageCore.Gray2dImage, OtherGray2dImageType}
Multiple dispatches is extremely important for robust image-processing algorithms because the algorithm behavior is totally different when types are different, e.g., dealing with 2d and 3d images, dealing with Gray and RGB images, and dealing with Normed and AbstractFloat base types. IMO, for most of the time, AbstractArray and AbstractArray{<:Colorant} are too generic. (These were easy to be typed down, but now Gray2dImage becomes easier)
The goal of ImageCore is to reduce too delicately manual dispatch for downstream packages as much as possible. In the meantime, ImageCore can't foresee and prepare for all possible types. For example, sometimes RGB images are processed channel-wise, and sometimes three channels are processed in a coherent way. Such kind of decisions must remain to downstream package developers.
In the future we may need similar symbols such as GenericImage, GenericColorImage, GenericRGBImage, Generic2dImage, RGB2dImage, but I haven't considered so far yet.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.