Фоторюкзаки: LowePro PhotoSport

А вот занесло меня на сайт к LowePro и увидел я там рюкзаки Pro Sport.

Имею сказать: они не безнадежны, не прошло и 9 лет c тех пор как я на них катил баллоны - и у них начало получаться что-то такое, что я бы тогда, 9 лет назад, купил бы.

Ну то есть вполне прилично выглядит же: 1.7 кило, 30 литров, отделение для фото внизу, отделение для шмоток наверху. По весу - примерно то же самое, что у меня на базе обычного рюкзака и самопальной вставки. По объему под фото-часть - ну вот мне уже мало (а под мелкую систему - что-то мне кажется, что будет неудобно).

Более крупные варианты мне не кажутся убедительными. Они сильно улучшились за 9 лет, но 2.7 кило за 45-литровый рюкзак с фотовставкой - ерунда же.

Q: Apple Developer Certificate

Вот регистрируемся в Mac Developer Program за $99 (в год).

Идем туда, выписываем себе девелоперский сертификат.

Смотрим в него - а он на 5 лет (с момента выписки, не с начала действия программы)

Верно ли я понимаю, что если в последний день действия годовой оплаты Эпплу выписать себе сертификат, то можно поэкономить $495 на следующие 5 лет? Или отвалится чего?

Речь не про (макосный) App Store, а именно про 3rd-party софт, который раздается мимо аппстора.

Про нейтральные фильтры Haida - 2

Продолжение темы про Про нейтральные фильтры Haida

У того же продавца заказал 85-мм (Cokin P). Сегодня приехали. Так как дешево, решил взять и 10-стопный тоже.

Результат вот:

Слева направо: без фильтра, 6-стопный, 10-стопный.

Яркость выведена в одинаковую в ACR кнопочкой Auto, ББ поставлен в Daylight для всех трех кадров.

Как мы видим, 6-стопный чуть желтит, 10-стопный - желтит-мажентит еще сильнее, но автобаланс со всем этим справляется:

Интересно с экспозицией/замером. Камера поставила, автоматом, 1/800, 1/13 (1.8D фильтр) и 0.4сек (3.0D). В реальности кадры с фильтром оказались недодержаны на 1EV и 2.5EV соответственно, второй даже переснял.

Получается, камера с плотными фильтрами изрядно недодерживает (окошко видоискателя при замере затыкал), при этом 6EV-фильтр на самом деле скорее 7EV, а 10-стопный - примерно 11-стопный.

О вибрациях - 2 (A7R + Zeiss 135/2)

Потратил еще полчаса на комбинацию A7R + Sonnar 135/2. За исключением объектива, участники те же, что и в прошлый раз.

Камера крепилась на штативе за L-bracket, никаких хомутов, никаких саппортов, ничего.

Методика та же самая: снимаем установочный кадр на 1/800-1/1000, ставим нейтральный фильтр и, на одной диафрагме (f/5.6, как и вчера) снимаем серии на разных выдержках-ISO. Выдержки от 1/3 до 1/100 с шагом в стоп.

Имею сказать следующее:

1. Горизонтальный кадр

Единственное отличие между кадрами - увеличение шума на ISO800. Кадры на ISO50-400 я вообще отличить не смог бы в слепом тесте, а 800 - да, видно по шуму на голубом небе.

2. Вертикальный кадр

На контрастных деталях ситуация аналогичная: я не вижу разницы в ряду 1/3-1/6..1/100 и 1/1000 (без нейтрального фильтра), за исключением разницы в шумах.

Зная, что вертикальные кадры - проблемнее - стал смотреть и другие места, нашел муарчик, ОПА, а 1/13 и 1/25 - отличаются, на 1/25 муарчика как-то меньше, не такой муаристый.

Но. На 1/50 и 1/100 (ISO800) - муар не стал снова муаристее. Подозреваю я, что съела его не вибрация, а увеличение чувствительности.

Итого

  1. Видимой мне проблемы с вибрациями в данной паре A7R + 135/2 - НЕТ.
  2. И вот что-то меня гложет, а вот Ллойд Чамберс, который увидел вибрационные следы на 55/1.8 - уж не по ISO ли брекетил?
P.S. Авторский коллектив этого блога передает привет пользователям челюстей с защелками. Вот винтовые челюсти я могу потянуть от души, а на защелочных это невозможно.

О вибрациях

Выделил несколько часов и таки позанимался лично проблемой Shutter Vibration у A7R.

Участники и методология

Камера: Sony A7R и немножко Canon 6D. Спуск у Sony - беспроводной ленивкой, у Canon - тросиком (и просто кнопкой, об этом ниже).

Оптика: Sigma 180/2.8 Macro, Canon 300/4 IS, Canon 70-2004 IS @200mm.

Штатив Gitzo Systematic 3530LS, металлические копыта (не шипы а такие широкие-плоские с зубцами, для камней) голова Photoclam PC54, челюсти на голове - RRS PCL-1. Дополнительное утяжеление штатива не использовалось.

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

Снималось богатое кабельное хозяйство на крыше соседнего дома, для удлинения выдержки использовался нейтральный 6-стопный ямб фильтр. Фильтр ставился к компендиум Lee (Medium Wide, если я правильно помню название), бленда раскатана на всю длину.

Погодные условия: сквозняк, в спину (из квартиры) дуло где-то 3м/с на первых опытах (Sigma 180), потом стихло (но забегая вперед - результаты Сигмы лучше всех, т.е. ветер не влиял).

Все снималось на одной диафрагме f/5.6, выдержки от 1/6 до 1/120, в пару к выдержке менялось ISO. На каждой выдержке делалось по три кадра.

Результаты

Забегая вперед: результаты в такой конструкции определяются, как мне кажется, качеством хомута (или, возможно, весом оптики, но 180/2.8 и 300/4 достаточно близки по весу).

Q: samsung galaxy note battery

А я верно понимаю, что если батарее в телефоне 2.5 года и телефон внезапно начал очень быстро садиться, то не надо искать жрунчика среди обновленных программ, а надо просто батарею поменять?

P.S. Мелкий карманный телефон у меня того же возраста, но эффекта в *такой* степени не проявляет, как раз в неделю заряжал, так и заряжаю вроде бы.

Ненависти к Qt псто

А вот представим себе такое вот:

  • QGraphicsView и QGraphicsScene
  • Показываем картинку с каким-то увеличением, так что есть скроллбары (или только один)
  • И хотим показать следующую картинку "примерно так же" (в смысле относительного положения окна просмотра относительно всей картинки)
  • И хотим, чтобы когда мы вернулись к предыдущей - позиция сохранялась бы.
Нормальное желание, правда?

Ну вот казалось бы решение:

  • Рассчитать какая (относительная, в координатах 0-1) точка исходной картинки расположена в центре экрана.
  • Рассчитать далее, какая абсолютная точка следующей картинки должна быть в этом самом центре.
  • Дальше - view->centerOn()
Почти работает.

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

И приходится нецензурно закатывать солнце вручную:

  • Если исходно скроллбар есть - запоминаем его относительную позицию (где у нас value() между minimum() и maximum()). Если нет - берем запомненную ранее, когда скроллбар был.
  • Дальше нужно посчитать, будет ли скроллбар при показе следующей (какой размер больше, картинки или viewport()
    • Если не будет, то скроллбар надо явно выключить, потому что если разница в несколько пикселов, то его может включить.
    • Если будет - то явно включить, доверять автоматике нельзя (бывает клево: view ставит скроллбары и зовет resizeEvent(). resizeEvent() знает, что режим у нас fit-to-screen и ресайзит картинку. view - видит что картинка поресайзилась, убирает скроллбары, зовет resizeEvent().....).
  • И если скроллбар будет - то явно ему поставить value (пересчитать из предыдущего относительного)
  • А если не будет - то припрятать относительное value до следующего раза, когда скроллбар появится.
Работает. Можно листать 10 картинок (разного размера и aspect ratio) вперед, потом назад - и вернуться ровно в ту точку/экранную позицию, с которой начинали.

Но, сука, 98 строк кода (считая пробелы). Вместо эдак 8-и, с которыми работает, но примерно.

Про AMD FirePro W9100

Вот между прочим, AMD выступила очень достойно с FirePro W9100: они сделали чип у которого отношение производительности Single Precision : Double Precision 1:2, вместо обычных для AMD 1:4 (а на HD5xxx было 1:5)

В результате у них 2.6TFlops DP (теоретической), что в 1.85 раза больше, чем у (самой толстой на сегодня) NVidia Tesla K40 (1.4Tflops теоретических).

Да, у AMD не все здорово с софтовой частью: все кто вычислял вычисления уже привыкли к CUDA, перенос кода на OpenCL и оптимизация для AMD займут время, но почти двукратный выигрыш по перформансу (и еще больше, по прайс-перформансу, если сравнивать с Теслой) - взбодрит разработчиков.

Я ожидаю, в первую очередь, взбодрения всяких CAD-ов. Это FirePro не выглядит картой для вычислительных кластеров (коим 6 видео-выходов без нужды), а вот на рабочих станциях, и 3D-графика и ее обсчет на одной карте - очень к месту ж.

Ждем, естественно, ответа NVidia. Так, по идее, Maxwell - хороший, 750Ti обгоняет 650Ti на вычислениях прилично так (при меньшем количестве cores и достаточно близких частотах).

P.S. Конечно, лидером по price/perf (DP) остается NVidia Титан, но это другая история (на Титан, в числе прочего, драйвера от Квадры не натянуть, т.е. всякие CAD-ы пролетают).

Про нейтральные фильтры Haida

Один из способов убрать "трясучку" у Sony A7R - это уехать из области опасных выдержек (1/200 - 1/4, в первом приближении). Укоротить - легко (в некоторых пределах), просто увеличим чувствительность на пару стопов, проблема - увеличить выдержку, особенно если диафрагма задана сюжетом (или каким-то еще соображениями).

Насколько я слышал, большинство Vari-ND-фильтров не полностью нейтральны. И чем нейтральнее, тем получается дороже.

Пластик (Formatt/Hitech), который я пользовал (4-9 стопов) - тоже достаточно сильно окрашен, многое выправляется балансом белого, но осадок остается. У Formatt появились еще ProStop IRND, стал про них читать, наткнулся на сравнение с Haida. А Haida - есть на Ebay, дешевле простопа раза в два-три (100mm: $85 /стекло/ с бесплатной доставкой против 100/150 фунтиков за пластик/стекло+ доставка), плюс еще вот хвалят.

Сегодня приехал 6-стопный (1.8D) и вот результат:

Это два кадра, с одинаковыми установками ББ в ACR (тупо Daylight, magenta cast не убирал), посередине там шовчик (на облаках видно, они уехали немножко пока фильтр снимал). По цвету - практически не отличаются, кривую яркости пришлось вывести по трем точкам, потому что:
  • Светорассеяние с фильтром заметно побольше, поэтому тени "поднялись"
  • Экспонометр в камере, не видя в положенном месте хайлайтов, разницу в экспозиции сделал примерно 1:100, вместо 1:64, снимок с фильтром получился малость недодержан.
Итого: я очень доволен. 10-стопный мне не нужен вроде бы, а 6-стоповый очень оказался хорош.

Про Adobe DNG и Adobe Bridge

Изучал тут поведение Adobe Bridge с DNG и XMP файлами, а оно смешное:

  • В DNG может быть XMP-секция, Bridge ее, естественно, читает. И пишет. Можно туда Keywords или рейтинги написать.
  • Если рядом с DNG лежит его XMP-файл (c тем же именем и, опционально, с тегом photoshop:SidecarForExtension="DNG"), то все берется оттуда, а XMP-секция в DNG - игнорируется.
  • Если начать редактировать метаданные, содержимое XMP + результаты редактирования будут записаны в DNG, а XMP-файл - удален.
  • С другими известными Бриджу файлами он так себя не ведет - пишет все в XMP (хотя в том же CR2 - может быть XMP-секция).
Меня это все сильно удивляло - ну сказано ведь "писать все в XMP", но нет.

А потом - доперло. Наберут по объявлениям. Типичный же workflow с DNG такой (если они не из камеры вылезают):

  • Запускаем DNG-конвертор
  • И фигачим DNG прямо в тот же каталог, откуда берем исходные RAW (сделать что-то отдельное - это ж морока)
В результате - в одном фолдере оказываются filename.raw, filename.dng, соответственно filename.xmp может быть только один. И прятать метаданные прямо в DNG - это хоть какой-то разумный выход из этой дурацкой ситуации. Потому что 8.3, завести filename.raw.xmp и filename.dng.xmp - не моги.

Вишенка на торте - поведение бриджа с файлами, которые он вроде бы знает (формат известен), а вроде бы и нет. Я пробовал с файлами от Sony A6000 (обычный ARW) и от Canon G1X Mark 2 (в этом файле есть XMP-секция):

  • Sony: писать метаданные отказывается, говорит не наш участок не знаю такого формата.
  • Canon: отказывается писать кейворды, но пишет рейтинги. Но пишет их не в сам файл (хоть там и есть XMP-секция) и не в sidecar-XMP, а в отдельный файл в каталоге .BridgeLabelsAndRatings (сказано, конечно, писать в XMP)
Все мысли на эту тему уже выражены в реплике Ильи. Количество специальных случаев, которые приходится обрабатывать, - удивляет.

Раскапывая RAW: Nikon Small NEF (NEF S)

Продолжаем традицию анонса наших публикаций. На этот раз на русском:

Раскапывая RAW: внутреннее устройство Nikon Small Raw

Для удобства ленивых читателей выводы вынесены в начало текста. Перевод на английский будет, но не мгновенно.

Комментировать можно там (требуется регистрация), можно тут, как удобнее.

P.S. И рабочий крик души про этот формат.

Q: embedded JPEG на вертикальных кадрах

Уважаемые читатели,

Если вас не затруднит, не могли бы вы сделать следующий эксперимент:

  1. Взять любой вертикальный кадр в RAW (или RAW+JPEG) с вашей камеры.
  2. Заглянуть в JPEG-часть (внутреннюю или внешнюю) Exiftool-ом (или чем хотите) и ответить на следующий вопрос:
    • Это действительно вертикальный JPEG (высота больше ширины)
    • Или он на самом деле горизонтальный (высота меньше ширины) и повернут тегом
Для Canon, Sony, Nikon у меня получился вариант два (поворот сделан тегом), но конечно я не все модели камер изучал. Хочется понять, есть ли камеры, которые пишут вертикальные JPEG-и для вертикальных кадров, или же оно всегда тегом.

UPD. В таком вот духе:

exiftool -*image* -*thumb* -*preview* -a -e filename.raw
Оно выдаст пачку *width/*height (на все картинки, что есть в файле), интересен случай, когда blablaHeight больше blablaWidth.

Pages

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