Muench Workshops runs small-group photography workshops, and I've traveled with them.
Request the free magazine →How HNNR Works in Phocus: Architecture from Binary Analysis
HNNR (Hasselblad Natural Noise Reduction) is the AI noise reduction built into Phocus 4.x for Mac. Hasselblad describes it as "an AI-powered model that runs locally on your computer." That summary is accurate but leaves a lot of structure undocumented. The Phocus 4.x application bundle ships eight CoreML models, 491 MB of encrypted weights, and an Objective-C wrapper around a Vision Perception Framework. This page documents what is externally observable in the bundle, where the evidence ends, and what stays uncertain.
The page is intended as a reference, not a critique. It exists because Hasselblad has not published a technical architecture document for HNNR, and outside observation can fill some of that gap without needing to defeat the encryption that protects the model weights themselves. If Hasselblad publishes their own architecture description in future, this page would be updated or retracted in favor of the official source.
If you want the short version:
- HNNR runs on the Apple Neural Engine. File-format evidence and power monitoring both confirm it, so this is observed, not inferred.
- The full pipeline is CPU, GPU, and ANE working together, not the Neural Engine on its own.
- Within one Apple Silicon generation, Pro and Max chips are no faster at HNNR than the base chip. Generation is the upgrade that moves the needle (M4 over M3 over M2 over M1).
- The X2D II, X2D 100C, and X1D each get their own model. HNNR needs Apple Silicon.
- The model weights are encrypted. Everything here comes from the observable bundle and power signatures, not from breaking that encryption.
Key finding: HNNR (Hasselblad Natural Noise Reduction) is Phocus's AI noise reduction: 8 camera-specific CoreML models (491 MB total, encrypted for the Apple Neural Engine) wrapped in a Vision Perception Framework that coordinates a hybrid CPU+GPU+ANE pipeline. Base, Pro, and Max share the same Neural Engine, so HNNR speed scales by chip generation, not Pro/Max tier.
What CoreML models does HNNR ship in Phocus?
The HNNR pipeline lives in two bundled resource directories inside /Applications/Phocus.app/Contents/Resources/:
PBNeuralNetworkDeNoise_PBNeuralNetworkDeNoiseModelResources.bundle/
x2d2_high.mlmodelc (94 MB)
x2d2_medium.mlmodelc (57 MB)
x2d2_low.mlmodelc (57 MB)
x2d_high.mlmodelc (57 MB)
x2d_medium.mlmodelc (57 MB)
x2d_low.mlmodelc (57 MB)
X1D_HIGH_R_ver4.mlmodelc (57 MB)
X1D_LOW_R_ver4.mlmodelc (57 MB)
solution.json.eng.enc
vpf_cfg.json.eng.enc
vpf_storage.json
PBNeuralNetworkDeNoise_PBNeuralNetworkDeNoiseOC.bundle/
Info.plist
Resources/{solution.json.eng.enc, vpf_cfg.json.eng.enc, vpf_storage.json}
Total HNNR footprint: 491 MB of compiled models plus a small wrapper bundle.
Have you seen the guide? I've published Essential Phocus 4.x for Mac - 85 topics across 8 sections and 238 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.
Which Hasselblad cameras does HNNR support?
The naming makes the camera coverage explicit: each supported sensor gets its own model, and the X2D II and X2D 100C each get three strength tiers (high/medium/low). The X1D gets two tiers (high/low) and an explicit "ver4" suffix, suggesting model versioning.
The x2d2_high.mlmodelc model is notably larger than the others (94 MB vs 57 MB). That's an interesting clue: the X2D II's high-strength denoise variant likely uses a deeper or wider architecture than the rest, but the model contents are encrypted and I can't open them to confirm.
Each .mlmodelc package contains:
model.mil.eng.enc- encrypted Model Intermediate Language bytecode for the Neural Enginecoremldata.bin.eng.enc- encrypted model metadatametadata.json.eng.enc- encrypted model metadata JSONweights/- encrypted weight tensors
The .eng.enc extension is the key tell. Apple's CoreML format ships ANE-targeted models in this encrypted form, and the runtime decrypts them on first use into a device-specific compiled form. You can't open them without Apple's loader, but the extension itself is sufficient evidence that these models target the Neural Engine specifically.
Alongside the model bundle is the OC ("Objective-C") wrapper bundle, which contains an unencrypted vpf_storage.json. That file describes a Vision Perception Framework pipeline with YUV image streams, bounding-box detectors, and multi-scale fusion outputs. This is a production-level computer vision pipeline, not a single denoise pass.
How do we know HNNR uses the Neural Engine?
HNNR runs on the Apple Neural Engine, and two independent lines of evidence confirm it.
File format evidence: the .eng.enc extension on every model file is Apple's standard format for ANE-targeted CoreML models. Models built for CPU or GPU inference don't ship in this form. The models themselves can't be opened, but their packaging declares the target hardware.
Runtime power signature: With macOS power monitoring active, the Neural Engine sits at near-zero idle draw and jumps to 1.0-1.6 watts the moment HNNR processing begins. No other Phocus operation produces this signature.
Both lines of evidence are from outside the application. Neither requires Hasselblad's confirmation, and both are independently verifiable. So "HNNR uses the Apple Neural Engine" is fairly called confirmed, not inferred.
Is HNNR purely a Neural Engine workload?
No. HNNR uses the GPU and CPU as well as the Neural Engine, running all three together in a hybrid pipeline.
Earlier coverage on this site (the Understanding Phocus on macOS post) framed HNNR as ANE-only, which is incomplete. Two pieces of evidence point to a hybrid pipeline:
The vpf_storage.json file describes the Vision Perception Framework configuration with multiple processing stages: input formatting (YUV streams), bounding-box detection, multi-scale fusion, and output composition. A pure ANE inference workload would not need that kind of orchestration layer. The presence of bounding-box detection alongside denoising suggests at least some content-aware processing happens before the denoise model runs.
Power monitoring during HNNR shows simultaneous activity on CPU, GPU, and ANE. The ANE spike is the most distinctive (because the ANE sits dead at idle), but CPU and GPU also climb during processing. ANE handles the inference; CPU and GPU presumably handle the I/O, the pre-processing, the post-processing, and the orchestration that hands tiles or stages between processors.
The exact split between processors is not visible from outside the binary. What I can say with confidence is "more than ANE alone," and what I can no longer say is "uses the Neural Engine" as if that were the whole story.
Why does Pro/Max not make HNNR faster?
Within an Apple Silicon generation, the base, Pro, and Max chip variants share the exact same Neural Engine. M1, M1 Pro, and M1 Max all have a 16-core ANE rated at 11 TOPS. M2/M2 Pro/M2 Max all share a 16-core 15.8 TOPS ANE. The same pattern holds for M3 and M4.
What Pro and Max chips do gain is more GPU cores, more memory bandwidth, and more performance cores on the CPU. For workloads that scale with GPU compute or memory bandwidth (Phocus's standard render pipeline, large-batch tethered preview generation, multi-image culling), Pro and Max are meaningfully faster than the base chip in the same generation.
For HNNR specifically, the inference is ANE-bound. The CPU and GPU stages of the hybrid pipeline are short relative to the ANE inference, so the ANE bottleneck dominates. Result: HNNR throughput scales by chip generation (M1 → M2 → M3 → M4) but not by tier within a generation (M2 ≈ M2 Pro ≈ M2 Max).
The Hasselblad documentation's own performance recommendations don't make this distinction, and earlier versions of my Understanding Phocus on macOS post implied that M1 Pro/Max would be "significantly faster" than M1 for HNNR. That's wrong. If HNNR throughput is the limiting factor in your workflow, the upgrade path is generation, not tier. M4 is roughly 3.5x M1 for ANE-bound workloads. M1 Pro is essentially M1 for HNNR.
What stays uncertain
Even with the bundle fully mapped, several questions don't resolve from outside the binary.
Exact data domain. The vpf_storage.json references YUV image streams, but YUV could appear at any of several stages: as input from a camera-side processor, as an intermediate format inside the pipeline, or as output to the renderer. The original Bayer RAW data has to be demosaiced somewhere, but whether HNNR sees the Bayer data, the demosaiced RGB, or a YUV intermediate is not visible without intercepting the runtime. Saying "operates on demosaiced RAW data" overstates what the evidence supports.
Per-stage processor allocation. I can see that CPU, GPU, and ANE all activate during HNNR. I cannot see which stages run on which processor without instrumented profiling. The pre-processing is probably CPU. The inference is almost certainly ANE. The post-processing and tile composition could be either CPU or GPU. The OC wrapper bundle's exact runtime behavior would need symbolication or runtime tracing to confirm.
Model architecture. The presence of "multi-scale fusion" in the VPF config plus an unusually large x2d2_high model suggests a U-Net-style architecture or similar, but the actual layers, depths, and convolutional structure are inside the encrypted .mlmodelc bundles. Apple's loader can decrypt them at runtime; an outside observer cannot.
What "Prioritise Purity" vs "Prioritise Detail" actually do internally. Hasselblad documents the user-facing distinction (one retains more luminance noise to preserve fine texture). What I don't know is whether the two modes use different models, different model strengths, different post-processing parameters, or some combination. There are three strength tiers per camera in the bundle (high/medium/low), but only two user-facing modes. The mapping is not exposed.
How to inspect the HNNR bundle yourself
Everything on this page is from observation of the publicly distributed Phocus 4.x application bundle, with no decryption of protected content. Three observation methods:
- Bundle file structure. Right-click
/Applications/Phocus.app→ Show Package Contents. OpenContents/Resources/. ThePBNeuralNetworkDeNoise_*directories are visible to any user. File sizes, names, and the.mlmodelcpackaging are obvious from there. - The unencrypted VPF configuration.
vpf_storage.jsonships as plain text alongside the encrypted models. It describes the Vision Perception Framework pipeline stages and is openable in any text editor. - Power monitoring.
powermetrics(built into macOS, requires sudo) reports per-subsystem power including CPU, GPU, and Neural Engine.
What was not done. No attempt to decrypt the .mlmodelc weights or the .eng.enc config files. Those are protected by Apple's CoreML encryption, which targets a specific device's Neural Engine. Defeating that encryption would cross a security boundary deliberately put in place to protect Hasselblad's models, and the externally observable behavior is sufficient to characterize HNNR accurately for users.
If Hasselblad would like to publish their own architecture description, internal documentation, or correction to anything on this page, contact details are in the support footer below; the page would be updated to credit and link to the official source.
What this page corrects from the earlier Phocus post
The Understanding Phocus on macOS post predates this analysis and contained four claims about HNNR that this page corrects:
- "HNNR appears to use the Apple Neural Engine" is true but understates the architecture. ANE plus CPU plus GPU in a coordinated pipeline is the corrected framing.
- "machine-learning-based noise reduction on the demosaiced RAW data" was speculation. The actual data domain is not externally visible.
- HNNR shows a mode-selection prompt (Prioritise Purity / Prioritise Detail) before processing. The earlier post said it "simply runs" with no dialogue. Corrected.
- M1 Pro/Max is not "significantly faster" than M1 for HNNR. Within a generation, ANE TOPS is identical. Corrected to a generation-only speed gradient.
Those corrections are now reflected in that earlier post.
What we know about HNNR, and what we don't
What HNNR is: 8 camera-specific CoreML models, 491 MB of weights, encrypted for the Apple Neural Engine, wrapped in a Vision Perception Framework pipeline that coordinates ANE inference with CPU and GPU pre/post-processing.
What HNNR is not: a pure Neural Engine workload, a function of how much GPU your Mac has, or a process that's faster on Pro/Max chips within the same generation.
What stays unknown: exact data domain, per-stage processor allocation, model architecture, the internal mapping between user modes and model variants. These would require runtime instrumentation or Hasselblad's own engineering disclosure to resolve.
If you're considering an Apple Silicon upgrade primarily for HNNR speed, the chip generation is the lever to pull (M4 over M3 over M2 over M1). The tier within a generation matters for everything else Phocus does, just not for HNNR throughput specifically.
References
¹ Hasselblad's Phocus 4.0 README described HNNR as "an AI-powered model that runs locally on your computer." (The original README has since been removed from hasselblad.com.)
² Apple chip Neural Engine specifications: M1 (16-core, 11 TOPS, Nov 2020), M2 (16-core, 15.8 TOPS, Jun 2022), M3 (16-core, 18 TOPS, Oct 2023), M4 (16-core, 38 TOPS, May 2024). Within each generation, base/Pro/Max share the same Neural Engine.
³ The full Phocus 4.x bundle analysis lives in my research notes and is summarised in Phocus 4.1.2 Has a Critical Color Preview Regression, which uses the same bundle-diff methodology to identify the 4.1.1→4.1.2 color regression.
