ColorField/ColorDialog and GeUserArea – Color Space Questions

lasselauch

Hi SDK Team,

we're currently developing a plugin that uses GeUserArea to display color swatches that users can sample with the ColorField's eyedropper. We've encountered some color space behaviors we'd like clarification on.

Issue 1: GetColorField returns LINEAR, DrawSetPen expects sRGB

When using a ColorField with a GeUserArea:

# Get color from ColorField - returns LINEAR
field_data = self.GetColorField(self.ID_COLOR_FIELD)
linear_color = field_data['color']

# Draw in GeUserArea - expects sRGB
self.DrawSetPen(linear_color)  # WRONG - appears too dark!

# Correct approach:
srgb_color = c4d.utils.TransformColor(linear_color, c4d.COLORSPACETRANSFORMATION_LINEAR_TO_SRGB)
self.DrawSetPen(srgb_color)  # Correct!

Question 1:

Is this the intended behavior? Should we always convert LINEAR→sRGB when drawing colors from ColorField/ColorDialog in a GeUserArea?

Issue 2: Eyedropper Roundtrip Doesn't Preserve Saturated Colors

We've noticed a more significant issue when using the ColorField's eyedropper to sample colors from our GeUserArea:

Test Case

Draw a pure red square in GeUserArea using DrawSetPen(Vector(1.0, 0, 0)) (sRGB)
Use ColorField's eyedropper to sample that red pixel
GetColorField() returns a LINEAR value
Convert back with linear_to_srgb() and draw the result

Expected Result

The sampled color should match the original: sRGB (1.0, 0, 0)

Actual Result

Purple (less saturated): Works correctly - roundtrip preserves the color
Pure Red/Green/Blue (saturated): Fails - the result appears darker/desaturated

The LINEAR value returned seems incorrect for highly saturated colors, causing the sRGB conversion to not match the original. That's why the user need to be advised to sample colors in "Raw" mode?! But then again, it's not working in all cases.

Reproducible Demo

We've attached a demo script (color_space_demo.py) that demonstrates this. It shows:

Test color squares (RED, GREEN, BLUE, PURPLE) drawn with known sRGB values
A ColorField to sample those colors
The result after LINEAR→sRGB conversion
The actual LINEAR and sRGB values for comparison

Question 2:

Is there a known issue with the ColorDialog eyedropper and color space conversion for saturated colors? Or are we missing something in our approach? Clearly I'm a little lost at this point.

Environment

Cinema 4D 2025+
macOS and Windows

Attached Files

color_space_demo.py - Runnable demo in Script Manager showing both issues

Thanks for any clarification!

→ Video: color_space_demo.py

→ color_space_demo.py

ferdinand

Hey @lasselauch,

Thank you for reaching out to us. The issue is likely that you do not respect OCIO color management in your document. You have marked this posting as S26, but my hunch would be that you are using a newer version of Cinema 4D and an OCIO enabled document. The first implementation of OCIO showed up with S26 in Cinema 4D, although it was just some internal systems then such as the flag DOCUMENT_COLOR_MANAGEMENT_OCIO and user facing systems arrived with 2024 the earliest I think. In Python, you can only truly deal with this in 2025.0.0 and higher, as that is when we added the OCIO API to Python.

When you indeed are testing this on an S26 or lower instance of Cinema 4D, the major question would be if DOCUMENT_LINEARWORKFLOW is enabled or not. Because you cannot just blindly convert colors.

Is this the intended behavior? Should we always convert LINEAR→sRGB when drawing colors from ColorField/ColorDialog in a GeUserArea?

The question would be what you consider here this ;). But if the question is if it is intended behavior for a scene with DOCUMENT_COLOR_MANAGEMENT_BASIC and DOCUMENT_LINEARWORKFLOW enabled, to have all its scene element and parameter colors expressed as sRGB 1.0, then yes, that is the major gist of the old linear workflow. It is also intended that drawing happens in sRGB 2.2 up this day.

Issue 2: Eyedropper Roundtrip Doesn't Preserve Saturated Colors

Generally, multi question topics tend to become a mess (which is why we do not allow them). But in short: While roundtrips in the form of sRGB 1.0 -> sRGB 2.2 -> sRGB 1.0 are not absolutely lossless (you are always subject to floating point precision errors), there is no giant loss by default. I am not sure what math TransformColor is using explicitly. A simple pow(color, 2.2) and pow(color, 1/2.2) are the naive way to do this and the loss would be rather small. TransformColor might be respecting tristimulus weights which is a bit more lossy but still in a small range.

OCIO roundtrips on the other hand are generally quite lossy, because ACEScg is a very wide gamut color space and converting from ACEScg to sRGB 2.2 and back can lead to significant losses in saturated colors. Some conversion paths in OCIO are even irreversible in a certain sense (depending on what color spaces you have assigned to which transform). OCIO is rather complicated to put it mildly.

Is there a known issue with the ColorDialog eyedropper and color space conversion for saturated colors?

Not that I am aware of. But you likely just ignored OCIO. And while the default OCIO Render Space of Cinema 4D (ACEScg) is in a certain sense similar to sRGB 1.0 for low saturated colors, it diverges significantly for highly saturated colors. So, your loss of saturation is likely stemming from treating an OCIO document with an ACEScg render space as sRGB 1.0.

See also:

Last but not least, I attached an example of what you are trying to achieve, get a color from a color gadget in a dialog and draw with it faithfully in your own user area.

Cheers,
Ferdinand

"""Demonstrates how to correctly draw with OCIO colors in a dialog.

This examples assumes that you are using Cinema 4D 2025+ with an OCIO enabled document. It will also
work in other versions and color management modes, but the point of this example is to demonstrate
OCIO color conversion for drawing in dialogs (more or less the same what is already shown in other
OCIO examples in the SDK).
"""
import c4d
from c4d import gui

class ColorArea(gui.GeUserArea):
    """Draws a color square in a custom UI element for a dialog.
    """
    def __init__(self):
        self._color: c4d.Vector = c4d.Vector(1, 0, 0) # The color to draw, this is in sRGB 2.2

    def GetMinSize(self):
        return 75, 20

    def DrawMsg(self, x1: int, y1: int, x2: int, y2: int, msg: c4d.BaseContainer) -> None:
        """Draw the color of the area.
        """
        self.OffScreenOn()

        # Draw the color.
        self.DrawSetPen(self._color)
        self.DrawRectangle(x1, y1, x2, y2)

class ColorDialog(gui.GeDialog):
    """Implements a dialog that hosts a color field and chooser as well as our custom color area.
    
    The colors in the color field and chooser are in render space, so we have to convert them to sRGB
    for correct display in our user area. All three color widgets are kept in sync, i.e., changing one
    updates the others.
    """
    ID_DUMMY_ELEMENT: int = 1000
    ID_COLOR_CHOOSER: int = 1001
    ID_COLOR_FIELD: int = 1002
    ID_COLOR_AREA: int = 1003

    SPACING_BORDER: int = (5, 5, 5, 5)
    SPACING_ELEMENTS: int = (5, 5)
    DEFAULT_FLAGS: int = c4d.BFH_SCALEFIT | c4d.BFV_SCALEFIT

    def __init__(self) -> None:
        """Initializes the dialog.
        """
        # Reinitializing the color area each time CreateLayout is called, could cause loosing its
        # state when this is an async dialog docked in the UI and part of a layout, as CreateLayout 
        # can be called more than once when a dialog must be reinitialized on layout changes. So, 
        # doing it in __init__ or guarding it with a check if it is already created in CreateLayout 
        # is better.
        self._color_area: ColorArea = ColorArea()

    def CreateLayout(self) -> None:
        """Called by Cinema 4D to populate the dialog with elements.
        """
        self.SetTitle("Dialog Color OCIO Demo")
        # Using the same ID for dummy elements multiple times is fine, using IDs < 1000 is often
        # not a good idea, as Cinema 4D usually operates in that range, and therefore an ID such 
        # as 0 can lead to issues (0 is AFIAK not actually used but better safe than sorry).
        if self.GroupBegin(self.ID_DUMMY_ELEMENT, self.DEFAULT_FLAGS, cols=1):
            self.GroupBorderSpace(*self.SPACING_BORDER)
            self.GroupSpace(*self.SPACING_ELEMENTS)

            # Add a color chooser and a color field.
            self.AddColorChooser(self.ID_COLOR_CHOOSER, c4d.BFH_LEFT)
            self.AddColorField(self.ID_COLOR_FIELD, c4d.BFH_LEFT)

            # Add our user area to display the color.
            self.AddUserArea(self.ID_COLOR_AREA, c4d.BFH_LEFT)
            self.AttachUserArea(self._color_area, self.ID_COLOR_AREA)
            self.GroupEnd()
        return True

    def InitValues(self) -> bool:
        """Called by Cinema 4D to initialize the dialog values.
        """
        self.SetColors(c4d.Vector(1, 0, 0))
        return True

    def SetColors(self, color: c4d.Vector, doc: c4d.documents.BaseDocument | None = None) -> None:
        """Sets the colors of all color widgets to the given render space #color.
        """
        # Just set the two color widgets first, as they expect render space colors.
        self.SetColorField(self.ID_COLOR_CHOOSER, color, 1.0, 1.0, c4d.DR_COLORFIELD_NO_BRIGHTNESS)
        self.SetColorField(self.ID_COLOR_FIELD, color, 1.0, 1.0, c4d.DR_COLORFIELD_NO_BRIGHTNESS)

        # When the call did not provide a document, use the active document.
        if not isinstance(doc, c4d.documents.BaseDocument):
            doc = c4d.documents.GetActiveDocument()

        # Check in which color mode the document is. Explicit OCIO color management exists in this 
        # form since S26 but it really only took off with 2025.
        isOCIO: bool = False
        if (c4d.GetC4DVersion() >= 2025000 and
            doc[c4d.DOCUMENT_COLOR_MANAGEMENT] == c4d.DOCUMENT_COLOR_MANAGEMENT_OCIO):
            # All colors in a document are render space colors (including the color fields in 
            # dialogs). GUI drawing however still happens in sRGB space, so we need to convert
            # the render space color to sRGB for correct display. For that we need a document
            # because it contains the OCIO config and the converted which is derived from it.
            converter: c4d.modules.render.OcioConverter = doc.GetColorConverter()

            # Transform a render space color to sRGB space (there are other conversion paths
            # too, check the docs/examples on OCIO).
            color: c4d.Vector = converter.TransformColor(
                color, c4d.COLORSPACETRANSFORMATION_OCIO_RENDERING_TO_SRGB)
            
            isOCIO = True
        elif not isOCIO and doc[c4d.DOCUMENT_LINEARWORKFLOW]:
            # For non-OCIO documents (older than S26 or DOCUMENT_COLOR_MANAGEMENT_BASIC), the scene
            # element color space ('render space' in OCIO terms) can either be sRGB 2.2 or sRGB 1.0
            # (linear sRGB), depending on whether DOCUMENT_LINEARWORKFLOW is set or not. In that 
            # case, we would have to convert from gamma 1.0 to 2.2. In a modern OCIO document, we
            # could also use #converter for this, but for legacy reasons I am using here the old
            # c4d.utils function. It might be better to use the converter when this is a 2025+
            # instance of Cinema 4D. #DOCUMENT_LINEARWORKFLOW is really old, it exists at least 
            # since #R21 (I did not check earlier versions), so I am not doing another version check.
            color = c4d.utils.TransformColor(color, c4d.COLORSPACETRANSFORMATION_LINEAR_TO_SRGB)

        # Last but not least, in practice you would probably encapsulate this logic in your user
        # area, similarly to how native color elements operate just in Render Space but draw in 
        # sRGB space. For dialogs (compared to description parameters), this is a bit complicated
        # by the fact that one cannot unambiguously associate a dialog with a document from which
        # to take the color management settings. A custom GUI of a description parameter can
        # always get the node it is hosted by and its document. For dialog GUIs that is not possible.
        # So, we have to do the active document approach I showed here.

        # In a super production scenario, you would overwrite CoreMessage() of the user area or
        # dialog, to catch the active document changing, to then update the color conversion, as
        # with the document change, also the OCIO config could changed and with that its render
        # space transform.
        #
        # All in all probably a bit overkill, and I would ignore this under the banner of "who
        # cares, just reopen the dialog and you are fine". Because users will also rarely change
        # the default render space transform of ACEScg to something else.

        self._color_area._color = color
        self._color_area.Redraw()
        
    def Command(self, id: int, msg: c4d.BaseContainer) -> bool:
        """Called by Cinema 4D when the user interacts with a dialog element.
        """
        if id == self.ID_COLOR_CHOOSER:
            color: c4d.Vector = self.GetColorField(self.ID_COLOR_CHOOSER)["color"]
            self.SetColors(color)
        elif id == self.ID_COLOR_FIELD:
            color: c4d.Vector = self.GetColorField(self.ID_COLOR_FIELD)["color"]
            self.SetColors(color)
        return True

# Please do not do this hack in production code. ASYNC dialogs should never be opened in a Script
# Manager script like this, because this will entail a dangling dialog instance. Use modal dialogs
# in Script Manager scripts or implement a plugin such as a command to use async dialogs.
dlg: ColorDialog = ColorDialog()
if __name__ == '__main__':
    dlg.Open(c4d.DLG_TYPE_ASYNC, defaultw=480, defaulth=400)