Project Settings
Real units
In previous Releases of Cinema 4D (prior to R12), no real units of measure were present. Although you could enter the unit "mm", this had no meaning for Cinema 4D.
This has changed in R12: a unit of 1 meter is now equal to 100 centimeters and 1 kilometer equals 1000 meters, and so on. Hence, if you change your units of measure from, for example, Meter to Centimeter, a cube 2m wide will then be displayed as being 200cm wide. The values will be converted automatically if the Use Units option is enabled.
In combination with (internal) double precision (which was increased from 32-bit to 64-bit with R12), rounding errors are a thing of the past, which means that you can model 2mm wide specks of dust and then switch to Kilometers and model a huge building in which they lie. Cinema 4D can handle this with no problems at all.
It is also possible to, for example, load objects modeled in Millimeters into a scene that contains objects modeled in Meters. The units will be converted automatically.
You can define units of measure within Cinema 4D at these locations:
- In the Preferences menu: This setting does not affect scene parameters. Only the units displayed in the respective fields will be converted. If, for example, a value of 3 cm was defined and you switch to Meters, the field will then display a value of 0.03 m (or 0.033 yd).
- In the Project Settings: Depending on what has been defined, the scaling of the scene can in fact be modified. A 200 cm wide cube (Document Scale: Centimeters) will be 200 m wide if you switch to Meters.
Scale document
This is the most important parameter with regard to units of measure. It defines how the numerical value saved within the file will actually be interpreted - 3 meters, 3 kilometers or 3 yards, for example? A new, empty scene will always use the Project Settings’ default values. You should determine the units of measure you want to use from the very beginning of your project. Simply orient yourself to the actual scale of the objects you are creating in 3D. For example, a house would be modeled in Meters, the inner workings of a watch in Millimeters and a mountain range in Kilometers.
. You can, of course, change the Document Scale at any time if you are working with very large and very small dimensions in a single scene.
When scenes created in older versions of Cinema 4D or objects from external applications are imported into Cinema 4D they often do not have the correct units of length or none at all. This command can be used to scale the scene to the correct size.
Let's say you have imported a hexagon bolt created in IGES with an unknown scaling. You know it's supposed to be an M6 bolt and the document is set to the default Centimeter scaling. All you have to do is select two opposing points on the hexagon bolt and define the interval between them (values can be seen in the Coordinate Manager).
Assuming both points lie 0.18 cm apart, the following values have to be entered to scale the scene correctly:
This value defines the frame rate for the current document. This value will be applied to all animations create with this scene.
This is the time (frame) at which the Timeslider is currently positioned.
Defines the starting point of the animation tracks. This can also be a negative value, e.g. for initiating a particle stream prior to the begin of an animation.
Defines the end time for animation tracks.
These values represent the start and end time of the preview range displayed in the Animation Toolbar. These values can be modified by double-clicking on the areas shown in the image above.
This value affects how each scene object for which a specific level of detail can be selected is displayed. Such objects include all Primitives, Metaballs or all Generator objects.
The level of detail can be reduced evenly, independently from an individual object's level of detail.
If this value is set to 100% all objects will be displayed in full detail (in accordance with the value defined in the object's parameters).
If this value is reduced to 50% all scene objects will be displayed with only half the number of lines in the Viewport.
The value defined in the Render Settings will be applied and the value defined by the LOD will be ignored.
These four options have the same effect as those in the main Cinema 4D menu. Details regarding how they work can be found here.
Disabling this option will disable the Motion System. Alternatively, the Motion System can be disabled in the main Cinema 4D menu.
Here you can create a color that will be assigned to all objects that do not have a material assigned. 80% Gray is the color used by Cinema 4D versions prior to R12.
If faulty depictions, as shown at left, result you should use a different Clipping region.
Due to the fact that it is possible to work in very large dimensions (e.g. kilometers) or in very small dimensions (e.g. nanometer), the display (only affects this display - the rendered display remains unaffected) can be a little strained (the Z buffer has a limited resolution and at some point can no longer discern which polygons lie behind other polygons, which results in poor display quality).
In this case you can define a Clipping region. Outside of this region (calculated from the point of view of the camera) the display will be cut off. Within the region the display will always be correct (the Near and Far values should not differ too much).
Select a region from the selection menu or do so manually via the Near and Far values, respectively.
The settings in this section define how input colors are interpreted and how rendered colors are displayed or how they are passed to an image file. With the introduction of Version 2023.0.0 the OpenColorIO (OCIO) color management system is available, which makes, among other things, ACES color spaces available. This makes a comprehensive, cross-application color management possible.
If you prefer not to use this or want to know how colors are displayed unchanged in older projects you can continue to use the linear Workflow of older Cinema 4D versions.
Color management can be quite overwhelming and is under continuous development. If you want to learn more about the basics, you can find an overview here. The following explanations cover the actual settings and modes as they are available in Cinema 4D.
At the top of the image you can see the Basic mode that is offered by older versions of Cinema 4D, including the linear workflow. At the bottom is the newly integrated OCIO color management system, which also makes it possible to work with loss-free ACES color spaces.
- Basic: In this mode, no expanded color management via OCIO (OpenColorIO) is available. Activating Linear Workflow lets you also use a linear color space here, which can be used to display differentiated lights and shadows. This is the default mode, which is also offered in older versions of Cinema 4D. How colors, for example of textures, should be handled that may not have an embedded color profile can be defined by the Input Color Profile option. Details about this mode can be found here.
- OpenColorIO: The OpenColorIO system is included with Cinema 4D and contains all components needed for professional and cross-application work with colors. Also included is the ACES color coding system, which makes it possible to work with continuous, loss-free color spaces. Activate this option to get the best possible quality with regard to saving and color adaption for archiving images and passing them to other applications.
If the OpenColorIO system is enabled for color management, this option lets you quickly define the primary direction your project should take with regard to color management - sRGB or ACES. Your project will be based on the OCIO color spaces. Considering the fact that post-production pipelines can easily have a dozen sRGB conversion varieties with different gamma values, different black point compensation and different methods (e.g., Bradford), you can put aside any doubts you may have and put your complete faith in this mode. It's good to know that your material is in good hands in an OCIO-managed pipeline. However, this only applies if everyone else who is working on this project also knows which settings have been made.
If you select sRGB, the render space will be scene-linear Rec. 709-sRGB. This color space offers a linear color space with float comma precision that is also the standard for computer monitors and HDTV.
If you select ACES, the color space will be ACEScg by default. This is not as comprehensive as ACES2065-1 but only uses positive values and is therefore easy to work with for many post-production tools. Additional information with regard to render space can be found further below on this page.
Comprehensive explanations of the different and varied color spaces can be found in the section that covers render spaces.
After installing Cinema 4D you can start working right away because OCIO will also be installed automatically, including all necessary components. So why is there a separate set of parameters for this?
The basic concept of OCIO is that your OCIO environment for various applications is at a central location, i.e., you only have to have it installed once. This makes it easier to update and manage individual OCIO settings. For example, instead of having to make sure that a large number of applications in your post-production pipeline have the same OCIO basis you only have to worry about one central OCIO installation, which is then used as a uniform basis for the various applications.
By entering $OCIO it will be used in an existing $OCIO environment path. As soon as a configuration is loaded, the following drop-down menus with the available color spaces and transformations will be filled out.
If you do not want to use your own OCIO installation with Cinema 4D you can use the default path used here.
Schematic stations of an OCIO color management. If the initial information is only used for the final output or only for temporary control purposes, the entire post-production and the archiving of the image material in the original quality will also take place in the color space of the rendering.
Input Information
As explained in the image above, you have to clearly define how colors, shaders and textures should be interpreted within the color management system. In each Color chooser you have the option of switching to the color space in which the color values should be interpreted. The same applies for the Bitmap shader and the Redshift Texture Sampler, as well as for special shaders such as the Vertex Map shader and the MoGraph Color shader.
This is the space in which your colors and your light lie. As a rule, this is a safe place for your colors as long as each part of the color pipeline works well.
The difference between Basic color space conversion and converting to OCIO
You can use a simple example to see what issues can arise when converting color spaces. To do so, open Photoshop, create an 8-bit per channel file in sRGB and then create a colorful gradient.
Display and histogram of a color gradient in sRGB color space in Adobe Photoshop. This will be used as the basis for both of the following conversion options to a new color space.
Now go to Edit>Convert to Profile. Display the histogram on your monitor. Select the option ProPhoto and keep an eye on the histogram when you click on OK. The color gradient will look unchanged but all values of the image will have changed in order to successfully convert to the new color space for your monitor.
The result after converting the sRGB gradient to a larger ProPhoto color space. As you can see in the histogram, the colors no longer take up the entire available value range but were converted in such a way that they look as identical as possible in the new color space.
Now undo the above and this time select Edit>Assign Profile>ProPhoto and keep an eye on the image. The colors are even shifted in the preview mode. The color values will be adapted to the larger color space. This would be an example for a false color profile management. This quick example gives you a good foundation for the following explanations if you should be completely new to this topic.
After the ProPhoto color space has been assigned to the original sRGB color gradient, the histogram will remain unchanged but the new interpretation of the colors will change the display of the color gradient.
Convert Render Color Space
This is exactly the principle that we demonstrated above. Color values used in the interface will be converted in such a manner so they appear unchanged. Images and film material that are not delivered in the same color space as the project can be converted accordingly.
Note that the color management system cannot know, for example, how colors are used in a given material. Colors that are, for example, used in data channels such as bump, displacement or alpha maps will also be included in the conversion. Example: a color shader in an alpha channel.
Different options are available for converting source and target color spaces and the same five color spaces for the initial setup. If you select one of the five options while the project is already working with other color spaces, the colors currently being used in the project will be interpreted incorrectly. This is comparable with the Assign Profile option in Photoshop.
Each of the five options sets the entire project to a new color space if it comes from a different color space and the conversion was applied. Without the conversion same->same only twenty possible combinations remain. Therefore, the decision should be made so that it works along the entire pipeline in order to avoid unnecessary workflow issues. A logical and simple communication should be created. While conversions in integer format tend to clip data and thereby destroy it, float comma formats are unlikely to result in any such issues.
When you start a new Cinema 4D project, no conversion will be necessary. You will use one of the five available OCIO color spaces. These are all float comma-based and linear, and require the use of a corresponding file format in the Render Settings (e.g., OpenEXR) to maintain their level of quality.
Schematic display of several ACES color spaces in comparison to common color spaces of display devices, e.g., Rec. 709/sRGB. The color contained in ACES color spaces far exceed the colors that can be displayed by sRGB, which is why the display of colors here is purely symbolic.
ACES 2065-1
This ACES color space is considered future-safe and offers the most comprehensive color space. However, negative color components can be included with which not all other applications can deal with.
ACEScg
This color space was developed later to overcome the restrictions of common post-production applications by using only positive values. It also offers enough space for a large gamut. In accordance with the ACES convention, this should only be in the "homemade" format since the color space is smaller compared to the ACES 2065-1 format and is not compliant with the ACES format.
Scene-Linear DCI P3 D65
This format is like the gamut, which is used by the typical movie projector, whereby the white point is set to daylight. Please check which white point is required for your project since a low Kelvin value can be required. For ACES 2065-1 this would not be a question that would need to be answered during production. Current high-end laser projectors can all create colors in the Rec. 2020-defined colors.
Scene-Linear Rec. 709 - sRGB
This is the standard for HDTV and computer monitors, whereby integer numbers are used. This format was first published in 1993 and the current version BT 709-6 was introduced in 2015 and, due to its relation to sRGB, offers numerous variations, especially with regards to gamma definitions. The specification as scene linear makes an exchange much easier since all gamma variations and definitions are excluded. Therefore, both are linear and offer the same color space (gamut). In Cinema 4D, both are used interchangeably (Scene-Linear Rec 709 and Scene-Linear sRGB), based on linear float comma values. This is not the case if they are converted down to integers. For color fidelity, a linear file format on float basis is imperative. This way the number of possible color definitions is increased dramatically. These are based on values greater than 1.0, even for colors that may lie below 1.0 in larger color spaces. If converted correctly in post-production, a higher degree of color fidelity can be achieved than would be possible with 8-bit or 16-bit formats in sRGB.
Scene-Linear Rec. 2020
This color space was introduced in 2012 as the new standard for UHD (Ultra High Definition) and defines a color space that far exceeds the sRGB and DCI-P3 color spaces. Subsequently, UHD, which was erroneously labeled 4K (3840 pixels wide), was no longer the only format that was defined in Rec. 2020. The second format is 7860 pixels wide and is often labeled 8K: in any case, an aspect ratio of 16:9 is used. The standard is considered to be 19 and 12-bit/channel integer, whereby float comma, also known as scene-linear, is often preferred during production for quality purposes. The linear workflow makes it possible to more-or-less manually manipulate the color values across the entire pipeline without clipping data. This helps avoid restrictions within the pipeline.
This setting can be used to define how the color information from the scene-related (rendered) data should be interpreted for viewing on a display device (normally your monitor). sRGB is currently the only standard.
Here you will find a series of options that are used to display transformation calculations for color values from the border regions so you can evaluate your work in the Picture Viewer, for example. The available transformations are often a type of tonal correction that transform large render values to smaller display values. This can, for example, be useful to define a correct illumination. The display space and the selected display transformation together describe the output transformation.
- ACES 1.0 SDR Video This is an OCIO display function that is also used under the name of sRGB Monitor (in sections EOTF). The abbreviation EOTF stands for Electro Optical Transfer Function used in color sciences and describes the conversion function between digital color values and the brightness displayed on a display device. The result is a gamma-based sRGB dataset.
- Log Stands for Logarithmic Gamma Curve and is the preferred method used by colorists for observing and working with content. The image contrast is reduced greatly, particularly in dark and bright regions, which leads to more detail being visible.
- RawAll color values will be treated as data values, which is in particular helpful when evaluating individual multi-passes if these are used for data storage (e.g., for masks or a Z-Buffer) This mode is therefore more relevant for the Picture Viewer.
- Un-tone-mapped: Normally the view space of a display device is much smaller than the linear render space. Colors that are read out will therefore be corrected via a tonal correction so they can be displayed. Here you can deactivate this tonal correction. The color values will then be displayed unchanged and will no longer be clipped, even if they lie outside of the display color space.
You also have the option of switching the display information directly in the Picture Viewer, if you want to experiment with the different options. Also, the View Presets offer options for overwriting the display information directly in the 3D view. Furthermore, an individual overwrite can be made in the Redshift RenderView.
Here, the same options as in the display information are available that, however, can only be used for the material preview and the preview area of Nodes.
Convert to OCIO ...
If you switch from Basic to OCIO color management mode, different colors will be used. This is due to the different interpretation method for the saved colors.
- In Simple mode, colors will be interpreted in the display area. In Cinema 4D this is normally sRGB:
- In OCIO mode, colors will be interpreted in the color space (also referred to as scene-based). This is often the ACEScg or sRGB (scene-linear) color space.
The conversion between both of these interpretation methods is done explicitly by clicking on the Convert to OCIO button. Upon doing so, a new dialog window will open an which the settings for the source and target spaces are already filled in.
- Input Color Space Low: This is used as the input color space for normal colors and 8/16-bit integer images.
- Input Color Space High: This is the color space for normal colors that are contained in 16-bit/channel/float or 32-bit/channel/float images as well as all linear colors.
- Render Color SpaceThis is the target color space to which the colors should be converted..
This can take quite some time for large, complex scenes since the converter must first run through the entire scene to ascertain which colors have to be converted.
Tips, Tricks and Traps when converting to OCIO
Combining different scenes
It can happen that you have to combine external content with your scene. First, open these scenes separately and check if they match the desired color space. If not, make a copy of the scene and convert the content accordingly. Once you have everything the way you want it, save the scene with a fitting name and note the color space used. You can now add this scene to the main scene.
You also have to be careful when using XRefs. It may at first appear that the XRefs were also converted when the conversion to OCIO was done. However, when the external scene is updated or reloaded, the original color management will be visible. Here, also, you should first adapt the original external scene to the desired color space before you integrate it into your project via XRef.
Presets, e.g., for color gradients, are often only available in a single color space. If the color space does not match properly it can cause issues. As above, the contents should be converted prior to integration with your scene.
Adapting color values
The Convert to OCIO function is very powerful. However, it can't know if a given color is used to control a parameter or should be used as a visible color. An alpha channel, for example, that is controlled by color gradients or Noise shaders. The same applies to Displacement, Normal or Bump channels or the roughness of a reflection and much more.
Or imagine a Node material for which a color gradient is used to control its surface color and the roughness of its diffuse shading. It's not possible to separate these applications. The conversion will treat them the same.
The conversion should only be done once. Even though it can be repeated any number of times, this might also lead to unwanted changes in many values.
The values can also change if Render Space and Input Color Space are set to linear sRGB if the function is executed again.
Values saved in Takes will only be converted if the respective Take is active. Since only a single conversion can be made, all other Takes must be adjusted manually.
The conversion will change the color but curve elements such as the Filter shader will not be affected as to have their curves modified during conversion.
The Colorizer shader will modify neither the positions nor the interpolation of the color tabs in its gradient. Color changes are unavoidable when the input color is changed. This change can be especially dramatic if a color gradient is combined with a colorizer.
Field colors that are saved in the MoGraph cache will not be converted. The colors will change when the cache is deleted and a new cache is created (MoGraph Color shader).
The Variation shaders, for example in Polygon mode, will not change the colors upon conversion.
The Posterizer shader will calculate deviating color layers if, for example, a color gradient serves as a source.
Each Overlay mode (e.g., in a Layer shader) that works with the Midpoint definitions (overlay) will have a different result after each conversion. Other Overlay modes can react differently.
OCIO Info Area
Below the Convert to OCIO button there will be up to two types of information displayed:
"This scene may require color conversion to properly work with OCIO" or "Scene successfully converted to OCIO". This helps you to see which file has already been converted. Please note here, as described above, the list of restrictions below. If, for example, you combine a project that has not been converted with a converted file, no complete, uniform project will ensue. You will have to make manual adjustments in order to modify parts of the scene. Newly added content must be adapted to the target color space before you can integrate them into the project.
The linear workflow (a.k.a. too many Gammas)
In short
In the past years, the idea of linear workflow (in the following referred to as lin. W) has almost been turned into a mythical process that promises to work miracles. Although linear workflow cannot produce miracles it can help you produce better images quicker and with less effort.
Overexposed regions will be reduced.
The effect a lin. W has can be seen in the image above. The scene is lit using two light sources, each with inverse square falloff. The quality when lin. W is used at right is dramatically better.
Lin. W offers the following advantages:
- More harmonious dispersion of light; scene appears brighter overall
- Overexposed regions will be reduced
- More natural coloration
- Summary: more realistic dispersion of light (use of light source with physically correct inverse square Falloff are recommended).
Note that all Cinema 4D-internal material colors and color gradients will be modified directly in the preview. This can also lead to confusion because, for example, grayscale gradients will look differently than before.
The color value of 128, 128, 128 at the center of a normal grayscale gradient (Linear Workflow option disabled) will change to approx. 192, 192, 192 when this option is enabled. This behavior is correct!
For those of you who are interested in the "how and why", simply read on. Everyone else can get started with rendering more beautiful images right away.
Details
The topic gamma values and the corresponding Lin. W is a result of renderers rendering with a linear Gamma value of 1 but being fed with input (textures, shaders, etc.) with a different Gamma value (most commonly 2.2 since the introduction of macOS X 10.6; previously 1.8) even though the renderer expects a Gamma value of 1.
This results in the renderer rendering "more incorrectly" (with regard to being physically correct) than it actually should.
If you now think that you rendered below-standard for the past 10 years we can confirm this with a hearty "yes and no". If the result is what you were looking for then the rendering was successful. However, you tend to get used to how your renderer works and generally end up working around its shortcomings. If, for example, a fill light was added, which ended up changing the coloration at places and resulting in an unwanted look, this might have been avoided if Lin. W had been used.
This is also the reason that older scenes don't automatically look better if Lin. W is enabled. Older scenes were designed to work well without Lin. W. If you want to re-use older, optimized lighting configurations you should adapt these for work with Lin. W. If, however, you are satisfied with the render results there is no need to do this.
Why do gamma values exist?
Most monitors, for example, have a gamma value of 2.2. If you paint a texture in an image editing program, this image will be displayed with a gamma value of 2.2 and will be saved accordingly. Almost all images that you have created or that you will find on the internet have a gamma value of 2.2.
Only with this value will images look good on an average monitor. This has to do with the fact that images with a lower bit depth (8-bit and 16-bit) are saved in a manner that displays a brightness range that looks good to the human eye. A human eye can make out finer gradation in darker regions than in lighter regions.
A gamma corrected 8-bit image with a gamma value of 0.45 is displayed on a monitor (gamma = 2.2) with a (for the human eye) linear brightness range.
Renderers on the other hand (including the Cinema 4D renderer) work internally with linear gamma ranges (i.e. gamma =1; defined by the prevailing algorithms) and expect the same from what they display (textures, shaders, etc.). However, this wasn't so simple in the past. The renderer wants a gamma value of 1 but is given input with a gamma value of 2.2. It's natural that discrepancies with the physically correct result arise.
As soon as the renderer has finished its work the rendered image's color and brightness has to be reduced and at the same time a gamma value of 2.2. has to be applied so the image looks good when displayed on the monitor (in the image was rendered in 32-bit the gamma correction would take place and the image saved in a subsequent step).
So how does the Lin. W fit into all of this? Simple - as soon as you enable Lin. W, all elements involved in the render process (textures, shaders, etc.) will be re-calculated so the renderer sees them with the required gamma value of 1. After this correct rendering has taken place - internally, the renderer also produces images with a gamma value of 1 - the images must be converted to a gamma value befitting the display device (most often a monitor with gamma = 2.2).
That was a brief description of the reason behind Lin. W. If you want to read more about the above you can download a very informative and free .pdf file by the name "Be Gamma Correct!" by Martin Breidt (a Web search should lead you to the correct file). Don't let it bother you that the document refers to a different 3D application from Cinema 4D - the principles are the same.
The Lin. W's settings include the color space sRGB. This is somewhat comparable to the above-mentioned gamma value of 2.2, i.e. if an image is saved with a gamma value of 2.2 it most often reflects sRGB values.
Basic Color Management
General
Everyone has heard of it but only few understand what it really is, even though many books have been - and still are being - written about this topic. In the following you will find a brief introduction of the issues regarding color fastness.
Surely you are familiar with the effect of an image looking perfect on your monitor (colors are exactly as you want them to be - brightness, contrast, etc. are immaculate) but when you view the same image on your colleague's monitor or even printed out it looks completely different - mostly worse.
How does this happen?
Colleague A creates an image using an image editing program. He creates his image according to how it looks on his monitor. When finished, he saves the image - and this is where the problems start: Image editing programs have to save images with a reproducible color definition (i.e. the color profile, which is mostly RGB). Most often a color profile is selected that corresponds to the display device - for most (but not all!) monitors sRGB and for printing CMYK, etc.
This means that the red value on colleague A's monitor has to correspond to the RGB value in the image file. Colleague A's monitor must pass on the image's colors exactly how the image processing program will display the RGB values. In order to do so, Colleague A's monitor must be calibrated correctly. Over time, a monitor's color display will change and should theoretically be calibrated every 4 weeks if being used for work with real color profiles. Regular calibration is also necessary for all input and output devices such as monitors, printers, scanners, etc.
If everything has been calculated correctly, the printed image from colleague A's monitor should appear exactly the same on colleague C's monitor after being scanned in. How probable this actually is can be attested to by anyone who has actually attempted such a feat (a 100% match is in fact not possible because not all devices can convert color profiles loss-free). But at least a nearly 100% match can be achieved on different monitors when calibrated correctly.
This was a simplified explanation of the issues involved with precise color management. What is basically required is a consistent, clearly-defined color profile within the creation process from image editing to the final output of the image.
And what does all this have to do with Cinema 4D?
First the good news: If you've never heard of color management and your renderings have always met or exceeded your requirements then you can simply ignore this parameter (and leave all Cinema 4D adjustable color profiles set to their default mode sRGB). To be honest, only very experienced artists will see the difference between images created using precise color management and those created by rule of thumb.
sRGB is the color profile that has been used for several years whenever no alternative color profile has specifically been defined. This is why about 99% of all images on the internet contain this default color profile. Even Cinema 4D versions prior to R12 saved images exclusively in the sRGB color profile.
The locations within Cinema 4D at which color profiles can be defined are listed below.
The most important color profile settings in Cinema 4D
As you can see, there are three "interfaces" from/to Cinema 4D where color profiles (or hardware profiles) can be analyzed:
-
Textures: As you know, bitmaps can be loaded into various material channels or Image Nodes. In the Project Settings you can define if and how imported color profiles should be handled. You can also define which color profile should be used if a bitmap does not contain its own integrated profile. Additionally, you can define how the individual bitmap should be used for individual channels (per bitmap shader).
The BodyPaint 3D layout also contains several commands with which and locations at which color profiles can be modified (e.g. Bitmap Layer or Change Profile...). - Monitor: Here you can define a custom (preferably calibrated) monitor hardware profile. This profile is responsible for the display of colors in Cinema 4D on your monitor, i.e. what you see in color selection fields, in the Viewport, Picture Viewer, etc. Not necessarily to be ignored if you consider how often you select colors within Cinema 4D.
- Files: Rendered bitmaps (color profiles cannot be added to movies rendered with Cinema 4D). Here you can define the output color profile that is saved with the file and used, for example, when the rendered image is opened in Photoshop.
In the attachment you will find a list of image formats with which color profiles can be used.
More information can be found under Color Management (in most cases sRGB will be correct).
Here you define 3 things:
- Whether or not the embedded color profile of textures should be used
- Which color profile should be used for textures with NO embedded color profile.
- Which color profile should color selection fields, gradients, etc. within the application use
The selected option is shown in the field below.
If a texture has an embedded color profile, these options define how the color selection fields, gradients, etc. will be displayed in Cinema 4D. sRGB is the most commonly used display mode (when in doubt, use this mode). Linear is the mode that less common and more difficult to use.
In this mode, embedded color profiles will not be taken into consideration. The sRGB color profile will be used instead. Simultaneously disabling the Linear Workflow option will reflect the mode prior to R12.