Every color-labeled thumbnail in Phocus, that green, yellow, or red dot, resolves to a single integer sitting in a plain text file next to your RAW. Once you know where that integer lives and what it means, you can read it, verify it, or troubleshoot it without touching Phocus at all.

This page is a reference, not a walkthrough. It documents exactly where Phocus stores color labels and Approval ratings for both 3FR and FFF files, what the values mean, and how to inspect them yourself.

A note on support: This post represents my personal exploration and testing, not official technical support or guidance from Hasselblad. If you need assistance with your Hasselblad equipment, please contact Hasselblad directly: customersupport@hasselblad.com for global support, support.us@hasselblad.com for the Americas, or visit hasselblad.com/support for regional options.

Key finding: Phocus stores a 3FR file's color label as a top-level Approval integer in the .phos sidecar (green=0, yellow=1, red=2), never in the RAW itself. FFF files encode it differently: Hasselblad MakerNote tag 0x0014 (green=1, yellow=2, red=3), a scale shifted by one from the sidecar. The two are not interchangeable.

Where does Phocus store color labels on a 3FR?

For a .3FR RAW file, the color label lives in the .phos sidecar and nowhere else. The .phos file is a plain Apple property list (an XML plist) that sits beside the RAW with a matching filename. It is not proprietary or encrypted. Any plist viewer or a plain text editor can open it.

Inside that plist, Approval is a top-level key, a direct sibling of GUID, Version, CurrentIx, ImageSettings, and ImageParameterCache. It is not buried inside the nested ImageSettings array that holds your exposure and color adjustments. The mapping is:

  • 0 = green
  • 1 = yellow
  • 2 = red

Yellow is the default. Every untagged file carries Approval=1, and the key is present even on files you have never touched, so a script or tool reading this value never has to guess at a missing default. Diffing a red-tagged sidecar against a green-tagged one from the same shoot shows Approval as the only field that differs in a way that matters. Everything else that changes between two sidecars, the GUID, embedded .tif preview names, a couple of index integers, is per-file identity, not the label.

For background on what else lives in a .phos file beyond the label, including how HNCS preset names and adjustment history get recorded, see what Phocus actually writes to the sidecar.

Critically, the RAW file itself is never touched. Setting, changing, or clearing a color label on a .3FR does not modify the RAW's bytes or its modification time. The label lives entirely in the sidecar, which is one more reason the sidecar is not optional if you care about labels surviving a file move.

How to check a color label yourself

You don't need Phocus running to read a label. On a Mac, the fastest route is plutil, which ships with macOS:

plutil -p /path/to/yourfile.3FR.phos | grep Approval

That prints the raw integer. Match it against the 0/1/2 scale above and you know the label without opening the image.

If you'd rather look at the whole file, open the .phos in any plain text editor. It's readable XML, not a binary format, so Approval will appear as a normal <integer> element you can search for directly. A GUI plist editor (Xcode's built-in viewer, or a third-party plist app) will show it as a labeled row in a property list instead.

This matters beyond curiosity. If you're building or using a tool that syncs ratings and labels between Phocus and something else, this integer is the ground truth. Anything reading the label from the file system, rather than asking Phocus, needs to read this exact key on this exact scale.

FFF files use a completely different encoding

FFF is Hasselblad's other RAW-adjacent format, and it does not store the color label the same way 3FR does. There's no sidecar involvement. The label lives inside the file's own Exif metadata, specifically the Hasselblad MakerNote (Exif tag 0x927C), a big-endian TIFF IFD of private, largely undocumented tags.

Inside that MakerNote, the label is tag 0x0014, stored as a LONG integer:

  • 1 = green
  • 2 = yellow (factory default)
  • 3 = red

Compare that to the sidecar scale above and the pattern is obvious: it's the same three-way mapping, shifted up by exactly one. Green is 0 in the sidecar and 1 in the FFF MakerNote. Yellow is 1 and 2. Red is 2 and 3. If you're writing code that reads both formats, do not reuse one lookup table for the other. Reading an FFF's tag 0x0014 as if it were the .phos Approval value would report every single untagged file as red, since a fresh file's MakerNote default (2) collides with the sidecar's red value.

ExifTool, as of the versions I've tested, has no name for tag 0x0014. It's undocumented territory outside this kind of manual decoding, which is one reason to trust the byte-level source over any tool that claims to interpret it.

What's confirmed and what isn't: the FFF encoding above was decoded from a byte-level diff of a file saved by Phocus 3.8.4. Whether current Phocus 4.x builds write labels into an FFF's MakerNote the same way is not established here. If your workflow depends on FFF label persistence in a recent Phocus version, verify it directly rather than assuming continuity from an older build.

For the broader question of why FFF and 3FR behave so differently as formats in general, not just for labels, see why FFF and 3FR aren't interchangeable and why that's actually good.

Why do color labels disappear in Phocus?

For a stretch of recent Phocus releases, the sidecar mechanics above were correct but the read path back into the UI was not. Phocus would write the value you set to the Approval key in the sidecar, exactly as described, but on relaunch the Viewer displayed the default yellow dot instead of your tag. The correct integer sat on disk the entire time. Phocus just wasn't reading it back in.

This was confirmed broken on 3FR files in Phocus 4.1.2 and again in 4.2. It did not affect FFF, JPEG, or HEIC files, which read their labels back correctly throughout. The fix landed in Phocus 4.2.1. I wrote up the discovery and the 231 days between the original report and the quiet fix in a separate post; the original failure report is here.

Scope note: what the very first Phocus 4.x builds did on the write side, before 4.1.2, isn't established from the evidence available here. Treat "confirmed broken" as covering 4.1.2 and 4.2 specifically, not the format's entire history.

What this means for syncing labels between tools

If you're moving color labels between Phocus and another application, whether a culling tool, a DAM, or a custom script, three things follow directly from the mechanics above:

  1. Read the .phos, not the RAW, for 3FR files. The label never touches the .3FR itself. A tool that only inspects the RAW will never see a 3FR color label, no matter how it was set.
  2. Never share a lookup table between formats. The 0/1/2 sidecar scale and the 1/2/3 FFF MakerNote scale encode the same three colors with a one-integer offset. Confusing them silently corrupts every label they touch.
  3. The Approval key is always present, so absence isn't a valid "no label" signal. Every 3FR sidecar carries an Approval value, tagged or not. The presence of the key tells you nothing; only the value does, and 1 (yellow) is indistinguishable from "never touched."

None of this requires Phocus to be running. The .phos file is a plain, readable format, and that's the whole point of documenting it here: the label survives independently of the application that wrote it, as long as you know which integer to look for.

References

  1. Understanding the .phos sidecar file (Tech Behind the Frame)
  2. Why FFF and 3FR aren't interchangeable, and why that's actually good (Tech Behind the Frame)
  3. Phocus Quietly Fixed a Bug I Reported 231 Days Ago (Tech Behind the Frame)
  4. Phocus color labels not saving, original report (Tech Behind the Frame)