I’m working on a project where the product is made of oak wood. The client requires the final output in PNG with the Adobe RGB 1998 color profile for maximum gamut and subsequent printing. However, the wood textures are JPG files with an sRGB color profile.
To make the VFB save the final render in Adobe RGB 1998, I disabled “Use Cinema 4D color space” in the preferences. I’m using a high-quality monitor set to the Adobe RGB 1998 color profile. But now the wood colors render with a reddish tint.
If this issue is caused by an internal incorrect conversion from the sRGB texture profile to Adobe RGB, I assume the same problem would apply to all textures and 3D models from the COSMOS library. Is that correct?
How do I save an Adobe RGB image without shifting the colors of sRGB textures?
If its only a technical requirement for print then in photoshop just go to Edit > Convert to Profile > Adobe1998.
If you are editing your image in that color space then render as .exr then set your profile for the document then bring in your rendered image and do your editing/corrections.
No need to convert your textures.
If your textures turned a bit red that means you have assigned a profile instead of converted to profile. Dont do this, sRGB is a smaller space than Adobe and thus should look exactly the same once converted.
I don’t use the Cinema 4D color space because in this mode there is severe “clipping” of dark tones. Shadows that should be, for example, gray become almost black. On the other hand, lighter tones tend to appear white more often.
For the wood I’m using a texture in JPG format with an sRGB profile. When the Cinema 4D color space is disabled, Corona natively saves outputs such as PNG in Adobe RGB 1998, and this is exactly where an internal color shift occurs, pushing the wood colors toward red tones.
I would expect CORONA to perform the necessary internal conversions so that this does not happen. It’s very frustrating when I want to take advantage of the color space that CORONA uses, but then end up with output that significantly alters some textures—such as wood or vegetation textures.
I am not sure about how C4D handles things. From the Corona docs it shows a screenshot with “Use Cinema4D color space” enabled. I assume this is how Corona performs its “necessary internal conversions”. Dev’s could clarify.
This sounds related to having the Cinema 4D color space is disabled. From the sounds of it you are assigning a profile, thus shifting the colors. I could be wrong but hard to tell since I just stick with the Gamma workflow and then edit linear images in Adobe 1998 for print.
The Corona documentation states that the rendering calculation is processed in a wide gamut. I believe this gamut is even wider than Adobe RGB 1998. Thanks to this, it covers a wide range of hues as well as dark and bright color values. In this way, by disabling the use of the Cinema 4D Color Space, it is possible to avoid overly dark areas of an interior, for example.
It is probably necessary to manually convert textures to Adobe RGB 1998, which is not a problem when dealing with visualizations of a single product, but it becomes impractical when importing 3D models from the COSMOS library and similar sources.
Are you using C4D 2026? Reading the Maxon docs it says that they have changed the default to ACES, which could be “Use Cinema4D color space” enabled. If so, you are correct in disabling it in this case (if your intention is not to use ACES), again not sure - cant find this info, its just an assumption.
This is an internal calculation, it has no affect on which color management settings you set.
I dont see why, what’s the issue with working with linear exr images, then adjusting the final product in Adobe 1998 (in your post software of choice)? You can go straight from linear RGB (Rec.709) to Adobe without bothering with converting textures as per this Maxon exr guide, unless you have a different intention?
Just to clarify things a bit, since its a bit of a lengthy topic I got chatgpt to summarize the workflow - and basically my thoughts on the matter explained better than I could (if this helps):
Short answer: yes, the 32-bit linear EXR contains far more usable range than Adobe RGB (1998)—but only if you keep it in a 32-bit / scene-referred workflow. Once you convert into Adobe RGB, you throw most of that range away.
Here’s the breakdown.
What a 32-bit linear EXR in Rec.709 actually holds
A 32-bit float EXR is:
Scene-referred
Linear light
Effectively unlimited dynamic range (values <0 and >>1 are allowed)
Typically capable of 20–30+ stops of highlight/shadow detail
The Rec.709 primaries only define the gamut (chromaticity), not the dynamic range.
So even though Rec.709 is a “small” gamut:
You can have values like:
0.001 (deep shadows)
1.0 (diffuse white)
50, 100, 1000 (specular highlights, sun, etc.)
Dynamic range lives in the floating-point values, not the color space.
What Adobe RGB (1998) actually is
Adobe RGB (1998) is:
Display-referred
Gamma-encoded (~2.2)
Limited to 0–1
Typically 8–16 bits per channel
Roughly 8–9 stops of practical dynamic range
Even at 16-bit, Adobe RGB:
Cannot store values above 1.0
Clips highlights
Compresses shadows
Is not designed for HDR or scene-linear data
Adobe RGB has a slightly larger gamut than Rec.709, but vastly less dynamic range than a 32-bit EXR.
What happens when you convert EXR → Adobe RGB
When you move from:
32-bit linear EXR → Adobe RGB (1998)
You are:
Tone-mapping (explicitly or implicitly)
Clipping or compressing highlights
Baking in contrast
Destroying recoverable HDR information
After this conversion:
You cannot recover blown highlights
You cannot re-expose linearly
You’re working in a display-referred space
So yes:
You absolutely have more range in the EXR than Adobe RGB for post
—but only before that conversion.
The important subtlety: gamut vs range
People often conflate these:
AspectEXR (Rec.709 Linear) Adobe RGB (1998)
Gamut Smaller Slightly larger
Dynamic range Massive (HDR) Limited (SDR)
Encoding Linear Gamma
Values >1.0 Yes No
Scene-referred Yes No
If your work involves:
Relighting
Exposure adjustment
Highlight recovery
Compositing
Physically based renders
EXR wins decisively, even with Rec.709 primaries.
Best-practice workflow
Correct approach:
Render to 32-bit linear EXR
Do all heavy grading, exposure, comp, and relighting in:
Linear
ACEScg or scene-linear working space
Convert to Adobe RGB / sRGB / Rec.709 only at final output
Avoid:
Editing EXRs in Photoshop after converting to Adobe RGB early
Doing major exposure work in display-referred space
This color shift is already noticeable during rendering. That means that even while setting up the scene and creating previews, the VFB already shows this color shift.
To avoid any distortion, I even bought a high-quality BenQ SW272U monitor that is capable of displaying Adobe RGB 1998. So it will probably not matter whether I save the output as EXR or 16-bit PNG, because the color shift apparently already occurs during the conversion of textures for the rendering calculation.
Moreover, I cannot properly set up a wood material if the VFB shows colors that differ from what the wood texture is supposed to look like. I will definitely try working with EXR, though. Thanks for the tip.
No worries, yes we use those damn expensive Eizo monitors for the same purpose, calibrated every 30 days. However our workflow is get the render 90% there, then do all color corrections in Adobe 1998 tiff for print and convert to sRGB jpg after for Displays. Also when doing things for film, tv, advertising we have a colorist who has these fancy monitors and what not but all he needs is 32bit linear exr files and hes good.
Regarding the color shift, not sure of your setup or how C4D works but sounds like something has gone a miss somewhere. Or there is a software limitation Im not aware of in your particular situation.
Where are you doing the texture conversion, and why?
Dynamic range lives in the floating-point values, not the color space.