Closed glennsweeney closed 10 years ago
Any time I see a bunch of functions with really similar names, I get pretty suspicious that this should be done with dispatch instead. Perhaps by providing color difference types and then having the color difference type as an optional argument to colordiff
?
Having color difference objects also naturally provides a place for parameters to the difference computation to live, which is another indication that it's a better way to express this.
Ugh. I'm still a C programmer at heart, sorry. I'll see what I can do for that; thanks for the input.
Any suggestions on what the objects could look like to be more coherent with the Julia mentality?
No worries – C is the desert island programming language, after all :-)
They should be something like this:
abstract ColorMetric
immutable CIEDE2000 <: ColorMetric end
immutable DeltaE94 <: ColorMetric
kl::Int
kc::Int
kh::Int
DeltaE94(; kl::Integer=1, kc::Integer=1, kh::Integer=1) = new(kl, kc, kh)
end
immutable JPC79 <: ColorMetric
...
Later you would do something like this:
colordiff(ai::ColorValue, bi::ColorValue, m::ColorMetric) = colordiff(ai, bi, CIEDE2000())
function colordiff(ai::ColorValue, bi::ColorValue, m::CIEDE2000)
...
end
function colordiff(ai::ColorValue, bi::ColorValue, m::DeltaE94)
# use m.kl, m.kc, m.kh values as parameters
...
end
Those parameter names could probably be better since they're now externally exposed.
Any progress? Does that approach make sense?
Yes, it does make sense! Sorry, it's approaching finals week - things are gonna move at a snail's pace for me for a bit. I'll try to get a look at this and put the changes in soon as I can.
No worries, just thought I'd ask.
Here's an updated version. let me know what you think. I also took the liberty of deleting a .swp file that had snuck into the repository with 0d7e39fb5ee930931ed8dff53ca45ac234ef6089. Left it as a separate commit for transparency.
Looks good to me but @dcjones should take a look and merge if it's good.
Nice work @glenn-sweeney.
The one issue I noticed is this:
julia> colordiff(color("red"), color("blue"), DE_BFD())
ERROR: no method convert(Type{XYZ}, RGB, XYZ)
in colordiff at /Users/dcjones/.julia/v0.3/Color/src/differences.jl:298
That's just exposing an existing issue though. We have a white point parameter when converting from e.g. LAB
to XYZ
, but not from RGB
to XYZ
. So if it makes sense, we should add the same parameter to every convert(::Type{XYZ}, ...)
function.
I've been noticing some problems as well; for instance, there is no
conversion with a white point from XYZ
to LCHab
or similar. If we want
to provide this support, it'll just mean adding white point control through
the entire conversion function set. Special care will need to be taken with
examples like RGB - right now we only support sRGB, which uses the D65
white point only.
On Sun, Jun 1, 2014 at 12:29 PM, Daniel Jones notifications@github.com wrote:
The one issue I noticed is this:
julia> colordiff(color("red"), color("blue"), DE_BFD())ERROR: no method convert(Type{XYZ}, RGB, XYZ) in colordiff at /Users/dcjones/.julia/v0.3/Color/src/differences.jl:298
That's just exposing an existing issue though. We have a white point parameter when converting from e.g. LAB to XYZ, but not from RGB to XYZ. So if it makes sense, we should add the same parameter to every convert(::Type{XYZ}, ...) function.
— Reply to this email directly or view it on GitHub https://github.com/JuliaLang/Color.jl/pull/28#issuecomment-44781849.
Yeah, a more general RGB
implementation would be good. I'd be best if we can do that without forcing people to care about the white point, etc, and default to sRGB.
It might be worth introducing a type like conversionparams
or something that can house relevant customized conversion information, such as a white point, and provide it as an optional parameter to any conversion. That way "longer" conversions through multiple steps could have access to necessary custom data. For instance, if you were converting from LMS
to LCHab
, it could provide white point information to the intermediate XYZ->LAB step.
This allows a bit of "futureproofing" as we accumulate more metadata needed for certain steps, but when not provided, could always revert to defaults. It could also become the backbone of a general RGB transformation; if nothing is specified, assume the sRGB tone function and D65 white point.
Just a thought, if there's a better way to structure this, I'm happy to consider that instead.
A whole slew of color difference formulae for those who just can't be satisfied with Delta E 2000. ;)
Some have industry applications; some are antique but still used. I will try to look up sources and include them soon.
You'll notice that
colordiff
survived untouched; it is just an alias forcolordiff_2000
now. See line 84.BFD has a feature to allow giving a white point for the LAB->XYZ and XYZ->LAB transform that happens internally. I left it undocumented to avoid confusion.