[R] bizarre color space conversion problem

[Sarah Goslee]

Wow. You are entirely correct. I would not have been able to pinpoint
the problem, or how to test it. Thank you.

I am unhappy you are right, since these are the fast workstations I
use for all of my heavy-duty analysis, and it's not even *possible* to
rerun everything.

Oh dear.

Here, with the options you suggested, it produces the expected results:

# env OPENBLAS_CORETYPE=Haswell R --vanilla

> white <- c(x = 0.953205712549377, 1, y = 1.08538438164692)
> red10.rgb <- structure(c(1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0), .Dim = c(10L, 3L), .Dimnames = list( NULL, c("r", "g", "b")))
> convertColor(red10.rgb, from = "sRGB", to = "Lab")
             L        a        b
 [1,] 53.48418 80.01027 67.38407
 [2,] 53.48418 80.01027 67.38407
 [3,] 53.48418 80.01027 67.38407
 [4,] 53.48418 80.01027 67.38407
 [5,] 53.48418 80.01027 67.38407
 [6,] 53.48418 80.01027 67.38407
 [7,] 53.48418 80.01027 67.38407
 [8,] 53.48418 80.01027 67.38407
 [9,] 53.48418 80.01027 67.38407
[10,] 53.48418 80.01027 67.38407


> red10.rgb %*% as.list(environment(grDevices::colorspaces$sRGB$toXYZ))$M
           [,1]      [,2]      [,3]
 [1,] 0.4168213 0.2149235 0.0195385
 [2,] 0.4168213 0.2149235 0.0195385
 [3,] 0.4168213 0.2149235 0.0195385
 [4,] 0.4168213 0.2149235 0.0195385
 [5,] 0.4168213 0.2149235 0.0195385
 [6,] 0.4168213 0.2149235 0.0195385
 [7,] 0.4168213 0.2149235 0.0195385
 [8,] 0.4168213 0.2149235 0.0195385
 [9,] 0.4168213 0.2149235 0.0195385
[10,] 0.4168213 0.2149235 0.0195385

On Thu, Jul 18, 2019 at 1:59 PM Ivan Krylov <krylov.r00t using gmail.com> wrote:
>
> On Thu, 18 Jul 2019 13:30:09 -0400
> Sarah Goslee <sarah.goslee using gmail.com> wrote:
>
> > I'm not even remotely a hardware expert: if the difference is due to
> > changes in the instruction set, I assume that has potential
> > consequences for other things, and I just happened to spot it in this
> > particular case because it's visualization-based? (Yikes.)
>
> Yes, this might be bad. I have heard about OpenBLAS (specifically, the
> matrix product routine) misbehaving on certain AVX-512 capable
> processors, so much that they had to disable some optimizations in
> 0.3.6 [*], which you already have installed. Still, would `env
> OPENBLAS_CORETYPE=Haswell R --vanilla` give a better result?
>
> > As it says in my first email (but way at the bottom), I'd already
> > gotten as far as locating the problem in this line from
> > grDevices::convertColor()
> >
> >     xyz <- from$toXYZ(color, from.ref.white)
>
> Thanks for confirming this! It felt that I had to make sure, since the
> behaviour we observe is so confusing.
>
> > > (red.xyz <- grDevices::colorspaces$sRGB$toXYZ(red.rgb,
> > > white.point))[1,]
> > [1] 0.7733981 0.9280769 0.1383974
> > > # [1] 0.4168213 0.2149235 0.0195385
>
> One last check: would
>
> red.rgb %*% as.list(environment(grDevices::colorspaces$sRGB$toXYZ))$M
>
> still produce different results on your computers?
>
> > blas.x86_64                                 3.8.0-12.fc30
> > openblas.x86_64                             0.3.6-2.fc30
>
> I do not know enough about Fedora's "alternatives" system, but it does
> look like R is using OpenBLAS.
>
> > A: working
> > Model name:          Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz
>
> > B: not working
> > Model name:          Intel(R) Core(TM) i9-7900X CPU @ 3.30GHz
>
> Again, this points in the direction of OpenBLAS not doing AVX-512 math
> properly. Let's hope that OPENBLAS_CORETYPE=Haswell solves it.
>
> --
> Best regards,
> Ivan
>
> [*]
> https://github.com/xianyi/OpenBLAS/issues/1955
> https://github.com/xianyi/OpenBLAS/issues/2029
> https://github.com/xianyi/OpenBLAS/issues/2168
> https://github.com/xianyi/OpenBLAS/issues/2182



-- 
Sarah Goslee (she/her)
http://www.numberwright.com