Migrating strategies for accuracy test

[kimikage]

As mentioned in #355, I want to change the accuracy test to something new.

Reducing the size of test data (:heavy_check_mark: Done)

Although this is not a so strategic matter, let's start here. The current test data is in "test/test_conversions.jld2". It contains an array csconv as schematically shown below:

Although the above is different from the actual internal representation of JLD2, there are 4840 color elements (11 from-colortypes x 11 to-colortypes x 20 swatches x 2). However, the from-data and the to-data should be the same for each color type. Of course, since the range of colors which can be represented varies depending on the colorspace*, there are certainly many one-way conversions. However, it is not a matter of the accuracy, so the colors in test data should be representable in all color types.

Removing JLD2 dependency (:heavy_check_mark: Done)

If we select to use the N-order test data instead of N^2-order, we can also use a plain-text (i.e. Julia script) instead of JLD2.

Incidentally, although it does not matter in local environment, in the CI (i.e. Travis or AppVeyor), JLD2 (or CodecZlib) may lead to an increase of the build time.

Originally posted by @kimikage in https://github.com/JuliaGraphics/Colors.jl/issues/355#issuecomment-535438639

Selecting the color swatches

I think the values in "test_conversions.jld2" have much greater errors than eps(Float64).

Originally posted by @kimikage in https://github.com/JuliaGraphics/Colors.jl/issues/355#issuecomment-534205203

Since a uniform threshold is currently used, the overall accuracy requirement is set by the one color pair with the largest difference. Although the requirement has been adjusted by PR #356, I think it is still loose. The problem is that the cause of the difference is unknown rather than the difference itself.

If we stop using "test/test_conversions.jld2", I would recommend re-selecting the 20 colors. I prefer intentionally fixed colors over random colors. For example:

Color3{Float64}[
RGB(0,0,0) RGB(1,0,0) RGB(0,1,0) RGB(0,0,1)
RGB(1,1,1) RGB(1,1,0) RGB(0,1,1) RGB(1,0,1)
XYZ(0.5,0.5,0.5) LMS(0.4,0.5,0.6) RGB(0.6,0.6,0.6) YIQ(0.5,0,0)
Lab(60,0,-20) Lab(50,-30,0) Lab(40,0,40) Lab(30,50,0)   
Luv(25,-10,-10) Luv(75,60,60) YIQ(0.5,0.5,0) YCbCr(100,128,240)
]

Originally posted by @kimikage in https://github.com/JuliaGraphics/Colors.jl/issues/355#issuecomment-535438639

Most of the time required for testing is compiling time, so I don't think the number of swatches needs to be less than or equal to 20. However, at most 50 colors can be easily identified by humans.

Selecting the target colortypes

The current N (=11) colortypes are:

• RGB{Float64}
• HSV{Float64}
• HSL{Float64}
• HSI{Float64}
• XYZ{Float64}
• Lab{Float64}
• Luv{Float64}
• LCHab{Float64}
• LMS{Float64}
• YIQ{Float64}
• YCbCr{Float64}

Of course, Gray is not suitable for this accuracy test, so its absence is not a problem. However, xyY, LCHuv, DIN99, DIN99d and DIN99o are also absent. DIN99 has the special test data. https://github.com/JuliaGraphics/Colors.jl/blob/0ceb396d38c3a0577110a3b50623dd5de5916d09/test/din99.jl#L4-L20 Should we add the absent color types?

Selecting reference generators

How do we generate the reference data for given colors and types? I don't have a good idea.

---

[]: This is related to the color gamut, but different from the so-called "out-of-gamut" problem. For example, the HSV colorspace has various gray representations with arbitrary hue*. This property is immutable whether the color gamut is "sRGB" or "Rec. 2020". Moreover the non-normalized grays are usually not "out-of-gamut".

[kimikage]

Using CIE TCSs is an idea. https://en.wikipedia.org/wiki/Color_rendering_index?#Test_color_samples However, since they are for reflective colors, they have little meaning for self-luminous colors.

[kimikage]

In order to modify the XYZ <--> RGB conversion matrices (in v0.13), I want to do this first. cf. https://github.com/JuliaGraphics/Colors.jl/issues/355#issuecomment-539524932