Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gray arithmetic #38

Closed
bjarthur opened this issue Apr 1, 2016 · 8 comments
Closed

Gray arithmetic #38

bjarthur opened this issue Apr 1, 2016 · 8 comments
Milestone

Comments

@bjarthur
Copy link
Member

bjarthur commented Apr 1, 2016

when mixing Gray with Number the type of the result depends on the order of the inputs:

julia> using ColorVectorSpace, Colors

julia> 2.0 / Gray(2.0)
1.0

julia> Gray(2.0) / 2.0
Gray{Float64}(1.0)

julia> Gray(2.0) / Gray(2.0)
1.0

my feeling is that the results should always be Gray, but wanted to ask for opinions before submitting a PR to fix it, as a whole a lot has to be changed, for all of + and - always returns Number when the inputs are of mixed types:

julia> Gray(2.0)+Gray(2.0)
Gray{Float64}(4.0)

julia> Gray(2.0)+2.0
4.0

julia> 2.0+Gray(2.0)
4.0
@timholy
Copy link
Member

timholy commented Apr 1, 2016

For the record, here's the logic behind the current choices:

  • In adding/subtracting quantities, at one point I felt it would be best to convert to plain numbers unless everything were gray. Not sure about this at all.
  • In Gray/Gray, the grays "cancel," much as units like meter cancel when you perform division. Stated differently, if you're computing a ratio of image intensities, isn't this a number rather than a grayscale value?
  • The weirdest one is 2.0/Gray(2.0). We don't have a type with units 1/Gray, so I made it just default to a real value.

I don't even begin to pretend I know how to make the right call here. This is murky territory, so I invite debate.

@bjarthur
Copy link
Member Author

bjarthur commented Apr 1, 2016

so long as there is a logic, i think i can live with it. thanks.

@timholy
Copy link
Member

timholy commented Apr 1, 2016

I do wonder if we should change addition and subtraction, though.

@bjarthur
Copy link
Member Author

bjarthur commented Apr 1, 2016

addition and subtraction treat Array{Gray} and Gray in a way which doesn't seem consistent:

julia> data = convert(Array{Gray{Float64}},rand(3))
3-element Array{ColorTypes.Gray{Float64},1}:
 Gray{Float64}(0.750356)
 Gray{Float64}(0.671796)
 Gray{Float64}(0.595428)

julia> data - 0.1
3-element Array{ColorTypes.Gray{Float64},1}:
 Gray{Float64}(0.650356)
 Gray{Float64}(0.571796)
 Gray{Float64}(0.495428)

julia> data[1] - 0.1
0.6503562677627358

@timholy
Copy link
Member

timholy commented Apr 6, 2016

Base julia uses an interesting rule: when performing an operation on an array and a scalar, the type of the array wins.

For example:

julia> typeof(UInt8(5)+3)
Int64

julia> typeof([UInt8(5)]+3)
Array{UInt8,1}

This was chosen to prevent promotion from blowing up the size required to store the result.

@johnnychen94
Copy link
Member

from users' experience, what can we expect about the output type of some complicated function?

"Colorants in, Colorants out" satisfies me most

@timholy
Copy link
Member

timholy commented May 9, 2019

There's real merit in that. The current system may be too complicated to intuit.

A defense of the current system, though, might be

meanval = mean(img)     # this would be Gray
ratio = img ./ meanval  # this would be Float64

To me this makes a bit of sense, if I'm computing a ratio I expect a plain number.

Anyway, I'm open to changing this.

@timholy
Copy link
Member

timholy commented Jan 21, 2021

Fixed by #131

@timholy timholy closed this as completed Jan 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants