Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - anatols

Страницы: 1 ... 3 4 [5] 6 7 ... 174
61
Основной форум / Re: depositphotos
« : Декабря 29, 2012, 04:38:02 pm »
Карты, привязанные к букерсу, стоки не видят в принципе. Или вы с этой карточки покупали на депозите что-то?

62
Основной форум / Re: depositphotos
« : Декабря 29, 2012, 04:08:10 pm »
Оперции могут быть, например, такие - покупка работ с ворованных кредиток с целью отмыть доход. Возможно, с вашего портфеля были такие продажи и депозит предполагает, что вы в доле.
Скорее всего так и есть, но это же какой-то полный неадекват в общении с их стороны. "Мы вас в тюрьму посадим, но в чем виноваты - сами догадайтесь, и подельничков сдайте". Какой-то совковый маразм.

Тем более, что народ с ворованных карт покупает со случайных аккаунтов, чтобы не привлекать внимание к одному своему.

63
Основной форум / Re: настройки
« : Декабря 27, 2012, 06:10:30 pm »
Мой вам совет, научитесь сначала снимать! Делать качественную, интересную картинку. Когда научитесь начнете и зарабатывать и совсем не обязательно это будут стоки.
А кто мешает учиться сразу на стоках? Всё равно изначально технику осваивать, и в этом плане стоки - хорошая школа выживания :)

64
Фототехника / Re: old broncolor
« : Декабря 04, 2012, 11:42:56 am »
хехе, может тогда в палатке днище белое сделать и целиком её надеть? будет софт 3х3 :)

65
Основной форум / Re: lucky oliver
« : Декабря 01, 2012, 08:50:05 pm »
ага, с сайтом в стиле цирка-шапито :)

66
Офф-топик / Re: тема для злобных фотографов
« : Ноября 28, 2012, 05:53:12 pm »
встречал мнение, что про книги - уже давно неправда, и рекапчу гугл уже не использует для тренировки распознавалок.
достала она жутко на шаттере. как я радовался, когда она исчезла после редизайна, так нет - обратно вкатили  :gunman:

67
Офф-топик / Re: тема для злобных фотографов
« : Ноября 24, 2012, 12:39:43 am »
Там основная проблема с углами. на 5 сантиметров сместил голову - цвета поплыли

68
Офф-топик / Re: тема для злобных фотографов
« : Ноября 23, 2012, 08:19:42 pm »
самсунг т220 - это же офисное барахло на TN матрице, нет?
ему никакой калибратор не поможет, можно не тратить деньги.

69
Офф-топик / Re: Тканевые фоны
« : Ноября 22, 2012, 07:04:25 pm »
Я ж не приду в магаз и не скажу - кароче, мне ткань как у Роверси на той фотке.
а почему нет? показать фотку, пусть тётки в магазине напрягаются :)

70
Основной форум / Re: istock
« : Ноября 15, 2012, 06:18:11 pm »
ну, по сравнению с категориями и дизамбигуацией это мелочь.

(вообще в 21м веке, когда микрософт демонстрирует технологию перевода голоса в реальном времени на китайский, требовать дизамбигуацию... :gunman: а уж категории по ключевикам определить -- это, блин, любой студент напрограммить сможет)

71
Основной форум / Re: istock
« : Ноября 15, 2012, 04:39:54 pm »
ну меня аналогично начали реджектить за отсуствие каких-то полей (location и shoot date, емнип), дописал их от руки в уже подписанные релизы и заново сосканировал. принимают

72
Основной форум / Re: istock
« : Ноября 15, 2012, 01:48:34 pm »
ну а чего просто не дописать эти даты? они же принимают релизы с дописанными от руки полями
бодаться с ними можно долго, и по-моему, лучше это время потратить на что-то более интересное

73
Рекомендую вам для начала разобраться, чем цвет отличается от тона. И что такое tonal response curve

74
а вообще это жопа какая-то, не могу в голове уложить весь процесс профилирования, мозгов не хватает :)
Давай попробую на пальцах объяснить. Вот смотри на ужасную картинку (я её честно стырил с википедии и пририсовал к ней ещё 3 треугольника - камеру и 2 монитора):
http://2xsamara.com/temp/Colorspace2.png

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

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

С точки зрения компьютеров цветовые пространства - это системы координат для реальных цветов. Грубо говоря, в каждом пространстве компьютер может “адресовать” цвет от 0 до 100% насыщенности (условно - расстояние от центра) и 0-100% оттенка (условно - азимут от центра). То есть зная численные значения насыщенности и оттенка, и зная, в какой это системе координат - можно вычислить, какой это будет цвет в реальном мире.

У современных камер довольно широкий охват (красный треугольник), и они видят “цвет” даже там, где его нет - народ снимает и УФ и ИК фото. Это, естественно, для данных, которые лежат в раве. При проявке рава ты выбираешь более узкий охват, для простоты пусть будет sRGB. То есть из всех снятых цветов оставляешь только те, которые входят в треугольник sRGB. Все остальные цвета тем или другим способом тоже загоняются внутрь меньшего треугольника.

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

Внутри охвата монитора компьютер оперирует значениями 0-100% по насыщенности и оттенку. И отсюда вытекает основная задача color management-а - “если я в монитор передам команду показать цвет X%,Y% - какой это будет цвет в реальном мире?” (или обратная - “чтобы получить такой-то реальный цвет, какие значения мне надо передать?”). Решить её можно только если для конкретного монитора замерить в реальном мире, что он показывает. Этот замер как раз и делает калибратор. И результат замера сохраняется как профиль монитора.

Дальше, этот профиль в системе прицепляется к монитору, и все желающие его могут взять и посмотреть.

В винде color management не принудительный, и сама система так и продолжает работать в пространстве монитора. Ей пофигу, что зелёная кнопка пуск немного синее будет, она выдаёт значения цветов как если бы монитор четко работал в пространстве sRGB.

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

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

Опять же, фотошоп знает исходное пространство потому, что к нему из рав-конвертора пришел файл с прицепленным профилем, в котором написано “я - sRGB”, например.

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

Глупые просмотрщики и сама система значения никак не преобразовывают. Поэтому когда к ним приходит, например, значение 100% зелёного -- они его в систему и отдают как 100% зелёного. И в реальном мире цвет, который должен был быть с верхней вершины треугольника sRGB, будет показан с верхней вершины треугольника охвата монитора. Для обычных мониторов это не так заметно, вершины рядом. Для wide gamut - цвет выйдет сильно перенасыщенным.

Та же фигня происходит, если делать Assign profile, только уже не в охват монитора, а в охват, который назначается (adobe rgb например). Численные значения для цветов пикселей не меняются, но меняется их интерпретация, система отсчета.

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

При конвертации в более узкое фотошопу надо решить, что делать с цветами, которые не влазят в новый охват. Там в настройках есть несколько вариантов, но в целом этот вопрос очень хорошо освоен в полиграфии, где в очень узкий CMYK пытаются всунуть буйство цветовой фантазии дизайнеров. Для примера картинка с двумя вариантами конвертации, она лучше текста всё поясняет:
http://digitaldog.net/files/Gamut_Clipping_vs_Compression.jpg

И вот тут как раз та проблема, о которой я упоминал - этот процесс нельзя автоматизировать. Нужно смотреть, внимательно, какие цвета потерялись, какие в какие превратились, корректировать, настраивать. Нельзя работать в AdobeRGB/ProPhotoRGB, а потом просто при выводе жпега сказать “а теперь сконвертируй в sRGB”, ибо цвета уйдут нафиг, непредсказуемо.

При конвертации в более широкий охват, казалось бы, всё нормально будет, просто не будет ни единого цвета за пределами оригинального охвата. Но ньюанс тут в том, что цвет у нас дискретно задаётся. Упрощенно: для 8 бит - 256 значений, при расширении охвата в те же 256 значений надо впихнуть больше цветов, значит оригинальные цвета нужно представить меньшим количеством значений. Часть цветов, разных в оригинале, будет представлена одним значением - и здравствуйте градиенты с бандингом. В 16 битах, конечно, проблема нивелируется.

Теперь к вопросу о том, в каком пространстве строить рабочий процесс для стоков. Подразумевается, что финальный вывод будет в жпег/sRGB.

Вариант 1: проявка RAW в ProPhotoRGB, рабочее пространство в фотошопе ProPhotoRGB, перед выводом - конвертация в sRGB.
+ сохраняем все цвета из камеры до самого конца, может быть важно если в процессе обработки в фотошопе(!) есть много работы в насыщенностью, особенно её уменьшения
- поскольку на сегодня ни один монитор не показывает ProPhotoRGB, работать придётся на половину вслепую, постоянно помня, что часть цветов мы не видим, в ходе работы обязателен постоянный пруфинг в sRGB.
- вывод в жпег для стоков становится дополнительной отдельной операцией по цветокоррекции
- обработка только в 16 битах, иначе разрешение по цвету будет никакое

Вариант 2: проявка RAW в AdobeRGB, рабочее пространство в фотошопе AdobeRGB, есть монитор с широким охватом (если монитора с широким охватом нет - это по сути тот же вариант 1).
+ аналогично варианту 1 сохраняем много цветов, не так много, но всё равно примерно на 30% больше sRGB.
+ на широкоохватном мониторе все цвета видно
- нужен пруфинг при работе
- вывод в жпег - тоже отдельная операция

Вариант 3: проявка в sRGB, рабочее пространство в фотошопе sRGB
- всю работу с цветом, особенно с насыщенностью, желательно перенести на этап проявки. (хотя, это сомнительный минус применительно к стокам - “конвеер” в лайтруме сделать проще).
+ можно работать и на мониторе с узким охватом
+ если сильной обработки по цвету в фотошопе нет - есть возможность работы в 8 битах, разрешение по цвету не страдает.
+ не нужен пруфинг
+ не нужен вывод как отдельная операция, просто сохраняется жпег и всё

То есть для стоков наиболее логичным выглядит вариант 3 (я, например, так работаю), но если нужно много обработки по цвету в фотошопе - тогда вариант 2.

Варианты с проявкой в одно пространство, конвертацией в фотошопе в другое и выводом в третье быть не должно в принципе - это тупо лишняя работа и лишние потери на каждом этапе.

75
да не хочется, чтобы потом сюда зашли люди и начитались бреда. но, смотрю, не переубедить.

Страницы: 1 ... 3 4 [5] 6 7 ... 174