Цветовые профили и рабочие пространства

Talon, просмоторщик и лайтрум, в твоем случае, используют разные профили монитора. Скорее всего лайтрум подцепил профиль моника, а просмоторщик нет.

Это рабочего пространства не касается, оно хоть адобе может быть, хоть фотопро. В ЛР, по моему, именно рабочее простраство, всегда фотопро.
При экспорте отдачи полюбому должно быть sRGB.
Для того чтобы увидеть как на голом монике будет отображатся, надо выключить профиль в системе, и открыть просмоторщиком, в котором поддержка профиля отключается, например irfanview.

 

Talon, она закрытая

 

По-хорошему, чтоб все проги отображали плюс-минус одинаково, надо бы рабочим профилем во всех программах выставлять sRGB, а в LUT видеокарты (лучше бы монитора, но это отдельная история) соответствующей программой грузить соответствующую корректировочную таблицу (во вновь созданном профиле она присутствует в виде так называемого vcgt-тэга). Тогда все будут думать, что мы работаем в чистом sRGB, а монитор будет отображать картинку с учётом поправок.

Чистую загружалку поправочной таблицы можно брать из комплекта ArgyllCMS, называется она dispwin. Из свойств дисплея полученный в результате калибровки профиль удаляем и вместо него пихаем стандартный системный sRGB. dispwin с нужными параметрами ставим в автозагрузку, чтоб он корректировал видюху.

Ещё надо вычистить из реестра где-то там висящую ссылку на профиль, который адобовские проги подгружают, даже если в системном профиле указано другое. Точный адрес этой гадости не помню, к сожалению. Ветка будет что-то там Adobe, а параметр - что-то там .icc. Эту строчку надо убивать самым беспощадным образом. И, разумеется, убивать из автозапуска любые упоминания про Adobe Gamma.

В общем, всё плохо и без ящика водки там не разберёшься Беда ещё и в том, что даже работать в одном и том же профиле, то всё равно разные проги будут несколько по-разному картинку отображать. К примеру, всем известная фишка, что лайтрум показывает одно, а когда грузишь в фотошоп экспортированный файл, то цвета слегка уплывают. Не сильно, но заметно.

Если хоть что-то из вышеописанного непонятно, то одинаковой цветопередачи не будет Собственно, её и так никогда не будет, но так мы вычистим хотя бы самую большую грязь.

 

И не надо, чтоб воспринимал. Работать надо в чистом sRGB и только в особых случаях при наличии супер-пупер дисплеев, калибраторов и устройств вывода (явно не наша ситуация) переходить в адобе или wide gamut. Но тогда весь рабочий процесс должен быть настроен на этот расширенный охват. В остальных же случаях сторонние профили (в том числе и калибровочные) - зло. Ну то есть, это моё личное мнение. Я считаю, что со снимками надо работать в чистом сргб, а дисплей настраивать так, чтобы он стал sRGB-шным. Так как он исходно таковым не является, то к худо-бедно эсэргебешному виду мы его приводим с помощью загрузки в LUT (LookUp Table) поправочной таблицы.

Калибровка - процесс, который на выходе даёт профиль, рассказывающий программам, каков на самом деле этот монитор. А это нам нафиг не надо. Нам вынь, да положь sRGB. Поэтому готовые профили в систему грузить чрезвычайно вредно. Именно из-за этого и происходят косяки, описанные выше.

Может, где в рассуждениях или исходных предпосылках я и ошибаюсь, но данное мировоззрение позволяет мне получать на практике именно то, что задумано. Ну с учётом разброса цветов при печати, естественно.

Короче, реестр надо чистить.

 

Talon, совершенно в дырочку. Ну сторонней там или родной - не суть важно. Главное - чтобы системным и специальным программным (как у, мать его, адобе) профилем был именно sRGB. К примеру, сейчас я подружился с Huey Pro и научился пользоваться егойным родным софтом. Но так как я работаю не под администратором, то эта прога доступа к профилю дисплея не имеет и только лут корректирует. А в системе явным образом прописан sRGB. И все без исключения программы отображают картинку плюс-минус одинаково. Если б не кривые руки индусских программистов, то и вовсе бы одинаково было. Потому что должно быть, вообще-то, одинаково.

Просто если профиль никакой не прописан, то, может, сргб присваивается, а может, и нет. Так что лучше явно прописать.

 

16 битный адоб. больше оттенков и как следствие меньше потерь при обработке.

 

UncleSam, ты путаешь рабочее пространство с пространством отображения. Идеальное рабочее пространство - линейное. И sRGB весьма далек от этого идеала, намного дальше Adobe и ProPhoto.

doberman*, для фото пофиг 8 или 16

 

DimaP, ну как тебе сказать "путаю". Да, путаю, наверное. Но чудится мне, что калибраторы, когда делают профиль, пытаются впихивать рабочее пространство в пространство отображения монитора, а это не есть совсем уж прекрасно и замечательно.

Кароч я изучил вопрос настолько, чтобы все программы показывали одинаково, а на печати получалось то, что на экране. Если при этом страдает терминология, тем хуже для терминологии Подробнее учить смысла нету пока что. Ну это как, допустим, нету смысла считать через релятивистские уравнения время путешествия из пункта А в пункт Б.

Разумовский в 3-м номере "Издато" на стр. 179 показывает, что разница есть.

 

А по мне так разница весьма и весьма ощутима.

 

Прям вот "весьма" или же просто ощутима? Мне до сих пор не удавалось разительной разницы обнаруживать. Честно говоря, на глаз её считай, что и нету. Скажу больше: тянуть в шопе, к примеру, небо даже в 16 битах без полос не получается. Т.е. тянуть значимые участки всё равно лучше в руме.

В двух словах о том, что Разумовский пишет: если крутить уровни, кривые и т.д., то в 8 битах после накрутки гистограмма получается полосатая, а в 16 - сплошная. Т.е. в 8 битах градации при обработке теряются.

Насчёт же адобе и вайд гамут скажу так: это изврат до тех пор, пока нет задачи выводить информацию в этом пространстве и пока не стоит перед носом моник с расширенным охватом, откалиброванный правильным калибратором. Может, и ошибаюсь, конечно.

 

Это смотря что для тебя "весьма". Для меня всё, что я могу увидеть невооруженным взглядом - это уже весьма и весьма. Можешь это тоже считать максимализмом, но я не вижу причин для отказа для него - работа с 16 не создает для меня никаких дополнительных сложностей, так зачем урезать? Опять же, всё зависит от дальнейшей постобработки. Я порой в шопе довольно активно работаю с градиентами. И разницу вижу. Еще как вижу.

А вот, кстати, сколь бы то ни было существенную разницу между "с" и "адоб" не вижу. В теории прекрасно понимаю, где именно там у адоба охват шире. А на практике не ощущаю реальных преимуществ.

 

[off]

Он не показывает, он рассказывает что есть разница. Если делать в шопе вещи которы надо делать в конверторе (тянуть тени, спасать света, экспокоррекцию, контраст), то вполне можно насребсти разницу. Но зачем же так делать?
На фото достаточно шума чтобы разницы между 8 и 16 битами была не видна.

---------- Сообщение добавлено 01.06.2011 21:18 ----------

Их там нет этих градаций, и потерятся они не могут. Не найдешь ты на фото чистого цвета 100 и 101, ибо шум, а шум прекрасно скрывает постеризацию.

---------- Сообщение добавлено 01.06.2011 21:21 ----------

А вот товарисчь нашел http://medvedevphoto.livejournal.com/20005.html?thread=389157 Кто ищет тот всегда найдет Это вам не на гистограммы пялиться.
Правда нет никаких проблем одним кликом получить такой-же красный канал в sRGB.

---------- Сообщение добавлено 01.06.2011 21:23 ----------

Сдобри градиент шумом и не увидишь.[/off]

 

Пожалуй, почитаю, как делать будет совсем нечего

Да это всё понятно. А если сделать даунсайз до 100 точек по длинной, да сохранить в джепег с максимальным сжатием, а потом сравнивать на экранчике мобильника - так вообще не увидишь разницу даже между нормальной камерой и встройнной в этот самый мобильник )))

 

Не верно!
И дисплеи/калибраторы тут не при чём ;о)
Впрочем если выходишь в пользовательский формат прямо из конвертора - безразлично. Даже полезно сРГБ поставить в конверторе. Что бы видеть сразу конечный результат.
В лайт-руме и АРС всё равно будет ОДИН просчёт и один транкейт в финале.
А вот если нужно выходить в фотошоп - аРГБ как минимум! Потому что это даёт примерно в полтора раза больше информации!!! А чем больше инфы - тем чище результат. И это даже для простого ресайза очень актуально..
И только один раз, в финале, при выходе в пользовательский формат, можно транкейтить на понижении битности..

Если кто то, на своих мониторах, не видит разницы - это вовсе не означает, что её нет!

Ещё раз: суть корректной работы с любыми цифровыми данными - сохранять максимальное количество инфы до самого конца, до выхода в пользовательский формат. И только там, один раз можно(приходится) транкейтить.
(транкейт - обрезание битности, отбрасывание информации которая не умещается в разрядную сетку)
Только такой принцип работы позволяет свести к минимуму искажения и артефакты.

Эта операция называется дитерингом (dithering). В некоторых модулях даже галочку "dither" можно поставить ;о)
При конвертации цветового пространства он тоже применяется.. ;о)
Суть процесса в добавлении шума, не коррелированного с полезной информацией, на уровне младшего бита, с целью "размазать" и сделать не заметной ошибку возникающую при транкейте

 

nibumbum, кажись, я понял, о чём ты. Смею предположить, что выводить в более широкое, чем сргб, цветовое пространство, имеет смысл только в 16 бит. Правильно?

 

Это значит что эта разница не имеет значения.

Поставь камеру на штатив, перейди в LV, и с тросика серией снимим белую однородную стену или там натюрмор. Вычти два снимка - получишь разницу укладывающуюся в 2-3 бита, т.е. два снимка одного и того же не одинаковы. О каких потерях тонов в младших битах можно при этом говорить?
При обработке сигнала с шумом необходимо что бы разрядности хватало для отображения устойчиво различимого сигнала. Если шум будет в 2 бита, то что 8 битами кодировать, что 7 - без разницы. Шум сведет картинку к 6 битной.
http://theory.uchicago.edu/~ejm/pix/20d/tests/noise/noise-p3.html
Особо показательны Fig. 17 и Fig. 18

Ну и потом, откуда взялись 16 бит из 14 битного рава (тем более из 12ти) после наложения гаммы? Гамма это степенная функция которая в целочисленной арифметике неизбежно ведет к потерям. И после этого все равно надо еще 2-4 бита выдумать, потому что взяться им неоткуда.

Ну и в третьих - 8 бит на канал это 24бит на три канала, это 16млн цветов. Соседние из которых человек отличит только на больших плашках. Два соседних пикселя различных цветом в один бит человек не отличит. 9бит это уже бред для фотографии, не говоря уже о 16.

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

Битность и охват цветового пространства никак не связаны. 8битный sRGB уже чем 8битный же AdobeRGB.

 

Не обязательно. Зависит от того, что делать нужно. Как ни будь объясню подробно, при встрече :о)

К сожалению имеет значение! (
Она имеет значение для обработки, Дим. Для математики и пересчётов.. А не для того, что мы видим..

Они и не обязаны быть одинаковыми :о) Ты ещё про неодинаковость снимков сделанных в аналоге расскажи нам... xDDD
АЦП не может отработать одинаково, это заложено в математике его алгоритмов.. И влиять на это пользователь никак не может ;о)
А вот влиять на последовательность и корректность, с точки зрения математики, обработок в праве пользователя ;о) Так почему же этим не пользоваться?! :о)))

В том то и подвох! Любая обработка, даже банальная яркость/контрастность ведёт к увеличению битности до максимальной. До той точности с которой работает программа...
Потому что любая обработка это умножение каждого значения на некий коэффициент.. А он далеко не всегда цельночисленный.. - получаются значения которые превышают возможности разрядной сетки... Что не умещается - отбрасывается.. Этот транкейт неизбежен (
Но в высшей разрядности/разрешении он вызывает гораздо меньшую деградацию....
А ещё он имеет свойство "накапливаться"..

Короче тут всё как в жизни - бесплатных пирожных не бывает :о) и любая обработка/улучшение картинки ведёт к неизбежной деградации данных ;о) Вопрос лишь в том, что бы максимально минимизировать её последствия :о)

Понимаю, что это не очевидно, но они связанны :о) Так же как и разрешение с битностью... ;о)
Если говорить совсем простыми словами - и то, и другое, и третье количество информации.
И чем её больше - тем изощрённее можно с ней работать и сделать неизбежные потери менее заметными. Всё. Dixi

P.S.
DimaP, ссылку мельком глянул, ничего не понял, разбираться дотошно нет времени..
С математикой цифровой обработки данных я лет десять назад разбирался с пристрастием :о) Сейчас уже лениво снова в глубь лезть.. А так как законы физики, методы кодирования данных и структура хранения файлов не изменились с тех пор - вроде как и надобности нет :о) Достаточно просто соблюдать несколько простых правил, которые вполне позволяют минимизировать потери ;о)

 

Пересчета чего, шума? Мы и не видим разница только потому что на фото есть шум.

 

смотри ниже, я про коэффициенты все подробно написал.
"Пересчёт" значений каждого пикселя в изображении...

 

Да причем тут АЦП. Для среднесерого и светов, шум АЦП и шум чтения это принебрежимые крохи, по сравнению с фотонным шумом. В иделальной матрице, с нулевым шумом чтения, картинка будет содежать шум. В этой вселенной так.

Один пиксель ничего ценного не содержит. Там значения тона с шумом в несколько бит. Нельзя ткнуть в пиксель и сказать что в этом месте вот такой-то цвет. Можно сказать что в пикселе цвет находится вот в таком-то диапазоне. И даже для 8 битной фото дельта диапазона больше 1 бита.

8 битный цвет 150/150/150 в 16 бит будет записан как 38400/38400/38400, умножаем на коэф 1.789, получаем 255/255/255 в 8 битах и 65565/65565/65565 в 16ти. При этом, если шум для 8 бит был, допустим, 2бита, то в 16 битах он будет 9-10. Ну будет шум вычислятся точнее, дальше то что?

Которые чаще всего являются мнимыми потерями

Цветовой охват это не количество информации, это разброс реальных цветов закодированных в пространстве. Напомню, что цетом можно назвать только то что видит человек.
В одном цветовом пространстве яркозеленый кодируется допустим как 255, в другом как 125. Это один и тот же физический цвет, например яркоосвещенной травы. Оба пространства 8 битные, при этом второе шире первого, так как у него есть суперяркий зеленый закодированый как 180 и мегаяркий зеленый 255, которые в первом пространстве просто нет, оно далеко за его границами. Пространства могут быть хоть однобитными, при этом разного охвата.

Чем выше разрешение, при равной площади кадра, тем меньше нужна битность. Пленка вообще однобитна.
Если конечно обрабатывать файлы в разрешении 200 на 200, то я не спорю, надо 16 бит, но зачем для много мекапиксельных фото 16 бит - совершенно не ясно.

 

и поэтому тоже файлы разными будут

Да. Но(!) пересчитываются ВСЕ.. И все с ошибкой ... ;о)

На самом деле 268,35 :о) Это не совсем корректный пример. Изменю условия:
8 бит, 149/150/151
коэффициэнт 1.28
результат 190,72/192/193,28 превышает возможности разрядной сетки! Происходит транкейт... ОГРУБЛЕНИЕ
И так при каждой операции... А то, что потеряно - "востановить взад" невозможно (

В 16 битах - 38300/38400/38500
коэффициэнт 1.28
результат 49024/49152/49280 уместился в разрядную сетку, мы не потеряли информацию!

Ну вот было у тебя в исходнике просто зелёный, мега и супер зелёные, вышел ты в sRGB в фотошоп, и весь твой зелёный стал ПРОСТО зелёным, без оттенков и градиентов к мега и супер... - то есть ты потерял часть информации...... Fatal Error

Дим, ты конечно можешь сказать, что и на фиг она не нужна :о))
Да, часто этого не заметно. Но и часто, когда какая то изощрённая обработка нужна, эти потери становятся слишком сильны.

Ошибочка! Это только в цифровой реальности она однобитна :о)))
В отличии полностью плоской матрицы плёнка трёхмерна.... И в каждой её точке не одно зёрнышко... ;о)
Как это влияет на реальную битность думаю не нужно объяснять? ;о)

P.S. Эй, тут есть ещё кто ни будь живой? Это хоть кто ни будь читает? Все эти "теории" ещё кому ни будь интересны, кроме нас с Димкой?

 

И что? Ошибка квантования не превышает один бит. Если у тебя и так шум больше бита, то этой ошибки считай что нет.

А шум где? Твой пример работает когда шум 0. При шуме больше нуля уже нет.
Ты не забывай что все равно потом конвертить в 8 бит, и вся твоя точность пропадает.

Я прекрасно знаю где вылезет недостаток 8 бит - тянем тени в отконверченном изображении и и получаем каку. Только нахрена это делать после конвертации, если можно во время.
Не вопрос, для бездумной обработки естественно 16 бит удобней, не надо тратить время на подумать заранее и в грамотной последовательности обрабатывать файл.

А причем тут битность? В sRGB любой битности просто зелёный, мега и супер зелёные, будут просто зеленым.

Я говорил о том что зерно как неделимый атом избражения имеет один оттенок или не имеет его вообще, т.е. однобитен. Это всего лишь иллюстрация того что при большом разрешении битность снижается до предела, т.к. смысл в многобитности теряется.

Врятли. Остальным интересно не заморачиваясь пользоватся 16 битами.

 

понятно.

Если я выйдя в адобе в фотошоп буду, например, уменьшать яркость - всё сдвинется и при конвертации в пользовательский сРГБ какие то оттенки и градиенты в этом зелёном останутся...
Но если я выйду в фотошоп через сРГБ - там уже ничего не будет кроме ровно-зелёного..
Информация будет потеряна!

деградация накапливается... Увы. Поэтому лучше сразу избегать..
Собственно вот и весь спик.
Есть простой алгоритм корректной работы с цифровыми данными. Если его придерживаться - никаких артефактов не наловишь по глупости :о) Причём это не только в обработке изображений..

Всё, Дим, давай сворачиваться :о) Мы с тобой можем и в реале это обсудить ;о)

 

Сем - Смею предположить, что выводить в более широкое, чем сргб, цветовое пространство, имеет смысл только в 16 бит. Правильно?
Я - Битность и охват цветового пространства никак не связаны.
Ты - Понимаю, что это не очевидно, но они связанны :о) Так же как и разрешение с битностью... ;о)
Если говорить совсем простыми словами - и то, и другое, и третье количество информации.
Я - Цветовой охват это не количество информации, это разброс реальных цветов закодированных в пространстве. ... Пространства могут быть хоть однобитными, при этом разного охвата.

Дальше ты приводишь пример иллюстрирующий охват, но никак не касающийся битности. В твоем примере адоб может быть и 8 битным, а сРГБ 16ти, и все будет на тех же местах - при понижении яркости останутся оттенки, а в сРГБ их как не было так и не будет.

Это как утверждать что света из рава спасаются потому что там 12-14 бит, а из камерного джипега не спасаются потому что там только 8бит. Но на самом то деле не по-этому.
Диапазон значений физической величины и битность ее кодирования для обработки не связаны. Одним битом можно закодировать диапазон в 16EV, а можно 1EV

 

Подведём итоги: кто видит разницу, обрабатывает в 16-битном тифе адобе, кто не видит - в 8-битном сргб-шном жпеге. Лично я, как ни прискорбно, разницы ни хрена не вижу. Но примерчик от Медведева меня заинтересовал, как-нибудь при случае поэкспериментирую.

Вот чем отличается рав от тифа и жпега - прекрасно вижу и понимаю, а с ентими пространствами - вопрос открытый.

На самом деле жутко не хочется с конвертациями битов и цветовых пространств заморачиваться. В сргб 8 бит всё просто и быстро. В адобе, широком охвате и лабе 16 бит всё сложно, долго и объёмисто.