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

Я дописал строчечку там, как выглядит (в первом приближении) Receiver::run()

Ну не вполне так:
1) Qt-шный механизм коммуникаций таки нужен: если мы хотим по обработке чего-то таки позвать какой-то Qt-шный слот из main thread (а альтернативы этому довольно плохие: или блокировать event loop у main thread и читать из очереди; или поллинг по таймеру).
То есть выливать из main thread задачи в worker-ов можно через очереди, поскольку worker-ам можно (и нужно!) блокироваться если работы нет. А вот забирать результат - так нельзя.

2) "хитрость" в том, что мы зовем slot в контексте main thread не из большого количества рабочих потоков (это работает плохо или очень плохо) а из одного вспомогательного потока. Там наверное тоже где-то встречаются mutex/семафор/что-то подобное, но когда их теребят из одного потока - оно ведет себя гораздо лучше, чем если бы мы теребили из 32).

Нет, остался квадрат.

> Цвета патчей равны тем, что получены при измерении спектрофотометром

фантастика... прямо таки любое dE* = 0.000000 ?

зачем Baseline Exposure компенсировать кривой - есть же тэг в dcp профиле для компенсации оного ? и потом (если уже не сказали) к тому что писалось кем то выше от независимость dcp профиля и конвертера... baseline exposure оно ж в коде конвертера записано (ACR в данном случае) - так это кусок в dcp профиле таки привязан к тому что adobe пишет в коде... или мы компенсируем ACR/LR в dcp профиле или нет - с другим конвертером применение того же самого dcp профиля не приведет обязательно к тем же самым результам

>> В синтетическом DNG нет ProfileToneCurve, камерный профиль не применяется, поэтому вы получаете правильные тона плашек.

1) если бы вы сходили бы по ссылке - то увидели бы (наверное), что там работают с реальным RAW-файлом из реальной камеры, а не с синтетикой.

2) Поскольку непосредственно RAW-данные доступны для разглядывания глазом и расчетам в экселе (при помощи RawDigger), линейность конвертора совершенно несложно оценить впрямую, а не путем сравнения с эталонным конвертором.

Профиль камеры не привязан к RAW-конвертеру. Он не может ничего "компенсировать", т.к. в процессе его создания ACR даже не запускается.

"Нелинейность" по вашей ссылке из-за кривой, зашитой в стандартные профили от Adobe (Adobe Standard, Adobe Color etc.). В спецификации DNG это ProfileToneCurve. В ACR кривую ProfileToneCurve нельзя выключить, она применяется последовательно с кривой, заданной пользователем. Даже когда выбирается PV2 и линейная кривая, кривая профиля ProfileToneCurve по-прежнему применяется, поэтому измерения тона плашек Q13 по вашей ссылке не совсем корректны.

""What happens to my mid-tones? I set exposure using exposure meter; open the shot in Adobe Lr (or Adobe Camera Raw, or some other converter) - the shot looks overexposed and everything starting from mid-tone and up looks very flat." — это потому, что зашитая в профиль Adobe Standard кривая поднимает средние тона (см. DNG SDK, dng_render.cpp, dng_tone_curve_acr3_default::Evaluate). Именно поэтому в профиле задаётся отрицательное значение BaselineExposure.

В синтетическом DNG нет ProfileToneCurve, камерный профиль не применяется, поэтому вы получаете правильные тона плашек.

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

Поправили, а то неровно висит, действительно: https://github.com/LibRaw/LibRaw/commit/e53e15c72e630d6478f30e8c2c90ace9...

Да, в мастер мержится (нечасто, раз в полгода в среднем) наша внутренняя рабочая версия, которая перед этим прошла тестирование на живых пользователях (RawDigger, FastRawViewer). Это в любом случае отнимает силы и время т.к. изменения нужно хоть как-то задокументировать. API/ABI в каждом таком merge - меняется.

Релизы (типа 0.19) мы выпускаем еще реже потому что а) сил надо гораздо больше б) релиз имеет фиксированный API/ABI (т.е. dll/so от 0.19.5 можно подложить вместо 0.19.0 и все будет ок).
В релизах дальше (0.19.0-0.19.5) правятся только критические баги, новые камеры не добавляются.

В принципе, если не требовать бинарной совместимости по dll/so (т.е. или статическая линковка или shared libs принесены с приложением), то надо брать всегда мастер, он достаточно оттестирован для использования (и если есть багрепорт по мастеру - мы его в публичном мастере же быстро правим).

Но вот за libraw_version.h в мастере мы не следим, это ошибка, надо поправить с 0.19-Beta на 0.20-Work-In-Progress :)

Да мы в этом месте особо не паримся :)

Но наверное стоит увеличить, да.

> Во-вторых, я понятия не имею как делать в биосе скриншоты.

очень просто - берешь сотовый и щелк-щелк

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

Температура, режим перемешивания, время проявления....?

Я знаю про эту штуку, ну и не более того, знаю - и знаю.