асес эксплейнер
Канал автора - t.me/r_nghtmr
Список сущностей, действительно необходимых для достаточного понимания темы:
Цветовые значения изображения (RGB values), Color Gamut (цветовой охват), гамма-коррекция (сокращается до "Gamma", хотя правильно вообще Transfer Function), маппинг значений, математика рендера (Light Transport).
В процессе разберемся с такими сущностями, как: Color Management, ACES Transform, Color Transform, OCIO.
Проблема
За размытыми формулировками в гайдах и статьях крайне сложно понять несколько вещей: чем является ACES на уровне концепции, какую конкретно проблему он решает и как именно он её решает на практике. Дело в том, что весь топик не держится ни на чём определенном и полностью сводится к миллиону не очень конкретных условностей, в которых, тем не менее, реально разобраться.
Cначала давайте обсудим рендеринг. Для простоты опустим существование цвета и представим белый ареа лайт с интенсивностью 567 напротив камеры; если мы его отрендерим, мы получим изображение, которое не просто визуализирует яркость лайта, а фактически полностью её передаёт из одного формата (настроенная 3д сцена) в другой формат (изображение). То есть, если мы проверим пипеткой значение пикселя на лайте на отрендеренном изображении, мы увидим значение 567. Если мы посветим этим лайтом на серую стену, мы получим на ней значение 567/2, если сделаем стену более серой, то 567/3, если этот свет отразится на пол, на полу будет значение 567/5 и так далее. Это концепция Light Transport в максимально упрощенном виде. Есть луч света, у него есть значение, которое меняется в зависимости от его пройденного пути. Рендер - процесс записи этих значений в изображение. Фактически, мы можем считать рендер конвертацией сцены из одной формата в другой. Проблема в том, что числовое значение это абстракция, как и цвет. Какие правила определяют соответствие какого-либо цвета какому-либо значению? Эти правила определяет Rendering Color Space. Это самый первый этап, на котором ACES влияет на то, что вы делаете. "Рендерить в колорспейс" означает задать правила, по которым движок будет считать значения, записываемые в файл.
Что такое колорспейс?
Ещё одна абстракция. К счастью, человек к абстракциям весьма привычен, а значит можно привести удобную аналогию. Словесное наименование цвета фактически является упрощенной моделью колорспейса. Я пишу слово "красный" - вы представляете нужный цвет. Англоговорящий человек не представляет, так как не знает слово "красный", но представит, если я напишу "red". Это два колорспейса - русский и английский. А вот есть цвет "श्वेतः", это третий колорспейс и он не поддерживается.
Суть колорспейсов легче понять, получив ответы на несколько вопросов:
Что будет, если никакого колорспейса нет, можем ли мы рендерить без него?
Ничего не будет, нет, не можем. Нам нужно правило, чётко обозначающее соответствие определённых значений определённым цветам. Красный цвет в нашем мире существует потому что мы понимаем что мы называем красным цветом. Если движок не понимает что такое цвет - он не может сконвертировать нашу сцену в изображение, состоящее из цветов.
Что было до ACES?
Rec709, он же кек709. Концептуально тоже самое что и ACES, только хуже. Был единственным доступным колорспейсом в Blender до 5-ой версии. Про AgX и прочие Filmic'и чуть позже.
На что конкретно влияет Rendering Colorspace?
На числовые значения (RGB values), записываемые в файл при рендере. А выбор колорспейса - за то, насколько большой диапазон цветов могут описать эти значения, и в ACEScg он самый большой.
В каких случаях нужно рендерить в ACEScg, а в каких в Rec709?
Ни в каких. Если ваш движок поддерживает рендер в ACEScg - вы рендерите в ACEScg. Выбор колорспейса это не artistic choice, это сугубо технический выбор, а у ACEScg наилучшие технические характеристики.
Для ясности уточню, что в случае простенькой сцены, не сильно яркой, не сильно насыщенной, вы, при условии конвертации цветов в материалах, получите почти идентичные изображения при рендере в любой колорспейс. Для полного понимания я крайне рекомендую самостоятельно собрать тестовую сцену, в которой на плоскость будут светить несколько цветных ярких лайтов и один тусклый лайт рядом.
Отрендерите в несколько доступных колорспейсов, закиньте в любой композитинг-софт, сравните в режиме Difference, посмотрите как реагирует на любые манипуляции с цветом и яркостью каждый из вариантов: область с яркими насыщенными лайтами будет вести себя иначе в каждом из вариантов, область с тусклым белым лайтом будет поддаваться любым настройкам одинаково.
А что после рендера?
После рендера мы получаем файл, который хранит большие значения, что идеально для любых композных манипуляций, плохо для визуального восприятия. Значения могут быть меньше нуля, они могут быть сильно выше десятков тысяч, монитор их нам не покажет. Для простоты будем считать, что человеческий глаз тоже видит значения только от 0 до 1.
Есть два варианта разобраться с проблемой: просто отрезать всё, что ниже нуля и выше единицы. Это нерелевантный подход, так как это приведёт к полной потере информации за пределами этого диапазона. Это то, что называется clipping и это проблема.
Второй вариант - маппинг. Маппинг это просто: у нас был диапазон значений 0т 0 до 1, мы "говорим": пусть там, где было значение 0.5, станет значение 0.8. В данном случае мы оставляем исходный диапазон значений, но меняем их распределение, благодаря чему в диапазоне 0-0.8 станет больше информации, а в диапазоне 0.8-1 её станет меньше. Мы также можем не менять распределение, но поменять диапазон: при исходном диапазоне 0-1 "говорим", пусть там, где было 0 станет -54, там где было 1 станет 54. Colorspace Transform представляет из себя набор из нескольких операций, но глобально их можно назвать ремаппингом. Всё. ACEScg colorspace - набор правил для рендер-движка, Colorspace Transform - ремаппер того, что видел рендер-движок в то, что адекватно воспринимает наш монитор и наше зрение.
Упорядочивание
Всё, что написано выше достаточно просто для понимания и по сути является полным изложением всей сути топика, однако можно заметить, что сущностей в начале статьи было обозначено больше, чем упомянуто к этому моменту. Давайте предметно обсудим какое место они занимают в теме.
Color Manadgement
Не является термином, просто общее название перечня цветовых настроек в софте. Обычно определяет колорспейс, в который вы рендерите и вью трансформ, который отвечает за то, как вы видите во вьюпорте/ipr то, что вы рендерите.
OCIO
Является форматом конфиг-файла, который содержит в себе настройки, касающиеся колор менеджмента. Как, например, .mtl файл рядом с .obj моделью, который просто хранит информацию о материалах или какой-нибудь .json конфиг. Дело в том, что каждый софт использует свою математику трансформов и свои ЛУТы, поэтому, если вы сравните то, как выглядит ваш рендер во вьюпорте и после рендеринга и колортрансформа в да винчи, нюке и ае - вы рискуете получить четыре немного разных результата, т.к рендерите с одним конфигом, а трансформите с другими. С каждой программой и каждым движком идёт свой дефолтный осио, у нюка свой, у ае свой, у редшифта свой и так далее. Если все они будут ссылаться на один ocio конфиг - проблем не будет.
Чем отличается Colorspace Transform от ACES Transform или от LUT'а
Сначала про всё, в названии чего есть слово "трансформ": это одно и то же, но иногда по-разному. Если вы наблюдаете в вашем софте несколько способов колотрансформа - погуглите в чём разница. С точки зрения надёжности и предсказуемости правильнее всего будет использовать тот, в который можно скормить OCIO конфиг и указать конфиг, на который полагается ваш рендер.
Применение ЛУТа- операция, логически идентичная колортрансформу, которая ремапит входные значения, просто другим образом. Мы могли бы создать ACES LUT, который, при применении выдавал бы результат, схожий с результатом колортрансформа, хотя это будет аппроксимация, так как колортрансформ аккуратно считает новые значения для каждого существующего исходного цветового значения, тогда как LUT представляет из себя более ограниченный набор правил для ремаппинга и его применение предполагает интерполяцию для промежуточных значений. Представим, что есть диапазон значений от 0 до 1 и ЛУТ, который ремапит 0 в 0.1, а 1 в 0.2. 0.5 станет 0.15, но что если мы должны были получить 0.161? Почему 0.161? Потому что разработчики ACES считают, что это значение лучше скажется на визуальном восприятии финального изображения, а мы работаем в этой системе и верим ей, в этом смысл.
Почему я могу применить Colorspace Transform в пяти разных местах тремя разными способами?
Основная разница следующая: вы применяете его либо глобально на весь проект, либо локально на каждую секвенцию и каждый футаж. Суть очевидна, в первом случае вы лишены необходимости настраивать каждую секвенцию отдельно, если их тысяча и все они порендерены в один колорспейс; во втором случае вам это необходимо, потому что у вас тысяча секвенций и все они порендерены в разные колорспейсы, а где-то вообще затесался футаж, снятый на нокиа люмию. Математически это те же операции, никакой разницы ни на каком этапе работы не будет, если делать всё правильно, не запутаться и не стакать трансформы. Пример базовой ошибки: засетапить правильный колор менеджмент на уровне проекта и думать, что ваши футажи всё еще в исходном спейсе, это не так. Если вы настроили трансформ ACEScg в ACEScc на уровне проекта, ваши футажи уже в ACEScc и финальный аутпут трансформ должен быть из ACEScc в sRGB.
AgX, Khronos PBR, Filmic
Не колорспейсы, но тон мапперы (tone-mapping). Да, тоже про ремаппинг. Мы не рендерим в AgX, мы его применяем к рендеру в Rec709 или любое другое пространство, а значит не в любом случае получаем преимущества рендера в большой колорспейс. Блендер до последних версий не поддерживал рендер в ACEScg, а ACES, который можно было "поставить" на более ранние версии тоже играл роль тон-маппера.
Но... ведь картинка становилась приятнее?
Да. Под капотом ACES Transform чуть больше операций, чем просто колорспейс трансформ, включая свой тон-маппер, названный RRT (Reference Rendering Transform). Это та часть, благодаря которой мы получаем ACES-лук.
Не хочу ACES-Look
Никто не заставляет. Та часть, где вы были привязаны к ACES здравым смыслом и техническими требованиями закончилась на моменте, когда вы отрендерили изображение в ACEScg колорспейс. Всё что дальше - artistic choice; есть красивые ЛУТы, но под рек709? Колортрансформьте, применяйте, радуйтесь. Хотите Filmic лук? Пожалуйста.
Но ведь при настройке сцены я вижу изображение в ACES? Если я хочу работать с AgX тон-маппингом, мне работать наугад?
Нет, если вы хотите работать с кастомным тон-маппингом, вы создаёте/скачиваете ОСИО конфиг, в котором будут настроены нужные вам правила и указываете нужный View Transform в настройках коломенеджмента. ОСИО будет ссылаться на ваш кастомный ЛУТ или CTL(Color Transform Language) файл, в котором прописаны нужные правила для желаемого вами трансформа. Если вы хотите работать в кастомном колорспейсе, рендеринг в который не поддерживается напрямую (допустим проприетарный DaVinci Wide Gamut), вы создаёте кастомный ЛУТ и предсказуемо работаете, видя в IPR достаточно хорошую аппроксимацию того, что у вас получится после рендера, колорспейс трансформа и трансформа в sRGB. Но всё это очень маловероятные для соло-артиста желания.
Раз всё сводится к числовым значениям, что качественно отличает Colorspace Transform от любого другого способа получить те же значения и возможно ли это технически?
Да, возможно, и это путает. Вы можете хоть вручную попиксельно раскрасить изображение в соответствии с ACEScg рендером и после трансформа получить идентичные результаты. Ответ на вопрос заключается в причине, по которой вы не будете попиксельно раскрашивать изображение.
Color Gamut и Gamma
Color Gamut - цветовая гамма, слово гамма в значении охват, спектр, тот самый цветовой треугольник, вездесущий для каждого ролика по цветовым пространствам. Описывает основные цвета (Color primaries). Чётко определяет значения, соответствующие тому или иному цвету и является основной характеристикой любого колорспейса, так как характеризует количество возможных цветов, которые он может передать. Ошибочно отождествлять колорспейс и его возможности с линейностью. Rec709 может быть линейным, Rec2020 может быть линейным, ACEScg может быть линейным. Может ли ACEScg быть sRGB? Да, а изображение в sRGB колорспейсе может быть линейным. Здесь ненадолго разделим две сущности: Colorspace и Gamma. Когда мы говорим Rec709 Linear мы подразумеваем Rec709 колорспейс (то есть его описание цветов, которое является скудным в сравнении с ACEScg) и Linear гамму. Линеар гамма это хорошо, но гораздо лучше, когда у тебя еще и короспейс описывает достаточно больше количество цветов, а за это отвечает Color Gamut.
Гамма - ни в коем смысле не является синонимом вышеуказанной гаммы, которая Gamut, это два разных слова. Как зáмок и замóк. В гамме нужно разобраться подробнее: в контексте нашего топика её не существует как самостоятельного термина и она не описывает какое-либо конкретное действие или атрибут, которым может обладать изображение.
Вернемся к разговору про колортрансформ, с помощью которого мы получаем из сырого рендера визуально привлекательную картинку. Визуальную привлекательность картинки можно определить как соответствие её внешнего вида тому, как мы воспринимаем окружающий мир нашим зрением. ACES - то, что берёт на себя ответственность за трансформацию сырых значений в удобные и приятные для восприятия. Что конкретно происходит со значениями?
Gamut Mapping и Gamma-correction. Гамма-маппинг отвечает за ремаппинг из одного диапазона цветов (колорспейса) в другой нужным образом, гамма-коррекция отвечает за то, чтобы яркость изображения была распределена таким образом, которым яркость воспринимает наш глаз. Первое влияет на то, какие цвета мы получим после трансформа, второе влияет на то, насколько они "подогнаны" под наше зрение.
Предметно: после рендера мы имеем изображение с линейной гаммой (Linear image), сырые не адаптированные для просмотра значения. Хорошо для некоторых композных операций, плохо для других композных операций. После колортрансформа мы получаем адаптированное для просмотра нелинейное изображение. По сути мы можем отождествить нелинейность и смотрибельность.
На цифрах нелинейность работает так: представим тёмную комнату, в которой находится люстра с 10 одинаковыми лампочками. После включения лишь одной мы станем видеть комнату существенно более яркой, чем она была до этого. Если мы включим еще одну, станет значительно светлее, но если мы включим пять - мы не увидим, что комната в пять раз светлее, чем при одной лампочке. По мере включения большего количества ламп, их влияние на наше восприятие яркость будет уменьшаться, потому что мы воспринимаем свет нелинейно. Мы хорошо видим разницу между двумя темными участками, плохо видим разницу между двумя светлыми. Теперь представим трехмерную сцену, настроенную аналогичным образом: при тех же манипуляциях с включением каждой новой лампочки, на сыром рендере мы будем наблюдать линейное увеличение яркости, 10 лампочек будут в 10 раз ярче, чем одна. Это совсем не то, как мы видим. Гамма-коррекция решает эту проблему, распределяя значения, полученные при рендеринге таким образом, которым их видел бы наш глаз в реальном мире в аналогичных условиях. Под гаммой подразумевают соотношение исходной, сырой яркости изображения с яркостью, полученной после любого тон-маппинга.
Важно не воспринимать это как какую-то отдельную операцию, потому что это не так - гамма-коррекция просто происходит или не происходит в процессе ремаппинга RGB значений. Чтобы лучше понять, подумайте об этой операции в HSV-интерпретации цвета вместо RGB. В HSV интерпретации есть параметр яркости, если мы применим к нему S-образную кривую для создания контраста или ремапнем значения, перераспределив их - мы, нелинейно изменив значения, сделаем то, что принято называть гамма-коррекцией. В RGB интерпретации мы просто увидим новые значения.
Значение гаммы отражает соотношение нашего сырого изображения с линейной гаммой (равна единице, т.к если мы применяем гамма-коррекцию 1.0 - распределение значений не меняется, остаётся линейным) с полученным после гамма-коррекции изображением. Gamma 2.2 означает одну кривую значений, Gamma 2.4 другую, у некоторых колорспейсов, например у ACEScc и ACEScct своя гамма. Антоним линейной гаммы - логарифмическая гамма (Log), любая гамма кроме линейной является логарифмической (хотя на некоторых участках распределение значений может оставаться линейным).
Почему я назвал гамму несуществующим понятием? Представим: у нас есть линейное изображение, на котором мы закрасили одну половину черным цветом. Стало ли оно от этого нелинейным? Что если мы применили гамма-коррекцию, но наполовину смешали полученный результат с исходником? Если мы применили гамма-коррекцию, но кривая на 99 процентов линейная? С каким изображением мы работаем, если мы не знаем его источник и не имеем представления о том, какие его правильные исходные сырые значения? Короче, гамма это конструкт, который рушится без объективного знания о том, какие значения мы должны иметь в конкретном изображении и довольно легко рушится, даже если нам это известно. Например, я осознанно применил гамма-коррекцию к одному АОВ в художественных целях, но далее работаю с изображением как с линейным. Более того, гамма-коррекцию можно инвертировать, тем самым вернув исходное распределение значений, собственно это и является причиной, по которой важно осознавать существование такого конструкта, так как для некоторых манипуляций вы можете сознательно менять гамму, а некоторые комплексные инструменты, например колорспейс трансформ, должны делать это под капотом для корректной работы. Поэтому он и просит гамму, которую ему ожидать на входе, чтобы корректно конвертировать её в ту, с которой ему нужно проводить математические операции.
Итого, значения гаммы, которые от нас будет ждать софт в разных ситуациях, являются чем-либо из следующего: значение гамма-коррекции, примененной к исходному линейному изображению или значение гамма-коррекции, которое мы хотим получить на выходе (название необязательно числовое, ACEScct-гамма всё еще гамма, как и Gamma 2.2, просто иначе названа и разных названий много).
Саммари:
Подведём итоги на данный момент: у нас есть рендер-движок, он может рендерить в разные колорспейсы. Мы рендерим в ACEScg, потому что он самый лучший, но при этом ни к чему нас не обязывает в дальнейшем. Далее мы проводим композные манипуляции, в процессе которых нам может понадобиться гамма-коррекция или колорспейс трансформ, которые на данном этапе являются полностью обратимыми манипуляциями (да, пока вы не отрендерили футаж в более ограниченный колорспейс, вы можете конвертировать ACEScg в Rec709 и обратно без потери данных). Далее применятся финальный колортрансформ из какого угодно спейса на котором вы закончили работать, в спейс, который вам нужен. Если это финальный этап работы, то это в основном будет sRGB.
Термины:
ACES: общее название системы подхода одной конкретной компании к цвету.
Colorspace: система координат, определяющая соответствие цветовых значений какому-либо цвету. RGB и HSV тоже можно считать колорспейсами и они достаточно лёгкие, чтобы вы их нативно воспринимали мозгом при работе с диджитал цветом.
ACES/Colorspace Transform: процесс конвертации колорспейсов, может играть роль проявки изображения, т.е конвертации несмотрибельного изображения в смотрибельное, может играть промежуточную роль.
View Transform: колортрансформ для вашего вьюпорта или IPR. Математически и логически обычный колортрансформ.
Gamma: то, как изображение передаёт яркость; в смотрибельном виде (Log) или в подходящем для композа виде (Linear).
Вопрос-ответ:
В редшифте можно выбрать LUT в IPR, но ведь там уже ACES, куда он применяется, как в этом вообще ориентироваться?
Попробуем понять принцип, который позволит в этом разобраться. Вспомним самые конкретные вещи, которые мы знаем: рендер-движок рендерит в определенный спейс, в IPR есть View Transform из ACEScg в sRGB и есть LUT, который является ремаппером. Ведь ремаппер не может быть настроен одновременно на то, чтобы работать одинаково хорошо с разными входящими диапазонами значений? Верно, а значит настоящий вопрос: что именно настроен делать конкретный LUT? Логически мы их можем разделить на 2 типа: View LUT, который функционально нужен для того, чтобы ремапить нужные значения в видимые нам и Creative LUT, который по сути является колор-корекшен пресетом. Первый будет ожидать на входе сырые значения и ремапить в видимые нам, второй может ожидать на вход всё, что угодно и играть роль колор-корекшена. Документация была скудна на детали, но опытным путём было установлено, что редшифтовские LUT'ы хорошо и ожидаемо работают именно с Raw вью трансформом, а значит это View LUT'ы (они же проявочные), они выполняют задачу ACES Transform'а и не предназначены к совместному использованию (по сути это как применить колортрансформ дважды).
Но я всегда ими пользовался с дефолтным трансформом чтобы сделать картинку интереснее и мне нравится.
Никаких проблем, пользуйтесь. Как уже писалось выше - все, что после рендера изображения - это artistic choice. Если вас устраивает как это выглядит, то никаких проблем нет; как именно это работает - полезно знать, как минимум чтобы потом получить вашу картинку после рендера. В данном случае вам нужно будет применить ваш LUT после аутпут колорспейс трансформа, это то, в каком порядке это делает редшифт по дефолту.
Что если я работаю в ACES 1.2, а трансформ сделаю в ACES 2.0?
Для начала обсудим что это вообще за цифры: за ними стоят математические операции ACES Transform'a. По сути это новая версия старой операции. На математику рендера они не влияют, она определена ACEScg спейсом, а он неизменен. Вы не работаете в ACES 1.2, вы применяете к вашим сырым значениям ACES 1.2 вью трансформ, чтобы видеть что вы делаете при работе в сцене. Вы можете после рендера применить ACES 2.0 трансформ, и даже получить картинку лучше, чем если бы вы применили ACES 1.2 трансформ, но есть важный нюанс; вы настраивали сцену, подразумевая именно 1.2 трансформ, вы задавали цвета и настраивали яркость, ориентируясь именно на него, и это приведет к одной простой вещи: ваша сцена будет выглядеть не так, какой вы бы её настроили, если бы изначально подразумевали ACES 2.0 трансформ. Под него вы бы настроили немного другие цвета, где-то подняли бы яркость, так как ACES 2.0 может работать с ней лучше, где-то поменяли оттенок, но не делали этого, потому что с 1.2 это выглядело хуже. Вы бы не стали работать в Blender Filmic чтобы потом накинуть AgX ровно по той же логике.
Чтобы получить похожие картинки при работе с 1.2 и 2.0 вью трансформом, вам нужно будет менять настройки лайтинга и материалы в вашей 3д сцене, потому что цвет, который вы видите зеленым, является числовым значением {56, 351, 75} (условно), а ACES 1.2 и ACES 2.0 трансформируют их по-разному
Разве это не путает еще сильнее?
Да, путает. Но между ACES 1.2 и 2.0 есть качественная разница, это не просто одно и то же по-разному. Заключается она в решении вполне определенных проблем, таких как сохранение визуальной информации в темных и светлых участках изображений и в сохранении правильных оттенков цветов в этих участках (Hue Skew).
ACES пайплайн - лучший?
ACES пайплайн - единственный популярный и единственный, который поставляется с софтом, а его качество и юзер-экспириенс небезосновательно ставят под вопрос.
Вот пост про исправление некоторых проблем ACES
Мелочи, которые больше никуда не влезли(
Стоит упоминания, что ACES имеет гораздо больше смысла и более лёгок к пониманию в контексте работы со съемочными футажами, а не рендерами. Представьте, что в ваших руках две совершенно разных камеры, которыми вы снимаете небо. Каждая камера по-своему передаст яркость и насыщенность картинки, но если вы переведете их из исходных колорспейсов в ACES, то получите достаточно схожие изображения, а идентичные операции будут оказывать ожидаемый результат (то есть, крутанув сатурейшн на одном футаже и на другом на одинаковое значение, вы получите похожие оттенки неба, потому как цвет неба, хоть изначально и был описан разными системами, сейчас сконвертирован в одну). В данном случае ACES выступает как некоторый общий знаменатель, без которого к каждому футажу, снятому на разные камеры, пришлось бы применять разные операции для достижения одинакового результата, что непрактично.
Тон-мапппинг, применение ЛУТа, ручной ремаппинг через Curves, колорспейс трансформ, ACES трансформ, всё вместе можем считать колор трансформами, но только колорспейс трансформ и ACES трансформ являются колорспейс трансформами.
OpenEXR формат абсолютно никак не связан с топиком - это просто контейнер, который позволяет хранить значения. С тем же успехом их можно хранить в .tiff, .hdr или блокноте. В .png нельзя было бы, так как этот формат не поддерживает хранение значений за пределами 0-1 диапазона.
Ссылки, приносящие пользу
Самая понятная грамотная объяснялка: https://docs.derivative.ca/Color_Space
Сайт с большим количеством подробного материала на тему цвета в CG: https://chrisbrejon.com/cg-cinematography/chapter-1-5-academy-color-encoding-system-aces/
Просто использовалось при написании:
https://www.image-engineering.de/library/technotes/714-color-spaces-rec-709-vs-srg
https://www.vfxprofessionals.nl/wp-content/uploads/2016/03/ColorspACES_v1.01.pdf
https://rebusfarm.net/blog/the-ultimate-guide-to-color-space-and-the-advantages-of-using-aces
https://www.toadstorm.com/blog/?p=694