OpenDefocus

The Magic Defocus project has moved to Open Defocus as an OSS project.

It seems the current target is Nuke, but I’m really curious.

10 Likes

My weekend project :upside_down_face:
Porting OpenDefocus to OFX - OpenDefocus now working with Flame.

24 Likes

I published the Linux binary and source code here:

There is only a Linux binary, but I think you can compile and build on macOS as well.

Please read the original OpenDefocus (by Gilles Vink) document and the README_OFX.md file carefully before trying:

  • The OFX port aims to be a faithful reproduction of the original NUKE NDK version.
  • Upstream bugs or unimplemented features are preserved as-is — the OFX side does not independently fix or extend upstream behavior.

Please do not use this plugin in your important projects until you have completed sufficient testing in your environment.

I did UAT with Nuke and Flame. NOT YET TESTED WITH ANY OTHER HOST APPS.

Have fun!

Hiroshi

9 Likes

This looks really interesting. Any chance of Fusion OFX by any chance? Thanks.

1 Like

Which version of flame does this work with?

1 Like

@paul_round
I tested it with versions 2025.2.5 and 2026.2.2. However, I think it should work with any version of Flame that supports OFX.

1 Like

sorry, some ppl asked me where’s the download link.
The download link is collapsed. Please open “Asset” to find linux binary.

@Kruno
I quickly checked with DaVinci Resolve Fusion page(Re-Fusion) and Fusion Studio.
Available in Re-Fusion but Fusion Studio had got an error of OFX loading. I have no idea why this error comes… I need some more study around Fusion Studio.


2 Likes

Thank you for checking it out. If you could get it working in fusion studio and or resolve, but certianly fusion studio that would be a bit contribution to that community as well land appreciate it. Thank you. It looks like a very interesting project.

1 Like

Update the OpenDefocus OFX version.

Some issues have been fixed and performance has been improved slightly. README_OFX.md whichi incluides description of Flame limitaions whichi could not be controled in OFX.
Regarding CPU fallback, it’s practically synonymous with freezing, so don’t rely on it. Even a Xeon Gold 40-core processor can’t handle UHD rendering… :upside_down_face:

Note: The original NDK version (by Gilles Vink) has not been updated and remains v0.1.10.

The Linux binary is available to download.

Cheers,

1 Like

I gave this a go just for giggles, and after installing cmake & rust, no dice. It fails when it gets to the linking part:

Compiling opendefocus-datastructure v0.1.10 (/Users/kyle/Development/opendefocusOFX/upstream/opendefocus/crates/opendefocus-datastructure)
Compiling opendefocus v0.1.10 (/Users/kyle/Development/opendefocusOFX/upstream/opendefocus/crates/opendefocus)
Compiling opendefocus-ofx-bridge v0.1.10 (/Users/kyle/Development/opendefocusOFX/rust/opendefocus-ofx-bridge)
Finished `release` profile [optimized] target(s) in 1.88s

Linking CXX shared library OpenDefocus.ofx
Undefined symbols for architecture arm64:

... (all the areas it failed)

ld: symbol(s) not found for architecture arm64
clang++: error: linker command failed with exit code 1 (use -v to see invocation)

More than happy to share all the error messages but there are quite a few so I thought I’d not clutter this post with them.

This, of course, isn’t your issue. I just wanted to let you know. Compiling software is beyond me and I wouldn’t even know where to start when it comes to fixing it but in case others give it a go, it’s not a simple matter of following the instructions.

2 Likes

@kyleobley
Sorry for your incovinient, this is my bad.
I didn’t complete CMakeLists which only has a symbol for Linux system for now…

In fact I am totally away from OFX+macOS development for 2-3 years…but claude code is great help. Also I began to feel I need some more study for wgpu and Metal on arm64 system though.

Sorry again, I will fix CMakeLists and release macOS binary and fixed source code asap.

3 Likes

Amazing, thank you @Hiroshi. More than happy to try to build it again on my end if you don’t have a Mac available.

1 Like

I’ve updated the CMakeLists. Please check the macos-per-arch-build branch:

I ran a quick build and test on an Intel Mac using NUKE.

Known Issues:
FAIL:** 37.1 / 37.2 — Focus Point XY Overlay Crash (See [Issue #24]

For details, please refer to “HISTORY_DEV_en.md” (line 1868+) and “UAT_checklist_en.md” (line 604+).

[UPDATED]
Flame can display the focal point crosshair. This error is caused by NUKE’s OpenGL. Further information can be found in the README_OFX file:

I’ve attached the x86_64 and arm64 binaries (I know attaching binaries isn’t best practice, but they are here for quick testing).

Note that the arm64 version was cross-compiled on an Intel Mac, so please test it carefully.

OpenDefocusOFX.ofx.bundle.zip (13.1 MB)

3 Likes

another amazing tool! I’m looking forwards to giving the Mac version a spin. thanks for your generosity.

1 Like

Amazing, thank you @Hiroshi. I was able to pull this branch and build on my machine so it’s native arm64 (M4).

OpenDefocusOFX.ofx.bundle_arm64.zip (6.4 MB)

Thank you again for this port. The plugin itself is pretty amazing and I can’t wait to really dig into it more. I spent about 20 min playing around with it and I found these issues. I realize that one of them is an upstream issue but I thought I’d share nonetheless:

Axial Aberration:
Blue/Yellow & Red/Blue show no difference. (#7 on the on the upstream deferred list, but weirdly changing between either of these vs Green/Purple does have an effect where as the note on Github says it does nothing.)

Catseye:
None of the inverse buttons have any effect (Catseye Inverse, Catseye Inverse Foreground & Inverse Foreground)

Sliders:
When dragging the values, they only go up by full integers. Not great for most of the values as they seem to only work within a very small range. Unsure if that’s something that can be changed.

Thanks again for this. Let me know if you ever want me to run another build on a native arm64 chip.

4 Likes

@kyleobley
Thank you for your feedback and your kind offer! I am currently testing and fixing a few more OFX issues, and I will send all upstream issues to the original NDK repo.

Also --and very importantly-- I’d like to express my huge thanks to Gilles Vink. The fact that he released OpenDefocus as open source rekindled my interest in OpenFX plugins. This port provided me with an opportunity to learn more about Claude Code and OFX. I am truly grateful!

This community, Logik, is a fantastic place where Python, Matchbox, and OFX knowledge are shared daily, and where people generously share their techniques and code. Without a place like this, I think the OFX porting work would have remained a purely personal project…

Thanks again,

Hiroshi

4 Likes

Updated:

What’s New in v3

  • macOS support — Intel (x86_64) and Apple Silicon (arm64) builds
  • NUKE macOS: Focus Point crash mitigation — Use Focus Point parameters are automatically hidden on NUKE macOS to prevent host crash (Known Issue #24). Flame macOS works correctly. Use Focus Plane parameter directly as alternative
  • CMakeLists.txt — Per-architecture build support, Apple framework linking (Metal, OpenGL, Foundation, QuartzCore)

@kyleobley

Catseye:
None of the inverse buttons have any effect (Catseye Inverse, Catseye Inverse Foreground & Inverse Foreground)

Those options are effective in Depth mode.

Sliders:
When dragging the values, they only go up by full integers. Not great for most of the values as they seem to only work within a very small range. Unsure if that’s something that can be changed.

This is a Flame OFX issue.
Parameters have “setRange” en “setDisplayRange” ,but Flame’s UI ignores “setDisplayRange”.


I’ve began to think that I should submit a report suggesting improvements to the OFX specifications for Flame.

Compared to NUKE OFX, FlameOFX’s performance is extremely slow. This is because Flame’s OFX doesn’t support interrupt processing and, during this time, doesn’t accept user input, such as moving the viewer’s crosshair or changing sliders.

In the current OFX version, image processing is supposed to be interrupted by user input, but this isn’t functioning correctly in Flame. This is also the case with other OFX plugins, and in Flame, some significantly degrade the UI performance and usability.

Cheers,

4 Likes

weekend build - v0.1.10-OFX-v4;

  • P0 stability fixes based on third-party Flame technical review
  • Windows build support (MinGW)
  • LTO optimization: binary size reduced
  • Thread safety upgrade: eRenderInstanceSafe declaration

*Now, the master repository is moving ahead to v5, which will improve some performance and stability.

2 Likes