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

Ну вот как бы и вопрос.

Даже для непережатых фильмов (40 гигов на 2 часа) получается 5.5Mb/sec.
802.11n у меня вроде бы дает раза в два побольше (с макбука на сервер), т.е. особо большой буфер вроде и не нужен.

Но мнение практиков оно того, интересно.

Что-то мне сомнительно, что HD over wireless не будет заикаться. Все наши попытки сделать это "в лоб" успеха не достигли.

Стало быть, как-то разумно буферизовать всё-таки придётся.

Не могли бы Вы рассказать о рабочем процессе с применением LibRaw, ну или о Вашем рабочем процессе.

С уважением Юрра.

Насколько я помню, надо
1) кликнуть (двойным кликом) на .dmg - он смонтируется и откроется окошко finder
2) Перетащить из этого окошка в Applications (или на десктоп, неважно куда) приложение RPP

(не помню тк дальше оно само апдейтится)

Если что-то идет не так - у меня в блоге спрашивать почти бессмысленно. Есть ЖЖ-сообщество, где автор появляется: http://community.livejournal.com/raw_rpp/
Ну и просто Андрею можно писать (контакты тут: http://www.raw-photo-processor.com/RPP/Support.html)

Rosetta - это запуск старых бинарников (для PowerPC) на новых маках.

Сдается мне, что-то вы делаете не то или не так.

А зачем большую?
Берите малую, ведь каждому пикселю на сенсоре соответствует довольно маленький кусочек бумаги.

А экспонометр (отраженного света) меряет не освещенность, а яркость.

Вот кстати, может пригодится -
http://support.microsoft.com/kb/2280741

Само исправление не пробовал, зато уже видел в деле сам баг:
http://bugreports.qt.nokia.com/browse/QTBUG-11445
Студия влепила movaps на данные выровненные по восьми байтам, а не 16..

Если снимаем то-же солнце в большом зеркале, а зайчик наводим на фотик, то увидим то-же самое небо, как если бы положили фотик вместо белой бумаги. Снимаем линзой F/1 лист белой (0,99)бумаги (примем)диффузно отражает, так что ее освещенность снижается в пи раз(Ландсберг т.3 стр.203). Эта освещенность и будет на матрице. Если на лежащий вместо бумаги фотик надеваем телеобъектив с диафрагмой 1 так, что на всю матрицу оказывается солнце, то это неправильно, т.к солнечную энергию тогда собираем объективом большим, чем сама матрица. Если же взять "рыбий глаз", то средняя освещенность матрицы станет как без объектива. Вроде так.

А далеко не всем алгоритмам от удвоения регистров так уж полегчает

Не, ну понятно. Просто например в double векторизовать не всегда очень выгодно (при sse2) - лезть в ассемблер или intrinsics, только из-за двух-кратного ускорения (также учитывая что точность теряется, так как fpu это всё-таки 80бит..), не очень хочется.
Ладно если float..

Мне вот гораздо больше нравится, что у новых горшков можно (вроде бы! пока всерьез не изучал) о выравнивании гораздо меньше заботиться

А вот это кстати по-моему ещё с Core I7 (в смысле не в новейших). Я по-моему даже какой-то тест делал - на Core2 unaligned инструкция чуть ли не в два раза медленней чем aligned, когда на Core I7 скорость точно такая же..

Не-не. Объектив не снимаем.

Снимаем лист белой бумаги (отражение >99%) освещенной солнцем. И то же солнце в зеркале (отражение тоже >99%)

Вы действительно не видите разницы между зеркалом (отражение >99%) и белой бумагой (тоже >99%) ?

В 5 раз, это если солнце освещает поверхность с отражением 20%. А 12 стопов вместо 10-ну можно по разному мерять стопы у Кэнона. Можно в матрице и 12 стопов ДД намерять. А интересен как раз последний стоп. Главное: хорошо бы придти к 1 фотону на стоп: при большом количестве фотонов цветовой шум будет маленький (а на глаз видно, что шума много).

Можно уменьшить на отражение от серой поверхности в 5 раз, да еще взять не 10 стопов Canon, а 12, т.е. еще в 4 раза. Останется 20 фотонов.

Я не вижу в ваших расчетах светосилы, ну допустим она спрятана в той 1/10, что "фотик регистрирует".

Но не возражаю против того, что если снимать прямо вот солнце в кадре, то на выдержке 1/100 все будет сильно пересвечено.