1. Этот сайт использует файлы cookie. Продолжая пользоваться данным сайтом, Вы соглашаетесь на использование нами Ваших файлов cookie. Узнать больше.

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

Тема в разделе "Фото", создана пользователем Talon, 30.05.11.

  1. Talon

    Talon Активный участник

    2.020
    1
    Купил себе новый моник, откалибровал его... и вот после обработки серии фотографий в lightroom, после конвертирования при просмотре в просмотровщиках фото явно имеют оттенок иной и контрастную составляющую... думаю WTF, вроде как привык конвертил в sRGB (до этого не было никогда таких проблем), дай думаю сконверчу с выбором профиля который при калибровке получился...ставлю,и опля на выходе в просмотровщике, тот же результат что и в лайтруме..
    Так вот к чему я...почему щас у меня так получилось, раньше же такого не было, и сам механизм интересен, он получается мой профиль встраивает в файл или адаптирует хз...
    самое что меня тревожит это как эти фото будут на другом компе и монике смотреться. (насчет что моники у большинства не калиброванные и обычный ползьователь увидит фиг знает что эт я знаю)
     
  2. DimaP

    DimaP Активный участник

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

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

    Talon Активный участник

    2.020
    1
  4. DimaP

    DimaP Активный участник

    9.822
    0
    Talon, она закрытая:)
     
  5. UncleSam

    UncleSam Активный участник

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

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

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

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

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

    Talon Активный участник

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

    UncleSam Активный участник

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

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

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

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

    Talon Активный участник

    2.020
    1
    т.е. в виндовс должен стоять профиль сргб, а подгрузка поправок в видеокарту осуществляться должна программой сторонней при каждой перезагружке?
     
  9. UncleSam

    UncleSam Активный участник

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

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

    doberman* Активный участник

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

    DimaP Активный участник

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

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

    UncleSam Активный участник

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

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

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

    Akvilon Активный участник

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

    UncleSam Активный участник

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

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

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

    Akvilon Активный участник

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

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

    DimaP Активный участник

    9.822
    0
    [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]
     
  17. Akvilon

    Akvilon Активный участник

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

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

    nibumbum Активный участник

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


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

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


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

    UncleSam Активный участник

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

    DimaP Активный участник

    9.822
    0
    Это значит что эта разница не имеет значения.
    Поставь камеру на штатив, перейди в 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.
     
    Последнее редактирование: 02.06.11
  21. nibumbum

    nibumbum Активный участник

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


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


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

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

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


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

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

    DimaP Активный участник

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

    nibumbum Активный участник

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

    DimaP Активный участник

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

    Один пиксель ничего ценного не содержит. Там значения тона с шумом в несколько бит. Нельзя ткнуть в пиксель и сказать что в этом месте вот такой-то цвет. Можно сказать что в пикселе цвет находится вот в таком-то диапазоне. И даже для 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 бит - совершенно не ясно.
     
    Последнее редактирование: 02.06.11
  25. nibumbum

    nibumbum Активный участник

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


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


    На самом деле 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. Эй, тут есть ещё кто ни будь живой? Это хоть кто ни будь читает? Все эти "теории" ещё кому ни будь интересны, кроме нас с Димкой?
     
  26. DimaP

    DimaP Активный участник

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

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

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

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

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

    Врятли. Остальным интересно не заморачиваясь пользоватся 16 битами.
     
    Последнее редактирование: 02.06.11
  27. Talon

    Talon Активный участник

    2.020
    1
    я так через строчку ваши математико-визические рассуждения проглядываю ))
    че могу сказать по теме, так что раньше у меня небыло проблемы с профилями, откалибровал... профиль калибровачный в системе по умолчанию... везде все по цветам одинаково а тут на тебе обновил лайтрум до версии 3.4 (я именно с этим связываю это) и понеслось разброд... пока спасаюсь как выше описано переключением профилей когда лайтруме работать сажусь... потом наверное свадьбу доделаю и откат с удалением полным на старую версию лайтрума сделаю посомтрю что будет.
     
  28. nibumbum

    nibumbum Активный участник

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

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

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

    DimaP Активный участник

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

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

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

    UncleSam Активный участник

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

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

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