How to draw HDR bitmaps into a dialog?

[T1001]

Thank you again for your help and the great examples on creating images using RGBAf!

I'm now looking for a way to draw and display HDR RGBAf (or ARGBf) images directly inside a GeUserArea. It seems standard methods like DrawImageRef or DrawBitmap automatically convert HDR images down to LDR, losing HDR details.

Is there any way to initialize or configure a GeUserArea to support displaying HDR images properly?

Additionally, if there's an option to achieve this using OpenGL or another hardware-accelerated method, that would be great (though hardware acceleration is not strictly required—just preferred).

Previously (e.g., R21), there was an OpenGL-related class in cd4_gl.h, but it seems to have been removed from newer SDK versions. What's the current recommended approach?

Thanks again for your support!

[ferdinand]

Hello @T1001,

Thank you for reaching out to us. Please follow our support procedures in the future, questions that are not a direct follow up question constitute a new topic. We must enforce this to ensure our forum remains a searchable database of questions and answers. I have forked your question. We generally also do not allow umbrella question postings (Question 1, Question 2, ...) for the same reason. I would recommend to read Support Procedures: How to Ask Questions when you have not already done it.

Is there any way to initialize or configure a GeUserArea to support displaying HDR images properly?

The answer is sort of 'yesn't'. Dialogs and other UI elements do not have (yet) a builtin fully automated OCIO/HDR support. I.e., you cannot just give something an OCIO bitmap and expect it to draw it with its user facing data. These methods will always draw the raw data, i.e., one would have to bake things before drawing them. Drawing HDR is also a bit ambiguous request, as you cannot truly draw HDR data, even on a high end HDR monitor in a pure HDR pipeline, you can only emulate it by choosing tech like OLED for better blacks and some potent back lightning for higher contrast values. But that is not fundamentally different from SDR display tech. I.e., HDR monitors are sort of a marketing gimmick. So, the question would be: What do you mean by 'displaying HDR images properly'?

HDR image data is usually linear image data, i.e., it is not meant for human consumption. Did you mean that with 'HDR'? See our Color Management manual for details on how to convert image data between color spaces. If you wanted to go this route, you could color convert pixels from linear sRGB or sRGB-2.1, i.e., the color space display devices usually operate in.

And then there is of course OCIO. You could also just set the display profile and view transform profile on your 32-bit linear image data and then bake the data. But to do that, your image would have to be in the render space of Cinema 4D, or you would have to construct your own color profile and set that as COLORPROFILE_INDEX_RENDERSPACE. With 2025.2.0 we added cinema::BakeOcioViewToBitmap, a function which bakes down 32/16 bit OCIO image data to 8 bit data.

Additionally, if there's an option to achieve this using OpenGL or another hardware-accelerated method, that would be great (though hardware acceleration is not strictly required—just preferred). Previously (e.g., R21), there was an OpenGL-related class in cd4_gl.h, but it seems to have been removed from newer SDK versions. What's the current recommended approach?

Our OpenGL interface has been replaced by the Drawport API and it is only semi-public. You must apply for the Maxon Registered Developer Program to get access. The Drawport API is all about hardware acceleration. This is a fairly specific question, but I think there are no functions for hardware accelerated color management in that API, it is mostly about drawing things and writing shaders.

The Image API (e.g., the color management article I linked to above) and our OCIO impl. (which is part of the Image API) can both run on the CPU and GPU. E.g., for color data conversions, you can request a GPU handler with ColorProfileConvertInterface::GetGpuHandler but that is implemented in a non-public framework, the image_gpu.framework. It might be enough to call ColorProfileConvertInterface::InitGpu on the generic reference, but I would have to try that out myself or read some code to confirm that.

For OCIO it is a bit better, because with the newly exposed OcioConfigInterface and OcioProcessorInterface you can deliberately could construct a GPU processor via OcioProcessorInterface::GetGpuHandler. But I did not yet get to documenting all these newly exposed interfaces in code examples.

But generally I would put a bit into question how sensible it is to use the GPU for color conversions, unless you do this on a truly large scale.

Cheers,
Ferdinand

[T1001]

Hi, thank you for the detailed explanation!

• I'm aware of HDR display capabilities, including 10-bit per channel output (and in some setups, 12-bit or 8+2 FRC displays).
• I also understand that using GPU APIs like OpenGL or DirectX, it’s possible to display HDR images and perform real-time tone mapping from 32f float data.
• While I realize that Cinema 4D's standard UI (e.g., GeUserArea) doesn't currently support HDR/OCIO display workflows out of the box, I’m exploring the idea of integrating a custom OpenGL pipeline into a plugin (e.g., within a GeDialog), to handle float texture rendering and tone mapping myself.

Do you have any suggestions or best practices for integrating this kind of GPU-accelerated image display pipeline in a plugin?
Any insight into safely embedding an OpenGL context, or managing drawing inside a GeUserArea-backed dialog window, would be appreciated.

Thanks again for your support and insight!

[ferdinand]

Hey @T1001,

I am still not 100% sure how you all mean that. But in short what you are doing is not possible in the public API and also only to some degree in the internal API. First of all, Cinema 4D only supports HDR in the viewport and it must be enabled by the user:

I.e., viewport effectively means Drawport API. What the docs write there about the only the viewport is only semi true, because you can embed a drawport into a GeDialog (but that functionality is still not even semi-public I think, but we could change that in a future release).

I am not quite sure what you mean by 'integrating a custom OpenGL pipeline into a plugin'. When I take this at face value, I would say you cannot do this. The Drawport API is an abstraction around effectively Vulkan and Metal. We do not write OS specific graphics API code anymore. This goes as far as that we have (sort of) our own shading language (MSL). You cannot just draw with OpenGL into a GeDialog, because that dialog will not be drawn with OpenGL and we also do not offer a direct access point to drawing handlers.

I assume this all has something to do with implementing some kind of render buffer? I really would recommend then applying for the Maxon Registered Developer program to get access to the Drawport API. Just as a warning ahead, the Drawport API is not totally undocumented but not documented to the same degree as our fully public API. It is an API from graphics API experts for graphics API experts. You seem fairly knowledgeable there, so this might be just your thing, but you have been warned, there will be less hand-holding there.

Cheers,
Ferdinand