Помогите разобраться AdobeRGB или SRGB.

Всего 209 сообщ. | Показаны 181 - 200
Re[vga50]:
Цитата:
от: vga50
imho, и для принтера и для монитора данные готовятся как 8битные RGB именно из за ограничений архитектуры.

И мне так кажется.
Цитата:
от: vga50
А значит, поскольку эти RGB описывают широкое пр-во,

А вот так мне не кажется: никто не сует в монитор тройки чисел, описывающих цвет в sRGB/AdobeRGB/ProPhotoRGB и т. д. Иначе бы монитору пришлось бы самому думать о том, что (128, 0, 0) в одном случае означает один цвет (и субпиксели надо зажигать с одной интенсивностью), а в другом - другой (и интенсивности должны быть другие). Для таких размышлений монитор слишком туп.
Цитата:
от: vga50
Можно замеппить все 255 wRGB на 255 значений монитора - ну и что получим? Assign sRGB? :)

В таком случае мы получим Assign (профиль монитора).

Но замапить можно и иначе.

Пусть монитор способен отобразить 256*256*256=16 млн. цветов. Этот набор цветов не совпадает (какие бы кнопки на мониторе мы не нажимали) с набором из 16 млн цветов восьмибитного sRGB (или любого другого пространства). Это просто какие-то 16 млн цветов. Посылая в монитор sRGB'шные данные (как это и происходит при просмотре картинок в IE при полностью отсутсвующей CMS) мы получаем на экране совершенно произвольное по цвету изображение - поскольку у каждого монитора свои представления о том, что такое (255, 128, 0). Кончено, красный с синим никто местами не меняет, но "красный" на двух разных трубах может быть абсолютно разный.

Теперь мы берем калибратор, и с помощью него измеряем (допустим, в XYZ), какие цвета каким тройкам чисел у данного монитора соответствуют. Результаты измерений записываются в профиль монитора. Затем, когда мы просим компьютер нарисовать на экране плашку sRGB(255, 128, 0), он пересчитывает эту тройку чисел в XYZ (правила этого пересчета есть в профиле sRGB) и ищет такой же XYZ в профиле монитора. Точно такого же там может и не быть, но есть максимально похожий, и ему соответствует тройка чисел, к примеру (240, 140, 17). Вот эту тройку видеокарта и передает монитору, и он отображает цвет именно с таким XYZ, как надо.
Re[vga50]:
Цитата:
от: vga50
Значит wRGB 128,0,0 будет показан как sRGB 255,0,0; 127->253, 126->251 и т.д. Половина возможностей монитора (254,0,0) не используется, а половина wRGB (129-255) не показывается. :)

Так поэтому я все время и повторяю, что для широких пространств особенно важно пользоваться 16тибитным представлением. Тогда, продолжая Вашу аналогию (хотя это все очень мало похоже на то, что происходит в действительности), мониторное (254, 0, 0) будет соответствовать wRGB (127.5, 0, 0).

Половина wRGB, естественно показываться не будет - выше головы не прыгнешь.
Re[miope]:
Цитата:

от:miope
А вот так мне не кажется: никто не сует в монитор тройки чисел, описывающих цвет в sRGB/AdobeRGB/ProPhotoRGB и т. д. Иначе бы монитору пришлось бы самому думать о том, что (128, 0, 0) в одном случае означает один цвет (и субпиксели надо зажигать с одной интенсивностью), а в другом - другой (и интенсивности должны быть другие). Для таких размышлений монитор слишком туп.

Подробнее

Конечно, не так. Color engine рассчитывает, какие РГБ послать, чтобы получить нужные XYZ. чтобы XYZ монитора совпадал с XYZ sRGB или wRGB. Но в видеокарту посылается именно RGB. RGB аппаратного пр-ва монитоа..
У Вас стоИт системный профиль? Сделайте простой опыт. Сделайте заливку aRGB 170,0,0 скажем 200х200, скопируйте и сконвертите копию в sRGB. Пипетка покажет 210,0,0 (под рукой ФШ нет, так что цифры примерные) Все нормально. Теперь делаем PrintScreen и наклеиваем картинку в ФШ. А теперь посмотрите пипеткой - в скриншате должны быть те RGB, которые ФШ шлет в видеокарту. Их фотошоп рассчитал из профиля монитора.

Цитата:

от:miope
В таком случае мы получим Assign (профиль монитора).

Но замапить можно и иначе.

Пусть монитор способен отобразить 256*256*256=16 млн. цветов. Этот набор цветов не совпадает (какие бы кнопки на мониторе мы не нажимали) с набором из 16 млн цветов восьмибитного sRGB (или любого другого пространства). Это просто какие-то 16 млн цветов. Посылая в монитор sRGB'шные данные (как это и происходит при просмотре картинок в IE при полностью отсутсвующей CMS) мы получаем на экране совершенно произвольное по цвету изображение - поскольку у каждого монитора свои представления о том, что такое (255, 128, 0). Кончено, красный с синим никто местами не меняет, но "красный" на двух разных трубах может быть абсолютно разный.

Теперь мы берем калибратор, и с помощью него измеряем (допустим, в XYZ), какие цвета каким тройкам чисел у данного монитора соответствуют. Результаты измерений записываются в профиль монитора. Затем, когда мы просим компьютер нарисовать на экране плашку sRGB(255, 128, 0), он пересчитывает эту тройку чисел в XYZ (правила этого пересчета есть в профиле sRGB) и ищет такой же XYZ в профиле монитора. Точно такого же там может и не быть, но есть максимально похожий, и ему соответствует тройка чисел, к примеру (240, 140, 17). Вот эту тройку видеокарта и передает монитору, и он отображает цвет именно с таким XYZ, как надо.

Подробнее

Все правильно, и я именно то же самое пытался рассказать выше. :) Когда я говорил wRGB 128,0,0 я имел ввиду цвет в этом пр-ве, а не тот факт что именно эта триада посылается в видеокарту.

Но я не об этом. С sRGB все понятно, а вот если мы просим показать например aRGB 230,0,0 на монитор шлется уже 255,0,0 (а на моем ноуте, 255,0,0 посылается уже при 210,0,0) Очевидно, 230 уровней aRGB были отображены (замеппались на) 255 уровней монитора. А 25 пропали, а с ними 10% возможных цветов. С более широкими пр-вами дискретность растет еще больше. На принтере та же картина, поэтому печать широких пр-в остается проблемой.
Re[vga50]:
Спорили мы там много очем :D :D
В конце пришлось доказывать что вообще существуют картинки, не влезающие в сРГБ :)
Ну да бог с ним..

Можно вам вопрос? Я конвертирую с сохранением профиля камеры. Потом небольшая коррекция в шопе обычно, без конвертации в рабочее простанство, т.е. она происходит в пространстве камеры. Считал, что чем меньше конвертаций, тем лучше. Судя по вашим словам это неверно? Как лучше/правильнее? Конвертировать в рабочее пространство? (ну т.е. в аРГБ :) )

PS А вы тоже за 8-бит форевер?

PPS Мне казалось, что возможность конвертации в пространство камеры - одно из преимуществ КепчерВана. И я не говорю о серьезной коррекции. Так, мелочи, чуть уровней может быть, локальный контраст, тудым-сюдым... Если приходится что-то серьезно крутить (в меру умения, ну или неумения), тогда конвертирую сразу в абстр пространство.
Re[vga50]:
По поводу основного спора- можно я вас тоже спрошу - правильность/целесообразность выбора абстр пространства на ваш взгляд зависит от качества монитора фотографа?
Ну давайте возьмем крайний случай - коррекции в шопе нет. Вообще. Коррекция в конвертере его средствами и дальше на печать через шоп. Тогда зачем резать цвета?

И что лучше - напечатать то, что сняла камера, но не показал монитор, или не печатать этих цветов вообще никогда?

И все, все, на эту тему я дальше молчу, аки рыба об лед... :)
Re[vga50]:
Цитата:

от:vga50

Но я не об этом. С sRGB все понятно, а вот если мы просим показать например aRGB 230,0,0 на монитор шлется уже 255,0,0 (а на моем ноуте, 255,0,0 посылается уже при 210,0,0) Очевидно, 230 уровней aRGB были отображены (замеппались на) 255 уровней монитора. А 25 пропали, а с ними 10% возможных цветов. С более широкими пр-вами дискретность растет еще больше. На принтере та же картина, поэтому печать широких пр-в остается проблемой.

Подробнее

Ну разве что в последний раз
Согласен с миопом и не согласен с вами.
В аРГБ было не 255 уровней, т.к. он не 8-битный.
Их там было несколько больше. Соотв ваша арифметика
-----. Значит wRGB 128,0,0 будет показан как sRGB 255,0,0; 127->253, 126->251 и т.д. Половина возможностей монитора (254,0,0) не используется, а половина wRGB (129-255) не показывается.-----
не работает.

Половина вРГБ, конечно, не пказывается, т.к. не влезает. Но все цвета монитора "заняты" теми цветами вРГБ, кот "между" значениями 8-битного пространства. Вы по привычке пишете, что они изменяютс от0 до 255. Но тогда для16-битного простр вам нужно использовать дробные значения, т.к. между (0,0,0) и (255,0,0) у вас уже не 256 значений, а много больше. Дискретность 16-битного пространства, пусть и широкого, очень мала по сравнению с дискретностью 8-битного, но узкого, пространства. Вроде так.
Re[argo4]:
Цитата:
от: argo4
Спорили мы там много очем :D :D
В конце пришлось доказывать что вообще существуют картинки, не влезающие в сРГБ :)
Ну да бог с ним..
Ну, это Вы погорячились. Уж кто кто, а reef об этом догадывается. :)

Цитата:

от:argo4
Можно вам вопрос? Я конвертирую с сохранением профиля камеры. Потом небольшая коррекция в шопе обычно, без конвертации в рабочее простанство, т.е. она происходит в пространстве камеры. Считал, что чем меньше конвертаций, тем лучше. Судя по вашим словам это неверно? Как лучше/правильнее? Конвертировать в рабочее пространство? (ну т.е. в аРГБ :) )

Подробнее

Из каких это слов? Из этих?
Цитата:
от: vga50
Я не раз печатал из 16битного камерного и Wide и Generic пр-ва на принтере i9900. Ну, впечатления смешанные, иногда неплохо, отличные тени в Generic (за счет минимум конверсий, думаю) ....

Вроде как раз наоборот. :)

imho, выбор пр-ва конвертации зависит от назначения картинки (принтер, лаб, веб, двдшоу...) и желания повозиться с ней.



Цитата:
от: argo4
PS А вы тоже за 8-бит форевер?
Для одиночной возьни с картинкой, я делаю 16бит, иногда линейный, если картинка под печать, то делаю в основном aRGB, иногда и пошире. Если надо крутить цвет в ФШ, то скорее выберу 16бит sRGB.
Если поток для обучного пользователя, знаю что будет смотреться на компе, печататься в лабе - да, jpeg sRGB. :)
Насчет forever - жду не дождусь scRGB от К. с М$. И чтобы камера в него выводила в 16битах, и монитор 16 бит понимал ипринтер их печатал. Вот и будет оно, надолго. :)

Цитата:

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

Подробнее
Ну так и я так же поступаю. Смотрится профиль камеры и принтера, ищется, где они дружат, смотрим, если у картинки точки в этих районах - и вперед, можно попробовать напечатать.
Re[vga50]:
Цитата:
от: vga50
Хм, а градиент нормально показывается?

А почему градиент должен быть ненормальным?
Может как вкост говорит у меня трабл с глазами :)
Но вот обычная Сонька, вот вариант выбора при конвертации в Адобе raw 16 и 8.
Выбираешь 8 - картинка неприятна глазу, выбираешь 16 (при том что камера дает 12!) - сразу лучше...
Re[vconst]:
Цитата:
от: vconst
это у тебя с монитором траблы - или с глазами -- я серьезно

Так или иначе, но качественные книги и журналы печатают в Финляндии. Так что траблы может у тех кто окопался у нас в дизанерах-порнографстах? :)))
Re[vga50]:
Цитата:
от: vga50
Все правильно, и я именно то же самое пытался рассказать выше.

У меня тоже ощущение, что мы пытаемся сказать одно и то же :D
Цитата:
от: vga50
Очевидно, 230 уровней aRGB были отображены (замеппались на) 255 уровней монитора. А 25 пропали, а с ними 10% возможных цветов. С более широкими пр-вами дискретность растет еще больше.

Именно так. Но если уровней aRGB не 256, а 65 тысяч, то на 255 уровней монитора отобразятся 60 тысяч. И при отображении 60 тыс на 256 никакой дополнительной дискретизации не происходит (сверх той, которая которая в любом случае будет происходить в мониторе). В результате, монитор используется оптимальным образом - и дискретизация и цв. охват ограничен только самой конструкцией монитора.

Конечно, для этого программа должна передавать в Color Engine полные шестнадцатибитные значения - в противном случае будет вся та дрянь, о которой Вы пишите. Но, вроде бы, ФШ все расчеты делает корректно, без лишних округлений.

А если какие-то программы не умеют нормально работать с 16тью битами, но просто не надо ими пользоваться. И если у кого-то хватило ума WideGamutRGB в JPEG сохранить, то только его проблемы, а не WG RGB.
Re[vga50]:
Цитата:
от: vga50
imho, выбор пр-ва конвертации зависит от назначения картинки (принтер, лаб, веб, двдшоу...) и желания повозиться с ней.

Это так. Если картинка готовится для выкладывания в интернет, то у нее судьба оказаться в sRGB 8 бит 800*600, и рано или поздно ее придется туда сконвертировать. Но это же не значит, что ее надо сразу в конверторе приводить к такому виду. На этапе обработки желательно иметь как можно больше информации, которая была в исходном RAW'е, и выбрасывать ненужное лучше только на самом последнем этапе - это все, что я хотел сказать о войне во Вьетнаме.
Re[Алексей В. В.]:
Цитата:
от: Алексей В. В.
Так или иначе, но качественные книги и журналы печатают в Финляндии. Так что траблы может у тех кто окопался у нас в дизанерах-порнографстах? :)))

у финов печатают потому что у них своя бумага и выходит здорово дешевле -- особым качеством они не отличаются
Re[Vasja]:
Прочитал ветку и местами рыдал.
vconst, а ты, как оказалось, нехороший человек!
Че не позвал то?
Я чуть было весь цирк не пропустил. Название ветки не предвещало такой качественной развлекухи. :D
Re[miope]:
Цитата:

от:miope
Но если уровней aRGB не 256, а 65 тысяч, то на 255 уровней монитора отобразятся 60 тысяч. И при отображении 60 тыс на 256 никакой дополнительной дискретизации не происходит (сверх той, которая которая в любом случае будет происходить в мониторе). В результате, монитор используется оптимальным образом - и дискретизация и цв. охват ограничен только самой конструкцией монитора.

Подробнее

Логично. Ну, в принципе, можно провести эксперимент - сделать градиент в 16битном WideGamut и посмотреть PrintScrin'ом какие monitorRGB насчитеат ФШ - если будет гладкий 8 битный градиент - значит, да, ACE сначала мэппит 16битник, потом конвертит в 8 бит. :)
Re[Krainov]:
Цитата:

от:Krainov
Прочитал ветку и местами рыдал.
vconst, а ты, как оказалось, нехороший человек!
Че не позвал то?
Я чуть было весь цирк не пропустил. Название ветки не предвещало такой качественной развлекухи. :D

Подробнее

Re[Алексей В. В.]:
Цитата:
от: Алексей В. В.
А почему градиент должен быть ненормальным?

Потому что пытаюсь догадаться, что у Вас с монитором и что значит лучше и что значит приятней.

Если Вы заявили ФШу, что мониторный профиль aRGB, значит ФШ будет картинки в sRGB показывать с уменьшенной насыщенностью и бОльшей дискретностью. На градиенте это видно.
Вообще-то картинки aRGB при системном аРГБ, ФШ показывает точно также, как картинки sRGB при системном sRGB - т.е. практически без пересчета. Т.о. Вы организовали из ФШ вьюер типа IE для aRGB картинок. Не больше, не меньше.
Но это же не дает основания заявлять, что aRGB "лучше" sRGB? Как Вы считаете?
Похожая ситуация у вим - у него камера выдает jpeg в пр-ве Epson2001, а в законный таг инфу не прописывает. В результате вим убежден, что редактировать фотки - это зло, поскольку ФШ их корежит. :)
Re[vconst]:
Цитата:
от: vconst
у финов печатают потому что у них своя бумага и выходит здорово дешевле -- особым качеством они не отличаются

Ну ты вкост как скажешь! А чего бумагу ихнюю привезти нельзя? Нет вкост, проблема в том что финны АдобеРЖБ1998 ставят, а твои порнографы - сРЖБ
Re[vga50]:
вот и я об этом. конечно монитор все равно искажает цвета, но не делает же из синего зеленый.

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

Фотографии в AdobeRGB с 16 бит, больше похожи на пленочные.
P.S. Извиняюсь, если термины путаю...
Re[vga50]:
Цитата:

от:vga50
Логично. Ну, в принципе, можно провести эксперимент - сделать градиент в 16битном WideGamut и посмотреть PrintScrin'ом какие monitorRGB насчитеат ФШ - если будет гладкий 8 битный градиент - значит, да, ACE сначала мэппит 16битник, потом конвертит в 8 бит. :)

Подробнее

Да запросто.

Создал картинку 1024 пикселя шириной, установил Wide Gamut RGB, залил градиетном (0, 255, 255) -> (255, 255, 255). Циан был выбран потому, что очень уж внегамутный.

При движении из конца в конец картинки собственная фотошоповская пипетка показывает плавное измениние R от 0 до 255. Тут ничего удивительного.

Пипиетка же от Digital ColorMeter'а (эксперимент проводился на маке), которая показывает мониторное RGB, ведет себя иначе: примерно две трети картинки идет сплошное (0, 255, 255), то есть все эти две трети вылезли за охват монитора и показываются одинаково, в последней трети идет изменение R от 0 до 255. Изменяется довольно скачкообразно, но это и так и должно быть - для плавного изменения надо больше пикселей на одно "деление" wgRGB.

Это тоже нетрудно: заливаю те же 1024 пикселя градиентом (164, 255, 255) - (180, 255, 255). Это тот участок, на котором изменение мониторных значений R шло особенно быстро. Медленно еду вдоль него пипеткой ColorMeter'а и наблюдаю вполне плавное изменение мониторных значений. То есть на каком-то учатске панель Info стабильно показывает (165, 255, 255), а ColorMeter - изменение R от 0 до 26 со всеми промежуточными значениями.

Так что в ФШ все честно.
Re[miope]:
Наглядно.
Видны и проблемы 8битных широких пр-в (очевидно, jpeg аRGB в том числе) и убедились в честности ФШ. :) 100% и печать из широкого 16битника осушествляется по той же методе.

Так что, Ал.В.В., теперь понятно, почему 8 битный aRGB смотрится на мониторе хуже, чем 16битный?

Вы не авторизованы

Пожалуйста, авторизуйтесь, чтоб иметь доступ к полному функционалу сайта

Обратная связь

Здесь вы можете оставить свои контактные данные, чтобы мы могли связаться с вами.