Capture One Pro (5, 6, 7 ,8, 9, 10, 11)

от: Eugene_O
Так речь же шла совсем не про Вас,
а про кэпчу. :)

Я про то что нужно конструктивно смотреть на вещи.
И если для вас что то не так, то вовсе не значит что для других ровно также.

На вопрос то так и не ответили. Зачем вам без каких либо изменений выводить из программы больше чем один файл чисто с практической точки зрения?
Только чтобы потом сравнивать их побитно?

от: iTuner
Я про то что нужно конструктивно смотреть на вещи.
И если для вас что то не так, то вовсе не значит что для других ровно также.
...

Подобные утверждения - это _стандартный_ метод прикрыть свое непонимание обсуждаемой проблемы,
ну или упираться до последнего, когда все и так очевидно .

И похоже этот метод все чаще используется.

от: iTuner

...
На вопрос то так и не ответили. Зачем вам без каких либо изменений выводить из программы больше чем один файл чисто с практической точки зрения?
Только чтобы потом сравнивать их побитно?

Скучно Вам что-ли ?

от: DeeMoon
ну тоже не всегда, не всегда...если покупать – то да, а если продавать... могут быть варианты... :D
...

:)

DeeMoon, все Ваши теоретические доводы вполне разумны.

И да, если отключить шум,
то файлы становятся одинаковыми.

Но я думаю, что скорее всего - это позорный "баг" в чистом виде.

Потому что:

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

2. Сомнительно думать, что разработчики других конвертеров настолько отстали от "квантовых теорий" :)
Но у них с выводом все хорошо, независимо от того, включен ли "Noise Reduction".

3. Я уже говорил, что у С1 v9.3 тоже все в порядке по данному вопросу.
Если же предположить, что С1 v20 вышла на новый уровень "квантовых теорий" :),
то было бы логично предупредить юзеров о таком _странном_побочном_эффекте_.
Но этого не сделали ни в мануалах, ни в "Release Notes".

Такие вот соображения.

Добрый день!
Где почитать про организацию хранения и обработки фото в С1.
Все фото у меня хранятся на отдельном HDD (4ТБ).
Как лучше - копировать на диск с системой (SSD 1ТБ), обрабатывать и копировать в хранилище или сразу обрабатывать на HDD?
Опыта в С1 нет, только разбираюсь. Всегда обрабатывал в DPP.

Зависит от стиля работы.

Сценарий 1.
Все сырцы уже лежат на HDD, а на SSD расположите каталог С1. Время считывания RAW не особо критично, по крайней мере перебрасывание фалов "туда-сюда-обратно" сожрЁт больше ресурса и времени.

Сценарий 2. Если предпочитаете сессионную работу, тогда разумнее сперва импортировать на SSD, там обработать и потом уже скинуть всё на HDD, где и хранить (в случае чего там можно и "доработать").

Основная дисковая нагрузка – создание превьюх и запись настроек, вот это лучше организовать на SSD.

от: Eugene_O

Но я думаю, что скорее всего - это позорный "баг" в чистом виде.

Это оценочное суждение, у нас есть чудесное право иметь МНЕНИЕ. Это СВОБОДА! ... но не истина ;)

от: Eugene_O

1. Нет никаких обоснованных причин применять "шумоподавление" на этапе _вывода_ в результирующий файл.

Шумодав RAW-процессора, это НЕ ОТДЕЛЬНАЯ процедура, как в фотошопе, где работа идёт с триадами RGB. Шумодав RAW принципиально отличается и работает с виртуальными, ещё НЕ СУЩЕСТВУЮЩИМИ точками изображения, причём это не потом делается, не при выводе файла, а непосредствено и ОДНОВРЕМЕННО с вычислением "цветовых триад". Т.е. шумодав RAW-процессора – это фактически ДЕМОЗАИК и есть. Он не делается "потом", типа при записи, он делается в момент демозаика.

от:Eugene_O

2. Сомнительно думать, что разработчики других конвертеров настолько отстали от "квантовых теорий" :)
Но у них с выводом все хорошо, независимо от того, включен ли "Noise Reduction".

Подробнее

во-первых, далеко не "всё хорошо", проверьте по той-же методике LR, там всяко бывает, в зависимости от наложенных фильтров обработки.
во-вторых, а может и ДА, вполне возможно, что далеко не все используют "квантовые вычисления", ввиду нетривиальности мат. аппарата.
Вы обращали внимание, что на одном "железе" конвертация С1 обгоняет LR-acr примерно в три раза при включенном OpenCL; а при выключенном – отстаёт примерно на 30%! Чем у нас занимается GPU ? Правильно, – операциями над матричными массивами с float point! Это косвенное, но серьёзное свидетельство, что математический аппарат С1 намного более современный и прогрессивный. Кодеры адобы реально забили на GPU оптимизацию или... им НЕЧЕГО оптимизировать под его возможности. А "одиночкам-кулибинам" подобные процедуры вообще не под силу. Смекаете? ;)

от: Eugene_O

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

Мы склонны преувеличивать нашу значимость для тех, кому платим (или не платим?) свои жалкие копеечки....
Вот в Вашем "крузаке" производитель изменит прошивку мозгов, прямо во время регламентного сервиса... Как думаете будет об этом сообщать ЭндЮзеру? Да об этом даже сервис-механик знать не будет. Его дело подключить разъём и подождать пока ОК не загорится. А ведь это на порядки ДРУГИЕ деньги и другая ОТВЕТСТВЕННОСТЬ. Да?

Вы много чего написали, но как-то не в тему.

Я не говорил, что шумоподавление делается "при выводе файла".
Я говорил ровно обратное.

Всякие тонкости с RAW, OpenCL, и хитрыми "квантовыми алгоритмами" оставим в покое.
Они не имеют _никакого_ отношения к _обсуждаемой_проблеме_.
Они уже совершились для конкретного исходника.

Чтобы было проще и понятнее, отмотаем немного назад.

от:Eugene_O

...
В изображении с колочекером24 размером 960x630 пикселей (от NikonD3s) отличия больше 100-а единиц RGB(16bit) такие:

X,Y : RGB из Сохранения_1 - RGB из Сохранения_2
-----------------------------------------------------------
220,467 : 41568 17841 16670 - 41463 17788 16631
221,467 : 41360 17793 16658 - 41257 17734 16604
228,818 : 12034 08096 06097 - 11933 08043 06063
...

Подробнее

Из 1-ой строки берем исходные Adobe RGB:
RGB1 = 41568, 17841, 16670
RGB2 = 41463, 17788, 16631

После пересчета в LAB для D50:
LAB1 = 46.0605, 48.3387, 29.8959
LAB2 = 42.1185, 38.7448, 22.5916

Получаем разницу между этими LAB:
deltaE2000 = 5.25

Я не знаю, допустима ли такая разница "чисто с практической точки зрения" для iTuner'а.
Он все хотел от меня примеров.

Какая еще нах "практическая точка зрения" ?
Такая ?

Я обрабатываю исходное изображение в C1.
Ставлю "контрольные точки" в нужных местах.
Коррекцией довожу их до _нужных_ мне значений.

Заканчиваю работу и вывожу это изображение в файл.
Проверяю точки в полученном файле (конечном продукте) .
И ...

Разница в deltaE2000 = 5.25
от того, что мне надо, и на что, я потратил время.

Что за х... ?

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

Итого:

Меня упорно хотят убедить с помощью демагогии и заумных рассуждений,
что это _нормально_ ?

Вы это серьезно ?

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

Сценарии использования фотографии очень разные... Если нужна аптечная точность и математика уровня "2х2=4" – используйте или другие протоколы или этот с учётом "квантовых штучек". А для задач "творческого полёта" все нормально и с текущими алгоритмами.

"Жизнь такова, какова она есть, и больше - никакова!"

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

Повторный вывод уже имеющегося файла ну, такое... для чего непонятно, только для любителей пипетками тыкать и побитно сравнивать исключительно ради науки. :))

от:iTuner
Ну ясно. Ответить по существу вы не можете, потому как все эти ваши потуги сравнивать файлы на практике вообще не актуальны.
Выводить разом две копии программа не позволяет все равно и на выходе мы имеем уникальный файл, копируйте его сколько хотите, если вам нужна побитная копия.
...

Подробнее

Я давно уже понял,
что Вы не в состоянии осмыслить простую логическую цепочку:

"Входные данные" -> "Процесс" -> "Нужный результат"

Вам не помогли ни метафоры, отсылающие к Еxcel, или Калькулятору.
Ни конкретный пример с цифрами.

от: iTuner

...
Повторный вывод уже имеющегося файла ну, такое... для чего непонятно, только для любителей пипетками тыкать и побитно сравнивать исключительно ради науки. :))

Поэтому Вы и не понимаете, что все сказанное мною про повторный вывод файла,
- лишь наглядная иллюстрация того, что С1 _позорно_ косячит,
начиная по крайней мере с V20 Build12.

И я правильно понимаю, что С1 косячит и под MacOS ?
У Вас же MacOS ?

Имхо, если в проявителе действительно есть какие-то элементы ИИ/анализа картинки (для шумопонижения, например), а не тупое следование жёстко заданной последовательности, то побитовая разница - норм.
Тем более если на глаз не видно.

Имхо, если вывести картинку в jpg в качестве 100% и 99%, разница по цифрам будет ещё больше (сам не сравнивал). Но кто это заметит?

Так что весь это спор о разнице - ни о чём.

от:Lesnoybrodyaga
Имхо, если в проявителе действительно есть какие-то элементы ИИ/анализа картинки (для шумопонижения, например), а не тупое следование жёстко заданной последовательности, то побитовая разница - норм.
Тем более если на глаз не видно.

Имхо, если вывести картинку в jpg в качестве 100% и 99%, разница по цифрам будет ещё больше (сам не сравнивал). Но кто это заметит?

Так что весь это спор о разнице - ни о чём.

Подробнее

Разговор даже не о величине этой разницы.
А о том, что ее не должно быть в принципе.

И все эти притянутые за уши к разговору "ИИ", "Квантовые теории" и "Псевдо-случайный выбор", если они _на_самом_деле_там_есть_,
должны быть реализованы, примерно, так:

1. По совету "ИИ", или даже подбрасывания монетки, в изображении выбираются нужные области;

2. По ним вычисляются все нужные для дальнейшей обработки параметры;

3. Эти параметры _запоминаются_;

4. Делается любая дальнейшая обработка;

5. Результат при этом совершенно одинаковый, сколько бы раз обработка не повторялась.

И все это тоже, как "2 x 2".

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

Главное, чтобы они не задумывались, для чего им в C1 сделали "пипетку" в LAB
для замеров с точностью в 2-а знака после запятой.

На фоне заговора мирового закулисья обсуждаемый "косяк" капчи имеет теоретическое значение, это сродни обсуждению "удельной плотности сферического коня в вакууме" :-) Обращаю ваше внимание на РЕАЛЬНЫЕ проблемы, которые касаются всех программ и каждого файла без исключения.

На порядки больше искажений возникает при ЛЮБОМ процессе цветового рендеринга. Что имеется ввиду. Если триплеты растрового файла (jpg, tif, psd, png и т.л.) просчитаны в RGB пространство, то при последующем выводе на ЛЮБОЕ устройства (монитор, принтер, офсет и пр.) происходит цветовой рендеринг, при котором неизбежно огромное число приближений и округлений! Все "ошибки капчи" – теряется и нивелируются на порядки менее точными целочисленными округлениями CMS.

Надеюсь ни для кого не секрет, что для демонстрации "anyRGB" (любого РЖБ) картинки на мониторе она обрабатывается CMS-движком компетентного программного обеспечения. Схема примерно такова "AnyRGB->L*a*b->монитор-RGB". А если файл еще и печатать? При выводе на принтер рендеринг идёт по пути "anyRGB->L*a*b->targetCMYK". Все это делается в CSM движках и ТОЛЬКО над целочисленными данными триплетов, и ТОЛЬКО целочисленной арифметикой. Количество искажений при "впихивании" 16-ти битного ProPhotoRGB в цветовой охват 8-цветного принтера страшно даже представить....

Делать "ранее CMYK связывание" в капче – не очень хороший вариант, ибо если файл надо выводить и на принтер, и на офсет – то рендеринг пойдёт по схеме "CMYK_001->L*a*b->CMYK_002" это верный путь получить на отпечатке изумительные цвета кирзового сапога. :D

Логика подсказывает, что если цифровые данные растрового файла будут ИЗНАЧАЛЬНО в пространстве L*a*b – то при последующем его выводе на устройства с разным охватом, – будет на одно преобразование меньше. А это примерно 50% работы целочисленного CMS-движка, соответственно проблем и ошибок будет меньше тоже на 50%... Ощущаете масштаб?
Конечно я понимаю, что L*a*b файлы нуждаются в дальнейшей обработке, сразу на монитор их отправлять нельзя. Но когда есть необходимость вывода на разные устройства, тогда обработка в L*a*b – это отличная идея!

Братушки, давайте обсудим как бы нам обустроить вывод растровых файлов сразу в пространство L*a*b – вот достойное применение для коллективного разума! :-) Может фатит уж про "косяки" С1?

от:DeeMoon

...
Братушки, давайте обсудим как бы нам обустроить вывод растровых файлов сразу в пространство L*a*b – вот достойное применение для коллективного разума! ...

Подробнее

Дяденька,
Вы, как минимум, ошиблись веткой,
и даже клубом.

Есть профильные ресурсы у полиграфистов.

Но я бы не рекомендовал Вам повторять там то,
что Вы тут понаписали.

от:Eugene_O
Поэтому Вы и не понимаете, что все сказанное мною про повторный вывод файла,
- лишь наглядная иллюстрация того, что С1 _позорно_ косячит,
начиная по крайней мере с V20 Build12.

И я правильно понимаю, что С1 косячит и под MacOS ?
У Вас же MacOS ?

Подробнее

В том то и дело что у меня не косячит в данном конкретном случае, я вывожу нужный вариант и пользую этот файл, который если надо, копирую средствами винды :)
Я не ищу проблем там где их нет. :)
И если мне не нужны особенности капчи, я даже не лезу в нее.

Яблоком последние несколько лет не пользуюсь, кроме iPad, пользую только стационарный комп на WIN10, сейчас сборка 1909 и до 2004 не обновлял еще, пусть допилят сначала.
В общем совсем не знаю как там с MacOS сейчас, помнится еще совсем недавно с самой макосью были траблы у всех и у фотошопа и у капчи.
Последний раз пользовал вроде 10-ю капчу на iMac.

да ты просто хам, я думал умный, а ты еще и глупый хам

от: DeeMoon
да ты просто хам, я думал умный, а ты еще и глупый хам

В общем я тут подумал ...

К полиграфистам действительно рискованно.

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

"Ощущаете масштаб" ?

И уж извините меня за _такой_ мой хамский тон.
Сам знаю, что нехорошо, но заносит время от времени.

[УДАЛЕНО]

от: Ingi

В RGB я имею дело с 3-мя степени свободы работы с цветом, а в LAB всего с двумя.
Так что не сходите с ума!
-----------

Похоже Вы не в теме ни разу, не смотря на большой опыт практической работы с цветом.
Хорошо, пусть в Вашем понимании один канал=одна степень свободы (хотя на самом деле это не так ни разу).
Тогда в Лаб их уже восемь если не двенадцать (смотря как считать), поскольку а) в Лаб два канала, каждый из которых представляет ДВА цвета в отличие от РГБ, б) так же отдельный яркостный канал, который позволяет работать отдельнно с яркостью, не трогая цветовые координаты и наоборот, работать с цветом в каналах а и б не трогая Л, что в РГБ даже в теории не возможно. Плюс синтетичность канала ЛАБ с его "невидимыми" цветами даёт преимущество в пересчётах цветов и яркостей, что ведёт к минимизации возникновения артефактов по сравнению с РГБ.
Я конечно понимаю, что сейчас Вы, как это у Вас принято, начнёте хамить в своей гопнической манере, но тем не менее всё таки не нужно писать то, в чём у Вас нет полного понимания. ;)

Коллеги, а у Капчи есть функционал из колорчекера профиль делать?