Tonal Photo

Tonal Photo Trying to make a business of my photos

A reader mail landed last week with the kind of question I like best: what am I doing wrong, or is this a bug? This time...
09/05/2026

A reader mail landed last week with the kind of question I like best: what am I doing wrong, or is this a bug? This time it was the Grayscale panel. Tick the checkbox and the photo goes black and white, as expected. Then drag any of the RGB sliders and the whole frame brightens or darkens together, like an exposure control that wandered into the wrong panel. Push one slider to -100 and the frame goes black. Not "the reds go dark". Black.

My first reaction was to agree. I opened an ordinary landscape frame in Phocus 4.2.2, dragged Red down, and watched the entire image dim. A brightness slider in a channel-mixer costume, case closed.

Except I have learned, the slow way, not to trust my eyes on a preview. So I put a ColorChecker in front of the camera and started reading actual patch values. That is where things got a little more interesting.

💡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: [email protected] for global support, [email protected] for the Americas, or visit hasselblad.com/support for regional options.

Key finding: Phocus 4.2.2's Grayscale panel is a per-channel luminance mixer with absolute RGB weights, not a global brightness control. On a ColorChecker frame, raising Red from 21 to 60 lifted the red patch roughly 65 percent more than the blue patch. It looks global because nearly every real pixel carries all three channels.

Why does a selective tool look global on an ordinary photo?

Because almost nothing you photograph is a pure, saturated color. Skin tones, foliage, sky, weathered wood: all of them carry meaningful amounts of all three channels at once. When you raise the weight the mixer assigns to one channel, every pixel that contains that channel shifts by some fraction, and in a typical frame that's nearly every pixel. The shift isn't uniform across the image, but on a scene with no strongly separated colors the differences between pixels are too small to notice next to the shift they all share.

Selectivity in this panel is proportional, not binary. It only becomes visually obvious when a patch is heavily saturated in one channel and starved in the others, which is exactly the condition a ColorChecker is built to provide and an ordinary photograph usually isn't.

What I actually measured

I shot a ColorChecker frame on the X2D II, enabled Grayscale in Phocus, and sampled patch values off the rendered preview before and after moving individual sliders. A caveat has to sit right next to these numbers: the preview is display sRGB, not a colorimeter reading off a calibrated target, so the magnitudes below are approximate. The direction and the ratio between patches is the finding. Treat the exact digits as illustrative, not as a spec.

Slider moved
Patch sampled
Change

Red: 21 → 60
Red patch
+61

Red: 21 → 60
Blue patch
+37

Blue: 7 → 60
Blue patch
+66

Blue: 7 → 60
Red patch
+34

Red: 21 → 60
White patch
clipped at 255, unmeasurable

Blue: 7 → 60
White patch
clipped at 255, unmeasurable

Raising Red moved the red patch about 1.6 times as much as the blue patch. Raising Blue reversed that relationship almost exactly: the blue patch moved about twice as much as the red patch. That's the signature of a per-channel weighting function, not a single global gain applied to every pixel equally. The white patch is in the table for completeness and nothing else. It contains all three channels near their maximum already, so it clipped to 255 in both tests and can't tell you anything about the mixer's ratios.

Researching and writing the blog and page posts I produce takes up a lot of my time and costs me money for software subscriptions, tooling, and other incidentals related to running a business.

Please consider a paid membership to help me keep the lights on and pay the bills - it is only a fraction of the cost of an X2D II and a lens. Click on the button to go to the membership page to see the options available.

Support the blog.

The defaults are close to Rec. 709 luma weights

Phocus opens Grayscale with R=21, G=72, B=7. Scale the Rec. 709 luminance coefficients, 0.2126 red, 0.7152 green, 0.0722 blue, up to a base of 100 and you get 21.26, 71.52, 7.22. That's a close match to what the sliders show at default, close enough that it's clearly not a coincidence.

I want to be precise about what that does and doesn't tell you. The defaults closely match the Rec. 709 weights. I haven't traced Phocus's internal color pipeline, so I can't say whether the mixer operates in the same linear-light space those coefficients assume, or at what stage in the render it applies relative to HNCS. Read it as strong circumstantial evidence that the default conversion follows the standard broadcast luma formula, not as a verified statement about the internal math.

Why does a single slider at -100 black out the frame?

This part follows straightforwardly once you treat the sliders as weights in a sum rather than as independent brightness controls. Set all three to 0 and the weighted output for every pixel is 0, a black frame, which is consistent with an additive model where the sliders scale each channel's contribution before they're added together.

Leave the other two sliders at their defaults and push one hard negative, and the weighted sum for most pixels swings below zero, because the channel you just inverted was contributing a meaningfully positive amount before. A value below zero has nowhere to go but clip to black. Lightroom's Black & White Mix does not behave this way, and that is the reader's fairest point. Its eight sliders target hue ranges and sit on a normalized base, so dragging Blue to -100 on a frame with no blue in it does almost nothing, and no single slider can black the frame out. The reader followed up with a side-by-side of the same frame in both apps, and it shows exactly that. Phocus's three sliders are absolute weights on the RGB channels, and the math doesn't care that you only meant to suppress reds: it computes the sum you asked for.

Have you seen the guide? I've published Essential Phocus 4.x for Mac - 85 topics across 8 sections and 250 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.

Get it here

The filter presets are the faster path for most edits

The Grayscale panel's header menu carries Red, Green, and Blue filter presets alongside Default, each emulating the contrast effect of shooting black and white film through a colored glass filter over the lens: a red filter darkens blue skies and lightens skin, a blue filter does the opposite. For most conversions these presets get you closer to a finished look in one click than dialing three sliders by hand, and they're worth reaching for first. The manual sliders earn their place when a preset gets close but not quite right, or when you're working a frame the presets weren't built around.

Why do the three histograms look identical with Grayscale on?

One box to check first, because it changes what the panel shows: Output values, in the Histogram panel header. With it unticked, which is how my install came up, the histogram plots the input data and ignores the Grayscale sliders completely. I dragged Red to -100, watched the frame go black, and the histogram did not move. Tick it and the panel plots the rendered output, which is where the rest of this section applies.

Because after conversion, every pixel has R equal to G equal to B. Grayscale collapses the three channels into one value per pixel and writes that same value into all three, so the three per-channel histogram views are reading identical copies of the same data. Move the Red slider while you're looking at the blue channel's histogram and it responds exactly as if you'd moved the blue slider, because by the time the histogram renders, there's no difference between the channels left to show.

That's not a bug. It's arithmetic doing exactly what identical channels look like. The reader's report of symmetric per-channel histograms was accurate, and it's the direct evidence for what conversion does, not a sign that something is broken.

The underlying critique still stands as a fair one. Phocus's histogram already diverges from familiar conventions elsewhere in the app, and showing three identical channel views once Grayscale is on adds a layer of confusion that a single gray histogram, the way Lightroom's black and white panel handles it, would avoid without losing any information. Three redundant histograms tell you nothing that one wouldn't.

How to actually see the mixer working

Don't test this on a landscape with muted, overlapping colors. Pull up a frame with strongly separated hues instead, a red barn against green foliage, or a blue sky over orange sandstone, and the selectivity becomes obvious within a couple of clicks: one slider moves one region and barely touches the other. On a typical frame, reach for the filter presets first and save the sliders for the cases where you need to push past what a preset gives you.

The Phocus Grayscale sliders look like a global brightness control. Measured on a ColorChecker frame, they're a genuine per-channel B&W mixer.

Two weeks ago I sent Hasselblad support a question I thought had a one-line answer. I know, I know, I should know better...
08/29/2026

Two weeks ago I sent Hasselblad support a question I thought had a one-line answer. I know, I know, I should know better than that by now, right?

But I digress...

Let's get back on topic: when Phocus for Mac and Phocus Mobile render the same RAW file differently, which one is the real HNCS? Twelve days, two support cases, and three engineering replies later, I have an answer of sorts. But it didn't resolve the question. It dismantled it.

Along the way, that answer proved a claim I published in early August wrong. So this post is two things: the clearest definition of HNCS Hasselblad has ever put in writing, as far as I know, and a retraction.

💡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: [email protected] for global support, [email protected] for the Americas, or visit hasselblad.com/support for regional options.

Key finding: According to Hasselblad engineering (August 2026), HNCS is applied to every RAW render in both Phocus for Mac and Phocus Mobile, as an internal processing stage linked to white balance. No preset or import state "is" HNCS. My 9 August claim that default Mac imports aren't HNCS is therefore retracted; the measured gap is vignetting correction.

One RAW file, two Hasselblad apps, two different pictures

The question came out of the import preset investigation. Quick recap for anyone joining late: Phocus for Mac, in its default configuration, does not apply the Adjustment preset you pick in the Import dialog. Every image lands in an as-imported state the toolbar calls "3FR" (the color processing is all there; what is missing is most of the lens vignetting correction, so the corners sit darker), and it stays that way in every export until/if you apply a preset yourself. Phocus Mobile on the iPad offers no preset choices at all, and its one and only render matches the Mac's Standard preset almost exactly, roughly fifty times closer than it sits to the Mac's default import state.

Same file, same company, two different default pictures, about ten percent of full scale apart. I naively assumed that surely one of them had to be the real HNCS rendering that the marketing promises? Hasselblad themselves describe HNCS as a color system that runs "from the initial capture to post-editing"¹ and removes the need to fiddle with profiles. Well, OK then! Which of your two renders is it then?

On 7 August I put that question to Hasselblad support, with the measurements attached.

Researching and writing the blog and page posts I produce takes up a lot of my time and costs me money for software subscriptions, tooling, and other incidentals related to running a business.

Please consider a paid membership to help me keep the lights on and pay the bills - it is only a fraction of the cost of an X2D II and a lens. Click on the button to go to the membership page to see the options available.

Support the blog.

Hasselblad's first answer: crop settings

The engineering reply arrived on 14 August:

Both are valid HNCS renderings. Phocus includes 5 factory preset adjustment templates. Users can select the appropriate template based on their scenario, then make fine adjustments. [...] "3FR" represents the embedded adjustment scheme within your 3FR file. It has the same basic settings as "Standard," but includes additional crop settings.

"Both are valid HNCS renderings" should have been the first hint of where this would end up, but I was more than a little confused by the second half. Crop settings cannot be the explanation for what I measured mostly because none of the test images was ever cropped. All three exports, Mac default, Mac Standard, and the iPad's render, are 11656 x 8742 pixels.

And a crop does not change the value of a single pixel anyway; it changes which pixels you keep, as I had to explain to Hasselblad Engineering. The difference I measured is radial, strongest in the corners, which is the signature of lens falloff correction, and it shows up on every uncropped frame I tested.

So I wrote back the same day and posed the problem as a fork. Phocus Mobile has no preset selector. It produces exactly one rendering, and that rendering matches the Mac's Standard preset. So, either Standard is the HNCS rendering and the Mac's default import state is not, or Phocus Mobile cannot produce HNCS at all, which would be its own defect. I attached the RAW file, all three exports, and checksums, and asked them to pick a branch.

The same answer came back on a different case

While that rebuttal sat with engineering, my separate bug case about the import preset behavior got its own engineering reply. It contained the same crop explanation(!!!), in slightly different words, with no sign anyone had read the rebuttal filed three days earlier on the other case.

I would like to say this surprised me. The first time I asked Hasselblad what the "Use embedded if available" checkbox actually does was last November. That reply asked me for a screen recording, and the thread went quiet. The checkbox that decides whether your chosen preset gets applied at all appears nowhere in the official Phocus manual, which still only documents the software up to version 3.8. Nine months of asking, and the closest thing to documentation is still a support thread.

Then something approximating a real answer landed.

Have you seen the guide? I've published Essential Phocus 4.x for Mac - 85 topics across 8 sections and 250 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.

Get it here

What is HNCS, according to Hasselblad?

According to Hasselblad Engineering, HNCS is a processing stage that both Phocus apps apply to every RAW render. Always. That is the answer that arrived on 19 August, this time from their engineering team after they had "reviewed your findings and measurements again carefully." Quoted in full:

Both Phocus and Phocus Mobile apply HNCS when processing RAW images. HNCS takes effect during the intermediate stages of image processing and is strongly linked to white balance parameters. Since different presets utilize different white balance parameters, this is the primary factor influencing the visual outcome of HNCS. Other post-processing adjustments, such as vignetting or tone curves, do not affect the HNCS processing currently applied to the photo.

Read that twice, because it quietly redefines the thing photographers argue about in forum threads. HNCS is a stage inside the rendering engine. Every RAW file passes through it, in both apps, every time. You cannot turn it off, you cannot select it, and you cannot point at a render and say "that one is HNCS." The as-imported state? HNCS. Standard? HNCS. The iPad's render? HNCS. Asking which render is the real HNCS turns out to be like asking which cup of coffee is the real water.

The presets sit on top of that stage, and per Hasselblad the main way they influence its visible outcome is through white balance. Vignetting and tone curves sit outside it entirely.

And to give credit where credit is due, this definition agrees with my own measurements better than my original interpretation of them did. When I isolated the mechanism on 11 August, the as-imported state and Standard turned out to share one identical color pipeline. The entire visible difference between them, byte for byte, is the Lens Corrections Vignetting slider moving to 100. A lens correction. The exact category Hasselblad now says lives outside HNCS. Their definition and my toggle test are two independent descriptions of the same pipeline, and they fit.

The crop explanation from the earlier replies was not mentioned again because I requested they refrain from diversionary tactics.

The retraction

On 9 August I published a post titled "Phocus for Mac Imports Aren't HNCS by Default. Neither Are Your Exports." Under Hasselblad's definition, that title was wrong, and so was the claim it stood on: that a render without the preset applied is a render without Hasselblad's color science. Every one of those exports carried HNCS. Every render Phocus has ever shown me carried HNCS. What the default import flow withholds is a lens falloff correction.

The measurements in that post were right, and every one of them still stands. The interpretation was mine, and it overreached. The post has been corrected in place with dated updates, and its title no longer makes the HNCS claim. I am also re-checking the wording in the HNCS explainer and the .phos teardown against this definition, and will note any corrections there the same way.

The lesson is one I have preached here before and then failed to follow myself: pixels beat labels. I proved with checksums that the pixels differed, then reached for a label the pixels never claimed. In my defense, if they'd just have documented all this in the first place we wouldn't be here.

For completeness, Hasselblad also confirmed the behavior that started all this. The default import flow skipping your selected preset is, in their words, "expected behavior." As is the checkbox re-ticking itself every time Phocus restarts. None of it is a bug in their eyes, which makes the practical advice below permanent rather than a workaround.

What does this settle, and what stays open?

Settled: the community had the shape of this right years ago. A Luminous Landscape analysis from 2015² modeled HNCS as white-balance-driven color transforms selected per illuminant, and "strongly linked to white balance parameters" is the first time Hasselblad has confirmed that link in writing, as far as I know. Settled too: preset differences are adjustments layered on one shared color pipeline, which is exactly what the .phos sidecar teardown found when it diffed the factory presets.

Open: one detail of Hasselblad's answer does not, however, line up with that same teardown. They say different presets "utilize different white balance parameters" as the primary factor. The sidecar diffs across all five factory presets found sharpening and tone curve changes, and no white balance delta at all. Maybe presets pass the as-shot white balance through rather than setting their own. Maybe the answer describes a layer the sidecar never records?

Alas, also still open, and unmoved by any definition so far: the same RAW file still produces two visibly different default renders depending on whether you open it on a Mac or an iPad, up to 18 percent apart in the corners on my test frames. Both are HNCS. Both are intentional. Neither app tells you the other one disagrees, and outside of these support threads, nothing in writing says so either.

The practical rule survives every redefinition unchanged: untick "Use embedded if available" when you import, or apply your preset afterwards with the Adjustments dropdown or Modify. That gets your Mac the same corrected render the iPad produces without being asked.

Which leaves the question I should have sent on 7 August, and which is now sitting with Hasselblad on the still-open bug case: if every render is HNCS, why does Phocus for Mac default to withholding a lens correction that Phocus Mobile applies to every single image? When that answer arrives, I'll be sure to update you all right here.

References

1. Hasselblad, "Hasselblad Natural Colour Solution": hasselblad.com/learn/hasselblad-natural-colour-solution
2. Luminous Landscape Forums, "Hasselblad Natural Color Solution (HNCS) - how it works (probably)": forum.luminous-landscape.com

Hasselblad engineering defines HNCS: an always-on stage in every Phocus render. What my earlier claim got wrong, and what the gap really is.

You shoot a high-contrast scene in HDR mode. The X2D II's screen shows a clean capture: highlights intact, histogram com...
08/22/2026

You shoot a high-contrast scene in HDR mode. The X2D II's screen shows a clean capture: highlights intact, histogram comfortable. Then you open the same file in Phocus 4.2 and it renders darker, with a different histogram and cyan clipping warnings that don't line up with what the camera showed you. The first instinct is that something broke: the metering, the file, or Phocus itself.

Nothing broke. A reader (who had posted the same findings in a DPReview thread¹) wrote to me with exactly this, and his framing was better than most: he'd stopped trusting Smart Metering because record mode, playback, and Phocus all showed him something different, and with the camera in HDR mode he couldn't spot-meter his way out. Both observations are correct. The fix isn't a setting; it's knowing which of the three pictures is the file.

💡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: [email protected] for global support, [email protected] for the Americas, or visit hasselblad.com/support for regional options.

Key finding: The X2D II's live view, in-camera playback, and Phocus 4.2 are three different renders of one RAW, and only Phocus renders the actual file. HDR mode's forced Smart Metering deliberately holds exposure back by up to ~2.5 stops to protect highlights, so Phocus's darker render is the real, intended exposure.

Why do record mode, playback, and Phocus all disagree?

Because you are not looking at one image three times. You are looking at three renders built for three different jobs:

* Record mode (live view) is built for composing and focusing. It doesn't always track your exposure.
* Playback shows the camera's processed preview, tone-mapped to look good on the built-in screen. Its blinking clip warning reads from that preview too, which is why it can disagree with Phocus about what clipped.
* Phocus renders the RAW itself through Hasselblad's color pipeline. This is the only one of the three that shows you the file.

When my reader took the question to Hasselblad support, their answer (posted in full in the thread¹) was a compressed version of the same point: "The camera renders a preview as opposed to displaying the full RAW file which you will see in Phocus." That's correct, but it leaves out the two mechanisms that make the previews diverge, and those mechanisms are where the confusion actually lives.

What record mode is really showing you

The live view image is governed by a setting you may never have opened: Exposure Simulation, under Main Menu > Exposure Settings, not under Display where you'd expect it (X2D II manual, section 3.2). When simulation is active for your shooting mode, live view tracks the exposure you've dialed. When it isn't, the screen shows a brightness-optimized preview instead, built so you can compose and focus, not so you can judge exposure.

Two behaviors compound this. The manual states that Exposure Simulation is automatically deactivated while autofocus is analyzing the subject, then reactivated after focus completes. In practice: the display brightens during your half-press, exactly when you're looking hardest at it. And the setting is scoped by exposure mode (the manual's options are "A/S/P/Auto" or "A/S/P/Auto/M"), so depending on how it's configured, an entire mode's live view may never reflect your dialed exposure at all.

So record mode can genuinely look brighter than the exposure being set. Playback then shows the captured result without the composition aid, which reads as "the image got darker between record and play." No metering changed. Only the rendering did.

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.

Get it here

Phocus is darker because the metering did its job

With HDR output enabled, the X2D II locks metering to Smart Metering and removes Spot, Centre Spot, and Centre Weighted entirely. That's not a bug my reader hit; it's how the camera works, and it's documented behavior (manual sections 2.4 and 2.7). In high-contrast scenes, HDR Smart Metering pulls exposure back from a neutral reading by up to about 2.5 stops, specifically to keep highlights from clipping. I covered why that trade is the right one for this sensor in the highlight-metering post: shadow recovery on a 15.3-stop sensor is essentially free, and clipped highlights are gone for good.

The camera's playback preview is built to look pleasant on the 1400-nit screen, so you never really see that deliberate underexposure in the field. Phocus doesn't extend the same courtesy. It renders the RAW as metered, which means the darker image in Phocus is not a rendering error. It's the first honest look at the exposure the camera chose on purpose. The cyan marks are Phocus's Highlight Warning tool (a toggle, ⌃⇧H, light cyan by default) flagging what its current render treats as clipped, and that brings us to the checkbox.

Unchecking HDR in Phocus doesn't remove clipping. It hides headroom.

My reader noticed that turning the HDR checkbox off in Phocus made the clipping warnings shrink, which made HDR mode look like the culprit, as if the HDR render were boosting highlights into clipping. It's the other way around.

With HDR unchecked, Phocus maps the whole file into the standard SDR range. The brightest tones get compressed toward white, the histogram fits neatly inside the familiar 0-255 view, and values that actually extend beyond SDR white get squeezed together at the right edge, where the clip indicator treats them as one undifferentiated "clipped" mass. With HDR checked, those same tones spread out into the extended range above SDR white, where the histogram's gray capability zone shows them as what they are: recorded highlight data your display may or may not be able to preview. The RAW held that range the whole time. The checkbox only decides whether Phocus shows it to you.

Phocus also has a second, separate highlight tool worth keeping distinct here: the HDR Warning overlay (View > HDR Warning). Its yellow and red regions map your display's headroom, not the file's data. Red means "your screen can't preview this tone right now," not "this tone is clipped in the file." Treating that overlay as a clipping indicator is the fastest way to talk yourself into pulling down highlights that were fine.

The Mac brightness trap

One more layer catches people who check their files on an HDR-capable Mac and still see more clipping than the camera showed: a Mac's HDR headroom is not fixed. macOS adapts it to display brightness and ambient light, so at normal working brightness you are usually not getting the display's full HDR range.

Hasselblad's own advice is to lower monitor brightness for HDR work, and you can watch the mechanism directly: with the Phocus histogram open on an HDR file, drop your display brightness a few notches and the gray HDR capability zone expands to the right. Highlights that looked clipped at full brightness start showing recoverable detail. I walked through the full histogram workflow, including this behavior, in Part 3 of the HDR series, and Part 4 covers which displays have meaningful headroom to give.

How do you expose for HDR when you can't spot meter?

That's the mechanics. Here is the practical answer to my reader's direct question, "how do you adjust exposure in HDR mode," in the two workflows that actually work.

Option 1: let Smart Metering do the job it already does. HDR mode's forced metering is doing precisely what you would reach for spot metering to do: holding the histogram off the right wall. In high-contrast scenes it protects highlights by design, and the RAW almost always carries more highlight detail than the camera preview suggests. Shoot, then treat the Phocus render as ground truth and lift shadows there. On this sensor, that lift is clean.

Option 2: take manual control back by leaving HDR mode off at capture. Turn HDR output off and Spot metering returns. Meter the highlight you care about, lock it with AE-L, recompose, shoot. Then enable HDR in Phocus afterward. The in-camera HDR toggle changes the preview, the metering, and the JPEG sidecar, and it never touches the RAW, so you lose exactly nothing by metering in SDR and going HDR in post. I covered the toggle's real scope in the RAW+JPG post.

The four combinations of camera HDR mode and the Phocus HDR checkbox reduce to a simpler table than the menus suggest:

Camera HDR
Phocus HDR checkbox
What you get

On
Checked
Smart Metering's highlight-protective exposure; extended-range render showing the full headroom

On
Unchecked
Same protective exposure; SDR render that compresses highlights and over-reports clipping

Off
Checked
Your own metering (Spot available); extended-range render of the same full RAW

Off
Unchecked
Your own metering; SDR render

The RAW in every row is a complete, full-range capture. The camera setting changes how the exposure gets metered and what preview you see; the Phocus checkbox changes how much of the captured range the render shows you. One precondition the table leaves implicit: the two camera-HDR-on rows require a mode where the toggle exists at all, meaning a JPEG- or HEIF-inclusive image format, single-shot drive, and a non-Manual exposure mode. The full grayed-out list is in the RAW+JPG post linked above.

What to change in practice

Treat the camera's screen as a framing tool and the Phocus render as the exposure reference. The preview is built to look clean, not to report the data.

Before judging highlights in Phocus on a Mac, drop your display brightness and watch the histogram's gray zone open up. Full working brightness silently costs you HDR preview range.

And when a scene demands precise highlight placement, don't fight Smart Metering for control it won't give you. Switch HDR off, spot meter, lock, shoot. Check the HDR box in Phocus when you get home. The only way to lose that headroom is to forget the checkbox.

References

1. DPReview forum thread, "Problem w clipping on X2D2", the public version of the reader findings this post responds to.
2. Hasselblad X2D II 100C User Manual v1.0, sections 2.7 ("HDR Function") and 3.2 ("Exposure Settings" / Exposure Simulation), available from Hasselblad's support downloads.

Want help setting up your own backup workflow? I offer one-on-one consulting for photographers who’d rather not spend a weekend Googling file structures and cloud services. It’s practical, friendly, and totally tailored to your gear and goals.

Contact Me!

X2D II HDR shots look clean on camera, then clip in Phocus 4.2. Why live view, playback, and Phocus disagree, and how to expose for HDR.

Address

San Acacia, NM

Website

, ,

Alerts

Be the first to know and let us send you an email when Tonal Photo posts news and promotions. Your email address will not be used for any other purpose, and you can unsubscribe at any time.

Contact The Business

Send a message to Tonal Photo:

Shortcuts

Share

Category