At Huly Labs, we’re developing our own ray tracing-based 3D engine. Today, I’d like to share our experience integrating a denoising library into that engine - Intel’s Open Image Denoise (OIDN).

Why OIDN?

To be honest, I initially didn’t pay much attention to the fact that OIDN received a Technical Achievement Award from the Academy of Motion Picture Arts and Sciences in 2025. But after working with it, I realized this award wasn’t just for show - it reflects real, thoughtful engineering. If you’ve ever read Jason Hughes’ article “What to Look for When Evaluating Middleware for Integration” from Game Engine Gems, OIDN feels like a textbook implementation of those principles.

What impressed me?

  1. Cross-platform and vendor-agnostic. OIDN works on CPU (x86 and ARM) and GPU - with no hard dependency on any specific vendor. You’d never guess it’s an Intel product, because there are no Intel-only limitations. Everything worked equally well across different hardware.

  2. Full, practical documentation. It’s not just a dry API reference. The documentation reads more like a technical guidebook, full of real-world tips, edge-case explanations, and data preparation best practices. This kind of developer-first documentation is rare and extremely helpful.

  3. Modularity and extensibility. OIDN allows you to plug in your own hardware backends - like CUDA, Vulkan, or other APIs - and even connect custom-trained neural networks. The training setup, including dataset preparation, is also open and documented. This makes the library a great fit not only for direct use, but also for advanced customization.

  4. Open source and fully packaged. OIDN is fully open source, including all necessary components for training and inference. Even better, the distribution includes prebuilt binaries (DLLs, SOs) for multiple platforms and architectures, along with all required dependencies. There’s no “build it yourself” hassle - everything works out of the box.

  5. Comes with a CLI tool. The command-line interface is great for quick testing and evaluation. It lets you run denoising on your own images, tweak settings, and get performance metrics. I started our integration by reproducing the CLI’s behavior in Rust - it gave me a clean reference point and helped validate the data pipeline. The input format, PFM, is somewhat inconvenient - we ran into some issues due to its limited adoption. Still, it’s workable.

  6. Robust input handling. OIDN is flexible when it comes to inputs. You can feed it data with or without normals, in HDR or SDR, even with gamma correction - it just works. From our tests, the best image quality was achieved using HDR float data (one float per channel) with all the aux data provided (normals and albedo).

Performance: where are the numbers?

The biggest drawback is the lack of official performance benchmarks. And for real-time applications, that’s a serious concern. When doing real-time path tracing, we’re bound by strict frame budgets: ideally under 16 ms, and absolutely no more than 33 ms per frame (for 60 FPS and 30 FPS respectively). You can pipeline rendering and denoising (i.e., denoise the previous frame while rendering the next), but only if neither step maxes out the GPU on its own.

Here’s what our tests showed:

  • On a mobile RTX 3070, OIDN couldn’t hit real-time for full HD - denoising alone took around 47 ms.
  • For 800x600 resolution, however, it handled denoising in 12 ms, which is promising.
  • These numbers exclude data prep and copying, but those can often be handled in parallel through pipelining.

We’re very curious to see how OIDN performs on a RTX 4080 or 5090. On paper, those GPUs should be capable of real-time denoising. Unfortunately, we haven’t had access to those cards yet.

What about alternatives?

There’s also NVIDIA’s NRD (Real-Time Denoisers). On the same RTX 3070, the sample demo shows 30�80 FPS on complex scenes, which is an encouraging sign. It serves as a proof of concept: real-time Monte Carlo path tracing with denoising is absolutely feasible on consumer hardware.

That said, from an engineering perspective, NRD is significantly harder to work with. The demo and the core library are distributed separately, but the demo is often the only practical reference. The standalone library comes with many unclear dependencies and extracting a minimal working example takes real effort - at least a week of engineering time. And that’s before considering Rust porting or integration with an existing renderer. As a result, we’ve put NRD aside for now.

Final thoughts

OIDN is, without exaggeration, one of the best-engineered libraries I’ve ever worked with. It’s:

  • cleanly designed and mature;
  • well-documented and developer-friendly;
  • modular and extensible;
  • fully open-source;
  • and comes prepackaged with everything needed to start working immediately.

The big question remains: can it be fast enough for real-time usage on top-tier GPUs? If so, it’s the ideal solution. For now, we continue to test and optimize our integration - but even at this stage, I can confidently say: working with OIDN has been a pleasure.

P.S.

If you’re going to integrate OIDN into a Rust application, I don’t recommend using the existing crate named “oidn” from the package manager. As of May 2025 (version 2.3.3), it doesn’t build out of the box on Windows, contains some performance issues, and has several inaccuracies in how it communicates with the library’s API. I would recommend using the crate’s repository with source code as a starting point, and relying on the raw unsafe bindings to the library provided there as well. While the library does include some unit tests, they are rudimentary and won’t be of much help when making significant architectural changes.