Q: /3GB switch и карта памяти

Вот есть у меня RawDigger в его 32-битной виндовой ипостаси.

И есть одна и та же виндовая машина, Win7-64 бита.

Линкую с поддержкой/без поддержки /3GB (/LARGEADDRESSAWARE у линкера) и скармливаю один и тот же файл (80-мегапиксельный с задника). На 64-битной винде программе с поддержкой /3GB дадут 4GB, а без такой поддержки - 2Gb.

Дальше начинаю собирать и так и сяк и вижу, что вариант без поддержки 3GB получает от системы по рогам когда потребление памяти у него (Peak Working Set по таск-менеджеру/процесс-эксплореру) вовсе не 2Gb, а ~1.1. А вариант с поддержкой - дорастает до 1.2Gb (многовато, да, но примерно столько и расходуется на всякие глупости, чтобы при смене настроек не перечитывать файл).

Вопрос: а чем-то можно в винде посмотреть "использованное адресное пространство"? Ну то есть я догадываюсь, что ~800M пропали по причине фрагментации, а как-то можно мэпу хипа глянуть?

Может есть какой-то правильный маллок, которому можно пометить аллоцированное (именами, или по номерам строк в файле), а он потом карту нарисует?

Потому что сдается мне, что 80Mpix можно и без /3GB смотреть, надо только аллокации в правильном порядке делать.

Про Nikon D7100

В связи с выходом 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

Про 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 ничем (кроме номера версии) не отличается. Перепост и распространение - приветствуются.

Pages

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