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

lexa - 20/Фев/2014 17:30

Вот есть такой вызов, 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

lexa - 19/Фев/2014 23:15
Два текста про гистограммы RawDigger (наверное, со временем станут частью мануала): На русском языке, увы, не существуют.

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

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

lexa - 14/Фев/2014 21:16
Год с хвостиком назад, когда я в первый раз озаботился соневским cRAW, я из общих соображений предсказал, что должны быть проблемы на кадрах типа "звезда на фоне темного, но не черного неба".

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

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

Такие дела.

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

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

lexa - 14/Фев/2014 13:13

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

Exposure for RAW vs. Exposure for JPEG

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

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

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

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

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

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

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

Q: Qt 5.2 и Retina

lexa - 11/Фев/2014 11:01

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

Особенно использующие 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

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

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

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

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

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

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

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

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

lexa - 07/Фев/2014 16:34

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

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

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

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

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

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

Литий в почте - 2014 - 3

lexa - 06/Фев/2014 16:23
Продолжаем репортаж (начало тут, продолжение здесь).

Шведские улитки сегодня принесли мне литиевые батарейки. Итого общий тайминг:

  • 15 января заказал
  • 22 января - появились в шведском трекинге (но, как я понял, в Сингапуре)
  • 26 января "Прибыло на территорию РФ" (новое слово в нашем трекинге)
  • 29-го - "импорт"
  • 30-го растаможка
  • 4 февраля засветилось на моей почте
  • сегодня получил (извещение тоже сегодня или вчера вечером)
Если считать, что "экспорт" из Сингапура был 22-го, то получается 2 недели с копейками, из которых половина по Москве.

Режим лютует, в прошлом году "хорошей нормой" было недели 4 (под многотонные завалы в аэропортах лично я не попал, худший вариант был недель 6).

Открытий чудных....

lexa - 06/Фев/2014 13:49

Пару недель назад я уже писал о чУдном EXIF в RAW у Sony A900: в 12-битном линейном режиме в EXIF остается тоновая кривая (которая в этом режиме не нужна/не используется) и уровень черного от cRAW (вчетверо выше правильного).

То есть, если вы хотите брать черный из EXIF (что идеологически правильно: выйдет Sony A901 или там поменяют в firmware что-то - а ваш софт уже готов и работает), то нужно проверить на каком мы свете формат и поделить на 4, если 12-битный линейный.

Вчера выяснилось, что аналогично отличилась и компания Nikon: у D5300 в 12-битном режиме совершенно все так же: уровень черного записан для 14-битного режима, а если файл 12-битный, то надо поделить этот черный на 4.

Но и это не все: у D3300, у которого 14-битного режима вовсе нет, в уровень черного в EXIF опять записан учетверенный вариант. Там написано 600 (для тех файлов, что имею на руках), а правильный - 150.

Возможно, Nikon отличился давно, а не в последних моделях, но раньше черный вычитала сама камера, поэтому в EXIF в этом месте были нули.

P.S. невольно начинаешь любить DNG.

P.P.S. Вполне возможно, что Nikon, на самом деле, так заботится о нас. Ну то есть D3300 сохраняет совместимость с D5300 в этом месте. Убилбынах.

Q: Macbook retina + внешний монитор

lexa - 05/Фев/2014 15:32

А вот, я извиняюсь, вопрос.

  1. Берем MacBook pro с ретиной
  2. Выключаем Mission Control - Displays have separate Spaces
  3. Подключаем внешний (не ретинный) монитор
  4. Запускаем какую-нибудь Retina-enabled программу (я взял Keynote)
  5. Размещаем ее окошко на двух мониторах сразу
  6. И начинаем немножко двигать с монитора на монитор.
Так вот, если >50% окна на ретине, то на не-ретина-мониторе как-то пере-рендеривается эмуляция ретины (ну более-менее понятно что происходит - рендерится в фреймбуфер и растягивается немножко). И наоборот.

При этом, если совсем мелкие/тонкие шрифты при таком пере-рендере выглядят плохо, то вот начиная с более-менее рабочего размера шрифта - наоборот, этот пере-рендеренный вариант нравится мне больше и для некоторых приложений (вроде Терминала, где шрифты крупнее "лимита") я бы его сохранил.

Вопрос: а как, собственно? Ну кроме как оставить половинку окна на ноутбуке (что меня совершенно не устраивает).

Обратное неверно - если HiDPI-режим выключается, на ретинном мониторе оно смотрится плохо.

P.S. Ретина - рулит, конечно. Сходу в глаза оно не бросается, но вот два 15" макбука рядом - просто вот вопросов нет. Захотел 4k монитор еще отчетливее.

P.P.S. Теория, что оно просто 2x и все - ерунда. В той же Keynote, если 51% окна утянуть на не-ретинный монитор, в оставшихся 49% букивки маленько прыгают. Метрики шрифтов немножко разные.

RawDigger 1.0.3: удобный анализ экспозиции (для ETTR и не только)

lexa - 03/Фев/2014 18:58
Мы тут которую неделю обсуждаем экспозицию и то, что современные камеры склонны недодерживать относительно разумной (для RAW-фотографа) экспозиции.

Илья на эту тему написал текст, но в процессе его подготовки мы выяснили, что имеющиеся в RawDigger инструменты неудобны для тех, кто не умеет логарифмировать в уме.

Поэтому в RawDigger 1.0.3 включен более удобный механизм, позволяющий оценить а что было бы, если бы мы этот снимок снимали бы с большей экспозицией . Собственно, состоит он из единственного дополнительного движка Auto OE Offset на вкладке Over/Under Exposure в настройках:

Вот этот самый Auto OE Offset позволяет подвинуть границу, по которой считается передержка, вниз относительно определенного автоматом (если автомат не нашел на гистограмме снимка признаков передержки, то граница OverExposure ставится по лимиту данных камеры, исходя из битности и уровня черного).

Pages

Subscribe to blog.lexa.ru: все статьи