Curious why OIDN_FORMAT_FLOAT4 is not supported?

[rezaali]

Hi! I love the mission of this library and would love to use it with Metal. Currently, I'm using a RGBA32Float texture backed by metal buffers and I'd love to use OIDN to denoise the output of my path tracer.

So I'm curious what would be involved to support OIDN_FORMAT_FLOAT4? I'm happy to help extend Oidn, but I need guidance whether its even possible.

Thank you again!
Reza

[atafra]

Hi! I think there's a misunderstanding here. The format OIDN_FORMAT_FLOAT4 indeed isn't supported but that doesn't mean you cannot denoise RGBA images. RGBA isn't a single 4-channel feature but is composed of a 3-channel color feature (OIDN_FORMAT_FLOAT3) and a 1-channel alpha feature (OIDN_FORMAT_FLOAT1), which are significantly different. Because of this, the RGB and A features need to be denoised separately, using two denoising invocations. This can be done even if these features are physically stored in a RGBA buffer by passing the right pixel strides and offsets to the filter. So there's no need to change the memory layout or do any additional copies. I hope this helps.

[rezaali]

Thanks for getting back to me and the information. I ended up writing compute shaders to convert my rgba texture to a rgb buffer (MTLBuffer) and use that as input to oidn. The results were promising, but I ran into other issues with synchronization.

I'm using metal and I'm curious if there is a way to synchronize the work that an oidn filter does. i.e. pass it the MTLCommandBuffer it should encode its work to?.

[atafra]

Yes, you can pass your MTLCommandBuffer to OIDN by using oidnNewMetalDevice. Please see the documentation for details.