Hasselblad has never published the primaries of its own working space. Phocus renders into Hasselblad RGB, the guide I wrote says its gamut is "comparable to Adobe RGB," and that phrasing was a hedge, because nobody outside Gothenburg had the numbers.
The numbers were sitting on the disk the whole time. Phocus installs Hasselblad RGB.icc into your ColorSync folder, and an ICC profile is not a black box: the colorant and white point tags are plain binary at known offsets. I decoded both Hasselblad working spaces from the files that ship inside Phocus 4.2.1 and compared them against ten standard spaces.
Key finding: Adobe RGB (1998) fits entirely inside Hasselblad RGB, making it a strict superset rather than a same-tier equivalent. Hasselblad L* RGB and ProPhoto RGB cross rather than nest. And the two Hasselblad spaces do not nest either: Hasselblad RGB's blue primary falls outside L* RGB.
What is actually in the profile
Both files are plain matrix and tone-curve profiles. Three colorant tags, a white point, three tone curves. Here is what they contain, adapted to D50, which is how ICC stores them:
| Space | Red x, y | Green x, y | Blue x, y | White | Tone curve |
|---|---|---|---|---|---|
| Hasselblad RGB | 0.6814, 0.3137 | 0.2121, 0.7395 | 0.1335, 0.0461 | D50 | gamma 2.19921875 |
| Hasselblad L* RGB | 0.7563, 0.2437 | 0.0982, 0.9018 | 0.0183, 0.0221 | D50 | 700-point sampled curve |
Two details worth pausing on. Hasselblad RGB carries a gamma of exactly 2.19921875, which is the same constant Adobe RGB uses, so the tone response is borrowed even though the primaries are not. And L* RGB genuinely earns its name: instead of a single gamma value it stores a 700-point sampled curve per channel, which is the L* response the name advertises.
Neither space matches any standard. I checked both against sRGB, Adobe RGB (1998), Display P3, DCI-P3, Rec.2020, ProPhoto RGB, Adobe Wide Gamut RGB, ACEScg, Ekta Space PS5, Don RGB 4, Beta RGB and Best RGB. No match. These are Hasselblad's own spaces, which is exactly why being unable to select them by name in an export dialog costs you something.
How much wider than Adobe RGB?
Wider on all three primaries, and the containment is strict.
Adobe RGB's red sits at 0.6484, 0.3309. Hasselblad's is at 0.6814, 0.3137, further toward the spectral locus. The green moves from 0.2302, 0.7016 out to 0.2121, 0.7395. The blue moves from 0.1559, 0.0661 down to 0.1335, 0.0461. Testing each Adobe RGB primary against the Hasselblad triangle puts all three inside it.
So "comparable to Adobe RGB" undersells it. Hasselblad RGB contains Adobe RGB with room to spare. My own guide says "comparable" and leaves the containment question open as undocumented; that entry needs updating, and this is the evidence.
Does Display P3 fit inside it?
This is the one that resists a tidy summary. Display P3 is not inside Hasselblad RGB, and Hasselblad RGB is not inside Display P3.
P3's red (0.6820, 0.3193) sits marginally outside the Hasselblad triangle, and so does its green (0.2846, 0.6746). Hasselblad RGB reaches much further in green, P3 reaches very slightly further in red, and the two triangles cross. If you are exporting to P3 for the web you are not making a clean subset conversion in either direction. You are clipping a little in one corner and leaving headroom in another.
L* RGB is not simply "ProPhoto-class"
The common description of Hasselblad L* RGB, mine included, is that its gamut is comparable to ProPhoto RGB. That is close, and it is not quite the relationship.
L* RGB is wider than ProPhoto in red (0.7563 against 0.7347) and considerably wider in green (0.9018 against 0.8404). All three L* RGB primaries sit outside the spectral locus, by 0.031, 0.071 and 0.111 in xy, which makes every one of them imaginary. ProPhoto's green and blue are imaginary too; its red sits on the locus. But ProPhoto's blue reaches further along one axis than L* RGB's does, so neither triangle contains the other. They cross.
The two Hasselblad spaces do not nest
Hasselblad RGB is not a subset of Hasselblad L* RGB, which I had assumed it would be.
Its red and green primaries do sit inside L* RGB, as you would assume from a "wide" and a "wider" space. Its blue does not. Hasselblad RGB's blue at 0.1335, 0.0461 falls below the line joining L* RGB's blue and red primaries, which puts it outside that triangle. Switching a file from Hasselblad RGB to L* RGB in the Reproduction tool is therefore not a pure widening. There is a sliver of deep blue that the narrower space can describe and the wider one cannot.
Try it yourself
Every number above was read from the profiles on my disk, and the diagram below plots them. Pick up to three spaces and overlay them. The two Hasselblad entries are measured from Phocus 4.2.1; everything else uses its published primaries, credited on each card.
Use the projection toggle. CIE 1931 xy is the diagram everyone recognises, and it badly exaggerates the green corner, so comparing triangle areas by eye there will mislead you. CIE 1976 u'v' is closer to perceptually uniform. Same data, fairer picture.
Familiar, but not perceptually uniform: equal distances do not mean equal perceived difference, which stretches the green corner.
Three is the cap: past that the outlines stop being reliably distinguishable, including for colour-blind readers.
| Space | Red x, y | Green x, y | Blue x, y | White | Tone curve | |
|---|---|---|---|---|---|---|
Everything is plotted D50-adapted. An ICC v2 matrix profile stores its colorants already adapted to the D50 profile connection space, and that is the only frame in which the Hasselblad numbers are ground truth: the profiles record a D50 white point and nothing about the native white the space was designed around. So every space here is Bradford-adapted to D50 and read off the same way. Published figures for D65 spaces such as sRGB and Rec.2020 will differ from the table above for exactly that reason, and each card lists its native primaries alongside.
Area on this diagram is not gamut volume. A triangle that looks twice as big is not twice the gamut. Chromaticity ignores lightness entirely, and CIE 1931 xy stretches the green corner badly, which is why the u′v′ projection is here. Neither one substitutes for a volume computation in a uniform space.
Sources. Spectral locus: CIE 1931 2° colour matching functions at 5 nm steps, from
the Colour & Vision Research Laboratory tables. Hasselblad primaries: decoded from the
rXYZ, gXYZ, bXYZ and wtpt tags of
Hasselblad RGB.icc and HasselbladLStarRGB.icc as shipped inside Phocus
4.2.1. Every other space uses its published primaries, credited on its card.
What the extra width actually costs
Everything above describes the containers. Whether the extra room matters depends on whether photographs occupy it, which is a separate question and a measurable one.
The test frame is an X2D II file at base ISO 50, XCD 55V at f/2.5, roughly two thirds clear blue sky and one third sunlit green canopy. I exported it twice from the same render, once to Hasselblad RGB and once to Adobe RGB, then compared the two files pixel by pixel at full resolution, all 101,896,752 of them.
| Measured on the test frame | Value |
|---|---|
| Pixels outside Adobe RGB (boundary test) | 4.79% |
| Pixels shifted more than dE2000 1 by the conversion, sunlit canopy | 1.55% |
| Pixels shifted more than dE2000 1 by the conversion, everything else | 0.0067% |
| Pixels shifted more than dE2000 3, anywhere in the frame | 0.0000% |
| Largest shift anywhere in the frame | dE2000 2.42 |
The first and last rows only look like they disagree. “Outside the gamut” is a boundary test. It tells you a colour sits outside the triangle and nothing whatsoever about how far outside. dE2000 measures how much the conversion actually moved that colour. Nearly all of the 4.79% sits barely past the boundary and moves almost not at all.
I split the frame into regions using local texture in the luminance channel only, with no colour information entering the decision, so that asking which regions clip could not quietly answer itself. On this frame the sunlit canopy has 1.55% of pixels above dE2000 1 after conversion, and everything else in the frame has 0.0067%. Sky sits deep inside Adobe RGB. Deep blue atmosphere is nowhere near a gamut boundary, however saturated it looks.
The absolute magnitude is small. Nothing anywhere in the frame reaches dE2000 3, and the largest difference is 2.42. In textured foliage, where spatial detail masks colour differences, that is at or below what most people would see on a calibrated display.
Four unrelated ordinary photographs came out lower still: gamut excursions outside Adobe RGB reached at most 0.338% of pixels at a strict tolerance and 0.000% at a looser one.
What happens to the colours that are outside depends on how Phocus converts, and it clips in destination coordinates rather than compressing the whole gamut. I simulated a hard clip and compared it against Phocus's own Adobe RGB export of the same render, and the two agree to within 0.02 percentage points at every threshold I tested. With matrix and tone-curve profiles like these there is no gamut-mapping table for a colour engine to consult, so a clip is what you get.
This is one frame, deliberately chosen because it contains the two subjects most likely to stress a gamut boundary. It is not a survey.
What this does not tell you
Area is not gamut volume. These are two-dimensional slices that throw away lightness entirely, so a triangle that looks twice as large is not twice the gamut. A real volume comparison has to happen in a uniform space and account for the tone curve, which the diagram ignores.
The frame is D50 for everything. An ICC v2 matrix profile stores colorants already adapted to the D50 connection space, and the Hasselblad profiles record a D50 white point and nothing about the native white the space was designed around. That is the only frame in which these numbers are ground truth, so every space here is Bradford-adapted to D50 and read the same way. Published figures for D65 spaces will differ from my table for that reason alone.
None of this forces a change to your export settings. The colorimetry inside these profiles was always correct, and "Source" has always produced the right file. What changed is that the working space now has published numbers instead of a marketing adjective, and a measured figure for what the alternatives cost.
References
- Why Hasselblad RGB Is Missing From the Phocus and Lightroom Export Menus - the device-class defect that keeps these profiles out of the export pickers
- hasselblad-icc-profile-fix - the correction tool, and the ICC header parsing this post builds on
- Colour & Vision Research Laboratory - CIE 1931 2-degree colour matching functions, the source for the spectral locus
- Phocus, Capture One, or Lightroom? I Measured Instead of Guessing - what these rendering differences look like on an actual file