воскресенье, 24 февраля 2013 г.

Падал непрошлогодний снег..

воскресенье, 17 февраля 2013 г.

Обзор объектива Zeiss Distagon T 35mm F/1.4 ZF.2 - часть третья - фото

только фото, в разных режимах.

Обзор объектива Zeiss Distagon T 35mm F/1.4 ZF.2 - часть вторая

Чтобы было удобно сравнивать с теми тестами, которые были сделаны ранее, сегодня протестируем Zeiss Distagon T 35mm F/1.4 ZF.2 на кропе - камере Никон Д5100 и сравним с линзами, героями предыдущих обзоров: с Токиной 12-24 и с Никоном 40.

Во второй части сравниваем с Токиной на 24мм, в четвертой - с Никон 40мм.

Итак, стандартные условия тестирования, штатив, кроп с РАВ 1:1 и т.д. Слева, если не сказано иного - Токина на 24мм, справа - Цейс.

Центр, диафрагма =4.

напоминаю, что Токина на 24мм при Д=4 показывает максимально нерезкую картинку- особенность конструкции.

Края, Д=4

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

Центр, Д=5.6

Края, Д=5.6

Центр, Д=8

Края, Д=8

А теперь отдельно рассмотрим поведение Цейсса при максимально открытой диафрагме.
Слева и справа будет Цейс но при разных Д. Справа Д=8.

Центр, слева Д=1.4

Края:

Центр, слева Д=2.8

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

Обзор объектива Zeiss Distagon T 35mm F/1.4 ZF.2 - часть первая

В первой части - немного о самой линзе и ее характеристиках.

все: 830гр
оптическая схема: 11 элементов в 9 группах

Distagon - это название оптической схемы.
Цена: примерно 1900долл.

Впечатления.
Отличная сборка, металл, удобная эргономика. Тяжелый, средних габаритов.
Ручной фокус требует сноровки и времени.
В работе с Никон экспозиция очень часто определялась неверно, требовалась минусовая поправка более чем на 1.

Кому интересно почитать обзор на DxO Mark:
обзор линзы

Подробности полевого тестирования - в следующей части.

понедельник, 4 февраля 2013 г.

RAW SONY - всего 7 бит?

Кросспост из блога автора.

Про тоновую кривую в новых камерах Sony я уже писал и повторяться не буду.
Но тут переписывался с Ллойдом Чамберсом на тему Sony RX1 (прежде всего, конечно, как щупать RawDigger-ом неподдерживаемые камеры, как уровень черного определить и т.п.) и обнаружил массу веселья в самом формате ARW, точнее в новых его версиях.
В камерах Sony используются три формата записи RAW:
"Старый ARW" - камеры поколения Sony A100-A290 (точный список не составлял, по ощущениям это именно "старые камеры"). Это обычное такое хаффмановское сжатие, без потерь. При использовании этого режима - RAW-файлы будут сильно разного размера, в зависимости от детализации и шума.
Нежатый 12-битный RAW. Просто пишутся 2 пикселя в 3 байта, без сжатия, без потерь, без прочих глупостей. Этот формат используется в A900 в режиме "большие файлы" (~36Mb + размер JPEG), в Minolta 5D, возможно в еще каких-то, опять же не изучал. При использовании этого режима размер файлов "примерно одинаковый", полтора байта на пиксель плюс размер JPEG-а и EXIF-блоков. Соответственно, с A900 получается 36-37-мегабайтный файл.
Формат "ARW2" (так его называет Dave Coffin, а за ним и я). Этот режим записи используется во всех новых камерах Sony: NEX-xx, SLT-Axx, RX1, RX100. Его можно включить и на A900 (никогда не было этой камеры, надеюсь что этот режим включился не насильно после апдейта фирмвари, а есть возможность переключения юзером).
При использовании этого режима RAW-файл имеет размер "1 байт на пиксель" (+JPEG и EXIF, конечно). 24-мегапиксельная A99 или NEX7 (или A900 в этом режиме) выдают, соответственно, 24-мегабайтный файл.
Вот последний режим нам и интересен, потому что он (и только он?) используется в актуальных камерах. Вот как выглядит исходный код кусочка декодера (тот кусочек, который собственно распаковывает) этого формата в библиотеке RawSpeed (в dcraw - то же самое по смыслу, но Dave Coffin - истинный хакер и всякими глупостями вроде getBits(7) не пользуется):

// Process 32 pixels (16x2) per loop.
    for (uint32 x = 0; x < w - 30;) {
      bits.checkPos();
      int _max = bits.getBits(11);
      int _min = bits.getBits(11);
      int _imax = bits.getBits(4);
      int _imin = bits.getBits(4);
      int sh;
      for (sh = 0; sh < 4 && 0x80 << sh <= _max - _min; sh++);
      for (int i = 0; i < 16; i++) {
        int p;
        if (i == _imax) p = _max;
        else if (i == _imin) p = _min;
        else {
          p = (bits.getBits(7) << sh) + _min;
          if (p > 0x7ff)
            p = 0x7ff;
        }
        dest[x+i*2] = curve[p << 1];
      }
      x += x & 1 ? 31 : 1;  // Skip to next 32 pixels
    }
Если простыми словами, то 
Пишутся, действительно, 8 бит данных на пиксель.  
Конкретнее Строка пикселов разбивается на куски по 16 пикселов. 
Четные/нечетные пикселы обрабатываются отдельно т.к. они разных цветов. 
В 16 байтном блоке, описывающем 16 пикселов одного цвета, содержатся: 11-битный максимум значений в блоке. 
11-битный минимум значений в блоке. 
4-битные индексы минимального и максимального пикселов в блоке, что позволяет эти пикселы закодировать 4-мя битами и точно. 
14 7-битных дельт относительно минимума. 
7-битные данные превращаются в 11-битные путем сдвига на 0-4 бита влево и прибавления минимума в блоке. 
Соответственно Если у нас внутри 16-пиксельного блока одного цвета - маленькие  вариации (меньше 128 единиц АЦП), то данный метод пакует без потерь. И  всякие ровные градиенты будут переданы хорошо. 
А если в блок попала какая-то контрастная граница (или просто  пиксель зашумел), то точность представления остается все той же,  7-битной и данные о цвете/яркости будут переданы приблизительно (с  7-битной точностью). 
11-битные данные (точнее, "локально 7-битные") значения сдвигаются на бит влево и засовываются в кривую которую мы обсуждали тут год назад. 
Короче, если вы хотите потроллить соневладельца (но только с новыми  камерами, NEX-xx, SLT-Axx, RX-1, RX-100), вы просто скажите ему, что у  него RAW - 7-битный (а начнет возмущаться - ну уточните, что 1/8  пикселов - 11 битная, но остальные то - точно 7-битные).  P.S. Эти самые 7 бит - несравнимы с 8-битным TIFF и подобными. У TIFF -  гамма-коррекция, а RAW-данные - линейны и в тенях там, при наличии  хот-пикселов, резких границ и т.п. будет нехорошо. 
P.P.S. Сдается мне, что пресловутая 14-битность, про которую пишут для  RX1 и A99 - относится только к диапазону значений в тоновой кривой.  

О линейности RAW и ETTR

На картинке - кривая, которая применяется к RAW-данным камеры Sony NEX-C3 при их распаковке. NEX-C3 просто первая попалась под руку, в компрессированных RAW A77 или A900 совершенно такая же по смыслу кривая, немножно отличается в деталях.
После наложения этой кривой, RAW-данные становятся линейными. Соответственно, при упаковке используется обратная кривая, линейная в тенях и полутонах и загибающаяся в светах (последних 3 стопах диапазона). По сути, три верхних стопа диапазона сжали в 1 стоп сигнала.
Где именно происходит процесс сжатия светов из формы кривой (и процедуры распаковки) выяснить нельзя, это может быть и цифровой процесс над линейными данными обычного АЦП и сжатие в нелинейном АЦП или нелинейном предусилителе.
Собственно, ничего плохого в такой компрессии светов нет. От того, что в верхнем стопе будет не 2048 градаций (предполагая 12-битный АЦП), а "всего" около 600 - становится только хорошо, потому что поэкономленные 1400 градаций переезжают на второй и третий стопы сверху (полутона и следующий стоп за ними).

В случае Sony градаций на самом деле меньше: прежде чем наложить кривую, RAW-значение умножается на 2, т.е. реальная битность RAW-данных не 12, а 11. Cоответственно, в светах у нас примерно по 300 градаций на стоп, а в тенях - обычное линейное убывание, но в 4-м сверху стопе будет не 1024 градаций, а 512, в 5-м - 256 и так далее.
Следствий из этого я вижу два:
Если на вашей камере есть выбор между нежатым и жатым RAW (как он есть на A900), используйте нежатый. Вы не для того снимаете в RAW, чтобы сходу терять бит из данных, там их всего 12.
Для рассматриваемого же формата получается интересный вывод относительно ETTR:
Больше всего градаций - в 4-м сверху стопе. Т.е. "полутонах", "средне-сером".
Во всех стопах светлее средне-серого и в 5-м сверху - градаций около 300.
И только в более глубоких тенях количество градаций в данных начинает уменьшаться
Как следствие, сдвигать, к примеру, 4-ю зону (по Адамсу) в 6-ю нет никакого смысла, градаций не прибавится. А вот гемороя прибавится т.к. цветовые профили поползут.
Помимо Sony, подобные кривые, хранящиеся в метаданных, есть у большинства снимающих в 8-битный RAW камер, у некоторых камер Kodak, некоторых 12-битных камер Canon (подозреваю 1D/1Ds, но пока не проверял), кинокамер Red. Но содержимое кривых на этих камерах я пока не смотрел. Хотя по смыслу должно быть похоже, ибо делается для одного и того же.
Ну и в DNG тоже есть, но тоже не исследовал, используется ли, кем и как.

воскресенье, 24 февраля 2013 г.