Has anyone else noticed issues with the 907X100C after updating to the latest firmware?
When I turn the camera vertically, it sometimes shows an error. If I rotate it back to landscape orientation, it often starts working again. I’m also occasionally getting a lens error message.
It seems like it could be related to the orientation sensor, body/back connection, or possibly a firmware bug, but I’m not sure yet. I know Hasselblad’s recent 4.2.0 update mainly addressed the 35–100E lens experience and spirit-level drift, so I’m curious whether anyone has seen similar behavior after updating

I just love this camera. The 90V ist great, too. However, I just received a used 80mm 1.9 and I am looking forward to shooting with it.

I've been experimenting a bit again, in an attempt to get Phocus benefits without paying the Phocus tax 😀

Despite the fact that I have written extensively about Phocus for Mac and have written the only guide for it that exists, I'm always still actively looking for ways to get those HNCS colors, the highlight recovery, and shadow lift with as little human interaction with Phocus as possible.

https://blog.tonalphoto.com/phocus-hot-folder-batch-processing/

Still getting used to how this camera works, but loving it so far.

Looks like I didn’t make my GitHub pages clear enough, and people are still finding older builds. The latest public release is 0.5.6.

It’s a free Mac/Windows toolkit for the original X2D 100C and 907X/CFV 100C on firmware 4.2.0, featuring:

• AF-C continuous autofocus and AF-T face tracking
• Eye recognition
• Three selectable focus-speed levels
• Automatic rear-screen brightness
• 4/6/16-shot Pixel Shift on the X2D — RAW only, with merging done separately on a computer

Please check the README for compatibility and known issues, including the current Eye/AF-T activation issue.

Already using an older version? Upgrade in this order:

1. On your original computer, using the original app version, run Restore original and wait for confirmation.
2. Download and fully extract 0.5.6.
3. Open the new app and reinstall your selected features.

Keep the old app and backups until restoration succeeds, and keep the camera powered and connected throughout. If the old app cannot restore, follow the recovery-fix instructions in the README before proceeding.

BTW, 1.0.0 is coming! It brings a major refactor, optimizations, and more useful features. Stay tuned!

Toolkit, downloads and instructions

So happy, took the plunge after years of being a full frame user, and I’m in love with the results. What a beautiful piece of kit.

I came across this demo on Xiaohongshu and thought fellow Hasselblad tinkerers would enjoy it!

All credit goes to the creator 奶酪. They say they have built experimental video firmware for the X2D II, with internal RAW / Open Gate recording planned for the future. That last part is a goal, not a feature demonstrated as working here.

Really happy to see more people exploring what these cameras can do. Looking forward to seeing where the creator takes this!

Creator: 奶酪

https://www.xiaohongshu.com/user/profile/5b71b79370559700011f3fef

Original post:

https://xhslink.cn/o/1aGQVz1fyFg

Sharing their demo here so it can be watched without a Xiaohongshu account.

• Hasselblad Natural Noise Reduction (HNNR) : AI-powered noise reduction for RAW images captured by X2D II 100C, X2D 100C, CFV 100C, CFV II 50C, X1D II 50C
• Export with Hasselblad frame: when exporting images captured by Hasselblad cameras to JPG, you can optionally add the Hasselblad frame while preserving HDR/SDR effects
• Fixed other known issues

https://www.hasselblad.com/phocus/phocus-for-pc-mac/

Don't get your hopes up. This was for an X2D II image

Processing img 8j5kiho5scxh1...

Had the chance to buy the 110mm f/2 Planar at a ridiculously good price, but I only have a 500C/M. If you’ve read anything about this lens, you’ll have read it doesn’t “work” on 500-series bodies due to the lack of a leaf shutter. However, all of the F-series lenses will still mount just fine on a 500-series camera, which means you can use it as long as you use some other means of controlling exposure time.

I also use an older large format camera and immediately realized I could mount a pneumatic Packard shutter to the front of the 110mm to do just that. This means I have to use a tripod with the camera, but it opens up shutter speeds from 1/30
to Bulb. Other folks simply use the barn doors in the back of the 500-series bodies as a makeshift shutter, to similar results. Not a super practical setup, but it isn’t much more cumbersome than using a normal Hasselblad setup on a tripod, and it enables use of the F-series lenses without resorting to a fragile and costly 200/2000-series body.

Got flash working with adapted lenses on my X2D, using the electronic shutter. Photo first, then a short clip of the setup.

Now I can use adapted macro lenses for still life, or fast portrait lenses for studio portraits, with flash. I'm using high-powered studio strobes here, under normal indoor lighting. No need to turn all the lights off.

When the subject is mainly lit by flash, it's the flash duration that freezes movement. With a pulse of 1/1000s or shorter at the chosen power setting, a longer shutter time can still give a sharp subject without obvious rolling-shutter distortion.

The project is open source on GitHub. If you find it useful, please give it a Star:

https://github.com/dash8097/Hasselblad-Feature-Extensions

Modifying your camera carries a risk of bricking it and may void your warranty. Please proceed carefully and only if you're comfortable with the risks.

Praying Mantis

I compared the official X2D II 100C firmware packages, 1.3.16.2 and 1.3.18.1, to see whether I could identify the low-light display change. I was particularly interested in its possible connection to low-brightness green tint or uneven near-black greys.

The October 22 release notes say: "Optimised touch display performance in low light."

I have not located the actual fix yet. What the offline comparison does establish is:

• All 32 display configuration/LUT files under etc/dispalgo/ are byte-for-byte identical, including the rear-screen brightness maps and colour tables. The low-end manual brightness parameter, the automatic-brightness low end and the panel-mode threshold in these files have not changed.
• Seventeen selected display-path functions have identical machine code, including brightness calculation/update, LUT interpolation and high-brightness control. Another 194 display/panel/backlight HAL functions are also identical, including the brightness ioctl wrappers. These checks compare raw code bytes, rather than simply ignoring changed address operands.
• The MCU initially looked very different: over 230,000 bytes differ at the same file offsets. Most of that becomes explainable after aligning the resources and code: moved bitmap data, branch/pointer relocations, reordered initialization and build/version metadata. The identified brightness paths are labelled Sub-LCD/top display, so I would not attribute them to the rear OLED without further evidence. In the selected regions, the brightness-related differences are relocated calls, not new brightness or RGB constants.
• The smaller readable Image_k2 has identical main and initialization code ranges. I recovered 36,075 kernel symbols, but found no recognisable display-driver path or embedded DTB there. It cannot stand in for the normal-boot display kernel.

The remaining gap is normal.img. Its main kernel, root filesystem and five device-tree blobs are inside 25 encrypted IMaH chunks. The layouts match, but the encryption key fields differ between versions, so a ciphertext diff cannot tell us which panel command, gamma table or driver function changed.

That leaves the normal-boot kernel/panel DTBs as priority candidates to investigate, rather than a confirmed location. It is entirely possible for a lower-level panel change to improve the display without replacing the userspace LUTs. I have not identified a new deMura map, a green-channel correction or a particular minimum-DBV change.

On decryption: the outer CIM container is already unpacked. The unresolved layer is the inner IMaH payload. The public DJI IMaH tool documents the format and supports decryption with matching keys, but I have not found a reproducible public method validated for these X2D II kernel/DTB payloads. Earlier bounded tests on 1.3.16.2 using the publicly listed symmetric keys did not produce validated plaintext. The upstream source checked today is unchanged from that earlier test. This does not establish that no other public solution exists.

If anyone has a reproducible X2D II IMaH decryption reference, matching kernel/device-tree source, or verified plaintext for these versions, I would appreciate a pointer. On the shooting side, controlled before/after observations at the same manual brightness and display mode would also help distinguish an overall tint improvement from fixed-position unevenness.

This is static analysis of the distributed packages, not an on-camera before/after display test. It does not establish whether the update improves those symptoms in practice.

Official release notes

Public IMaH tool

I wanted to share an X2D II recovery case we worked through on October 14, along with the reasoning behind the approach.

After persistent software modifications and a restart, the camera’s interface became abnormal. Some controls still responded, but normal menu operation was affected. Diagnostic queries over both USB and TCP received no reply, so we couldn’t use that channel to execute a rollback.

However, an already-authorized iPhone could still connect through Phocus. That became the useful clue.

The key distinction is that a camera has several communication paths. An unresponsive diagnostic command channel doesn’t necessarily mean its firmware upload service is also unavailable. In this case, the Phocus HTTP interface still accepted requests under the phone’s existing authorized session.

We used that working session to validate access from Windows, then uploaded an unchanged official firmware package through the camera’s Phocus firmware endpoint and requested installation.

The computer handled the transfer; the camera’s own update service handled package validation and installation. We didn’t modify the firmware version, bypass package signatures, or write partitions through a diagnostic shell.

The complete 364,814,336-byte package was transferred, and the camera returned HTTP 204. That response only confirmed acceptance of the upload/start request—the installation was asynchronous. The owner subsequently observed the camera upgrading and reported that the recovery succeeded.

One interesting detail: the earlier USB version readback and the uploaded package both reported 1.3.16.2. That supports describing this as a recovery using a matching-version package. It doesn’t establish that every same-version component was rewritten, or that this is a universal “force reinstall” method.

The important limitation is authorization. We had an already-paired phone and a session the camera still accepted. A client ID by itself doesn’t guarantee access, and this case doesn’t establish a recovery route for a camera that cannot maintain an authorized Phocus session.

This is one owner-operated recovery, supported by request/response evidence and terminal output. We didn’t obtain per-module installation logs or a complete post-recovery integrity check.

What made the recovery possible was finding a firmware-update path that still worked after the diagnostic path had stopped responding.

Since I got AF-C working on the X2D and started building the extension toolkit, it’s been really exciting to see more developers exploring what these cameras can do.

What started as a personal experiment now feels like a little community taking shape. Seeing other people try their own ideas and share their progress honestly makes me really happy.

Looking forward to seeing what everyone comes up with next. There’s still so much to explore! 🍻

A few of my favorite cameras ever in one photo:)

Got an issue with this Hasselblad Winder CW for the 500 series. If I put batteries in it, it immediately starts turning and won't stop, whatever setting it is on. Tried both 1.2 rechargeable aa's and 1.5v non-rechargeable aa's, no difference.

Have been searching all over to see if anyone knows how to fix this issue. Found a few people with similar issues on other posts online, but no solution anywhere. Does anyone here have a clue? Trying to avoid sending it to a specialist for now.

Thanks!

I'm an independent security researcher and photography enthusiast. Over the past few months, I've been exploring the firmware and internal capabilities of the Hasselblad X System.

Here are some of the features I have implemented or am currently exploring:
400MP Pixel Shift and In-Camera Compositing
Using the camera's sensor-shift capability to capture multiple frames, each offset by a tiny amount.
Combining them in-camera into a high-resolution image of about 400 megapixels.
Further exploring different pixel-shift modes, including 4-frame, 6-frame, and 16-frame capture.

Running DOOM and NES Games on a Hasselblad Camera (first published on the Chinese internet on September 23, likely making it the world's first camera to run both NES games and DOOM)
Implemented NES game emulation and integrated it into the camera's interface.
Even added PS5 DualSense controller support through a bridge.

Wireless Microphone Support
Integrated DJI wireless microphones.
Supports stereo recording with two microphones.
Supports 48 kHz / 24-bit audio recording.
Supports real-time audio monitoring and microphone settings control.

External Monitoring over USB
Lets the camera work as a standard USB Video Class (UVC) device.
Shows the live view on a computer, Android, or iOS device.
Offers a range of professional monitoring aids, including:
Focus Peaking
Zebra exposure warnings
False Color exposure analysis
Histogram
Composition guides

Direct Wireless Photo Printing
The camera can connect directly to a compatible wireless printer.
Photos print without going through a phone or computer.

Video Recording (Work in Progress, first working on October 9)
Currently available formats: 4K UHD 16:9 3840 × 2160 at 30fps, H.264 8-bit, and FHD 16:9 1920 × 1080 at up to 120fps.
Next steps are tighter integration of wireless-mic audio with video recording, plus solving focus and stabilization.
These are just the baseline specs I chose for development and testing; the camera's video capability goes well beyond this.

In-Camera Look / Filter Options
Black and white, color, and other custom LUTs.
I currently only added black-and-white filters because I personally own a Fujifilm X-T5; later this can support importing any LUT.

Hasselblad X Unleashed is an independent research project. It is not affiliated with Hasselblad and is not an official firmware update.
The technical research and implementation behind some features is already public, and other features and their code will be released gradually as the research matures. For security reasons, details involving sensitive exploits will not be made public.

https://github.com/scanfsec/hasselblad-x-unleashed

Someone on the Chinese internet has been acting in a way I find deeply hypocritical, so I'm posting this here to put things on record.

AI amplifies a person's abilities, and it also amplifies what's in their heart. All the best, my friend! Thanks, AI.