ACES nie używa sRGB, nawet w tle. Ma własne, dużo szersze podstawowe barwy (primaries) — i dwa różne warianty, bo jeden do archiwizacji, a drugi do liczenia, to dwa różne zadania.
sRGB (Dodatek E) obejmuje ułamek barw, które widzi ludzkie oko — wystarczająco dla typowego monitora, za mało dla materiału z kamery filmowej, która rejestruje dużo więcej. ACES definiuje własne primaries na tyle szerokie, że praktycznie żadna realna kamera ani ekran nie wychodzi poza nie — dzięki temu konwersja do ACES z jakiegokolwiek źródła nigdy nie musi „ścinać” koloru.
ACES2065-1 (plik archiwalny, AP0) jest zaprojektowany, żeby nigdy nie trzeba było go „przerabiać” — nawet jeśli za 20 lat pojawi się ekran o gamucie szerszym niż dzisiejsze, oryginalne dane wciąż go obejmą. ACEScg (przestrzeń robocza, AP1) jest węższe świadomie: niektóre operacje matematyczne (mocny blur, niektóre mnożenia macierzowe w kompozycji) w AP0 łatwiej wypychają wartości w ujemne albo bardzo nietypowe liczby — AP1 jest bezpieczniejszym kompromisem do faktycznego liczenia i renderowania.
Każda kamera zapisuje obraz we własnym, zoptymalizowanym pod swój sensor kodowaniu logarytmicznym — ARRI LogC, Sony S-Log3, RED Log3G10. IDT to publikowana przez producenta konwersja z tego konkretnego kodowania na liniowe wartości ACES. Bez IDT, wczytanie materiału z dwóch różnych kamer do jednego projektu dałoby dwa niekompatybilne zestawy liczb, mimo że oba mają wyglądać „tak samo”.
Kiedy w Resolve, Nuke czy After Effects wybierasz „Input Color Space: ARRI LogC” albo „RED Log3G10” — wybierasz właśnie IDT z tego rozdziału. Jeśli wybierzesz złą kamerę dla danego materiału (albo zły model sensora tej samej kamery), kolory wejdą do ACES już przekłamane — żaden kolejny krok w pipeline nie naprawi tego błędu, bo dzieje się na samym wejściu.
Część 3 domyka drugą stronę pipeline’u: jak scene-referred ACES trafia z powrotem na konkretny ekran przez RRT i ODT.