Программирование

Можно попробовать: качаем по ссылкам из этого поста.

В чем фишка:

Большие файлы CR2, NEF, жатые DNG - открываются на 300-500мс быстрее на быстрой машине (i7-2600k@4.5Ghz), на медленных разница должна быть еще заметнее. На других поддерживаемых RawSpeed форматах (Sony, Panasonic, Olympus, Pentax, Samsung) - разница тоже есть, но не такая большая. Все неподдерживаемые форматы открываются, как и ранее, LibRaw.

Больше (кроме файлов Sony о которых ниже) - фишки не должно быть (еще чуть больше памяти используется). Собственно, это и хочется проверить.

Сравнить можно открыв закладку Preferences, менять положение галки и жать Apply. Если при этом не меняются статистики, гистограммы и т.п. - то все отлично.

Что мне интересно:

• Есть ли какие-то форматы кроме Sony, где данные и/или результаты рендеринга заметно отличаются. Тестовые файлы пока не нужны, достаточно марки камеры.
• Может оно вообще глючит и не работает, тоже интересно.

Про Sony:

RawSpeed возвращает значения пикселов для Sony в 4 раза бОльшие, чем LibRaw. Это ни на что не влияет в реальной жизни. При этом, конечно, на такое плавание уровня черного машинка не рассчитана и при нажатии Apply и стоящей галке 'Reset Black Level on file load' - ничего не поресетится в диалоге.

Это нормально и надо забить т.к. в следующих версиях поддержка Sony RawSpeed-ом будет отключена: разница в скорости для этого формата копеечная (не сотни миллисекунд как для CR2, а десятки), изменение значений в 4 раза рвет башню, а всякие полезные вещи вроде 'ARW2 Hack' и отключения тоновой кривой - не работают т.к. RawSpeed ничего такого не умеет.

Update: достоверно известно о глюках со старыми .CR2 (30D, 5D), репортить уже не надо.

RawSpeed - это такая библиотека раскодирования RAW, которая:

1. Очень быстрая (к примеру, 21-мегапиксельный файл от Canon 5D2 распаковывается на моей машине за 230мс, а код на основе dcraw делает это за 750мс. Притом, это сильно улучшенный мной код, до улучшений было больше секунды, насколько я помню).
2. Поддерживает мало форматов, правда все они популярные (свежие камеры Canon, Nikon, Olympus, Panasonic, Pentax, Samsung и DNG-файлы).

Авторы darktable давно просекли эту фишку и используют LibRaw как fallback на неизвестных камерах, а как основную библиотеку для открытия RAW - используют RawSpeed.

В то же время, RawSpeed распаковывает данные в буфер с очень похожим (но немного разным) форматом, поэтому использовать RawSpeed в качестве читалки файлов изнутри LibRaw (но иметь при этом единый API, единый постпроцессинг и т.п.) - было делом техники. И эта техника - применена в LibRaw 0.15-Alpha4.

Что получилось

• LibRaw::open_file()+LibRaw::unpack() /т.е. распаковка/ - в ~3 раза быстрее на CR2, в ~2-2.5 раза быстрее на NEF, в 1.5-2 раза быстрее на прочих поддерживаемых форматах. Реально это заметно на больших NEF и CR2 (выигрыш в 400-500 миллисекунд на моей i7-2600K @4.5Ghz), соньки и раньше распаковывались быстро, а у остальных форматов редко бывают совсем уж большие файлы.
• dcraw_emu -h ..список из 182 файлов.. - без RawSpeed было 150 секунд, стало 100 секунд. Разница "не в 2-3 раза" потому что постпроцессинг не изменился (хотя с -h он и так быстрый)

Отвечаю сам себе, вдруг кому-то еще интересно.

1. Из всех просмотренных книжек больше всего показалась Learning Modern 3D Graphics Programming, потому что она от fixed pipeline полностью отвязана. Только OpenGL 3+, только хардкор (хотя CoreProfile в Qt и не работает нормально, текстуры не аплоадятся).

   PDF-ная версия и примеры берутся отсюда.

   Буду теперь ея читать.

2. Вообще, оно (OpenGL) отвратительное. Вот, например:
   glBindBuffer(GL_ARRAY_BUFFER, positionBufferObject);
   glEnableVertexAttribArray(0);
   glVertexAttribPointer(0, 4, GL_FLOAT, GL_FALSE, 0, 0);
   И теперь надо запомнить, что glVertexAttribPointer() работает с тем буфером, которому сделали Bind() последнему. Как-то это не так, неправильно.

   Отчего в glVertexAttribPointer не передается идентфикатор буфера?

3. Отвратительно оно и в частности. Более всего меня потрясло, когда Qt-шный пример с крутящимися кубиками (и текстурами с цифрами 1-6 на гранях) я запустил на WinXP под VMWare. Кубики крутились, но грань у кубиков была одна, последняя (с шестеркой), предыдущие пять текстур куда-то подевались. Это не OpenGL3 (на VMWare только 2.1). На Win7 в той же VMWare - у кубиков по 6 граней, но отображается на всех - только одна текстура, первая. Смеялсо.

Отсюда вопросы:

• Оно вообще с совместимостью как? Можно ли рассчитывать, что OpenGL-приложение вообще работает (на случайно отобранной системе), или это сильно как повезет?
• Сужая предыдущий вопрос: если требовать OpenGL 3+, то не будет ли с совместимостью лучше (на тех системах, естественно, где этот самый 3+ есть)?
• Ну и чего я лишаюсь, требуя 3+ (т.е. оборудование класса DX10, как я понимаю)? Ну вот я сам накопал: Mac OS 10.6 и старше, интеловская встроенная графика старше SandyBridge, а еще что?

Было (это результат профайлера, разложенный по тредам):

Через два дня работы и ~800 строк кода стало (естественно, на тех же параметрах и входных данных):

Реально постобработка маленьких картинок ускорилась в 6 раз, больших - в 4. Почему маленькие быстрее - Х.З. Может быть кэши рулят. Это без учета распаковки, которая в профиль включена (и, увы, она для LJPEG не параллелится, если оный LJPEG не порезан на кусочки, как в DNG).

Имею сказать:

Пользователи мак-версии RawDigger вероятно заметили уже, что окошко гистограмм очень широкое.

А широкое оно оттого, что контролов много. Окну же сказано уменьшаться только до тех пор, пока все контролы видны.

А вот как это отрисовывает Qt под разными ОС (окно завернуто в минимальную ширину):

По клику откроется полный размер.

Сверху вниз:

• Mac Native (и такой spacing так и задуман) - ширина окна 1088 пикселов и меньше не делается.
• Результат применения setStyle(QStyleFactory::create("windows")); - 908 пикселов, на 20% меньше.
• Win7 Native (без каких-то настроек spacing) - 821 пиксел, еще на 10% меньше.

Эксперимент не полностью чистый: маковский десктоп 1920x1200 и никаких настроек шрифтов не делалось, на винде шрифты увеличены (115%), а разрешение монитора 2560x1600. В полностью одинаковых условиях винды, скорее всего, будут еще компактнее (пробовать страшно, потрогав размер шрифта у винды есть риск обратно не вернуться).

Родной маковский выглядит просторнее, но вот в редких случаях хотелось бы иметь возможность сделать все плотненько. Но разумным способом - никак (можно выписать свой StyleSheet, но хочется то бе этого). Имею сказать, что виндового размера контролов лично мне на маке очень не хватает.

Update: Добрые люди подсказали про Qt::WA_MacMiniSize. Результат - 859 пикселов ширины. Чуть хуже винды, но непринципиально. Хотя, конечно, спинбоксы по мне выглядят чуть мелковато.

Кто не понял про что это - смотрите теги :)

Qt - рулит. Ну то есть я не разобрался (пока?) с динамическими библиотеками, Frameworks и прочими страшными словами, поэтому с LibRaw слинковался статикой.

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

Делаем так:

Дальше напускаем туда (на получившийся pbproj) Xcode 4.2, Xcode с грохотом падает. Ну то есть известная проблема, как выясняется, но ведь ей минимум полгода?

Качаю Xcode 3.2 (4гига однако, еще где-то час).

Чтобы два раза не вставать. Я правильно понимаю, что если я соберу некий варез как 64-битный, то он не будет работать на Intel Macs с Core Solo (т.е. на очень старых Mac Mini) ну и естественно на PPC. А на всех остальных - будет, независимо от битности ОС, верно?

Задал вопрос в Информатик, отчего ваша Орфо не выдает мне Secutity Warning в моем тестовом окружении, а много других программ (включая и наш RawDigger) - выдают.

Получил ответ: ничего такого не делали, никакой уличной магии, просто подписываем, еще вот Win7 Logo получили.

Тогда попроверял всякий пробованный варез (штук 20 разных инсталляторов) на выдачу Security Warning и на нахождение в Windows 7 Compatibility List. Получается вот что:

• Подавляющее количество инсталляторов программ из этого списка запускаются без Security Warning.
• Подавляющее количество того что не в списке - запускается с таким предупреждением.
• Исключения, коих единицы, но есть:
  • Evernote 4.5 - запускается с Warning. В списке есть версия 4 (м.б. 4.5 и 4 - считаются разными).
  • Coretemp - взлетает мухой, без Warning, хотя в списке ее нет. Правда инсталлятор представляется как IntelliQ (это такая платформа монетизации бесплатных приложений), может быть его сертифицировали под каким-то еще соусом.

    Webmoney - нет в списке, но все работает.

Есть еще такие наблюдения:

Хочу сказать, что процедура выдачи Verisign Code Signing сертификатов, если пользоваться вот прямо их средствами, какая-то ужасающая:

• Приватный ключ (сгенерированный Verisign) приезжает в формате .p12
• Сертификат - в формате PEM
• Signtool хочет все вместе в формате .PFX (он же, похоже, .p12)

При этом - никаких инструкций "как с этой фигней взлететь" (для сертификатов сайтов - хоть есть "как это все поставить в Apache"), только строгое предупреждение в E-mail, по смыслу такое:

• Вам обязательно нужны два intermediate-сертификата, возьмите их отсюда.
• А на странице где эти сертификаты - две textarea с сертификатами, дескать Select All и сохраните в текстовый файл.

Кроме того, в E-mail инструкции строго написано, что скачивать сертификат можно строго на том компьютере, который делал запрос. Что делать, если за прошедшее время машинка дала дуба (а нам рисовали сертификат 2 недели, не верьте что в Штатах все быстро) - неизвестно.

На этом фоне рождаются душераздирающие инструкции вроде всосите все в MSIE и им экспортируйте, но они годятся только если private key уже импортирован в систему (например, сделан MS-овской тулзой, которая сразу инсталлирует сделанный ключ в систему), скачаный с Verisign приватный ключ - не импортируется.

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