Про Geforce Titan GTX

Интересная история происходит с Geforce Titan GTX. Все ожидали вчера анонса и 3dnews его даже выпустил в 21:00 т.е. все было готово. А потом - спрятал (ссылка - из гуглокэша, скоро протухнет). ixbt опубликовал тот же текст но как последние слухи. Аналогичная история приключилась c expertreviews.co.uk - они дернулись аж в 14:00 (по своему UK-ному времени, насколько я могу судить, по времени появления ссылок на них в твиттере).

Короче, что-то с анонсом пошло не так, на прошлой неделе было точно всем известно, что анонс будет 18-го, но его не случилось, на сайте NVidia - тишина.

Маловероятно, что продукт уберут в последнюю секунду и не будут аносировать, хочется его обсудить в предположении что он (уже почти) есть:

Про статический анализ С++

Тут меня навели на 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 велел, чтобы предупреждений не было, вот мы и дуем на воду)?
  • А в компактных проектах, которые ведутся очень небольшим количеством опытных девелоперов? (я опять же понимаю, что в большом проекте статический анализатор наводит орднунг, от которого польза..)
  • И если на оба вопроса ответ "да" - то есть ли польза от потраченного времени? Ну вот если потрачу я сейчас час-другой на расстановку галок "это - не ошибка, а специально так сделано" - стоит ли ожидать пользу в дальнейшем?

LibRaw 0.15.0-Beta4

Тем временем вышла LibRaw 0.15 Beta4.

Изменения:

  • Исправлено возможнле переполнение буфера, возникавший при использовании библиотеки RawSpeed для распаковки некоторых форматов файлов (проявилось на Samsung NX-100, но вообще подвержены очень многие некомпрессированные форматы)
  • Добавлены новые методы
    C++ API: LibRaw::recycle_datastream(),
    C API: libraw_recycle_datastream()
    и новый код ошибки LIBRAW_INPUT_CLOSED для вызовов unpack/unpack_thumb()

    Эти методы/вызовы позволяют освободить file handle (и ассоциированные буферы), если ваше приложение больше не собирается вызывать unpack() или unpack_thumb() и, сдедовательно, может разблокировать файл и освободить память, которая использовалась для чтения RAW-файла.

  • Поддержаны Multishot-файлы Imacon Ixpress 39Mpix
Первое изменение - это замазывание ошибки в RawSpeed, за буфер вылазит именно она (а значит надо дать буфер побольше). Это - цена оптимизации, выбирать по k бит и каждый раз проверять не вылезли ли - очень дорого.

О поддержке малого бизнеса

Зашел тут случайно на форумы "Клерка" и выяснил такое:
ИНФОРМАЦИОННОЕ СООБЩЕНИЕ
о приказе Минфина России от 22 октября 2012 г. 135н

....

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

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

Про отладку в Win32/Visual Studio 2010

Вот есть программа, один и тот же бинарник, релизная сборка. У пользователя - падает при некоторых входных данных. Проверяю у себя:

  • Запускаю просто бинарь, подаю проблемные данные - падает.
  • Запускаю тот же самый бинарь (релизный, без пересборки) из Visual Studio (2010) - работает.

Падает оно в buffer overrun, в одном и том же месте (внутри ntdll, а туда попадает из malloc, которому дали неверные данные в результате более раннего overrun).

Вопрос: как такое может быть? Visual Studio при отладке релизных бинарников подпихивает другие DLL? Или вообще что?

Update подниму из комментов эту вот ссылку: http://blogs.msdn.com/b/oldnewthing/archive/2013/01/03/10381959.aspx

В моем случае это оказалось ОНО. Т.е. _NO_DEBUG_HEAP - и сразу счастье. В том смысле, что ошибка появилась и под отладчиком.

Вдогонку про Nikon D5200

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

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

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

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

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

Про Nikon D5200

Update: мои рассуждения об отсутствии тоновой кривой были вызваны моей торопливостью. Тоновая кривая есть и приводится тут. Текст данного поста править не стал, пусть останется для истории (на него уже сослались много где).

Попались тут в руки тестовые кадры с D5200. Ну я их сразу в RawDigger и давай мучать:

Кадр, как мы видим, немножко недодержан, максимум на уровне 5900 (из чего мы делаем очевидный вывод о "14-битности"), тоновая кривая отличается от обычной никоновской.

Возьмем кусочек серого поля (прямогольник на нем) построим гистограмму:

Dual Boot: Hackintosh+Windows8

Переносил на чудесно обретенный SSD-диск тестовую машину, содержащую два хакинтоша и 10.8.

Методом проб и ошибок выяснил, как заставить этот бутерброд грузиться с одного диска (было: хакинтоши на одном диске, винды - на втором). Пусть побудет тут, в режиме записок.

  1. Грузимся с дистрибутива Win8, Shift-F10, открывается command prompt, в нем делаем:
    select disk 0 // или какой у вас
    clean
    convert gpt
    create partition EFI size=200 // EFI boot partition
    create partition primary size=NNNN // Hackintosh
    create partition primary size=NNNN2 // второй хакинтош
    create partition primary // Винды
    format fs=ntfs quick
    Выходим из diskpart, закрываем окно, поставиться на этот 4-й раздел нам пока не дают, инсталлятор винды ругается.

    Чтобы он не ругался - на диске должен быть GPT bootloader, к примеру Chimera (бывший Chameleon). Я это делал так:

  2. Загрузился с дистрибутива МакОСа, запустил Disk Utility, отформатировал второй раздел как 'Mac Extended Journaled' и восстановил 10.7 с тайм-машины (можно было просто поставить, но с бэкапа в моем случае быстрее).
  3. Загрузил восстановленный МакОс (инсталляционная флэшка с Химерой - выбираем что грузиться будем с диска) и накатил оную Химеру на макинтошевский раздел 2.

    В результате хакинтош стал грузиться.

  4. Грузимся опять с дистрибутива Win8 - и оно дает поставиться на 4-й раздел. Ура. При этом активным разделом становится виндовый.
  5. При помощи diskpart - делаем активным хакинтошевский раздел с Химерой.
  6. Восстанавливаем второй хакинтош (10.8) на 3-й раздел.
  7. ???
  8. PROFIT!!!
P.S. На SSD Win8 грузится действительно нереально быстро. На HDD - макос был явно быстрее, а винда долго диском грохотала, а вот на SSD - наоборот, Win8 заметно быстрее.

О цифровом среднем формате и экранных превьюшках

Разбирался вчера с вопросом "а поддерживает ли RawDigger файлы с новых Leaf/PhaseOne" (это которые IQ180, Leaf Credo 80 и т.п.).

В процессе - набрел на совершенно феноменальный эффект, который мое отношение к цифровому MF заметно изменил.

А именно (манипуляции - долгие т.к. автор тестовых снимков запретил их републикацию):

  • Берем Вот этот вот обзор Leaf Credo 80
  • Скачиваем файлики из из любезно предоставленной автором ссылки на Dropbox.
  • Нам нужен вот этот вот файл Mamiya Leaf Credo and Cambo Wide AE.iiq, на нем эффект проявляется лучше всего.
  • Напрямую - он ничем (кроме Capture One) не открывается, но на самом деле это ZIP-файл (сделанный этой самой Capture One), содержащий 0.IIQ (собственно RAW-файл) и несколько файликов с настройками Capture One.

    Распаковываем его: unzip "Mamiya Leaf Credo and Cambo Wide AE.iiq" или еще как и открываем получившийся 0.IIQ RawDigger-ом

  • Выбираем RGB Render и автоматический WB (с другим ББ лично мне эффект виден хуже).

    Внимание: если у вас 32-битная версия RawDigger, то RGB-render будет недоступен при настройках по-умолчанию. Preferences-Display Options-Disable RGB Rendering for files larger... и поставьте туда эдак 90. Но с большой вероятностью - поможет не сильно, а просто начнет падать. 80-Mpix файлы требуют реально много памяти: 160M на байер, 640M на рендер, 320M на экранную копию, а их нужно две т.к. double buffering - и с учетом фрагментации не влезть в 2Gb даваемые 32-битным программам очень даже легко. А при показе второго кадра - он сначала рендерится, а потом из памяти выносится старый, т.е. расход памяти почти удваивается (лечение: Misc Options - Unload opened file before loading new one).

  • Смотрим. Видим эффект (кадр резко отличается от всего с "узкой цифры"). Или не видим.
Кадр является некоторым аналогом "кирпичной стенки" в том смысле, что мелкие детали там именно каменной кладкой и образуются.

Так как перепубликация картинок - запрещена их автором, попробую объяснить словами что именно я там вижу:

А вижу я там - очень резкий микроконтраст. Снимок производит даже впечатление "HDR" с его задранным локальным контрастом, но без недостатков в виде гало и подобного.

При этом, окошко у меня - 1200x800, т.е. каждый пиксель образовался из примерно 8x8 пикселей исходника.

Казалось бы, с многомегапиксельных узких (FF и APS) камер в окошке 1200x800 тоже будет оверсамплинг, ну пусть не в 8x8 раз, а в 4-6x4-6. Но ТАКОГО эффекта локального контраста на необработанных снимках - я, пожалуй, никогда не видел. А всяких чужих необработанных фото я смотрю много.

После того, как эффект вербализован - его стало видно и на других кадрах, где не все поле кадра резкое, а только часть. Вот, скажем, кадр PhaseOne IQ180 Lizard Far.iiq (который не требует упражнений с unzip т.к. это чистый RAW с камеры, а не архив, включающий настройки Capture One) - ящерица на нем выглядит особенно, но я это заметил только после предыдушего кадра, с резкостью на все поле, поняв что именно надо искать.

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

P.S. В окошке ACR и в файлах открытых затем в фотошопе - эффект виден хуже. Судя по всему, по той причине, что RawDigger никогда ничего не сглаживает, ни при увеличении, ни при уменьшении, а у адобовских тулзов имеется сглаживание/подавление артефактов при уменьшении. Но "кирпичная стенка", открытая ACR-ом в фотошоп тоже смотрится необычно, хотя и менее необычно, чем в RD.

RawDigger 0.9.14

Вышел RawDigger 0.9.14. От Release Candidate ничем (кроме номера версии) не отличается. Перепост и распространение - приветствуются.

Немого кино уже нет, звукового кино еще нет....

Вот есть некая программа, которая активно использует OpenGL.

Используется Qt5 и все было бы хорошо, если бы не моментики:

  • QWidget::showFullScreen() не работает на Mac OS X 10.6
  • Курсор в форме руки - остается таковым и при выносе мыши за окно программы (тоже на Mac, на винде все нормально).
По первому случаю - я засабмитил баг, прямо вот 1-го января. Но он все еще в состоянии Not Evaluated (что неудивительно, если посмотреть на график количества багов в Qt за последние 30 дней). По второму - вроде нашел багрепорт, им как-то занимаются.

Ладно, у меня ничего специфического от Qt5 нету, собираем все то же самое на Qt 4.8.4. Работает (ну, пришлось поменять QOpenGLProgram на QGLProgram и так далее в том же духе, но изменений - мало).

Но:

На операционках, запущенных под VMWare (и Windows и Mac) - валится в QGLFunctions::initializeGLFunctions(), судя по отладчику - GL-контекст в этом месте нехорош, дальше не разбирался).

При этом, Qt5 на этих же виртуальных машинах - работает, возможностей тамошнего OpenGL вполне хватает.

На настоящих железных компьютерах с настоящим OpenGL - версия собранная с 4.8 - работает, а неприятные мне баги на маках - отсутствуют. Фулскрин работает, курсор меняет форму как надо.

Ну и как с ними жить? Баги Qt5 явно быстро не починят. Багу Qt 4.8 - скорее всего тоже не починят. Не, ну я могу gl....() сам порезолвить, но обидно же ж.

Про гарантию OCZ

Обновление от 01.11.2014: У OCZ теперь есть пункт приема в Химках

Как нам писали читатели нашего бложека "У OCZ гарантия действует даже при покупке с ебая".

Я решил проверить (у меня был сдохший 3.5" OCZ Vertex2, бумажки от которого были утеряны, но 5-летняя гарантия еще не закончилась) и вот что получилось:

1. Создал Support ticket (по ссылке с этой странице, строчку "Поддержка в России, нажмите здесь" сначала не заметил) в котором написал все как было (OCZ Vertex 2,внезапно сдох, очень страдаю)

2. В течение примерно одного дня мне был создан RMA Case и присланы инструкции: возьмите диск без упаковки и всякой прочей ерунды, упакуйте, вышлите в Голландию по такому-то адресу, на конверте напишите RMA Number

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

4. На следующий день после получения мой диск выслали DHL-ем. Из Роттердама в Амстердам, примерно. И еще через день или два он в этот Амстердам дошел, за этим процессом я с увлечение следил трекингом DHL-я (и присылаемыми на E-mail нотифаями)

5. После чего - все заглохло больше чем на месяц. Я даже написал в поддержку OCZ перед новым годом, мне ответили "доставку мы аутсорсим и ничем конкретным помочь не можем". Но очень участливо, и, по всей видимости, если бы замена не приехала в более-менее разумное время (2-3 месяца) - выслали бы еще раз.

6. А сегодня - оно взяло и приехало. Просто в родное почтовое отделение, обычной почтой.

Короче, замена - работает. Присылают - ровно ту же модель, что и сломалась, сделать таким способом апгрейд со старого вертекса на новый - не выйдет. Понятно, бумажки лучше не терять (так бы я поменял в Москве, быстрее и бесплатно), но если утеряны, то оплачивать придется только пересылку в Европу. Да, таможенную стоимость мне указали реальную (197 евров).

P.S. Самый первый сдохший OCZ Vertex я разобрал, чтобы узнать что у него внутри (никаких бумажек исходно не было, с eBay). Теперь вот знаю что зря.

Pages

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