I was running Chrome 57.0.2939.0 canary in this case, but I believe I've seen this behavior consistently since I first created and started using this profile earlier this year, so I agree that it's probably not the root cause for what I'm seeing.  Thanks!

I think I've identified the cause of the differences.  The ICC profile that you've attached has all kinds of information.

Red XYZ
Green XYZ
Blue XYZ
Red TRC
Green TRC
Blue TRC
This is the "standard" representation we see in most ICC profiles.  A gamut transformation and a transfer function.  One interesting observation is that the Red, Green, and Blue TRC curves don't match (which is very rare).

A2B0
A2B1
Multi-part tags that describe a transformation from the src encoding to a connection space (may include multiple TRC curves, multi-dimensional LUT, matrix).

B2A0
B2A1
Multi-part tags that describe a transformation from the connection space to the dst encoding (may include multiple TRC curves, multi-dimensional LUT, matrix).

The ICC spec tells us that when the A2B/B2A tags are present, we should use those in place of the XYZ-TRC representation.

This is really annoying - handling XYZ-TRC is fast and interpolating multi-dimensional look-up tables is slow.  Also, it's not clear to me what is the advantage of encoding information this way.  Luckily, it's pretty rare.  Skia has recently been adding support for A2B sources (which will be used when XYZ-TRC is not present)... the goal is to transform all sources into something that Skia knows how to draw.

On dsts, we are much more strict.  We really just want these to be XYZ-TRC, where the TRC is sRGB or linear, because that is what we can draw fast.  In the case where the dst profile has non-standard TRC, we want to render in linear and allow a final adjustment step for the TRC.

For legacy Chrome, we do provide the capability to transform to any XYZ-TRC dst at decode time - which is the behavior you are seeing.

It looks like Photoshop is using the B2A tag to transform to dst.  I did an experiment where I stripped the A2B and B2A tags from the profile and then converted with Photoshop (forcing them to use XYZ-TRC).  And now Photoshop looks like Chrome.  The images are attached.  I've assigned them both an sRGB profile (without conversion) to try to prevent whatever viewer we are using from re-converting the images (for that reason, these images are probably more interesting in comparison than in an absolute sense).

Why are these different?
I'm not 100% sure.  It's possible that the B2A tags and the XYZ-TRC tags just happen to provide slightly different information.  It's also possible that this particular B2A tag allows for superior quality of conversion or a encodes a conversion that cannot be represented completely in XYZ-TRC.

Regardless, support for B2A dsts is not on my list of short term things to do :|.

Still I'd be interested to hear more about how you created this profile.  It's definitely one of the more unique ICCs that I've seen.

Images are too large to attach so here they are on Drive:
https://drive.google.com/drive/folders/0B2R1JwFi2yZ9bnhLU1Itd0Vid0U?usp=sharing

Thanks for the detailed investigation!

I bought an i1Display Pro to calibrate my display.  It includes terrible software that produced a horrible profile (that limited output to 0-192, among other issues).  Even prior to purchase, the suggested route was DisplayCal, which was a graphical shell around ArgyllCMS.  That's what I used with essentially no tweaks to build the profile.

The following revision refers to this bug:
  https://skia.googlesource.com/skia.git/+/595599f46261225dfc67ab4d91d326e099558239

commit 595599f46261225dfc67ab4d91d326e099558239
Author: Matt Sarett <msarett@google.com>
Date: Thu Dec 15 18:05:53 2016

Rearrange ICC profile parsing

None of the small details have changed, just some high level
reorganization:
(1) Check for XYZ spaces before A2B.
(2) If we fail to parse the XYZ space, fallback by trying to
    parse the A2B space.

This should cause no image diffs on Gold.

There is an image from the ICC website that is *supposed* to
test that we parse the A2B tag before the XYZ tag.  Our
behavior on this image will actually not change - the XYZ
tag is invalid (non-D50 matrix), so we fall back to A2B
anyway.  I think this behavior is ok.

BUG:674584

Change-Id: I271fd990937268e03e98f5037a0837a574e775ef
Reviewed-on: https://skia-review.googlesource.com/6143
Reviewed-by: Robert Aftias <raftias@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>

[modify] https://crrev.com/595599f46261225dfc67ab4d91d326e099558239/src/core/SkColorSpace_A2B.h
[modify] https://crrev.com/595599f46261225dfc67ab4d91d326e099558239/src/core/SkColorSpace_Base.h
[modify] https://crrev.com/595599f46261225dfc67ab4d91d326e099558239/src/core/SkColorSpace_ICC.cpp
[modify] https://crrev.com/595599f46261225dfc67ab4d91d326e099558239/src/core/SkColorSpace_XYZ.h

> This is really annoying - handling XYZ-TRC is fast and interpolating multi-dimensional look-up tables is slow.

It is possible to speed it up utilizing the graphics hardware with shaders using 3D texture lookups though.

> Also, it's not clear to me what is the advantage of encoding information this way.

The difference is that in most cases cLUT-based profiles are (considerably!) more accurate than simple shaper + matrix based ones. In fact, most LCD-based displays available today, especially affordable ones, cannot be accurately profiled by simple matrices due to nonlinearity and limited additivity of those displays.

> It's also possible that this particular B2A tag allows for superior quality of conversion

Correct. Note that you're only interested in the B2A (PCS-to-device) part of cLUT-based display profiles, but in the A2B (device-to-PCS) part should a cLUT-based profile be embedded in an image.

Did this get fixed? I still see problems with my ICC profile viewing dark images. See last remarks in https://bugs.chromium.org/p/chromium/issues/detail?id=880648

Assigned, but no owner or component? Please find a component and/or owner