color space of MODATA_COLOR

ferdinand

I think I understand now what your problem is and what you mean by 'MODATA_COLOR is always linear'.

I thought MODATA_COLOR is in computational color space which is controlled by the settings in Scene Settings Project -> COLOR MANAGEMENT, that's why I thought I can get the MODATA_COLOR's color space by an API. However, the colors values I got from MODATA_COLOR remain the same no matter if "Linear Workflow" checkbox is ticked or not [...]

Does this mean that MODATA_COLOR's value won't be affected by any scene level color space settings? It seems the color I got from MODATA_COLOR is always linear no matter if "Linear Workflow" checkbox is ticked.

The major misconception seems to be here what changing color management settings does in Cinema 4D (pre-2025 at least). As pointed out in my first answer, changing these settings does not (always) entail scene colors to be converted:

@ferdinand said:

What might here be your implicit question, is that nothing happens when you switch a scene. I.e., you have a scene that has been created with Basic color management with linear workflow turned off, and you now turn linear workflow on. This just changes in which color space scene color data is interpreted, it does not convert scene colors. For OCIO later then we created the scene color conversion functionality, which among other places is accessible as SceneColorConverter in the API.

When you toggle a scene between linear workflow on and off, literally nothing will happen to all the color parameters in it. What will change, is how Cinema 4D will bring colors in and out of that scene, i.e., what color value is written when the user picks a color in sRGB-2.1 space in a color picker, how a texture is converted before rendering, and how the final render data is then converted into an output bitmap.

Existing colors stored in a scene, are then just reinterpreted as colors in that new color space. Reinterpreted Iin the sense as that when they or their byproducts must be converted into other color spaces for display or file output, they will be treated as colors of that newly set color space (although their numerical values have been defined for a different space before). I.e., they effectively become different colors. That is not the most sensible thing from a modern OCIO perspective, but that is how 'Basic' mode worked.

With 2024 we then introduced OCIO, which had the same behavior, changing to OCIO or the render space in OCIO would not automatically entail a scene color conversion. But we added the option to do that (the backend is the mentioned SceneColorConverter). With 2025 this now has changed and all render space changes also always entail a value conversion.

So, this is first of all not bound to MODATA_COLOR and would apply to all color values in a scene. And when the scene is in Basic + NO LWF mode and your render texture uses an sRGB-1.0 profile, you would have to convert that color from sRGB-2.1 to sRGB-1.0, when the scene is in OCIO mode, you would have to convert from render space to sRGB-1.0. And when then scene is in Basic + LWF mode, you would not have to do anything at all.

To my knowledge there is currently no exception in the MoGraph code which would always treat MODATA_COLOR as linear (if anything there could be an extra transform applied, but I am not ware of any in that case). When you still encounter a mismatch between your render engine output and our viewport, please reach out to us. It would then probably easier if you just show me.

Cheers,
Ferdinand

BruceC

Thank you very much, @ferdinand

I think I start understanding it now.

The MODATA_COLOR values existing in the scene won't get changed by the scene's color space settings, instead, they could be interpreted differently when scene's color space setting changes.

In the scene I'm testing, the MODATA_COLOR comes from a Linear Field (doesn't necessarily be Linear Filed, it could be other Filed types, like Box Filed, Capsule Filed) of Plain effector's Fields setting. The MODATA_COLOR values are not real colors, they are used to find the texture for each instance from a Multi Shader's setting.
So I think in this case, it could be safely assume the data is linear values?
If this is true, is there is a way to find if a MODATA_COLOR from a Field? So I can make sure MODATA_COLOR from Field are treated as linear values.

Thanks!

BruceC

Hi @ferdinand, thanks for all you help.
I think a cloner's MODATA_COLOR should be interpreted if the cloner uses Multi Shader. Is my understanding correct?

ferdinand

Hey @BruceC,

So I think in this case, it could be safely assume the data is linear values?

Normally, there should be no assumptions, the data should just be what the color management says. But I now replicated your field driving colors setup, and I too stumbled upon something which I cannot explain, at least at the moment.

I would really recommend sharing a scene file with us, and a more formal issue report (see Support Procedures: Reporting Bugs and Crashes). Feel free to also use your render engine in the file(s), we have licenses, but you always have the best chances of help, when you can isolate an issue down to the core API.

And while I understand that you want to support many versions, you should also establish a concrete version of Cinema 4D you are using for testing.

Cheers,
Ferdinand

BruceC

Thank you very much, @ferdinand
Yeah, in the video you attached, it looks to me that Linear workflow doesn't affect the final render result.

I have got the approval to attach this simple test scene that demonstrates the problem I'm experiencing. The setting is a bit different with your scene.

The scene attached uses Multi Shader. My understanding is that the MODATA_COLOR from the effector field is used to find which texture defined in the Multi Shader should be applied to each cloned instance. (so the MODATA_COLOR values are more like texture indexes). So the MODATA_COLOR values are not really used as colors in the viewport, and shouldn't be treated as gamma-corrected values regardless of the scene's color space.
Please let me know if my understanding is correct. Thanks again!

ferdinand

Hey @BruceC,

thank you for the scene. Just as an FYI, you can always share data confidentially with us via sdk_support(at)maxon(dot)net. In general, we encourage all users, including Maxon Registered Developers, to discuss problems in public, so that the whole community can benefit. But for sensitive topics there is of course always the option to switch to mail.

Regarding your scene file:

Could you please share the exact version you are using for testing. As I said, I am aware that you want to target multiple versions, but for bug reporting we should have a precise version, so that I can look at that exact version.
Please also provide a bullet-point step-by-step bug report as lined out before. See Support Procedures: Reporting Bugs and Crashes for details. Our insistence on these bug reports might seem a 'unnecessary' from the user side, but they really make a world of difference, when you try to debug something as complex as Cinema 4D.

Cheers,
Ferdinand

PS: I am a bit busy with the new C++ SDK at the moment, I will probably only get to having a closer look at this by the 27th.
PPS: What I forgot to mention, is that it could also be the Picture Viewer itself which is here interfering (i.e., the actual bitmap saved to disk is okay, the PV is just displaying it incorrectly. We had a few issues with the PV and OCIO over time).

BruceC

Thanks, @ferdinand

I think it's easier to reproduce this problem with C4D 2024 (say 2024.5.1).
I don't think this is a bug with C4D. It's a problem with our plugin about how to use C4D MODATA_COLOR from the effector field for Multi Shader in our Render Engine. The viewport always has the expected correct result, it's our plugin who doesn't produce the expected result.

With more and more thinking and testing, I began to believe that in the scene attached the MODATA_COLOR from the effector field is used to find which texture defined in the Multi Shader should be applied to each cloned instance. (so the MODATA_COLOR values are more like texture indexes). So the MODATA_COLOR values are not really used as colors in the viewport, and shouldn't be treated as gamma-corrected values regardless of the scene's color space.

If my above understanding is correct, I think our plugin just need to treat the MODATA_COLOR values in this particular case the same way as C4D viewport. Currently, our plugin convert the MODATA_COLOR values from linear to srgb based on the scene's color space, which I think is incorrect, because I think the MODATA_COLOR values are not real colors in this case.

ferdinand

Hey @BruceC,

Thank you for the added information, but I will still need that step by step bug report. Without it, I will not touch a debugger or a scene file. There are a plethora of reasons why this could go wrong. I am still very much in the dark at what you are looking exactly (e.g., are you using our Picture Viewer to view render results, or do you use your render engines one. What are your rendering and how, etc., pp.).

As I told you, applying a manual transform is not intended. It might be what you have to do as a work-around for older versions which we won't (hot)fix anymore, but there is no default answer here for you. But for all of that I first need a reliable bug/issue report which I can reproduce, and then other than you look at with a debug version of Cinema 4D. As I said, feel free to use your render engine, and please be precise in the reproduction steps. If you want to, you can also use our beta program bug tracker instead (since you are an MRD).

Cheers,
Ferdinand

ferdinand

Hey @BruceC,

I almost forgot this thread, but as a reminder: I will need that bug report as lined out before in this thread, see Support Procedures: Reporting Bugs and Crashes for details. You are of course free to explore other routes, but we can only start working when we have a concrete bug report for how to reproduce things.

Cheers,
Ferdinand

BruceC

Thank you very much for following up with this, @ferdinand.
At the moment, we are fairly confident about the way of fixing this issue after all the above discussion.
But I'll reach out with a bug report (even though I don't think this is C4D bug) for further information.