What Phocus Writes to the .phos When You Switch HNCS Presets
Phocus 4.1.x writes the HNCS preset name and slider values to the .phos sidecar on every commit, even though the toolbar dropdown won't show it.
If you've ever been curious which HNCS (Hasselblad Natural Colour Solution) preset produced the file in front of you in Phocus, you've probably hit the same wall I did. Switch your image to Nature, save, click to the next image. Come back later. The Adjustments dropdown reads "Edit..." or "3FR." Nothing about Nature anywhere in the UI.
I had been telling people for months that the preset choice simply was not recorded. I wrote it in a published blog post. I said it confidently in the Essential Phocus 4.x for Mac guide. Much to my chagrin, I today discovered I was wrong.
The HNCS preset name and its underlying slider values ARE written to the .phos sidecar file on every commit. The Phocus UI just does not surface them back to you. I had inferred the file format from the dropdown and never actually did a comparative investigation on .phos files for each of the presets. This post is what is actually in those .phos files, with the empirical data to back it.
Key finding: On every commit, Phocus 4.1.x writes the HNCS preset name into the newImageSettingsentry'sNameandReferenceSettingNamefields in the .phos sidecar, alongside the preset's slider values. The Adjustments dropdown post-commit shows "Edit..." or "3FR" and never surfaces the saved preset name, but the data is in the file and readable withplutil -p.
Does Phocus save which HNCS preset you used?
Yes, when you commit. The preset name lives in the Name and ReferenceSettingName fields of each ImageSettings entry inside the .phos sidecar plist. The Phocus toolbar Adjustments dropdown does not display this back to you, which is why so much community lore (mine included) had it backwards.
The mechanism: when you change the HNCS preset in Phocus, the rendering pipeline updates immediately and the slider values for that preset get loaded into the in-memory adjustment state. Nothing hits disk yet. The commit is what fires the write, and the commit triggers are the same as for any other adjustment: clicking Save Changes, exporting a TIFF or JPEG, or navigating away from the image with the "Always save" preference active (which is the default). The new entry that gets written to the .phos contains the preset name plus all the slider values plus whatever else you have adjusted, all in the same parameter dump.
If you switch the preset and never commit, none of it persists. The preset effect lives only in the rendering engine until something forces the commit.
What does the .phos record after a commit?
Three things land in the file when a commit fires.
The preset name in two fields: Name (e.g. Nature) and ReferenceSettingName (e.g. Nature).
The preset's slider values, in the standard parameter dump: USMAmount, USMRadius, USMNoiseLimit for sharpening; Gradations for the tone curve; plus any other field the preset touches.
Everything else at its current state: exposure, white balance, crop, clarity, dynamic range, perspective tools, your manual edits.
What does NOT land:
- A way to distinguish "Standard chosen explicitly" from "default 3FR baseline." Both write
Name='3FR'with an emptyReferenceSettingName. The .phos cannot tell you which one the user intended. - Anything from before the first commit. The file only records what was active at commit time. If you bounced between three presets before settling, only the final one survives.
- The preset name in any TIFF metadata. Export a TIFF and the .phos still records the preset, but the TIFF itself carries the rendered pixels with no preset tag. Hand a TIFF to someone without the .phos and they can see the look but cannot identify the preset.
The Phocus toolbar Adjustments dropdown does not surface the preset name back to you after a commit. It shows Edit... (with a timestamp) or 3FR. Why Phocus could not surface the saved Name field in that dropdown, they alone will know.
Have you seen the guide? I've published Essential Phocus 4.x for Mac - 83 topics across 8 sections and 220 pages covering everything from HNCS color science to HDR workflows. It's the reference manual Hasselblad hasn't updated since 3.8. Pay-what-you-want starting at $24.
What does each HNCS preset actually change?
Sharpening parameters and the Gradations tone curve. That is the entire delta. No saturation slider, no contrast slider, no separate colour matrix that I can find in the file format. To verify, I exported the same X2D II 3FR file once with each of the five HNCS presets, plus once with the default 3FR baseline. Six .phos sidecar files, each with one committed entry from the export. Reading them with Python's plistlib and diffing the parameter dumps gives the actual values Phocus assigns per preset.
| Preset | Name |
ReferenceSettingName |
USMAmount | USMRadius (UI) | USMNoiseLimit | Gradations |
|---|---|---|---|---|---|---|
| Standard | 3FR |
(empty) | 100 | 1.0 | 0 | linear |
| Nature | Nature |
Nature |
180 | 0.8 | 0 | S-curve: (0,0)→(71,31)→(184,223)→(255,255) |
| Portrait | Portrait |
Portrait |
90 | 0.8 | 3 | linear |
| Product | Product |
Product |
350 | 0.8 | 0 | linear |
| Square Crop | Square Crop |
Square Crop |
100 | 1.0 | 0 | linear (crop in ImageDescription.RelativeCrop) |
| 3FR (default baseline) | 3FR |
(empty) | 100 | 1.0 | 0 | linear |
A few things jump out.
Nature's S-curve is doing more work than its sharpening. The tone curve pulls shadows down (point at X=71 maps to Y=31) and lifts highlights (X=184 maps to Y=223). That is a classic punchy S-curve, and it accounts for most of the visual "Nature looks more vivid" impression even before the higher sharpening kicks in. So when readers ask about HNCS Standard vs Nature, the answer is mostly: tone curve plus sharpening. Not saturation, not contrast slider, not anything in the colour matrix that I can see in the file format.
Portrait is the gentlest sharpener at Amount 90 with USMNoiseLimit at 3. The non-zero noise limit suppresses sharpening on smoother low-detail areas, which is exactly what skin tones want. Whoever tuned this preset knew what they were doing.
Product is aggressive. Amount 350 is 3.5× Standard. Tighter radius too. Makes sense for product photography under controlled light where every micro-edge matters.
Square Crop is identical to Standard for rendering. The only difference is the crop, which lives in ImageDescription.RelativeCrop (Left 0.125, Right 0.875, Top 0.0, Bottom 1.0, a 1:1 crop), not in the parameter dump.
Standard and the default 3FR baseline are byte-identical. Same parameter values, same Name='3FR', same empty ReferenceSettingName. This matches a finding from a separate Phocus 4.1.x bug investigation where importing with Nature selected in the Import dialog still produced output identical to Standard. The Import dialog selection is silently ignored (Hasselblad case #9940198, engineering reproduced, fix committed for a future release). To apply a non-default preset in 4.1.x today, switch to it via the Adjustments dropdown after import, or apply it to a batch via Modify.
One subtle gotcha: USMRadius is stored as 10× the UI value, so a stored 8 corresponds to UI Radius 0.8. Same image data, same field, just a unit convention you would not know without comparing the .phos to what the UI shows you.
What I got wrong, and where the corrections live
The wrong claim was simple and load-bearing: "Phocus has no record of which preset was applied. The sidecar never contains the preset name." I had written it that way in Understanding Hasselblad Phocus on macOS, in several Phocus Guide topics, and in correspondence with at least three readers.
The mechanism inference was the lazy part. I had opened .phos files before. I had checked EXIF on exported TIFFs and seen no preset tag, which was true then and remains true now. What I had not done is the comparative thing: open .phos files from the same image exported under each different preset and diff them. Until I sat down and did that, I could not see what was changing between presets, and I had no way to know what was missing from my picture. The Name and ReferenceSettingName fields were sitting there the whole time. How I missed them on the first pass through the format, I genuinely cannot explain. It is what it is.
The corrections shipped on 2026-05-04. The Understanding Hasselblad Phocus post now has a "Correction note (May 2026)" blockquote at the top of Section 2 plus surgical edits throughout. The Phocus Guide topics on HNCS presets and the .phos sidecar (Topics 7, 8, 10, 11, 12, 13, and 88 in the Essential Phocus 4.x for Mac guide) have all been updated to match what the file format actually does.
Two sibling claims remain correct and unchanged:
- The exported TIFF carries no preset metadata. Only the .phos does. If you hand someone a TIFF without the sidecar, they can see the rendering but cannot identify the preset.
- HNCS itself (the rendering pipeline) cannot be replicated in Lightroom or Capture One. Those processors apply their own colour matrices and do not have access to HNCS. If preset fidelity matters downstream, archive the .3FR + .phos pair, not just the TIFF, and use the Phocus-to-Capture-One hybrid workflow for the editing handoff.
What this means for your workflow
Three concrete consequences, in priority order.
Archive the .phos alongside the .3FR. If you keep only the RAW and not the sidecar, you lose the preset name AND the slider values it set. Reopening the orphaned RAW falls back to the default baseline rendering. The .phos is small (sub-100KB even after multiple commits); there is no storage argument for not keeping it.
Multi-machine rendering is more reliable than I had previously claimed. I had told people that .3FR + .phos moved between Macs would render differently because the preset was not in the sidecar. Wrong. As long as you have committed at least once, the second machine reads the same parameter dump and renders the same way. The drift risk is narrower than I had implied: it bites only on uncommitted images, or on the Standard / default-3FR case where the file cannot tell which the user chose. So the longstanding "Phocus presets not transferring" complaint is mostly resolved by committing once before sync.
The .phos remembers what Phocus's UI does not. If you have forgotten which preset you used on a shoot six months ago, the Phocus interface will not help you, but the sidecar file will. Every time you have committed an edit on that image, Phocus has stamped a new entry into the sidecar with the preset name attached. The whole history is in there. Useful for figuring out which preset you A/B tested on a particular shoot, useful for archival audits, and useful for proving to yourself or a client that you used Standard (not Nature) on a series. There is no Phocus UI that surfaces this for you, but the data is preserved if you ever need to look.
A separate consequence is probably worth its own post: the per-preset slider deltas are now public, which means it is possible to build approximate Capture One Styles or Lightroom Develop Presets that recreate Nature, Portrait, or Product on a Standard-exported TIFF. With three caveats. The numeric values do not port across applications because Phocus's USM and the equivalent in C1 or LR are different sharpening algorithms. The Gradations curve operates on Phocus's intermediate render space, not on Adobe RGB pixel values, so applying the same control points to a TIFF in another editor's tone curve tool will be approximate. And HNCS may apply preset-specific colour matrices that never touch the .phos, which no third-party preset can reach. I will write that up properly once I have actually run the experiment.
References
- Python's
plistlibfor reading binary or XML plists: docs.python.org/3/library/plistlib.html. Apple'splutil -p file.phosworks equivalently from the command line on macOS. - Hasselblad case #9940198: the Import dialog's preset dropdown is silently ignored as of Phocus 4.1.x. Engineering reproduced; fix committed for a future release.
The Tech Behind the Frame Newsletter
Join the newsletter to receive the latest updates in your inbox.