Свежие комментарии

я наверно ниразу непонял, но розовое-то рисует код в одном месте и код же не видит клиппинга на гистограмме ? как так вышло ?

Речь скорее о том, что если мы сделали маску вроде color range, но на глазок - то придется переделывать.

Что, конечно, понятно. Но саму идею некоего "стека стадий обработки" несколько дискредитирует.

Да как-то маловероятно.

Не вижу противоречия. Любая маска (а тут по сути речь идёт о маске), которую нарисовал пользователь РУКАМИ (а не алгоритмически типа "abs(image.lab.a) > 64 || abs(image.lab.b) > 64"), да, надо будет переделывать РУКАМИ же. Ну а что? Да, это так. Ничего с этим не сделаешь. Но часто ли нужны ручные маски, причём ультра-тонкие?

Там, кстати, потом интересное автор комментария пишет:

Есть холст, есть палитра, есть краски, есть кисти, есть губки, есть грунт, это совершенно разные вещи с точки зрения художника

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

Кстати, что ещё бесит в фотошопе -- это то, что нельзя на RGB-картинку наложить Lab-кривую (и наоборот), что бы он сбегал в другое пространство и обратно сам.

Занятно. Ни разу не сталкивался, но я своим e-pl3 time-lapse и не снимал никогда.

Предположу, что есть не один тип насыщения, а (как минимум) три. Насыщение по заполнению светочувствительной ячейки электронами, насыщение по достижению максимального уровня усиленного сигнала с матрицы, и насыщение по исчерпанию разрядной сетки АЦП (или последующего за ним DSP и т.д.). Насыщение ячеек не может давать ровной полки по той причине, что емкость ячеек отличается от ячейки к ячейке. В зависимости от стабильности техпроцесса в насыщенном состоянии они, усредненно, должны давать более или менее узкий колокол. Насыщение по достижению максимального уровня аналогового сигнала после усилителя должно давать узкий (возможно, даже единичной ширины) пик, ширину которого определяет временнАя нестабильность усилителя (и питающего его напряжения) и нестабильность АЦП. Насыщение по исчерпанию разрядной сетки (либо любого искусственного цифрового порога) должно давать пик единичной ширины. Какой из них наступает раньше? Полагаю, что может случиться по-разному. В зависимости от коэффициента усиления (ISO), от температуры сенсора, от напряжения питания.

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

Может баг диггера?
Другими инструмантами попробовать, РПП тот же в режиме RAW

Интересно, в этом фото http://raw-rpp.livejournal.com/129669.html не аналогичная ли ситуация?

Не думаю, что в этом дело.
Там n-body довольно простой код с прямым суммированием, число вычислений растёт как n^2, а пересылаемые данные растут ~n, т.е. с определённого n скорость пропорциональна числу ядер, скорость обмена данными нивелируется.

Думаю код не трогали пару лет.
Тем не менее, на gtx670 работает отлично, который тот же kepler.

Ну поиграться с параметрами ещё предстоит, но архитектура k20 близка к удвоенной gtx670 IMHO.
k20 это первая карта начиная с 8800, где плохо работает "правило", попугаи в выводе nbody из cuda sdk примерно равны произведению числа куда ядер на частоту :-)
Для к20 оно примерно вдвое меньше ожидаемого.

Про K20: по идее, там все немножко иначе (относительно Fermi) - сами SMX больше (по числу одновременных потоков), регистровый файл тоже больше, shared memory - столько же.
Т.е. все оптимизации - другие.

Не совсем разбираюсь, но какие мишени поддерживаются, для QPcard 203 book что нужно будет?

И про команды не совсем понял
где и куда их вводить, и есть ли в них переменная?

""""""
txt2ti3 -v -i CGATS_From_RD.txt Orig_Digital_ColorChecker_SG.txt Data4ProfileCalculation

colprof -v -A "CameraMake" -M "CameraModel" -D "Profile Description" -C "Your Copyright" -y -qu -aG -nc -O ProfileName.icc Data4ProfileCalculation
""""""

Я не заверял год назад. Уточнял в налоговой при сдаче декларации - подтвердили, что необязательно.