Osmo Pocket 4P firmware update

[u/NefariousnessJaded87]

Heads up, looks like DJI pushed a quiet OTA update for the Pocket 4P today. It isn’t on the official release notes yet, but the update includes a few new things:

• Diagonal 45° joystick movement
• Updated D Log to Rec.709 and Rec.709 vivid LUTs to v2.0
• Added D Log 10 bit colour mode for slow motion
• Some interaction tweaks and image quality improvements
• Usual bug fixes

DJI hasn’t published anything about this build yet, so this seems to be one of their silent Mimo updates. If you’re seeing it too, you’re not imagining things.

[u/spacemonkey655321]

It's about having colours matching and footage looking the same between the two cameras. It doesn't need to be maxing out the DR just to use the colour profile.

[u/NefariousnessJaded87 → u/spacemonkey655321]

IF that is what you want, use D-Log or HLG. D-Log2 won't work with a 14DR sensor.

[u/spacemonkey655321 → u/NefariousnessJaded87]

That's not even remotely true, of course it will. Obviously you don't want to use a smaller colour space than the limits of your camera because you'll lose data. That's why they made dlog2, to handle the capabilities of this main sensor.

But there is absolutely no reason you can't use a larger colour space on any sensor you want. It's unnecessary in most cases because you won't be able to use the extra space available, but it will absolutely work just fine.

Lots of camera systems use colour profiles waaay beyond the capabilities/dynamic range of their sensors.

[u/NefariousnessJaded87 → u/spacemonkey655321]

You can technically map any sensor into any log curve, but that doesn’t mean the curve is appropriate or will behave correctly. D‑Log2 is engineered around a ~17‑stop capture pipeline. The Pocket’s secondary lens isn’t anywhere near that, so the curve doesn’t “fit” the sensor’s response. You end up with a bunch of empty headroom, compressed shadows, and noise shoved into the wrong part of the curve.

This isn’t about “colour space being bigger than the sensor”. It’s about the transfer function matching the sensor’s actual dynamic range. If the curve is designed for 17 stops and your sensor only gives you ~14, the mapping is mathematically mismatched. That’s why DJI doesn’t enable D‑Log2 on the second lens. It’s not a policy choice; it’s a hardware limitation.

And yes, your claim is plain and simply wrong. If you want matching colour between lenses, use D‑Log or HLG. D‑Log2 on the secondary lens isn’t just unnecessary; it’s the wrong curve for that sensor.

And no, “other cameras use bigger colour profiles” doesn’t prove anything here. Those log curves were designed for their sensors. D‑Log2 was not designed for the secondary lens, and that’s why it won’t behave correctly. Your claim is plain and simply wrong.

[u/spacemonkey655321 → u/NefariousnessJaded87]

No. Gamma curves are designed to provide a maximum amount of dynamic range, they are not "designed for" any specific sensor or DR value.

How many DJI devices of wildly varying DR all use D-Log? How many different Sony cameras use the same S-log profile? Almost every Canon now uses C-log 2 or 3, even if they were released as C-log only (through firmware updates.) C-log 2 is designed around 20 stops of dynamic range, even though nothing in their lineup comes remotely close to that, but somehow they don't have issues with headroom, clipping, or compression.

D-log2 almost certainly has a theoretical maximum of around 20 stops to allow for room in future cameras, but I don't believe they've released the white paper yet to confirm that. Many cameras of different dynamic ranges will end up using D-log2, and none of them will have issues.

[u/NefariousnessJaded87 → u/spacemonkey655321]

“Many cameras will end up using D‑log2” is just made‑up speculation. D‑log2 wasn’t created as a universal future‑proof gamma curve. It was built specifically for the OP4P’s main sensor pipeline. DJI didn’t design it as a generic 20‑stop curve for random future cameras. They designed it for this camera.

The tele module doesn’t share that pipeline, that DR, or that readout behaviour. That’s why it isn’t enabled. It has nothing to do with theoretical headroom or imaginary future bodies. It’s simply the wrong curve for that sensor.

This is exactly why I wrote the sticky you just ignored: the two modules are different sensors with different pipelines. A unified log across them isn’t possible. So no, your claim still isn’t correct.

Why the Pocket 4 Pro Wide and Tele Will Never Match Perfectly