2013

В связи с выходом Nikon D7100 без противомуарного фильтра имею сказать:

• Сам факт такого выхода - приветствую. Надо, естественно, на картинку посмотреть, но так вот из общих соображений 16Mpix на 4/3, 24Mpix на APS и, соответственно, 40-50Mpix на 24x36 - более-менее адекватны очень хорошей оптике. С учетом понятно а) прикрытия ее на пару стопов б) дифракции.

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

• С очень хорошей оптикой все непросто. Пресловутый Дистагон 1.4/55 (стоимостью в районе 3 килоевро, весом примерно кило и фильтровой резьбой 82мм - и это все полтинник) - не останется одинок. Не так оно и просто - сделать хороший полтинник, а хороший широкоугольник - еще непроще. С телевиками, конечно, немного полегче.

  То есть и цена у оптики будет "как у MF", и размеры/вес - судя по всему, тоже.

• Да, автофокус при таком разрешении - сильно теряет смысл. Равно как и съемка с рук.

Все это вместе выглядит забавно. Хотите влезть в MF-область по качеству (ну хоть краешком, сравнивать можно с MF на пленке, и только "по разрешению") - получите MF и по цене и по особенностям работы.

Update: ссылка в тему: blogs.zeiss.com/photo/en/wp-content/uploads/2011/12/en_CLB41_Nasse_LensNames_Distagon.pdf

Тут меня навели на Coverity SCAN, которую дают помацать опенсорсным проектам на халяву.

Ну я посабмитил туда LibRaw, сегодня пустили, результаты оказались удивительными:

107 предупреждений, из них где-то треть - с High Impact.

Из High Impact:

• Штук 10 в Microsoft STL (я самбитил виндовую сборку)
• Еще какое-то количество такого примерно вида:
   int variable;
   if(layout==Layout1) variable=value1;
   if(layout==Layout2) variable=value2;
  И на это дается предупреждение, дескать неаккуратненько, не инициализированная переменная. Я с ним согласен по общим ощущениям, так не надо делать. Но в реальной жизни бывает два вида layout - и это явно прописано в вызывающем коде. Т.е. у машинки достаточно данных, чтобы сообразить, что это не 'High impact', а просто неаккуратненько.
• Некоторое количество предупреждений, дескать unsigned short при расширении до 32-64 бит может больно укусить. С этим я не хочу спорить - формально машинка права, а по факту в этих unsigned short живут размеры картинки и до 32767 они в ближайшие годы не дорастут.

  Т.е. опять, фиксить не надо - в случае данной предметной области.

• Все остальные найденные 'High Impact' проблемы - это просто ложные срабатывания. Т.е. код, согласен, не идеальный (видели бы вы этот код из dcraw !), но все найденное - не является ошибкой.

  В частности, любимый коффиновский метод проверки диапазона значений 0..N одним действием машинка просто не чует:

  int var=-1;
  if(bla-bla) { var = some_non_negative_value; }
  if( (unsigned)var < 5) // => это проверяет на диапазон 0..4
  Я сам ТАК не пишу, но читаю и считаю что прием, как минимум, надо знать и в чужих исходниках распознавать.

  Но кроме этих ложных срабатываний - еще куча других, тоже ложных.

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

Вопросы у меня такие:

• А кто-нибудь использует статический анализ по смыслу (а не из соображений, что CTO/PM велел, чтобы предупреждений не было, вот мы и дуем на воду)?
• А в компактных проектах, которые ведутся очень небольшим количеством опытных девелоперов? (я опять же понимаю, что в большом проекте статический анализатор наводит орднунг, от которого польза..)
• И если на оба вопроса ответ "да" - то есть ли польза от потраченного времени? Ну вот если потрачу я сейчас час-другой на расстановку галок "это - не ошибка, а специально так сделано" - стоит ли ожидать пользу в дальнейшем?

Зашел тут случайно на форумы "Клерка" и выяснил такое:

ИНФОРМАЦИОННОЕ СООБЩЕНИЕ
о приказе Минфина России от 22 октября 2012 г. 135н

....

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

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

Я был неправ, когда писал что у Nikon D5200 нет тоновой кривой. Это в RawDigger тоновой кривой нет при работе через RawSpeed (а я про это постоянно забываю). А в этих файлах - очень даже есть.

Вот такая вот (синяя линия):

Эта кривая очень сильно отличается от кривой D5000/D5100, она достаточно близка к "идеальной" кривой, показанной красной линией. Идеальная - это зависимость яркости от L (в Lab) т.е. если бы была использована красная, то на каждую единичку L приходилось бы одинаковое количество градаций в камере. Порадуемся же за Nikon.

В остальном - все обычное, примерно как в D5100: 11.6 бита (3072 градации всего), странная загогулина наверху кривой.

Обращаю внимание, что клеточки на графике - "квадратные", 512 единиц по каждой из сторон. Для удобства чтения.