JuliaImages / JuliaImages/juliaimages.github.io

consistent method dispatch

Open
#103 2 comments 0 reactions 1 assignee View on GitHub

@johnnychen94 is already working on this.

Since Jan 1, 2020.

documentation
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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.