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

Установил, что с вновь установленной видеокартой использование OpenCL для процессинга даёт весьма ощутимую прибавку в скорости конвертирования. А именно, без OpenCL 40 тридцатимегапиксельных равов перевариваютcя в жпег за 1 минуту 55 секунд, а с включенным OpenCL - за 1 минуту 1 секунду.
Но вот вопрос: почему жпеги, сконвертированные с помощью опенсиэля имеют больший размер?

Цитата:

от:Балбес
Установил, что с вновь установленной видеокартой использование OpenCL для процессинга даёт весьма ощутимую прибавку в скорости конвертирования. А именно, без OpenCL 40 тридцатимегапиксельных равов перевариваютcя в жпег за 1 минуту 55 секунд, а с включенным OpenCL - за 1 минуту 1 секунду.
Но вот вопрос: почему жпеги, сконвертированные с помощью опенсиэля имеют больший размер?

Подробнее

Другой процесс и другой метод подсчета . Один прочесс не учитывает, другой подставляет не менее минимального. В современных процессах EULA разработчики обязаны иметь резервную длину ..ненормального.. конца файла. Это резервное место может быть пустым, но занимает в процессе резерв.

Цитата:

от: goalkeeper
Переустановить систему не проблема. Вот только еще куча всякого софта существует полезного которого 64 битного нету. Как жить то??? :D

Так вроде у 32битного софта нет проблем работать на 64битной системе. По крайней мере у меня лично ни одна 32битная программа работать не отказалась.

Я думаю более точно пересчитывает и от этого больше деталей остается. А джипегу детали как нож по горлу.

Другой процесс и другой метод подсчета. Один прочесс не учитывает, другой подставляет...

Понял лишь приблизительно.

Я думаю более точно пересчитывает и от этого больше деталей остается.

То есть тем, у кого по тем или иным причинам не задействован опенсиэль, приходиться довольствоваться меньшей точностью?

Цитата:

от: Rafael Fomenko
Я думаю более точно пересчитывает и от этого больше деталей остается. А джипегу детали как нож по горлу.

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

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

Никак не давала мне покоя разница в размерах жпегов на выходе в зависимости от использования OpenCL. Решил взглянуть на результаты более детально. И вот что удалось выяснить.
Без OpenCL:



С OpenCL:



Без OpenCL:



C OpenCL:



Опенсиэль, таким образом, добавляет немного шарпа в жпег. Отсюда и больший размер.
Пока не определился, благо это или же зло. По умолчанию значение Amount в инструменте Sharpening у меня выставлено на 280. Так вот, жпег, сохранённый с этим значением с использованием OpenCL по резкости на выходе равен жпегу, сохранённому без OpenCL, но со значением Amount 420. То есть OpenCL при конвертации перибавляет 140 очков шарпа.

Цитата:

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

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

Подробнее

Именно так. По-простому логика длиннее. Это никак не связано с точностью обработки, не обязательно точность зависит от длины путей процесса.

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

Что тупо добавляет шарпа- это зло. Надо определиться еще в другом - а нет ли доп шарпа в настройках видеокарты для вывода на экран?!

Решил опробовать Capture One 11. Все установил, запускается. Но в списке операций висит процесс "настройка аппаратного ускорения 0%" и крутится вечно кружок загрузки. Не могу сохранять фото, поскольку этот баг создает очередь в операциях. Кто-нибудь сталкивался с такой проблемой?

Всем привет, подскажите, где хранятся настройки программы.

Смотря какие. Полагаю у вас Винда и системный диск имеет букву С. Тогда:
Рабочее пространство хранится здесь: C:Users/%username%/AppData/Local/CaptureOne/Workspaces
Рецепты (настройки выходных файлов) здесь: C:Users/%username%/AppData/Local/CaptureOne/Recipes/%version%
%version% - версия программы. На данный момент версия С1 - 11.0, поэтому папка с рецептами носит название Recipes110.
Резкость по умолчанию для конкретных камер здесь: C:Users/%username%/AppData/Local/CaptureOne/DefaultsSharpening
Шумоподавление по умолчанию для конкретных камер здесь: C:Users/%username%/AppData/Local/CaptureOne/DefaultsNoise Reduction
Все собственные значения по умолчанию для тех или иных инструментов хранятся там же, то есть в папке Defaults.
Рецепты при переустановке всё же лучше создать заново, так как не всегда простая замена соответствующих файлов xml полноценно восстанавливает рецепты.
С дефолтной резкостью и шумодавом немного сложнее. Заменив соответствующие codefault нужно также ткнуть программу носом в свежие, то есть ранее ею не виданные равы. Иначе будет применять свои умолчания.

В списке операций висит процесс "настройка аппаратного ускорения 0%".

Здесь отключено?

А нет ли доп шарпа в настройках видеокарты для вывода на экран?

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

Цитата:

от: Rafael Fomenko
Что тупо добавляет шарпа- это зло. Надо определиться еще в другом - а нет ли доп шарпа в настройках видеокарты для вывода на экран?!

Это к заготовителям дров скорее, ХЗ что у них с творчеством. Просто вспоминаем сколько раньше весила вся винда, и сколько сегодня весит шофер для видео.... :cannabis:

Цитата:

от: humax67
Это к заготовителям дров скорее, ХЗ что у них с творчеством. Просто вспоминаем сколько раньше весила вся винда, и сколько сегодня весит шофер для видео.... :cannabis:

Ты же понимаешь что я тебя понимаю. Я порой не понимаю зачем так всё раздувают. Нет, я конечно понимаю, но всё же.

Но я не про творчество Нвидиии, а про настройки пользователя.

Цитата:

от:Балбес
А нет ли доп шарпа в настройках видеокарты для вывода на экран?

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

Подробнее

Не, ты всё знаешь. Я просто предположил что шарп взаимосвязан с настройками видеокарты. У меня нет ни одной такой - поэтому не на чем проверить. Вот и спросил.

Цитата:

от: Rafael Fomenko
Что тупо добавляет шарпа- это зло. Надо определиться еще в другом - а нет ли доп шарпа в настройках видеокарты для вывода на экран?!

За винду не берусь сказать, а у яблокофф , как только из системы вынули движок кварц, кексты (драйвера) к видео, (у мака железок поменьше) как нивдиа так и Интела с этиэшками начали на софтверном уровне содержать алгоритмы проявки сырцов . Чуть позже силы превью (встроеный вьювер) закрутили через встроенное приложение ..фото... итогом, можно сказать, что при выводе на экран силами видеокарт -имеется собственный алгоритм вывода, как сырцов так и жпегов из приложений. Думаю что и у винды, пути к процессами уже мульти, и ось просто сходит с ума, от сопоставлений этих путей между встроенными средствами, драйвером, и приложениями.

Конечно трудно представить что там твориться в драйвере. Надо читать, если такая информация предоставляется.