Рендер в HDR (32bit image) и Tonemapping

[DemX86]

Всем добрый вечер!
После некоторого опыта работы с mia_exposure_simple появилось желание начать рендерить из Maya в 32bit HDR формат (скажем, openEXR) и управлять tonemapping'ом уже в Photoshop'е. Действительно, несмотря на то, что настройки mia_exposure_simple никак не влияют на время рендера, но настраивать его интерактивно все равно нельзя -- приходиться постоянно рендерить картинку, а это неудобно.
Знаю, у mia_exposure_simple есть опция Use Preview, но если ее использовать, то получается, я должен делать рендер дважды: первый раз для того, чтобы посчитать картинку в hdr формат и загрузить ее в Use Preview ноды mia_exposure_simple, чтобы провести tonemapping на ходу; а потом, уже настроив mia_exposure_simple, рендерить все еще раз, финально, причем в файл 8bit формата.
Да и сама идея свободы настройки картинки в 32 битовом пространстве в постобработке как бы заманивает.

Итак, сказано-сделано:
Есть тестовая картинка [1], которую хочется отрендерить в 32бита hdr и провести tonemapping в фотошопе.
В сцене есть sun and sky, в окнах 2 area light c Quadratic decay rate, тенями и включенным Use Light Shape. Плюс Importons и Irradiance Particles, никаких GI и FG. Еще mia_exposure_simple на камере.
Считалась данная сцена 7m44s (это без учета времени на обработку importons and irradiance particle, все это посчитано в файл).

Начинаем эксперименты:
- Убираем mia_exposure_simple с камеры
- Формат изображения выбираем OpenEXR
- Ставим в Render Settings Data Type RGBA (Float) 4x32 Bit, gamma оставляем 1, остальное здесь тоже не трогаем
- Command line batch render

Первое, что замечается -- подскочило более чем в 2 раза время рендера. С 7m44s до 16m30s.
*** Вопрос номер 1: Это нормально?
Я читал, что в mental ray внутри все крутится и считается в 32bit hdr, и диапазон сжимается уже во время рендера (если мы выбираем 8bit image как output image format, конечно же). Тогда откуда такие дополнительные нагрузки?

Далее открываем полученный .exr файл в Photoshop CS4. Выскакивает окошко с просьбой выбора профиля цвета.
*** Вопрос номер 2: А что тут нужно выбирать-то?
Я выбрал sRGB, но не думаю, что это 100% правильно.

Покрутил фильтром Exposure параметры exposure, offset, gamma... Как-то не впечатлило.
*** Вопрос номер 3: Как делать tonemapping в Photoshop -- фильтром Exposure или настраивая параметры в окошке при выборе image > mode > 8bit (там даже при выборе Local Adaptation кривую можно покрутить)? При втором варианте у меня даже еще хуже все вышло, чем при exposure.


Еще дополнительные моменты:
Какое значение ставить gamma в Framebuffer, когда рендеришь в 32bit?
Я делал как советовали здесь: http://www.fnordware.com/supertiff/tutorial/. Т.е. оставил как было, gamma 1. Но может тут надо как-нибудь хитрее действовать?
Еще тут когда-то на форуме упоминалось, что там же, в настройках Framebuffer, желательно выключать галку Interpolate Samples, но я результате как-то не заметил изменений в итоге рендера.

Едем далее.
*** Вопрос номер 4: Если мы решили рендерить в 32бита, то тогда как нам делать превью в Maya, без mia_exposure? Ведь без tonemapping'а будут одни большие засветы.
Как советовали в предыдущей ссылке, выставление gamma во Framebuffer в 0,455 не особо помогло:
Картинка [2] -- как отображалась сцена в RenderView без mia_exposure, framebuffer gamma = 1
Картинка [3] -- при framebuffer gamma = 0.455. Не многим лучше.

Вот такие вот пироги.
Буду рад любой информации о том, как лучше поступать: пользоваться mia_exposure и считать в 8bit image, или же считать все в 32bit hdr и пытаться делать tonemapping в фотошопе?
Спасибо за внимание.

P.S. Помню тут была ветка, где обсуждались проблемы антиалиязинга при рендере в 32bit, но вот никак не могу отыскать эту тему -- там сначала был какой-то совсем другой вопрос, потом пошла дискуссия про антиальясинг. Буду очень признателен, если кто эту ветку вспомнит и найдет.

 

[DemX86]

Никто не хочет делиться секретами рендеринга в 32bit image?..

 

[Eugenicsbmx]

Я щас читаю книгу Ментал рей для Maya,XSI 3д макс, посмотрите там в главе про вывод в буфер автор про все эту битность буферы кадров и выводы пиешт, думаю что то полезное найдете.!

 

[Dark™]

Помню тут была ветка, где обсуждались проблемы антиалиязинга при рендере

Она?

подскочило более чем в 2 раза время рендера

Повышение времени связано с процессом запуска batch render, в отличие от Render View, где все уже загружено вначале. Но не помню, чтобы увеличение было столь значимым.

Я выбрал sRGB, но не думаю, что это 100% правильно.

Думаю, не существенно. sRGB идет на веб публикацию картинок, Adobe RGB - на печать и юзается для проф камер, так как формат напрямую поддерживается.

Покрутил фильтром Exposure параметры exposure, offset, gamma...

Exposure + Levels. Но есть сторонние альтернативы получше, например Photomatrix Pro.

Какое значение ставить gamma в Framebuffer, когда рендеришь в 32bit?
Я делал как советовали здесь: http://www.fnordware.com/supertiff/tutorial/

В примере не видно, что использовали ноду mia_exposure, поэтому они решили обойтись коррекцией через Framebuffer. В нашем же случае лучше использовать такие параметры:

• Framebuffer Gamma - 1.0 (по-умолчанию, но цвета текстур на рендере становятся "смытыми"); mia_exposure - 1 (сохраняем линейность для постобработки)
• Framebuffer Gamma - 0.4545 (альтернатива, которая решает проблему с передачей цветов) ; mia_exposure - 0.4545 (тоже сохраняем линейность для постобработки)

Ментал рей работает с "серыми" текстурами с гаммой 1. Но так как все наши текстуры уже имеют гамму 2.2, надо сделать обратную операцию 2.2*0.4545 и получим, что надо. На итоговое освещение это не влияет в обоях случаях, что (1/1)*1, что (1/0.4545)*0.4545 - без разницы.

Настройки для гамма коррекции в самой майе, без постобработки сторонними программами:

• Framebuffer Gamma - 1.0 ; mia_exposure - 2.2 (итоговая гамма для экрана)
• Framebuffer Gamma - 0.4545 ; mia_exposure - 1

*** Вопрос номер 4: Если мы решили рендерить в 32бита, то тогда как нам делать превью в Maya, без mia_exposure? Ведь без tonemapping'а будут одни большие засветы.

mia_exposure лучше вообще не убирать, с помощью этой ноды надо диапазон HDR убавить под конец до 2-4, а то будут проблемы с АА, как в теме по ссылке выше (этого вполне хватит для постобработки). Можно, в принципе, и весь диапазон оставить, если нужны детали в очень засвеченных местах. Вообще прочитал, что проблема с АА актуальна не только для HDR рендеров, но и для обычных фоток, но в них "плохой" АА скрывается за свечением.

Мои настройки врут, читаем ниже =)

 

[DemX86]

Я щас читаю книгу Ментал рей для Maya,XSI 3д макс

Спасибо за совет, книжка уже лежит, ждет своего часа.

Dark™
Огромное спасибо спасибо за ответы! Тему про антиальясинг вообще искал три раза; не думал, что уже больше года прошло с тех пор.

Повышение времени связано с процессом запуска batch render

Я не отметил это в своем первом посте, но самую первую картинку (8bit, с mia_exposure) я тоже рендерил batch render'ом.

Но не помню, чтобы увеличение было столь значимым.

Вот и я про тоже, запуск batch render -- ну от силы секунд 30. Значит тут у меня какая-то аномалия...

Про sRGB читал, что этот профиль подразумевает gamma 2.2, стало быть это то, что нам нужно.

Просто чудовищно огромное спасибо за советы по настройкам Framebuffer gamma и mia_exposure.
Позволь отрезюмировать:
> Значит, если мы собрались рендерить в 32bit image, то не надо убирать с камеры mia_exposure: мы ее будем использовать для того, чтобы по-черновому обрезать диапазон HDR (до 2-4). А потом отрендеренную картинку мы финально tonemap'им в сторонней программе для постобработки.
В таком случае гамму во Framebuffer и mia_exposure выставляем 0,4545 для того, чтобы скомпенсировать гамму текстур, которая изначально равна 2.2.
Я все верно понял?

с помощью этой ноды надо диапазон HDR убавить под конец до 2-4

Диапазон HDR обрезается параметром Compression? Если ставим этот параметр 4, то наш диапазон будет от 0 до 4, так чтоли?

И еще вопрос из той старой темы: где находится этот самый Preview tonemap tiles? Не вижу его ни в mia_exposure_simple, ни в Framebuffer в Render Settings.

 

[Dark™]

В таком случае гамму во Framebuffer и mia_exposure выставляем 0,4545 для того, чтобы скомпенсировать гамму текстур, которая изначально равна 2.2.
Я все верно понял?

Все верно, но сама компенсация происходит лишь со значением Framebuffer, а mia_exposure уже работает с целой картинкой.

Диапазон HDR обрезается параметром Compression? Если ставим этот параметр 4, то наш диапазон будет от 0 до 4, так чтоли?

Не совсем. Compression сжимает все, что идет после значения Knee. Можно вместе использовать Gain (сжимает весь диапазон), Knee и Compression.

Preview tonemap tiles

Render Settings вкладка Options -> Preview

 

[DemX86]

Можно вместе использовать Gain (сжимает весь диапазон), Knee и Compression.

Значит тут получается такой workflow: мы подбираем эти три параметра так, чтобы у нас в Render View была более-менее вменяемая картинка? А потом, батч рендерим все это дело в 32bit для того, чтобы иметь возможность внести небольшие изменения в эту картинку?

P.S. Нажимал кнопку "Спасибо", а она не работает...

 

[Dark™]

Значит тут получается такой workflow: мы подбираем эти три параметра так, чтобы у нас в Render View была более-менее вменяемая картинка? А потом, батч рендерим все это дело в 32bit для того, чтобы иметь возможность внести небольшие изменения в эту картинку?

Не совсем, вполне хватит просто срезать диапазон, а все остальное довести в постобработке.

ЗЫ Кнопка работает 1 раз в неделю 1 юзеру.

 

[DemX86]

Dark™, я невероятно признателен тебе за помощь.

Правда остался еще вопрос, который не совсем понятен.

Framebuffer Gamma - 0.4545 (альтернатива, которая решает проблему с передачей цветов) ; mia_exposure - 0.4545 (тоже сохраняем линейность для постобработки)

По поводу Framebuffer Gamma понятно, почему там необходимо ставить значение 0.4545, ведь этот параметр хоть и называется Gamma, на самом деле это Gamma Correction, т.е. множитель, на который домножается гамма в Maya. Значение по умолчанию 1 означает, что гамма коррекция отключена. И мы ставим 0.4545, чтобы компенсировать гамму 2.2 текстур до единички. Тут все ясно.
А откуда тогда взята цифра 0.4545 в Gamma ноды mia_exposure? Это же не множитель, это действительно значение гаммы, значит по идее там должны быть значения именно гаммы, т.е. например, 1, 1.8 или 2.2.

вполне хватит просто срезать диапазон, а все остальное довести в постобработке.

Эх, может я опять чего-то не понимаю, но как в таком случае настраивать освещение в сцене, если в Render View при таком раскладе будет один большой засвет?

И еще по старой теме: значит, если мы используем mia_exposure, то обрезание диапазона HDR происходит до расчета AA? То есть mia_exposure как бы вклинивается между рендером картинки и просчетом AA, а не просто накладывается типа post process на финальную картинку с уже просчитанным AA, верно?

И еще я не совсем догнал, как это вы численно определяете выводимый HDR диапазон (например 0-2.0)? В результате каких математических действий над параметрами mia_exposure получается конечная цифра предела диапазона (2.0 в данном случае) -- это тупо Gain или какие-то формулы с зависимостями между Gain, Knee и Compression?

 

[Dark™]

А откуда тогда взята цифра 0.4545 в Gamma ноды mia_exposure

Мы ведь создаем изображение для постобработки? Я выше в скобках написал, это чтобы сохранить линейность, т.е. гамму 1, которая считается для итоговой картинки так (1/Framebuffer Gamma)*mia_exposure Gamma. Поэтому и 0.4545.

Эх, может я опять чего-то не понимаю, но как в таком случае настраивать освещение в сцене, если в Render View при таком раскладе будет один большой засвет?

Для проверки можно временно использовать настроенную ноду mia_exposure, чтобы картинка уже почти обработанной была вместе с Tonemap Scale и Convert Tiles. Или да, использовать то самое поле Use Preview в mia_exposure, зато пересчитывать не надо.

И еще по старой теме: значит, если мы используем mia_exposure, то обрезание диапазона HDR происходит до расчета AA?

Думаю, да, если только слот Use Preview не заюзан.

И еще я не совсем догнал, как это вы численно определяете выводимый HDR диапазон (например 0-2.0)?

А тут все не так просто. Можно например Knee поставить 2 и большой Compression, тогда верхняя граница будет где-то чуть выше 2. После 2 будет резкий спад. Поэтому желательно еще использовать Gain. А чтобы точную границу узнать, можно использовать программу по типу Artizen HDR, там это показывается.

 

[DemX86]

это чтобы сохранить линейность, т.е. гамму 1

Gamma 1 = линейность? А gamma 2.2 = нелинейность?
В итоге, как я понимаю, мы должны прийти к гамме 2.2 (гамма монитора), правильно? То есть этот этап должен проделываться в самом конце на постобработке, так?

Вообще прочитал, что проблема с АА актуальна не только для HDR рендеров, но и для обычных фоток

АА в фотографиях?.. Разве это не чисто CG явление?

 

[Dark™]

Gamma 1 = линейность? А gamma 2.2 = нелинейность?

Верно, если на монитор подать реальный линейный градиент от черного к белому с итоговой гаммой 1, то в итоге покажется нелинейная зависимость (та, что снизу). Поэтому картинка и подвергается коррекции (график сверху), чтобы на экране выглядеть линейно.

АА в фотографиях?.. Разве это не чисто CG явление?

В цифровых камерах используется матрица, а это тоже пиксели, и все проблемы с ними связанные.

 

[DemX86]

Назрел такой вопрос: каков полный диапазон у HDR? 0-10 (если принять 0-1 как диапазон у LDR)?
Эту цифру надо знать, чтобы можно было указать параметр gain (множитель, который, как оказывается, главным образом срезает диапазон. Например при диапазоне 0-10 и при gain=0.2 диапазон срежется до 0-2).
Просто цифры 0-10 часто упоминается в хелпе по mental ray, но явно не говорится, что это полный диапазон HDR.

Если немного подумать, то получится такая математика:
8bit image: кол-во градаций яркости равно: 2^8=256.
Тогда для 32bit image: 2^32=4 294 967 296 на каждый канал RGBA.
Значит разница в диапазонах будет: 4 294 967 296/256=16 77 7216 -- "всего лишь" в 16 миллионов раз больше? Тогда выходит, что если LDR диапазон принять за 0-1, то полный HDR составит 0-16миллионов? По-моему, многовато, где-то здесь подвох.

А для того, чтобы выставить правильное значение gain, мы должны решить форумлу:
gain=(крайнее значение желаемого диапазона)/(крайнее значение диапазона HDR).
Как стандартный пример: 1/10=0.1. Тогда, если мы хотим, скажем, получить диапазон 0-3, то: gain=3/10=0.3.
Какое же значение принимать как крайнее в HDR диапазоне?

 

[Dark™]

Gain не срезает, а так сказать масштабирует весь диапазон. Если его только Gain'ом уменьшить до 0-1, то могут потеряться некоторые детали в зависимости от того, чего больше - темного или светлого.

Значит разница в диапазонах будет: 4 294 967 296/256=16 77 7216 -- "всего лишь" в 16 миллионов раз больше? Тогда выходит, что если LDR диапазон принять за 0-1, то полный HDR составит 0-16миллионов? По-моему, многовато, где-то здесь подвох.

Почему же, все верно, это лишь цифры. В реальности же этот диапазон не выходит за рамки 0-100к.

Можно это еще почитать.

 

[DemX86]

Gain не срезает, а так сказать масштабирует весь диапазон.

Согласен, неточно выразился, тут скорее будет уместен термин "сжимает".

Я наконец-то проделал несколько опытов.
Итак, рендерим в 32bit image, формат openEXR.
Общие настройки mia_exposure_simple приведены на рисунке.1.
Откуда такие настройки:
pedestal по умолчанию 0, судя по всему его лучше не трогать;
gain 0.3 -- данное значение обусловлено стремление прийти к конечному примерному диапазону 0-3;
knee 2 -- после 2х значения белого цвета будут сжаты значением compression 3;
gamma -- менялось по ходу эксперимента.

[1]
Значение Framebuffer gamma (для полноты картины я буду называть его framebuffer gamma correction): 0,455. Это для компенсации гаммы 2,2 текстур.
Gamma в mia_exposure: 0.455. Это для сохранения линейности, необходимой нам для постобработки.
Вот что получилось: Картинка 2.
К полученному exr файлу был применен exposure с указанными значениями.
Вроде бы неплохо, но обратите внимание на журналы на столике: текстуры просто убита (рядом представлены оригиналы текстур). Плюс какая-то грязь на ковре.
Причем, надо отметить, что это все считалось в общем-то на production качестве, настройки приведены на картинке.4.
Но в тоже время, текстура пола как бы более приближена к оригиналу.

[2]
Теперь пробуем так:
Framebuffer gamma correction: 1
Gamma в mia_exposure_simple: 1
Итог: Картинка 3. (Тут я еще немного подтянул curves).
Как видим, более приятно: по крайней мере текстура журнала стала похожа на себя. Правда вот пол "немного отличается", но может это нормально, ведь он же на свету находится...

Причем для предварительного просмотра можно пользоваться теми же самыми настройками mia_exposure_simple, временно сбросив gain до 0.1 и установив gamma 2.2 (если framebuffer gamma correction 1).
Картинка.5 -- вполне достаточно для того, чтобы выставить свет.
А потом, для рендера в 32bit вернем gain и gamma в свои значения.


В общем, получается, что коррекция гаммы текстур 0,455 себя не оправдала?
К тому же я заметил, что рендер при гаммах 1 идет пошустрее, нежели при 0,455 -- может это потому, что не затрачиваются ресурсы на гамма коррекцию текстур?..
Dark™, поделись, пожалуйста, мыслями что ты думаешь по этому поводу.

 

[Dark™]

А можно сценку глянуть?

 

[Dark™]

Вообщем, я был неправ. Для 32 битных цветов все работает иначе. Гамма во Framebuffer не корректирует само изображение лишь текстуры, поэтому получается, что mia_exposure делает лишнюю операцию. Выходит можно такие настройки использовать:

• Framebuffer Gamma - 0.4545 (делает де гамму коррекцию текстур, но не трогает целую картинку)
• mia_exposure Gamma - 1 (сохраняет изображение в линейном виде)

И еще забыл сказать, что гамма коррекция для 32 битных изображений происходит программой просмотра и делать гамму коррекцию 2.2 итоговой картинки не надо, по крайней мере для просмотра в фотошопе формата EXR.

Поэтому мой первый метод идет в топку.

 

[DemX86]

Согласен, метод: framebuffer gamma correction 0.455 + mia_exposure gamma 0.455 не годится.
Картинка 1. Вот результат с framebuffer gamma correction 0.455 + mia_exposure gamma 1.
Вроде бы все хорошо, но если обратить внимание на текстуры шпатлевок в центральной конструкции, становится видно, что они весьма затемнены.

Даже не знаю, чем это обусловлено -- гамма-коррекцией текстур 0.455, либо тем, что эти области освещаются непрямым светом, потому и темные.

 

[DemX86]

Продолжая разбираться с вопросами гамма коррекции я сделал несколько тестов, которые по сути копируют тесты из этой статьи:
http://3dlight.blogspot.com/2008/09/linear-workflow-addition-1.html

Итак, есть задача настроить гамма коррекцию текстур для того, чтобы при рендере они не выглядели пересвеченными (washed out, как говорят наши западные коллеги).
В целом, при линейном техпроцессе, значения гаммы претерпевают следующие изменения:
Имеются текстуры sRGB, т.е. с гаммой 2.2, т.е. в нелинейном пространстве, как мы видим их на наших монитора. В итоге же нам нужно прийти к гамме 1.0, т.е. к линейному отображению. Поэтому мы должно сделать дегамму с коэффициентом 0.455, чтобы получить единичку в итоге (0.455х2.2=1.0).
Схематично:
[текстуры с гаммой 2.2] >> [gamma correction by 0.455] >> [linear workflow]

======================================================
Давай посмотрим на тестовую сценку.
Отмечу сразу, что в этой сценке мы будем рендерить только "в Render View", не в 32 битные файлы типа openEXR, поэтому конечную гамму (2.2) мы уже выставляем в mia_exposure (я ставил 2.0, но это ничего страшного). Для рендера в 32бита мы просто поставим тут гамму 1.0 и все.

Рисунок [01].
В сцене есть две плоскости: одна с обычной текстурой из файла (Lightnig из Final Fantasy XIII), другая (квадратная) -- с черно-белой текстурой на cutout opacity, + бамп с процедурной текстурой. Зеленый цвет нацеплен на diffuse через ноду ramp с одним цветом -- зеленым (G128 из color chooser, по модели RGB 0-255). На сфере процедурный checker с серыми (RGB128) и синими (B128) шашечками.
В сцене включен sun and sky, все настройки по дефолту, FG включен тоже по дефолту.
Все материалы, конечно же, mia_material_x.
mia_exposure_simple тоже, разумеется, присутствует.

В итоге, если мы оставим все as is и не будем запариваться гамма коррекцией, то получим размытые текстуры (как процедурные, так и обычные из файла). Как мы видим, серые, зеленые и синие цвета на этой картинке -- совсем не те средне серые/зеленые/синие (128 в RGB), как мы бы ожидали их увидеть.
*** Здесь, правая часть картинки FFXIII -- это наложенное сверху оригинальное изображение (помечено "original"), т.е. как оно выглядит у меня на экране (с гаммой 2.2).

Очевидно, что такая картинка нас не устраивает, поэтому давайте перейдем собственно к гамма коррекции.

======================================================
На текстуру FFXIII я добавил ноду gammaCorrection со значениями 0.455 и поднастроил mia_exposure_simple так (менял gain и knee, eне трогая при этом гамму), чтобы в итоге картинка FFXIII была как можно более похожа на оригинал.
Рисунок [02]

======================================================
Ок, теперь мы "прицелились" и можно пробовать гамма коррекцию в Framebuffer.
Ставим там 0.455, убираем с текстуры поставленную ранее GC ноду.
*** Замечание: Framebuffer gamma correction работает только при data type RBGA (Float) 4x32bit, в то время как ноды гамма коррекции будут давать эффект и при 8bit.
То есть если вы поставите framebuffer gamma 0.455 и оставите 8bit, то получите неадекват в окне Render View -- пересвеченную картинку. Значит, надо сразу выбирать data type 32bit float, если собираемся заниматься гамма коррекцией при помощи framebuffer gamma correction.

Вот что получаем:
Рисунок [03]

Тут мы видим, что немного чего изменилось-то, по сравнению с предыдущим рисунком.
То есть framebuffer gamma correction не влияет на процедурные текстуры и на простые цвета, он действует только на текстуры из файла. А это значит, что обычные цвета в Maya (даже если это материал mia_material_x) и процедурные текстуры изначально имеют гамму 2.2, а значит их тоже надо дегаммить для линейного процесса! (эту мысль первым отметил Dark). В общем-то, если подумать, то это действительно так -- мы же ведь в color chooser'e выбирам цвет такой, какой нам показывает нам наш монитор, значит нелинейно. Просто как-то неожиданно

======================================================
Раз процедурные текстуры и цвета в Maya тоже надо дегаммить, то добавляем к ним ноды gammaCorrection со значениями 0.455 (вот почему я не просто сделал цвет квадратной плоскости зеленым, а повесил на нее ramp с одним зеленым цветом -- чтобы потом можно было на этот рамп накинуть GC ноду).

Рисунок [04]
Теперь у нас все гаммы отдегамлены: и обычные файловые текстуры, и процедурные и простые цвета тоже.

Вывод: цвета материалов, процедурные карты и, конечно же, обычные текстуры из файлов изначально имеют гамму 2.2. И поэтому, если мы хотим рендерить в линейное пространство, нам нужно все это добро дегаммить (aka гамма-корректировать). С дегаммой текстуры из файлов хорошо подходит значение Framebuffer gamma correction 0.455 -- чтобы не ковыряться у каждой ноды текстуры, проставляя для них свой собственный 0.455 gammaCorrection node.


======================================================
Бонус-раздел:
Framebuffer gamma correction VS textures gamma correction nodes
Я окончательно пока не определился, как же все таки проводить гамма коррекцию для обычных текстур -- при помощи общего значения 0.455 в framebuffer'e, либо проставляя ноды гамма коррекции у каждой текстуры.

Поэтому я собрал недостатки этих методов:
Недостатки gammaCorrection nodes:
- во вьюпорте после этих нод смазанные текстуры (но это лечится изменением Hardware Tuxture > Texture Resolution, но все равно, дополнительные телодвижения)
- делать тестовые рендеры с Default Light (я так обычно делаю) неудобно -- эти текстуры будут темными

Недостатки Framebuffer Gamma Corection:
- текстуры с бампом, дисплейсом и альфа черно/белые тоже подвергаются коррекции, а нам это по идее не нужно (update: или все таки нужно??? они же тоже с гаммой 2.2, а нам нужна 1.0...)

Так что по-моему, выбор метода гамма-коррекции обычных файловых текстур при помощи framebuffer gamma correction имеет свои преимущества, и к нему надо приглядеться.

P.S. Мы пришли к выводу, что обычные цвета, которые мы выбираем в color chooser для diffuse тоже надо дегаммить, так как они там тусуются под гаммой 2.2. Пои дее, отдегамить обычные цвета можно, выставляя в RBG поля цвета заранее откорректированные значения. Например, для серого цвета RGB128, это получается надо ввести значения 128*0.455=58 (если округлить), и в таком случае мы получим на финале правильный, нужный нам серый цвет.

 

[Dark™]

DemX86, спасибо за столь подробные тесты. Но есть пару неточностей.

*** Замечание: Framebuffer gamma correction работает только при data type RBGA (Float) 4x32bit, в то время как ноды гамма коррекции будут давать эффект и при 8bit.
То есть если вы поставите framebuffer gamma 0.455 и оставите 8bit, то получите неадекват в окне Render View -- пересвеченную картинку. Значит, надо сразу выбирать data type 32bit float, если собираемся заниматься гамма коррекцией при помощи framebuffer gamma correction.

Framebuffer gamma (FBG) работает во всех случаях, но работает по-разному для 8, 16 битных картинок и для 32 битных.

1. Для 8, 16 битного режима (Data Type в настройках рендера) FBG делает коррекцию только для 8,16 битных текстур, для 32 битных - не делает + в этом контексте гамма коррекции подвергается и итоговая картинка, которая идет на рендер, то есть FBG выступает простым аналогом mia_exposure. Поэтому в данном случае настройки надо компенсировать

• Framebuffer Gamma - 1.0 ; mia_exposure - 2.2 (ноды дегамма коррекции для 8, 16 битных текстур)
• Framebuffer Gamma - 0.4545 ; mia_exposure - 1 (ноды гамма коррекции для текстур бампа, дисплейса, всякого рода прозрачности и т.п., чтобы компенсировать воздействие от FBG)

В обоих случаях итоговая гамма изображения будет 2.2.

2. Для 32 битного режима Data Type FBG не делает коррекцию итогового изображения для рендера.

А это значит, что обычные цвета в Maya (даже если это материал mia_material_x) и процедурные текстуры изначально имеют гамму 2.2, а значит их тоже надо дегаммить для линейного процесса! (эту мысль первым отметил Dark). В общем-то, если подумать, то это действительно так -- мы же ведь в color chooser'e выбирам цвет такой, какой нам показывает нам наш монитор, значит нелинейно. Просто как-то неожиданно

Поговорив с Павлом, оказывается все интереснее. Он отметил, что все в майе изначально имеет гамму 1 (как я и раньше думал, но под конец ожидал всего =). И выбираем мы линейный цвет. И видим мы его таким, каким показывает монитор, то есть все Color Swatch'ы посылают на наш монитор линейный цвет, который прежде проходит некоторую стороннюю коррекцию, например, в драйверах монитора или видеокарты, как я впоследствии понял. Поэтому все не так очевидно. Если мы выбираем линейный цвет, то реальный цвет покажется, только после гамма коррекции. Выходит, что ноды GammaCorrect для Color Swatch служат лишь средством показать в итоговой картинке тот линейный цвет, что мы выбираем и видим в гипершейдере.

Это означает, например, что для цвета, отличного от белого или черного, Ramp'ы, Cheсker'а, источников света, процедурных текстур и т.п. надо вводить дополнительную ноду, чтобы добиваться на рендере c итоговой гаммой 2.2 выбранных цветов. Но будем надеется, что в следующей версии Майи сделают более точный контроль над гаммой для всего, в том числе и для Color Swatch'ей.

Framebuffer gamma correction VS textures gamma correction nodes
Я окончательно пока не определился, как же все таки проводить гамма коррекцию для обычных текстур -- при помощи общего значения 0.455 в framebuffer'e, либо проставляя ноды гамма коррекции у каждой текстуры.

Может эта статейка еще добавит небольшой аргумент в пользу одного из методов =)

- текстуры с бампом, дисплейсом и альфа черно/белые тоже подвергаются коррекции, а нам это по идее не нужно (update: или все таки нужно??? они же тоже с гаммой 2.2, а нам нужна 1.0...)

Конечно, не нужно, они рисуются в линейном пространстве и содержат лишь информацию высот, прозрачности и векторов. Зачем им гамма, вы ведь не смотреть их делаем.