воскресенье, 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) не пользуется):
  1. // Process 32 pixels (16x2) per loop.
  2.     for (uint32 x = 0; x < w - 30;) {
  3.       bits.checkPos();
  4.       int _max = bits.getBits(11);
  5.       int _min = bits.getBits(11);
  6.       int _imax = bits.getBits(4);
  7.       int _imin = bits.getBits(4);
  8.       int sh;
  9.       for (sh = 0; sh < 4 && 0x80 << sh <= _max - _min; sh++);
  10.       for (int i = 0; i < 16; i++) {
  11.         int p;
  12.         if (i == _imax) p = _max;
  13.         else if (i == _imin) p = _min;
  14.         else {
  15.           p = (bits.getBits(7) << sh) + _min;
  16.           if (p > 0x7ff)
  17.             p = 0x7ff;
  18.         }
  19.         dest[x+i*2] = curve[p << 1];
  20.       }
  21.       x += x & 1 ? 31 : 1;  // Skip to next 32 pixels
  22.     }
    Если простыми словами, то
    • Пишутся, действительно, 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 и так далее.
Следствий из этого я вижу два:
  1. Если на вашей камере есть выбор между нежатым и жатым RAW (как он есть на A900), используйте нежатый. Вы не для того снимаете в RAW, чтобы сходу терять бит из данных, там их всего 12.
  2. Для рассматриваемого же формата получается интересный вывод относительно ETTR:
    • Больше всего градаций - в 4-м сверху стопе. Т.е. "полутонах", "средне-сером".
    • Во всех стопах светлее средне-серого и в 5-м сверху - градаций около 300.
    • И только в более глубоких тенях количество градаций в данных начинает уменьшаться
    Как следствие, сдвигать, к примеру, 4-ю зону (по Адамсу) в 6-ю нет никакого смысла, градаций не прибавится. А вот гемороя прибавится т.к. цветовые профили поползут.
Помимо Sony, подобные кривые, хранящиеся в метаданных, есть у большинства снимающих в 8-битный RAW камер, у некоторых камер Kodak, некоторых 12-битных камер Canon (подозреваю 1D/1Ds, но пока не проверял), кинокамер Red. Но содержимое кривых на этих камерах я пока не смотрел. Хотя по смыслу должно быть похоже, ибо делается для одного и того же.
Ну и в DNG тоже есть, но тоже не исследовал, используется ли, кем и как.