In December 2025, I filed a bug report with Hasselblad: color labels set on a .3FR RAW file in Phocus didn't survive a restart. Tag a file green, quit the app, relaunch, and the tag was back to the default yellow dot.
Hasselblad called it a known issue and said they'd "internally reassess." Then silence, for 105 days. On April 7 I wrote it off as a de facto won't-fix and stopped chasing it.
This morning I found out it's fixed!
Key finding: Color labels on 3FR RAW files now persist across a Phocus restart, confirmed on Phocus 4.2.1. This was one of the first bugs I ever reported to Hasselblad, acknowledged as a known issue in December 2025, then left to die in silence. No release note, no reply on the ticket. Just a quiet fix.
What was actually broken?
In Phocus, the color label and the Approval rating are the same thing: the green, yellow or red dot on the thumbnail. Star ratings are separate, and they never had this problem. I wrote the original failure up here at the time.
The shape of the failure shifted over the intervening releases, which is part of why it was hard to pin down. By the time I was testing recent 4.x builds, Phocus was writing the correct value into the .phos sidecar. Quit and relaunch, and the label in the Viewer still reverted to the default yellow dot, even though the sidecar on disk held the value you set. So the value was being saved and then ignored on the way back in. FFF files and JPG/HEIC files persisted their labels correctly throughout. This was specific to 3FR RAW files.
That distinction is easy to confirm from the outside, because the sidecar is a plain XML property list sitting next to the RAW. The label is a single top-level Approval integer: 0 for green, 1 for yellow, 2 for red. Yellow is the default every untagged file carries. Tag a file red, and that integer becomes 2 immediately, whether or not the app can read it back afterwards. For 3FR files, the label lives only in the sidecar. The RAW itself is never rewritten to record a color tag. See how Phocus stores color labels and approval ratings for the full breakdown of where that integer lives.
How did I find out?
Not from Hasselblad. It surfaced sideways, through a feature request from someone using Palomino, the Mac culling app I work on with a colleague. The request made no sense if color tags didn't persist, so I went back and retested a bug I'd filed away as dead. I set a color label on a 3FR file in Phocus 4.2.1, quit, relaunched. The label held.
The fix landed in 4.2.1. A reader who ran a detailed test matrix in July still had this failing on 4.2, and I went back and compared the two releases directly to confirm it: 4.2 still carries the broken behaviour, and 4.2.1 does not. So the fix shipped in a point release, and it shipped silently.
Have you seen the guide? I've published Essential Phocus 4.x for Mac - 85 topics across 8 sections and 246 pages covering everything from HNCS color science to HDR workflows. It's the reference manual Hasselblad hasn't updated since 3.8. It's $49, and updates are included.
The actual cost of a silent fix
The fix itself is genuinely welcome, and it's not the only real one lately. Hasselblad's engineering has shipped several fixes to Phocus in the past few months, including some I reported myself. That part works.
What doesn't work is the part where nobody hears about it. No reply landed on the support ticket. Nothing appeared in the release notes. There's no changelog entry, no forum post, no mention anywhere that this particular bug is gone. I only know because I happened to retest it.
Every photographer who hit this bug and built a habit around it, tagging in Lightroom instead, giving up on color labels entirely, exporting before quitting Phocus to lock a rating in some other way, is still carrying that workaround today. The bug they adapted to no longer exists, and there is no way for them to know that unless they stumble into it the way I did.
The engineering here is fine. The fix works. What broke down is the telling, and that has a real cost: every silent fix leaves behind users still solving a problem that was already solved.
What would actually close the loop
Hasselblad doesn't need a public bug tracker to fix this. I built one myself, 23 reported bugs and their statuses, if anyone's curious what that looks like. A release note that says what changed, or two lines back to whoever raised the issue in the first place, would do it. Right now the only way to know a bug is dead is to go back and check it yourself, and most people don't have a reason to.
If you filed something with Hasselblad months ago and quietly gave up on it, it's worth ten minutes to go back and check. Mine had been sitting fixed inside a point release I'd already installed. Yours might be too, waiting for someone to try it again.