2014

Q: FreeBSD 10

Два вопроса
  1. Кто-нибудь уже использует FreeBSD 10 в бою?
  2. В апгрейде с 9.2 есть грабли какие-нибудь?

Я прийшов, а тебя два!

В прошлой заметке я написал:
После этого начинаешь любить Win32 особенно остро.
Это продолжалось недолго, я познакомился с Registry Redirector в WOW64. В сочетании с тем, что в в Win7 оно отличается от более старых версий.

Я прийшов, тебе нема

Вот есть такой вызов, strnlen:

     size_t
     strnlen(const char *s, size_t maxlen);

DESCRIPTION
     The strnlen() function attempts to compute the length of s, but never scans beyond the
     first maxlen bytes of s.
И он есть, например, в Mac OS X 10.7 и новее.

Берем код с этим вызовом, собираем с -mmacosx-version-min=10.5 (должен получиться совместимый c 10.5 код, да?) на 10.8, несем на 10.6, запускаем.

Все падает.

И ладно бы падало с внятным сообщением, вот не могу залинковать такое. Нет, SIGSEGV, нулевой указатель (на функцию?).

После этого начинаешь любить Win32 особенно остро.

Про гистограммы RawDigger

Два текста про гистограммы RawDigger (наверное, со временем станут частью мануала): На русском языке, увы, не существуют.

P.S. В конце второго текста есть ссылка на полезняшку, шкалу Q13 в DNG. Помогает понять тоновую кривую вашего конвертора, например.

Sony A7: околозвездная постеризация

Год с хвостиком назад, когда я в первый раз озаботился соневским cRAW, я из общих соображений предсказал, что должны быть проблемы на кадрах типа "звезда на фоне темного, но не черного неба".

И таки да. Вот у Ллойда Чамберса: нашелся пример (промотать до раздела Example).

UPD: Ллойд завел отдельную страничку под это чудо.

Такие дела.

И таки да, со star trails все плохо т.к. в артефактах будет весь снимок, не начистишься (лечение - убирать небо в черноту, но не всегда это годится).

Экспозамер: для RAW или для JPEG?

Меж тем, у нас родился текст (и видео):

Exposure for RAW vs. Exposure for JPEG

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

Ну и многие примеры поминались/обсуждались у меня в комментариях.

Sony cRAW ETTR: сжатие с потерями, теория и практика.

Продолжим обсуждение ETTR на камерах Sony (первая часть тут) и разберемся с lossy-компрессией и ее возможным влиянием на ETTR.

Напомню устройство сжатия с потерями в этом формате:

  • Строка изображения разбивается на блоки по 32 пиксела, в каждом из блоков содержатся пиксели двух цветов, зеленого и какого-то еще из двух оставшихся, по 16 пикселов каждого цвета.
  • Для этих 16 пикселов записываются
    • Минимальное и максимальное значение в 16-пиксельном блоке с точностью 11 бит.
    • Координаты минимума-максимума (номер в блоке).
    • 14 остальных пикселов кодируются в виде дельт с 7-битной точностью.
    • Шаг дельт равен (максимум минимум) / 128 (округленное до ближайшей бОльшей степени двойки).
    • Соответственно, если (максимум минимум) в блоке больше 127, то шаг дельты - больше единцы, то есть дельта-кодирование записывает значение пиксела приближенно.
  • После раскодирования дельт, к раскодированным значениям применяется тоновая кривая, о которой подробно писалось в прошлой заметке
Приведем эту тоновую кривую еще раз:
Как мы видим, наклон кривой в области тени-полутона равен 2, в самых светах 32, в промежутке (ступенчато) меняется.

Посмотрим теперь, как тоновая кривая сочетается с дельта-кодированием.

Q: Qt 5.2 и Retina

Граждане разработчики,

Особенно использующие Qt, вы же тут читаете, я знаю.

Вот есть Qt 5.2 и Маки с ретиной. Надо, значит, чтобы было Щастье.

На самом деле, 99% Щастья есть сходу: если в Info.plist написан NSPrincipalClass, то все стандартные элементы (шрифты, к примеру) рендерятся в ретину и все работает.

Но.

У меня используется свой OpenGL-код, который зовется из QGraphicsScene::drawBackground(). Он, понятно, сходу рисует в четверти окошка в таком случае.

Эксперименты показали, что достаточно поменять одну строчку. Вместо:

glViewport(x,y,w,h);
написать
int dpr = painter->device()->devicePixelRatio();
glViewport(x*dpr,y*dpr,w*dpr,h*dpr);
И все начинает (вроде бы?) работать как надо. Зумится, ротейтится, сдвигается - все вроде как надо.

Так вот, вопрос: Что Я Делаю Не Так?. Не упускаю ли я что-то важное?

P.S. Рассматривание кода Qt-шных примеров не дало ответа. А именно: в части примеров делают именно так. И все работает. А вот в qtbase\examples\widgets\graphicsview\boxes - вообще нет никакого следа devicePixelRatio(), все каким-то чудом работает "само" (и ретина поддерживается нормально)

Sony A7R (и другие cRAW): теория ETTR, часть 1

Как и обещал, опубликую свои соображения про ETTR в Sony A7R (и всех других камерах Sony, использующих формат cRAW, локально 7-битный и с тоновой кривой).

Техника ETTR (Exposure to the right) была разрекламирована Майклом Рейхманом, идея ее заключается в следующем:

  • Цифровой сенсор линеен по яркости , человеческое зрение (и фотография) нет.
  • В верхнем стопе цифрового изображения, полученного с линейного сенсора, размещается половина всех записываемых уровней, в следующем четверть, и так далее.
  • Как следствие, полезно экспонировать так, чтобы гистограмма прижималась к правому краю , так мы используем максимально возможное количество уровней.
Сама по себе идея выглядит разумно, ее несколько портит то, что RAW-конверторы (и/или используемые там цветовые профили) не вполне линейны, поэтому два кадра, снятые вправо и нормально , после приведения их конвертором к одной яркости не будут выглядеть одинаково (про что я уже писал 4 года назад).

Однако если (самостоятельно) построить цветовые профили под такое экспонирование, ETTR позволяет решить две задачи:

  1. Вообще использовать максимальное количество градаций (чем правее мы сняли, тем меньше градаций потеряем), в том числе и для полутонов.
  2. И особенно вытащить значимые тени (где мы планируем показать детализацию) из области с очень малым количеством градаций (и значимыми шумами) в область, где градаций - побольше, а относительный шум поменьше.
На мой взгляд, смысл имеет только вторая задача: нормально тянуть тени можно имея не менее десятка-другого градаций на стоп . Естественно, если мы увеличиваем экспозицию, чтобы тени попали в диапазон с бОльшим числом градаций, то у нас и света-полутона переедут повыше, то есть решая вторую задачу - мы как-то решим и первую.

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

Однако инженеры фирмы Sony внесли в это благолепие две своих изюминки: тоновую кривую и сжатие с потерями. В этом тексте рассмотрим только тоновую кривую.

Sony A7R: соображения про вибрации

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

Последние месяцы интернет бурлит на тему 'Sony A7R Shutter vibration'. Дескать затвор колотит так, что звезды с неба падают.

На эту тему очень много у Кассона, Чамберса (большей частью за paywall), dpreview, fredmiranda и прочая, прочая, прочая.

Я в комментариях поминал уже, что это все не кажется мне таким уж страшным для относительно небольших фокусных. На 400mm (на которых я уже смотрел) ситуация непростая (вкратце: при том креплении, что я использовал, эффект есть от 1/10 до 1/100, причем есть в неприятных масштабах; На более коротких выдержках - да, при 200% на экране можно видеть следы смаза, но я готов с этим жить), но чтобы ее исследовать в деталях - мне нужно дождаться L-bracket, а она "в пути".

Вместе с тем, в интернетах договорились уже до того, что на неудачном диапазоне выдержек (1/10-1/100 или что-то вроде того), даже с родным 55-мм объективом есть деградация "и 36-мегапиксельная Sony A7R становится 24-мегапиксельной по разрешению".

Вот что я имею по этому поводу сказать:

Pages