Color & Bit Depth

ArcBrush works in two color modes, and the color management that comes with the second one is the part most people find confusing the first time they see it. This page explains what every option does, and (more importantly) which one you should pick.

If your work only ever targets a normal computer screen, you can skip to The quick answer. If you work in a game, film, or VFX pipeline, the advanced section covers the full toolset.

Two modes: 8-bit and 32-bit

The mode is set from the Color menu.

Mode	What it is	Who it’s for
8-bit	Standard 256-levels-per-channel processing. The default. Your image is shown on screen exactly as stored.	Everyone. Icons, sprites, textures, and images destined for ordinary screens.
32-bit (float)	Full floating-point processing with HDR values, linear compositing, and OCIO color management. Requires a Pro license or trial.	Anyone who needs values brighter than white, physically-correct compositing, or an ACES / studio pipeline.

The two questions color management answers

Color management in 32-bit mode is really just two separate settings that answer two different questions. Keeping them straight is the whole game:

Working Space: what space do my pixels live in? A property of the document. Saved in the file.
Display / View: how should those pixels look on my screen? A property of your monitor setup. Saved as a preference, not in the file.

A useful analogy: the Working Space is the language a document is written in. The Display / View is the pair of glasses you put on to read it. Two people on different monitors can open the same file and each see it correctly, because the document’s language never changed, only their glasses did.

Working Space (a property of the document)

The working space is the color space every 32-bit node computes in. Set it in Color → Working Space.

Working Space	What it means	Use it when
Linear (scene-linear Rec.709)	Physically-linear light, standard-monitor primaries. The 32-bit default.	General HDR / linear compositing without committing to ACES.
sRGB (display-gamma)	Ordinary display-encoded sRGB, carried as float.	You want 32-bit precision but the same look as 8-bit, importing textures “as they are.”
ACEScg	ACES scene-linear, wide (AP1) gamut.	Game / film / VFX work that targets an ACES pipeline.
ACEScct	ACES log-encoded, wide gamut.	Color grading in an ACES pipeline (log working space).
Linear P3-D65	Scene-linear with DCI-P3 primaries.	Mastering for wide-gamut P3 delivery.

Most people never need to change this. Leave it on the default unless a pipeline tells you otherwise.

Display / View (how it looks on your screen)

This is the menu with all the combinations, under Color → Display / View. It looks overwhelming because it’s a full matrix, but you’re really only making two small decisions.

Step 1: Display (what is my monitor?)

The Display is a fact about your hardware, not a creative choice. You have exactly one correct answer:

Your monitor	Choose
A normal computer monitor or laptop screen	sRGB - Display
A modern Mac or a wide-gamut “P3” monitor	Display P3 - Display
A real HDR display (in HDR mode)	Rec.2100-PQ, Rec.2100-HLG, ST2084-P3-D65, or Display P3 HDR, to match your display’s HDR standard
A broadcast / mastering monitor	Rec.1886 Rec.709, Gamma 2.2 Rec.709, or P3-D65 as specified by your delivery

When in doubt, it’s sRGB - Display. The HDR and broadcast entries only help if you actually own that kind of output.

Step 2: View (what look do I want?)

The View is the creative/technical choice. Every display offers the same five views, because any look can be shown on any device:

View	What it does	Pick it when
ACES 2.0 - SDR 100 nits	The full ACES output transform: a filmic tone curve with highlight roll-off plus gamut mapping. The reference “rendered” look for scene-referred content.	You’re authoring HDR / scene-referred content and want the standardized ACES result.
AgX	A filmic display transform (the AgX tone mapping) with gentle highlight roll-off. It deliberately mutes saturated colors (see Why does AgX look so desaturated?). A more neutral, less contrasty alternative to ACES.	You want a filmic look that tames HDR values but is softer and less saturated than ACES; popular for stylized and illustrative rendering.
Standard	Converts to your display’s gamut and encoding with no tone curve. Values above 1.0 clip to white. (Its canonical OCIO name is Un-tone-mapped, shown in the view’s tooltip.)	You want your image shown exactly as authored, with no filmic rendering on top (display-referred 2D content).
Video (colorimetric)	A colorimetric mapping to the display’s video encoding, also with no creative look, aimed at numeric/broadcast accuracy.	You need colorimetric video fidelity rather than a rendered look. The visible difference from Standard is subtle for in-range content.
Raw	No transform at all; the stored numbers are shown directly.	Inspecting raw values, or when your working space is already display-encoded sRGB. Scene-linear data looks far too dark here.

The quick answer

If you just want your image to look right on a normal screen and don’t care about the theory:

Leave Display / View on Smart Default (it’s on by default and is correct for most work), or
Set Display = sRGB - Display and View = Standard to see your image exactly as you authored it.

That’s it. The rest of this page is for when you do care.

Smart Default

Smart Default (by working space) is the bottom entry in the Display / View menu, and it’s on unless you override it. It reads your document’s working space and picks a sensible view automatically:

sRGB working space → Raw (those pixels are already display-encoded, so the correct transform is identity, matching the familiar 8-bit look).
Linear working space → Standard (a plain linear→sRGB encode with no tone-map, so scene-linear data renders correctly instead of dark).
ACEScg, ACEScct, or Linear P3-D65 → the ACES output transform for your display (because scene-linear ACES data needs a rendering transform to look right).

Because it follows the working space, Smart Default is the setting we recommend leaving on. Choose an explicit Display/View only when you know you need one.

Why does ACES look darker or “different”?

This is the most common surprise, and it’s expected behavior, not a bug.

When your working space is ACEScg (or another ACES space), Smart Default applies the ACES output transform, which can look noticeably darker and more contrasty than Standard, Video, or Raw. Two things cause it:

Highlight roll-off. Standard and Raw simply clip everything brighter than white to solid white. ACES instead compresses those bright, saturated highlights into a controlled range. So an area that the other views blow out to flat white becomes a mid-toned, detailed region under ACES, which reads as “ACES is darker” when really the others are just clipping. (AgX also rolls highlights off, but more gently, and desaturates them rather than fully remapping the gamut.)
Midtone contrast. ACES seats mid-grey lower and applies an S-shaped contrast curve, so midtones sit a little darker than a plain linear-to-sRGB encode.

This is exactly what ACES is for in film and game pipelines: a predictable, filmic rendering that tames HDR values instead of clipping them. If you’re working with display-referred 2D content and you’d rather see your exact authored values, that’s a sign you want Standard (or the sRGB / Linear working space, where Smart Default already gives you a straight look) rather than an ACES working space.

Why does AgX look so desaturated?

Also expected behavior. AgX deliberately drains saturation from strong colors and pushes bright ones toward white (the filmic “path-to-white”): a pure red renders as a muted brick, and a pure blue lifts toward a pale sky blue.

On photographic or rendered content this reads as a pleasing softness, because fully saturated pixels are rare there. Flat graphic color is AgX’s worst case: a colored Noise, a Gradient, or a palette fill produces exactly the flat, saturated, mid-brightness values AgX compresses hardest, so under the AgX view they can look washed out to the point of seeming broken. The pixel data is untouched; switch the View to Standard (or sample with the eyedropper) and the full saturation is still there. Only the on-screen rendering mutes it.

Practical guidance:

For flat 2D / graphic work, use Standard (or leave Smart Default on). AgX is a photographic tone-map; for this content it’s the wrong pair of glasses.
Reach for AgX when the document is genuinely HDR / scene-referred and you want a gentler highlight roll-off than ACES.
If you author under AgX on purpose, compensate by picking more saturated and brighter source colors.

Exporting to a target color space

A 32-bit document works in a scene-referred space (ACEScg, Linear, …), but your deliverable usually needs a specific target like sRGB. The Export Image and Export Batch nodes have a Color Handling control (shown in 32-bit mode) that decides how working-space color is written to the file. Its default, Auto, picks per format: OpenEXR gets Working space (no conversion), and every other format gets As displayed (bake view).

Color Handling	What it writes	Use it for
As displayed (bake view)	Bakes the current Display / View into the file, so it matches your viewport. What Auto picks for standard formats.	The common case: a file that looks exactly like what you see. A plain sRGB PNG from any working space just works.
Convert to color space	A colorimetric conversion into the Target Color Space you pick (e.g. sRGB).	A precise, standardized deliverable. This is colorimetric, not the ACES tone-map, so highlights clip instead of rolling off, and it will not match an ACES viewport render.
Working space (no conversion)	Raw working-space (scene-linear) values, untouched. Offered only for 16-bit / 32-bit / EXR output.	Passing scene-linear data to another color-managed application (EXR / 16-bit / float TIFF intermediates).

The key subtlety: As displayed and Convert to color space answer different questions. “As displayed” reproduces the rendered look you see (including the ACES tone-map, if that is your view). “Convert to color space” does a colorimetric encode of the scene values into the target space, with no tone-map. From an ACEScg document the two produce visibly different files, so pick the one that matches your delivery.

By format

8-bit (PNG, JPEG, TGA, WebP, BMP): use As displayed or Convert to color space (sRGB). Both color-manage the output, so a scene-linear document exports a correct, viewable file.
16-bit PNG / TIFF: the same options with more precision, for a high-quality sRGB (or other target) deliverable.
32-bit float TIFF and OpenEXR: usually Working space (no conversion) to preserve the scene-linear data, or Convert to color space to hand a specific space to the next application. (Raw working-space output is offered only for these high-bit formats.)

Re-importing an export

When you bring a file back into a project, the Input Color Space picker defaults to Auto, which treats an 8-bit file (PNG, JPEG, …) as sRGB and a float / EXR file as already in the working space. That is correct for the files most exports produce:

Files written with As displayed or Convert to color space are standard sRGB (or your chosen target). Re-import them with Auto.
Files written with Working space (no conversion) (16-bit / EXR) hold scene-linear data in the working space. Re-import them by setting the Input Color Space explicitly to that working space (e.g. ACEScg), not Auto, since Auto would assume sRGB.
Files written with As displayed are final renders. They look correct as deliverables, but re-importing one into a scene-referred project (e.g. ACEScg) and viewing it through the ACES transform applies that look a second time. Treat a baked-view file as a finished image, not as scene data to composite back in.

For CG artists and compositors

The full matrix exists because 32-bit mode is a real color-managed pipeline, powered by the bundled, version-pinned ACES 2.0 Studio OCIO config (shown at the bottom of the Color menu). Notes for pipeline work:

Working space is the pipeline contract. Set ACEScg for scene-linear VFX/game work, or ACEScct for a log grading space. The choice is recorded in the .arcb file, and imports are decoded into it (the import dialog exposes an input color-space picker for camera and encoded sources).
The View is your monitor’s rendering. It’s a per-monitor viewing preference, so collaborators on different displays each pick the transform for their own screen. On export it is baked into the file only when Color Handling is As displayed (see Exporting to a target color space); the colorimetric and working-space modes ignore it. Use the ACES 2.0 - SDR 100 nits (Rec.709) view to review against the SDR reference render; switch the Display to your HDR standard (PQ / HLG / ST2084) when checking on an HDR monitor.
Standard vs Video (colorimetric) matters most for out-of-range and encoding-exact work: use Standard (canonically Un-tone-mapped) to inspect the scene data without a look, and Video (colorimetric) when you need a colorimetric mapping to the target video encoding.
AgX is an alternative filmic display transform to ACES: it rolls highlights off and desaturates extreme values more gently, for a softer, less contrasty look. Reach for it when the ACES render is too aggressive for stylized or illustrative content.
Raw is your “show me the numbers” view for debugging a graph; it applies no transform at all.
Creative and camera-log LUTs (.cube / .3dl, plus .clf / .ctf / .csp / .vlt) are applied inside the graph with the Apply LUT node, not as a viewer look: it wraps the table in a color-managed sandwich (working space → the LUT’s input space → apply → back to working space). EXR export (half/float, with an OCIO color-space picker) preserves the scene-referred data end to end.

The monitor ICC correction (Color → Display Color Correction) is independent of all of the above: in 32-bit mode it’s chained as the final stage inside the display transform, so the viewport is corrected exactly once and stays accurate on a profiled monitor.