Suppose there's a function out_img = f(in_img), can we assume eltype(out_img) == eltype(in_img) by default? More specifically,
- If we input an
AbstractArray{<:Colorant}, shall we output AbstractArray{<:Colorant} as well?
For Color3 images, it's definite yes, but for Gray images, I think we should keep the same.
However, it's not so consistent at present. For example, a + b would be Gray{Float64} or Float64, depending on whether one of them is Number.
related issue: JuliaGraphics/ColorVectorSpace.jl#38
- if we input an
AbstractArray{T} where T<:Colorant, shall we output AbstractArray{T} as well?
Ideally speaking, we should, but this would introduce a potential performance issue.
For example, if we have f1, f2, f3, ..., fn defined only for RGB images, which support generic Color3 images by converting them to RGB first. Should we convert them back after processing? If we convert it back, then there would be unnecessary many conversions when
fn(...(f3(f2(f1(img))))); if we don't, sometimes it would surprise the user when they process non-RGB images.
related issue: JuliaImages/ImageTransformations.jl#68
- if we input an
AbstractArray{Gray{T}} where T<:Number, shall we output AbstractArray{Gray{N0Tf8}} as well?
Storage type auto-promotion happens a lot here and there, especially for N0f8->Float64. But I think we don't need to restrict Float64 back to N0f8. I guess this is a common decision, just list the last item here to make sure I understand it right.
I don't have a good solution here for this issue, so I post it to get potential feedback if you happen to have some thoughts.
Suppose there's a function
out_img = f(in_img), can we assumeeltype(out_img) == eltype(in_img)by default? More specifically,AbstractArray{<:Colorant}, shall we outputAbstractArray{<:Colorant}as well?For Color3 images, it's definite yes, but for Gray images, I think we should keep the same.
However, it's not so consistent at present. For example,
a + bwould beGray{Float64}orFloat64, depending on whether one of them isNumber.related issue: JuliaGraphics/ColorVectorSpace.jl#38
AbstractArray{T} where T<:Colorant, shall we outputAbstractArray{T}as well?Ideally speaking, we should, but this would introduce a potential performance issue.
For example, if we have
f1, f2, f3, ..., fndefined only for RGB images, which support genericColor3images by converting them toRGBfirst. Should we convert them back after processing? If we convert it back, then there would be unnecessary many conversions whenfn(...(f3(f2(f1(img))))); if we don't, sometimes it would surprise the user when they process non-RGB images.related issue: JuliaImages/ImageTransformations.jl#68
AbstractArray{Gray{T}} where T<:Number, shall we outputAbstractArray{Gray{N0Tf8}}as well?Storage type auto-promotion happens a lot here and there, especially for
N0f8->Float64. But I think we don't need to restrictFloat64back toN0f8. I guess this is a common decision, just list the last item here to make sure I understand it right.I don't have a good solution here for this issue, so I post it to get potential feedback if you happen to have some thoughts.