суббота, 31 августа 2013 г.

[life.cinema] Очередной кинообзор (2013/08)

Подошло время очередного кинообзора. Как обычно, вначале идут фильмы, которые мне понравились больше всего. В самом конце те, на которые время можно не тратить вовсе.

Игра в правду. Просто лучший фильм из того, что довелось посмотреть за последний месяц.

Лучшее предложение. Очень понравился. Хотя для меня фильм оказался “немного предсказуемым” © ;)

Элизиум: Рай не на Земле. Как будто продолжение “Район #9” посмотрел. Здорово. Но “Район #9” явно покруче.

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

Ледяной. Похоже, авторы пытались показать две совершенно противоположных стороны одного человека: убийцы и примерного семьянина. С убийцей получилось, с семьянином нет. Впрочем, хорошие актеры и криминальный сюжет здорово выручают этот фильм.

РЭД 2. Если понравился первый РЭД, то можно смело смотреть и второй. Хотя мне второй понравился меньше.

Византия. На мой взгляд, в этот хронометраж легко можно было вместить больше экшена, жестокости, крови и, имея в главных ролях актрису с выдающимися формами, обнаженки. А так, актеры хорошие, операторская работа на уровне, какой-то сюжет есть. Но все постненько, нудненько и скучненько.

Сезон убийц. Даже Траволта и ДеНиро не спасают этот маразматический фильм. Ну никак не могу поверить в то, что отставной полковник американской армии оставит в живых человека, который мало того, что пытался убить полковника, так еще и угрожал оружием сыну и внуку главного героя.

Грабитель. Потенциально интересная история какими-то европейскими кинематографистами была превращена почти что в нуднейший артхаус.

пятница, 30 августа 2013 г.

[prog.thougts] Для разных целей разная сериализация...

Я уже давно имею дело с сериализацией различных структур данных в C++. Началось это где-то в 1995-м, когда я предпринял попытку создания объектной СУБД. Объектная СУБД -- это такая штука, в которой объекты хранятся как есть, без расщепления на составляющие. Например, если мы попытаемся сохранить в реляционной СУБД C++ный объект, который содержит не только простые атрибуты (int-ы или string-и), но и агрегаты (например, вектора или множества строк), то нам потребуется в схеме данных БД предусмотреть дополнительные таблицы для хранения значений этих агрегатов. А при сохранении объекта проводить раскидывание значений его атрибутов по разным таблицам (собственные атрибуты в одну таблицу, атрибуты из объектов внутри агрегата -- в другую). Аналогично и при чтении объекта из БД. В свое время евангелисты ООСУБД проводили такую аналогию: хранение объектов в РСУБД похоже на хранение автомобиля в гараже в полностью разобранном виде :)

Различные системы объектно-реляционного мэппинга (ORM) могут скрывать от разработчика всю трудоемкость этих преобразований объектной модели в реляционную, но, тем не менее, разработчик должен понимать, хотя бы в общих чертах, что именно происходит и чем ему за это придется платить. А вот при работе с ООСУБД такого расщепления объекта на составляющие не происходит, сама СУБД отвечает за то, чтобы из сложного объекта получить один сериализованный образ и сохранить его в БД. Поэтому продолжая аналогию с автомобилем, в ООСУБД автомобиль помещается в гараж и извлекается из гаража в полностью собранном виде, не тратя время на сборку/разборку. В определенных прикладных областях подход ООСУБД оказывался намного эффективнее (например, при работе с векторными изображениями, где объектами являются элементы изображения).

Так вот, занимаясь объектной СУБД пришлось решать задачу сериализации сложных C++ных объектов без участия разработчика. Под сложными я подразумеваю объекты, которые состоят не только из значений примитивных типов (т.к. int, float/double, char[]/string). В качестве типов атрибутов могут указываться другие сериализуемые пользовательские типы. А так же агрегаты (простые C-шные вектора, STL-контейнеры), элементами которых могут быть как примитивные, так и сложные пользовательские типы. Кроме того, поскольку речь идет об объектах, обязательно должно поддерживаться наследование. А уж коль речь зашла о C++, то и множественное наследование, ну и раз множественное, то и виртуальное множественное. Например, в следующем псевдокоде класс Polygon является сложным объектом (в отличии, например, от Color или Point):

struct Color {
   int8_t r;
   int8_t g;
   int8_t b;
};

struct Point {
   float x;
   float y;
};

struct Polygoin : public ImageItem {
   std::vector< Point > points;
   Color border_color;
   Color fill_color;
   int32_t fill_pattern_id;
};

Под "сериализацией без участия разработчика" я подразумеваю то, что разработчику не нужно писать код, управляющий (де)сериализацией. Т.е. программист не должен вручную писать что-то вроде:

Archive &
operator<<( Archive & a, const Polygon & o )
{
   a << o.points.size();
   forauto & p : o.points )
      a << p;

   a << o.border_color
      << o.fill_color
      << o.fill_pattern_id;

   return a;
}

Archive &
operator>>( Archive & a, Polygon & o )
{
   std::size_t points_count;
   a >> points_count;
   while( points_count-- )
   {
      Point p;
      a >> p;
      o.points.push_back( p );
   }

   a >> o.border_color
      >> o.fill_color
      >> o.fill_pattern_id;

   return a;
}

Применительно к объектным СУБД возможность (де)сериализации без участия программиста была нужна вовсе не для того, чтобы упростить жизнь пользователю СУБД. Там это было необходимо для того, чтобы СУБД могла получать доступ к значениям атрибутов объекта (для построения индексов, проведения поисковых запросов, просмотра/модификации данных из административных GUI-инструментов) и для поддержки эволюции схемы данных (например, для автоматической конвертации значений объектов при изменении типа Point::x/y с float на double). Но, на мой взгляд, именно автоматическое управление (де)сериализацией объектов делает практически осуществимой работу с действительно сложными структурами данных.

Мой первый опыт работы с автоматической (де)сериализацией C++ных структур данных был накоплен в период с 1995-го по 2000-й год во время попытки создать полноценную клиент-серверную объектно-ориентированную СУБД. Через два года, в 2002-м этот опыт был использован в новой разработке ObjESSty, которая задумывалась как a) встраиваемая в приложения система долговременного хранения объектных данных + b) система (де)сериализации этих самых объектных данных.

Спустя 10 лет от поддержки в ObjESSty встраиваемого долговременного хранилища я решил оказаться. А вот в качестве системы (де)сериализации данных ObjESSty продолжает развиваться и сейчас. Как раз длительный опыт использования ObjESSty в разных качествах привел меня к мысли, что не смотря на то, что одна и та же сериализация может использоваться для разных целей, все-таки есть важные отличия между двумя основными задачами сериализации данных:

  • для долговременного хранения и последующего чтения/воспроизведения/модификации информации. Например, бинарный Word-овский doc-файл, который может внутри себя содержать текст, картинки, таблицы и пр. Или sav-файл компьютерной игры, в котором сохраняется текущее состояние игрового процесса;
  • для поддержки транспортных протоколов (коммуникация между взаимодействующими между собой приложениями/узлами сети). Например, текстовый UCP/EMI. Или бинарный SMPP. Или же текстовый SOAP.

Фокус в том, что универсальная система (де)сериализации может применяться и для того, и для другого. Например, XML-представление может использоваться как для долговременного хранения данных (см., например, Open Document Format), так и в качестве формата транспортного протокола (SOAP), хотя за применение XML в транспортном протоколе нужно изгонять из профессии ;) Поэтому такое различие несколько условно. Между тем, есть моменты, которые показывают, что дьявол таки скрывается в деталях.

Первый момент -- это вопрос сложности поддерживаемых системой (де)сериализации структур данных. Если речь идет о транспортном протоколе, то вряд ли имеет смысл выходить за рамки простого использования объектов в качестве атрибутов других объектов и агрегатов сложнее векторов однотипных объектов. Нужна ли, например, в транспортном протоколе поддержка multimap-ов? Или наследования объектов (и уж тем более множественного наследования)? Это, конечно, зависит от протокола, но, скорее всего, вряд ли. Однако, если речь идет о долговременном хранении сложных данных, то поддержка основных структур данных языка и наследования должны быть обязательно, иначе разработчики придется слишком много возится с преобразованием данных вручную. Так же крайне полезным будет поддержка атрибутов-указателей, причем указателей на полиморфные объекты (т.е. атрибут имеет тип указателя на базовый класс, а содержать будет указатели на объекты производных классов). А так же, в некоторых случаях, окажется востребованной и поддержка циклических ссылок между объектами.

Второй момент -- это сложность формата сериализованного представления данных. С ростом вычислительной мощности обычных компьютеров, объемов доступной оперативной памяти и размеров жестких дисков этот вопрос для долговременного хранения данных все менее и менее важен. Разработчики офисных пакетов могут себе позволить применять XML, который затем будет еще сжат zip-ом, не сильно считаясь с расходами вычислительной мощности, оперативной памяти и диска. А вот разработчики транспортного протокола могут быть вынуждены уделять вопросам сложности формата данных самое серьезное внимание. Например, если одна из взаимодействующих сторон -- это маломощное встроенное устройство, программу для которого нужно писать учитывая каждый байт и контролируя глубину стека. Парсить в таких условиях XML или даже JSON не очень разумно. Или если транспортный протокол разрабатывается для мощных серверов, которые обмениваются друг с другом сообщениями в темпе 15000 в секунду.

Интересная сторона сложности формата -- это ручной его разбор. В случае долговременного хранения информации разработчикам не так уж часто приходится вручную разбирать сериализованный образ объекта, чтобы понять где и что лежит. Как правило, этим приходится заниматься разработчикам самой системы сериализации, но не ее пользователям. А вот в случае транспортного протокола ситуация меняется. Пользователям системы сериализации довольно часто бывает необходимо вручную расшифровать полученный от кого-то дамп коммуникационного обмена. И если система сериализации как-то хитро упаковывает объекты, то эта задача может оказаться еще той работенкой. Например, очень неприятно разбирать дампы двоичных протоколов, в которых информация передается в Little Endian представлении. Особенно когда там много 32-х или 64-х битовых целочисленных значений :)

Третий момент, плотно взаимосвязанный со вторым, -- это объем сериализованного представления данных. В общем случае транспортные протоколы обычно требовательнее к объемам, чем долговременное хранение данных. Но тут не так все очевидно. Например, если для долговременного хранения сериализуются объемные данные (видео, аудио, сложные векторные изображения, результаты интенсивных измерений), то объем их сериализованного представления, а так же скорость их (де)сериализации могут оказаться критичнее, чем объемы единичных пакетов какого-нибудь транспортного протокола, вроде SMPP. С другой стороны для некоторых транспортных протоколов могут существовать специфические ограничения на формат данных. Например, если протокол используется для взаимодействия устройств по 32-х битовой транспортной шине, где передача одного двойного слова (4 байта) осуществляется за один такт, очень желательно размещать поля сериализуемого объекта на границе 4-х байт. Поэтому, если поле A имеет размер шесть байт, а следующее за ним поле B -- три байта, то для двоичного представления полей A и B потребуется 12 байт: первые 8 для поля A (из которых два последних будут пустыми, используемыми только для выравнивания -- т.н. padding bytes), затем 4 для поля B (где первые 3 содержат значение B, а четверый -- это padding byte).

Четвертый момент, плотно связанный с третьим, -- это минимизация объема сериализованного представления за счет опциональных значений атрибутов. Представьте себе, что у вас в программе у множества объектов есть пара-тройка атрибутов, имеющих значение по умолчанию. Например, пусть у вас есть объект PhotoDescription с атрибутами title, subject, rating, tags, comments, authors, copyright и т.д. В ряде случаев для большинства объектов PhotoDescription эти поля будут иметь пустые значения. Нужно ли их сериализовать? Ведь это и объем, и вычислительные ресурсы. Допустим, что сохранять опциональные значения не нужно. Как это будет выглядеть в сериализованном представлении объекта? Например, если используется структурированный текстовый формат (XML, JSON) можно не указывать соответствующие теги. Если же используется двоичный формат, как указывать опциональность атрибутов? Используется ли при этом теговое представление данных или нет? Можно ли использовать битовые флаги?

Пятый момент, плотно связанный с четвертым, -- это возможность расширения объектов со временем. Особенно это актуально для транспортных протоколов. Например, в первой версии протокола прикладной пакет StartSession мог содержать пять обязательных полей и три опциональных. Проходит какое-то время и этот пакет требуется расширить еще двумя десятками необязательных полей. Формат сериализованных данных должен это поддерживать. Причем, в транспортных протоколах речь идет именно о расширении уже имеющихся прикладных пакетов опциональными полями. Новые обязательные поля туда добавлять намного сложнее. Проще бывает добавить новый прикладной пакет, что-то вроде StartSessionEx.

Шестой момент, плавно проистекающий из пятого, -- это возможность модификации структуры сериализуемых данных, так же известная как полноценная поддержка эволюции схемы данных. И здесь, как правило, имея дело с транспортными протоколами, не приходится сталкиваться с кардинальными изменениями схемы данных. Например, если в первой версии протокола координаты передавались в виде float-ов, то крайне тяжело будет изменить float на double. Тогда как если координаты сохранялись в файле с векторным изображением, то следующая версия запросто может потребовать на лету преобразовать старые значения из float-а в double, а потом выполнить обратное преобразование, если происходит сохранение в режиме совместимости с предыдущими версиями.

Седьмой момент -- это поддержка межъязыковой и межплатформенной интероперабильности. В случае с транспортным протоколом очень велика вероятность, что одна из взаимодействующих сторон будет написана совсем на другом языке программирования. Не на C++, к примеру, а на Java, C#, Python или Ruby. И работать она будет совсем на другой аппаратной платформе. Поэтому для транспортных протоколов очень желательно, чтобы выбранная система (де)сериализации поддерживала несколько разных языков программирования и не была привязана к конкретной аппаратной платформе. Для долговременного хранения информации это не так актуально, но наличие такой интероперабильности так же будет большим плюсом.

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

По хорошему, об этом нужно думать всем: и пользователям систем сериализации, и их разработчикам. Но с пользователями особенно-то ничего не сделаешь. В простейших случаях они вообще не думают ;) Ну а чего думать -- есть XML, его и возьмем. Ну не нравится XML, возьмем JSON. Когда повезло настолько, что уперлись в производительность/доступные объемы, тогда уже можно будет посмотреть на что-нибудь более шустрое и компактное: ASN.1, Google Protobuf, Apache Thrift. Ну а тех, кому реально приходится работать с большими и сложными структурами данных, похоже, не так уж и много. Тем не менее, полезно задумываться о том, а заточена ли выбранная вами система сериализации под те нужды, для которых вы ее выбрали. Скажем, Google Protobuf вполне сгодится для создания транспорта. Но вряд ли стоит брать его для хранения sav-файлов в RTS-игре с большим количеством разнообразных юнитов. Здесь Apache Thrift подошел бы получше. А ObjESSty еще лучше ;)

А вот разработчикам систем сериализации думать о том, какую именно задачу решает их система, нужно очень и очень серьезно. Транспорт -- это одно. Здесь акценты на скорости, простоте и компактности представления, своеобразных путях расширения схемы данных. Долговременное хранение информации -- это совсем другое. Хотя, опять же, сильно может зависеть от характера информации. Хранить результаты интенсивных измерений (огромное количество в принципе однотипных значений, возможно каким-то образом сгруппированных) -- это одно. Текстовый или графический документ, или чертеж из САПР -- это совсем другое.

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

Но теперь, по прошествии более десяти лет использования и развития ObjESSty, приходится всерьез задумываться о том, на чем же именно сделать акцент. И вопрос этот непростой. Отчасти потому, что ObjESSty успешно зарекомендовала себя при организации транспорта. Но здесь сильная конкуренция со стороны тех же Protobuf, Thrift, XML и JSON. С другой стороны, не так уж много для C++ готовых инструментов для сериализации сложных структур данных. И это можно было бы обратить в свою пользу. Так что есть о чем подумать.


Еще на эту тему:

четверг, 29 августа 2013 г.

[bugs] И за это еще просють денех?

Решил попробовать DxO OpticsPro 8. После инсталляции он мне предложил скачать дополнительные модули для D700 и нескольких вариантов 85mm объективов. Цейсовского среди них не было, поэтому я выбрал два: D700+Nikkor AF 85/1.4D и D700+Nikkor AF-S 85/1.8G. После чего при попытке перейти к стадии Processing DxO OpticsPro стал выдавать предупреждения о том, что некоторые модули мешают друг другу. Но обработку снимка все-таки делал. После чего в меню DxO Optics Modules/Installed DxO Optics Modules... выбрал модуль для AF-S 85/1.8G и удалил его. После чего при попытке просмотреть снимки я стал получать вот это:

А еще до удаления злосчастного модуля DxO OpticsPro, после включения в опциях галочки для использования OpenCL, тупо завис и его пришлось убивать через Task Manager.

Может это у меня карма такая, подпорченная долгими годами программирования, что баги сразу вылезают. Но платить за такое как-то совершенно расхотелось. Не смотря на то, что шумодав в DxO результаты дает поприятнее, чем Lightroom.

PS. Неужели народ программы писать разучился? :(

[life.photo] Еще немного фотографического

За несколько дней до поездки на Belarus Open-2013 стал думать, какой объектив брать с собой для съемки соревнований. То, что брать нужно всего один объектив было уже понятно: на турнире, особенно если ты сам играешь, нет времени менять объективы. Выбор был из 4-х вариантов: Nikkor 50/1.4D, Nikkor 80-200/2.8, Zeiss Makro-Planar 2/50mm и Zeiss Planar 1.4/85mm.

Полтинники, по опыту съемки на Belarus Open-2012 и Дартс-Весна 2013, не есть удобный вариант. Даже если снимать игрока в полный рост, нужно находиться довольно близко от него, что уже ему мешает. А уж если захочется снять игрока только до пояса, то подходить придется практически вплотную.

В общем, выбор был только между телевиками. Nikkor-овский 80-200/2.8, в принципе, очень хорош. Но. Во-первых, он большой и тяжелый. И если вес еще как-то можно было терпеть, то вот здоровенная труба, прицепленная к аппарату, в принципе не давала возможности играть с фотоаппаратом на себе. Это означало, что когда нужно играть тебе, то фотоаппарат нужно снимать и куда-то класть. А потом следить за ним :)

Во-вторых, диафрагма 2.8 на 80-200, хотя и рабочая, но не такая резкая, как f4 (или, хотя бы f3.2). А если ставить диафрагму f4, а потом еще и выдержку в 1/200 (чтобы компенсировать фокусное расстояние в 200mm), то даже ISO 6400 может не хватить.

В-третьих, автофокус. Штука это, для репортажной съемки, очень нужная. Но вот при съемке спортивных событий далеко не однозначная. Либо я не умею автофокусом пользоваться, либо же это мне так везет, что в самый кульминационный момент автофокус ловит в фокус совсем не то, что задумывалось.

Поэтому, по совокупности факторов, я решил взять Цейсовский мануальный 1.4/85mm. Очень большим плюсом в его пользу был еще и такой фактор. Мне показалось, что Цейсовские стекла пропускают больше света, чем Никоновские. По крайней мере на своем D700 мне приходится ставить экспокоррекцию в -1 стоп, чтобы получать нужную экспозицию при съемке Цейсовским объективом. При съемке Никоновскими стеклами экспокоррекция, как правило, не нужна (а если нужна, то крайне редко она опускается до -1). А разница в -1 стоп при съемке при недостаточном освещении -- это очень много.

Своим решением я доволен. 85mm для таких условий оказалось отличным фокусным расстоянием. Не уверен, были бы 100mm или 135mm полезнее. А 85mm давал возможность и делать портреты, находясь на достаточном расстоянии от объекта съемки, и снимать общие планы не отходя слишком уж далеко (а там особо и некуда было уходить).

Ручная фокусировка оказалась не проблемой. Особенно для такой спортивной дисциплины, как дартс. Правда, было несколько вещей, которые мешали. Главная -- это небольшая глубина резкости на открытых диафрагмах (т.к. f1.4, f2, f2.8). Поэтому я снимал, в основном, на f3.2, иногда открывая до f2, иногда прикрывая до f5.

Еще одна вещь -- это недостаток опыта общения именно с этим объективом. При ручной фокусировке нужно на уровне инстинктов понимать, куда вращать кольцо на объективе при удалении или приближении объекта. У меня такого инстинкта еще нет. Нужно больше практики. Вообще же, ручная фокусировка, особенно на Цейсах, где очень большой ход кольца фокусировки, отличная штука для уточнения фокуса. Т.е. объект съемки немного сдвинулся, чуть-чуть подкорректировал фокус кольцом и все в порядке. А вот где мануальный фокус напрягает, так это при необходимости быстро переключится с близкого к тебе объекта на удаленный. Тогда кольцо нужно вращать очень сильно. Тут бы хотелось помощи от автофокуса с последующей ручной фокусировкой. Пользовался я такой штукой на Никоновских объективах с возможностью instant focus override, но там ход у кольца ручной фокусировки настолько мал, что ошибиться с фокусом вручную гораздо проще, чем на Цейсе.

Вот с чем я, при съемке на Belarus Open-2013, похоже, сильно лопухнулся, так это с параметрами Auto ISO. Лето в этом году выдалось довольно солнечным, поэтому в настройках Auto ISO в качестве желаемой минимальной выдержки я поставил 1/320. Как правило, при хорошем освещении эта выдержка сохраняет ISO 200 даже при диафрагмах f8 и f11. При этом позволяя "замораживать" движения литочков/цветочков при небольшом ветерке.

Так вот на турнире я оставил эти параметры в силе. С одной стороны, это позволило получить более-менее четкие снимки (при движении игроков смаза намного меньше, чем, например, при использовании 1/160). Но, с другой стороны, ISO поднимался до 4000, 5000, а то и 6400. Что не есть хорошо, даже не смотря на возможности D700. Нужно было мне ближе к вечеру, когда освещение становилось слабее, увеличивать максимальную выдержку хотя бы до 1/200. Но я об этом забывал :( Опять же, сказывается отсутствие достаточного опыта.

С Belarus Open я привез более 900 фотографий. На их обработку, если подсчитать потраченное время, ушло два полных рабочих дня, а то и с овертаймами. Отсев и обработка фотографий, даже если она ограничивается всего лишь Lightroom-ом, это серьезная и весьма утомительная работа. Устал я не меньше, чем если бы столько же времени увлеченно что-то программировал.

После того, как я закончил обработку привезенных из Минска фотографий, решил попробовать Capture One Pro от PhaseOne. Мысль об этом терзала меня уже давно, несколько последних месяцев, как минимум, еще до официального выхода Lightroom 5. В пользу C1 говорило то, что эта программа позволяет сочетать в себе как простую массовую обработку потока фотографий (то, под что заточен Lightroom), так и более серьезную индивидуальную доводку отдельных снимков с корректирующими слоями и прочими продвинутыми возможностями (то, под что заточен Photoshop или GIMP). Т.к. я не планирую в ближайшее время осваивать Photoshop (просто нет на это времени, мне бы нормально свое текущее оборудование освоить), то очень соблазнительно было взять себе инструмент, который бы на два-три года обеспечил меня как функциями Lightroom, так и функциями Photoshop-а.

Вчера скачал триальную версию Capture One Pro 7.1.3, поставил, попробовал обработать одну фотографию. После чего удалил C1Pro нафиг :)

Не потому, что это плохой инструмент. Просто я сразу столкнулся с двумя вещами, который поставили на нем крест. Во-первых, С1 явно рассчитан на очень серьезный подход к делу. В частности на то, что нормальные профессионалы никогда не будут заниматься обработкой фотографий на 14" мониторе с разрешением 1366x768. Для них даже FullHD мало. Поэтому по умолчанию в C1 такое расположение контролов на экране, что для редактируемой фотографии места остается совсем ничего. Я знаю, что в C1 весь интерфейс полностью можно подстроить под себя. Но в том же Lightroom все удобно и все под рукой даже на 14" экране с небольшим разрешением.

Но главным разочарованием был совсем маленький список объективов, для которых C1 может делать коррекцию снимка (виньетирование, дисторсия, абберации). В частности, в разделе Nikon-овских камер не оказалось ни одного цейсовского объектива :( Хотя какие-то варианты Цейса были перечислены в других камерах, но немного. И это при том, что профили Macro-Planar 2/50 и Planar 1.4/85 есть даже в Lightroom 3.6!

В общем, первая попытка использования Capture One Pro оказалась неудачной. Буду пробовать Lightroom 5 :)

Еще есть мысль попробовать продукты от DxO: DxO Optics Pro и DxO ViewPoint. Кто-нибудь их пробовал? Какие ощущения?

И даже более общий вопрос: какие еще инструменты (или связки из таковых) заслуживают внимания? Требуется брать сотни/тысячи сырых снимков в RAW, отфильтровывать брак, проводить корректировку оставшихся снимков (экспозиция, баланс белого, вытягивание деталей из темных/светлых участков, удаление пятен, шумоподавление, управление четкостью, коррекция особенностей объектива, экспорт результатов в JPG/TIFF, иногда коррекция перспективы), но без фанатизма, пририсовывать ноги/руки в фотошопе не нужно :) Очень желательно под Windows, т.к. под Mac совершенно не хочется переползать.

среда, 28 августа 2013 г.

[darts.photo] Фотографии с турнира Belarus Open-2013

С 23-го по 25-е августа, в Минске, в олимпийском спорткомплексе Стайки прошел очередной международный турнир по дартс Belarus Open-2013. На котором я уже в третий раз подряд поучаствовал и как игрок, и как фотограф. Вот фотографии, которые удалось сделать.

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

PS. Буду признателен за распространение ссылки на этот пост на российских и украинских дартс-форумах. Да и вообще за распространение. Фотографирование на таких турнирах и последующая обработка фотографий -- это серьезная и утомительная работа. За которую хотелось бы получить вознаграждение в виде посетителей этой заметки. Уж простите мне это нескромное желание ;)

PPS. Авторство нескольких снимков принадлежит Эльдару Абдуллаеву и Андрею Бузуверову.

понедельник, 26 августа 2013 г.

[life.photo] Вчера вечером, в Минске, на ул.Карла Маркса

Удалось чуть-чуть пофотографировать отдыхающих. Вот что получилось:

PS. Снималось все на Nikon D700 + Zeiss 1.4/85mm. Съемка велась сначала в сумерках, затем в очень плотных сумерках.

PPS. Сразу захотелось камеру, у которой ISO 6400 работает еще лучше, чем в D700 :)