> ## Content Index
> Fetch the complete content index at: https://blog.tonalphoto.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# 23 to 81 Pixels: What the X2D II Firmware Bug Does to Your Lightroom Renders
- URL: https://blog.tonalphoto.com/x2d-ii-firmware-bug-lightroom-renders-measured/
- Published: 2026-11-07T10:25:00.000Z
- Updated: 2026-11-07T10:24:59.000Z
- Author: Konrad Michels
- Tags: X2D II, Bug Reports

Set the X2D II's Unit of Distance to feet and the camera writes focus distance in feet into a field the EXIF standard defines in meters. Lightroom reads that number as meters and corrects the lens for a distance you were never at. That is the [feet bug](https://blog.tonalphoto.com/x2d-ii-firmware-focus-distance-feet-lightroom/), and in that post I put the cost at roughly 200 to 275 pixels at the frame corners.

In a rendered file it comes to 23 to 81 pixels, measured on six pairs across three lenses, and on one of them the biggest shift is nowhere near a corner. Open the same raw twice, once with the distance the camera wrote and once with the distance the lens was really at, then flick between the two. Parts of the picture move while other parts stay where they are.

**Nothing in Lightroom tells you this is happening.** The wrong correction is applied whenever profile corrections are on, it is baked into every export, and the frames it hits hardest are close-focus work. It is not only a settings mistake either. The same camera sometimes writes a distance and then leaves it there while you refocus, and no unit setting fixes that one.

💡

****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](mailto:customersupport@hasselblad.com) for global support, [support.us@hasselblad.com](mailto:support.us@hasselblad.com) for the Americas, or visit hasselblad.com/support for regional options.

> **Key finding:** Correcting the focus distance in an X2D II raw moves the Lightroom render by 23 to 81 pixels, measured on six file pairs across the XCD 25V, 55V and 90V with profile corrections on. The shift grows with how wrong the stored distance is. On the 90V the largest movement sits mid-frame, not at the corners.

## How do you measure a lens correction you cannot see directly?

Each pair is one raw file twice. The original carries the distance the camera wrote. The copy carries the distance I was really at, written into the same eight bytes by the tool from the first post, with nothing else in the file touched. Both go into Lightroom with the same profile, the same white balance, no crop, no exposure change, and Adobe's lens profile corrections switched on, which is the setting that makes the distance matter at all. All of this is Lightroom Classic. Capture One reads the same field and I have not measured it.

Both are exported as 16-bit TIFFs. Software then compares the two in a grid of 130 windows spread across the frame and works out, for each window, how far that patch of picture moved between the renders. The method is ordinary image registration, the same idea as aligning frames for a panorama, and it resolves well under a pixel.

Fit a smooth curve through all 130 windows and the measurements sit within 0.2 to 1.8 pixels of it, depending on the pair, so the field each pair produces is a real shape rather than scatter.

![Displacement arrows drawn over a photograph of a rose at 0.72 metres, each arrow showing where that part of the frame lands once the focus distance in the file is corrected, with labels from 6 to 81 pixels](https://storage.ghost.io/c/f5/ac/f5aca107-db6c-464b-b8b7-7b834c3c955f/content/images/2026/10/fig1-displacement-grid.png)

*Figure 1\. The XCD 90V frame, arrows drawn twelve times longer than life. Every one points inward, and the longest sit between the middle of the frame and the edge.*

## How far does the image actually move?

Between 23 and 81 pixels, depending on the lens and on how wrong the stored distance was.

| lens    | file says | really was | largest movement |
| ------- | --------- | ---------- | ---------------- |
| XCD 90V | 2.35 m    | 0.72 m     | 81 px, mid-frame |
| XCD 55V | 1.49 m    | 0.45 m     | 64 px, corner    |
| XCD 55V | 1.62 m    | 0.49 m     | 70 px, corner    |
| XCD 25V | 4.64 m    | 1.41 m     | 23 px, corner    |
| XCD 25V | 4.64 m    | 0.71 m     | 62 px, corner    |
| XCD 25V | 4.64 m    | 0.62 m     | 75 px, corner    |

Where the movement lands is a property of the lens, and the three do not agree. The 90V pulls everything inward, hardest about half way out to the corner, and arrives at the corner itself with almost nothing left. The 55V pulls the middle inward and pushes the corners outward, crossing over at about four fifths of the way out, so the frame changes shape rather than size. The 25V does the same thing in gentler form.

![Three small charts, one per lens, plotting radial displacement in pixels from the centre of the frame to the corner. The 25V and 55V curves dip inward then rise outward past zero near the corner; the 90V curve dips to 81 pixels inward around mid-frame and returns to zero at the corner](https://storage.ghost.io/c/f5/ac/f5aca107-db6c-464b-b8b7-7b834c3c955f/content/images/2026/10/fig2-displacement.png)

*Figure 2\. The same six pairs as curves. Inward is negative. The 55V's swing, 50 pixels in at mid-frame and 64 out at the corner, is why it reads so strongly when you flick between versions.*

On a 100 megapixel frame, 70 pixels is under a third of a percent of the frame width, which is the kind of number you would expect to ignore. What makes it visible is that the frame does not slide sideways as a whole. One part of it moves inward while another moves outward, and that relative movement is easy to see even when the absolute distance is small. Brightness barely moves by comparison: the outermost part of the frame is 0.108 EV brighter on the 90V pair, and within 0.05 EV on the 55V and 0.004 EV on the 25V.

![Two crops of the same 430 by 430 pixel window from the same raw file, rendered with the wrong and the right distance, with a crosshair at the same pixel in each. A leaf junction sits in a visibly different place against the crosshair](https://storage.ghost.io/c/f5/ac/f5aca107-db6c-464b-b8b7-7b834c3c955f/content/images/2026/10/fig3-pair-crop.png)

*Figure 3\. One window of one file, at 1 to 1\. Same sharpness in both, shifted by about 70 pixels.*

## Why the number in the first post is not the number you will measure

That post said Adobe's profile puts about 266 pixels of distortion correction at the corner for 0.67 m and about 9 the other way for the entry nearest 2.19 m, and "on an 11,656-pixel-wide frame, that is a difference of roughly 200 to 275 pixels at the corners". The first half of that is Adobe's own numbers and it stands. The second half turns a gap between two profile entries into a claim about what lands in your file, and that is the part I got wrong. At the 90V corner the measured difference between the two renders is 6 pixels.

Separating the measured field into a scale term and a curvature term shows where Adobe's number went. The curvature part, which is the component that changes the frame's shape rather than its size, comes to 220 pixels at the corner on the 90V, 203 to 220 on the 55V, and 36 to 116 on the 25V depending on the size of the distance error. Adobe's entries are as far apart as the first post said.

What I left out is that Lightroom does not hand you the bare difference between two corrections. The corrected render also comes out slightly smaller, by 1.8 to 2.9 percent on the 55V and 90V and by 0.2 to 0.6 percent on the 25V, and that scaling cancels most of the corner difference. What survives into your exported file is what I measured: up to 81 pixels.

So the earlier figure describes the gap between two profile entries accurately, and describes the gap between two exported files badly. If you go looking for hundreds of pixels at the corners of your own pair you will not find them. The scaling is consistent with Lightroom keeping the corrected image filling the frame, which is what a raw converter has to do after bending the geometry, though that is my reading of the numbers and not something I have confirmed.

## Does a bigger distance error cost more?

Yes, and the 25V shows it cleanly, because all ten of its frames from that afternoon stored the same wrong number, 4.64, wherever the lens was focused. Three of them, corrected to three different distances:

| file says | really was | movement at the corner |
| --------- | ---------- | ---------------------- |
| 4.64      | 1.41 m     | 23 px                  |
| 4.64      | 0.71 m     | 62 px                  |
| 4.64      | 0.62 m     | 75 px                  |

One of those three distances is exact and two are estimates. For the 1.41 m frame the correction is a unit conversion of 4.64 feet, and an independent estimate from the camera's own magnification data lands at 1.44 m, so that one is solid. For the other two the corrected distance is that estimate alone, which carries the uncertainty of my per-lens calibration. The direction and the ordering are reliable. Read the individual figures as close rather than exact.

## What I could not show

The test I wanted was the other way round: show that the corrected version is straighter. A physically straight line stays straight in an undistorted rendering, so tracing one should favour the correct render. I traced three deck seams across the 25V frames. Both versions depart from straight by about 9 pixels, which turns out to be the noise floor of tracing a seam in composite decking rather than curvature in either render. The seams also sit at radii where these two renders barely differ. A clean version of that test needs a long high-contrast straight edge running into a frame corner, and these frames do not have one.

## What to do about it

Set Unit of Distance to Metre, under Main Menu, General, Language and Unit. I switched my own camera over on the day the first post went up, which is why every frame in this one still carries a feet value. They were all shot before that.

For frames already on disk, the distance can be corrected in a copy, which is what all six pairs here are. The tool that does it is the subscriber script from the [first post](https://blog.tonalphoto.com/x2d-ii-firmware-focus-distance-feet-lightroom/). It reads the magnification the camera records in its maker note, works out what the distance should have been, and rewrites those eight bytes in a copy while your original stays untouched.

The 25V frames above are the second fault, the one no unit setting fixes: the camera sometimes writes a value and then leaves it there while you refocus. Three reports went to Hasselblad on October 28\. All three have tickets as of October 30, and support has forwarded the first two to the firmware engineering team and is checking the third with their engineers, with one to four business days quoted on each. No engineering finding and no fix version yet. When there is one I will say so here and on the [known issues page](https://blog.tonalphoto.com/phocus-known-issues/).

If you would rather see it on your own files than take my word for it, you need a copy of the raw carrying the right distance. That is what the subscriber script makes, and anything that can write the EXIF SubjectDistance field into a copy will do the same job. Open both versions in Lightroom with profile corrections on, zoom to 1 to 1 near a frame edge and flick between them. Compare view is harder to read than flicking, which is how I saw it in the first place.

## References

1. [X2D II Firmware Writes Focus Distance in Feet. Lightroom Reads It as Meters.](https://blog.tonalphoto.com/x2d-ii-firmware-focus-distance-feet-lightroom/)
2. [Hasselblad X2D II RAWs Record Focus Distance. Now Your Editor Reads It](https://blog.tonalphoto.com/hasselblad-x2d-ii-focus-distance/)
3. [CIPA DC-008-2012, Exif Version 2.3, section 4.6.5 SubjectDistance](https://www.cipa.jp/std/documents/e/DC-008-2012%5FE.pdf?ref=blog.tonalphoto.com)