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

• Этот кусок зовется на каждый пиксел и рассчитывает, куда именно поместить распакованный из CR2 пиксель (там не так просто все).
• jidx - номер пикселя в потоке, плавно возрастает.
• Изображение поделено на cr2_slice[0] полос шириной cr2_slice[1] и одну полосу шириной cr2_slice[2].
• cr2_slice[0] - небольшое число, 1-3-5
• j - соответственно - 0 или 1.

На 15 мегапикселях - 330 миллисекунд. Разворот if правильный (чтобы было не 1+j, а честно 1 или 2) - минус 70 миллисекунд. Замена на таблицу с заранее насчитанными оффсетами - минус 200 миллисекунд. Но все равно много, перемудрили в кэноне. Главное, их "слайсы" вполне можно было бы распаковывать впараллель (как они жмутся параллельными Digic-ами), если бы в RAW были бы смещения начал. Ан нет.

Тем временем, вышла LibRaw 0.12 (beta).

Усилиями контрибьюторов (как их писать на нашем, "вкладчики"?) была добавлена большая пачка разнообразных методов демозаики.

К несчастью, лицензионные ограничения не позволяют распространять все это богатство на тех же условиях, что и LibRaw (LGPL/CDDL), поэтому часть этих методов раздается отдельно, под соответствующими лицензиями:

• Демозаика DCB и шумопонижение FBDD (автор: Jacek Gozdz) добавлена в основную LibRaw, ибо лицензия позволяет.
• LibRaw-demosaic-pack-GPL2 включает в себя:
  • Алгоритмы, реализованные в Modified DCRAW by Paul Lee: VCD, modified AHD, AHD+VCD и модифицированные медианные фильтры.
  • Алгоритмы из Perfect Raw by Manuel Llorens (удивительно, но не нашел куда нормально дать ссылку): AFD и LMMSE
• LibRaw-demosaic-pack-GPL3: AMaZE из RawTherapee 3 и подавление хроматических аберраций оттуда же.

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

Граждане программисты,

Я - человек темный, граблями причесываюсь на фортране-77 все еще программирую. Но мне пишут, что дескать в современных C++-стримах все сделано по уму в смысле буферизации и работают они временами сильно быстрее, чем любимый мой FILE*

Собственно, сомневаться причин нет, в тестах так оно и получилось (и разница заметная), но мучает меня вопрос с совместимостью.

Мою LibRaw на чем только не собирают, вот даже на Maemo, а давеча я проблемы с Visual Studio 2003 правил.

Отсюда вопросы (сам я за всем этим не слежу, проще спросить):

• Интерфейс то стримовый за последние лет 7-10 - он вообще как, стабилизировался?
• Следует ли ожидать всяких открытий чудных, вроде того что метод есть, но не работает?
• С Linux/Mac проблем нет, я вижу что в gcc 4.x все (на первый взгляд) нормально. А что с виндами, причем как в ипостаси Visual Studio, так и cygwin/MinGW? Может есть какая-то табличка по совместимости хотя бы по Visual C++

Некоторые пользователи LibRaw тусуются здесь, поэтому я тут и поспамлю немножко.

LibRaw 0.10 Release

Это формальный выпуск, признание того факта, что версия 0.10 - стабильна, каких-то значимых нареканий на нее за лето не было. Значимых отличий от 0.10-Beta3 нет.

LibRaw 0.11 Beta1

А это, наоборот, дивный новый мир с дополнениями и изменениями:

• Выходное изображение (результат) можно кропать. Кроппинг делается до постпроцессинга, поэтому для маленького выходного размера постпроцессинг будет очень быстрым^*.
• Сильно изменена обработка вычитания уровня черного: теперь для всех камер (за единственным, но никому не интересным исключением, которое я просто протестировать не могу^**) на этапе распаковки RAW-данных вычитание черного не производится. Дальше можно вычитать одним из трех способов: постпроцессинг (dcraw_process()) сделает все сам, если вы делаете демозаику и т.п. сами - вам подойдет новый вызов LibRaw::subtract_black(), ну и полностью самостоятельно все можно делать, данные черной рамки доступны и все такое.
• Ну и всякие изменения по мелочи, скажем аллоцированное dcraw_make_mem_image()(_mem_thumb()) теперь надо освобождать через dcraw_clear_mem(), обсуждению этого парадокса посвящен предыдущий пост.

Вот, казалось бы, хорошая идея - давить пиковые выбросы прямо в RAW-данных. Hot pixels так можно задавить. Вот мне для LibRaw такой патч и прислали, причем, как я понимаю, он уже вовсю работает в одном опенсорсном RAW-процессоре.

На картике слева (кликабельна, по клику увидите как оно на экране при 150%) показан результат применения этого веселого подхода к снимку resolution target. Сверху - результат фильтрации, снизу - без фильтрации. Холст, масло, Canon 500D, снимок взят с imaging-resource.

И результат совпадает с ожиданиями, если на исходно ч-б картинке обработать каналы независимо, до интерполяции, а потом интерполировать, то появления цветных каемок сложно будет избежать.

И ведь не индус какой прислал этот патч, а вполне уважаемый человек, помянутый RAW-процессор пишет, который даже многим нравится.

Такое впечатление, что тестировать результаты собственного программирования - просто не принято в последние годы. Я эту красивую картинку получил в первом же (!) тесте (то, что туда попалась resolution target - случайность, но артефакты полезут на любых контрастных границах).

Похоже, что я излишне суров к Adobe, дивный новый мир опенсорца - гораздо хуже.

P.S. Второй содержательный патч из того же источника - не тестировал пока, хотя он мне идеологически тоже не нравится. Он давит maze artefacts, но должен и малоконтрастные детали тоже сгрызать.

Я как-то не уследил, потому что AMD/ATI-шными видеокартами начал интересоваться с выходом HD5xxx, а оказывается все очень весело. На gpgpu.ru это уже пообсуждали, ну я сюда наброшу, в более концентрированном виде.

Раньше высокоуровневым средством для разработки считалок на видеокартах у ATI был Brook+. Однако начиная с какой-то беты ATI Stream SDK 2.0 Brook из SDK исчез.

Читаем в ATI-шном форуме (это август-2009):

Yes, this SDK 2.0 beta is for CPU only. It focuses on OpenCL 1.0 for CPU. Brook+ is now available on SourceForge: http://sourceforge.net/projects/brookplus

Ну ладно, Stream SDK Beta-1 вообще не поддерживает никаких видеокарт, смешно.

Синхронизация Drupal с ЖЖ оказалась гораздо более простым делом, чем в случае Movable Type:

• Ставим LiveJournal CrossPost
• Ставим LiveJournal Sync (плюс нужные модули для работы jbackup.pl)
• И все работает (PROFIT!)

Ну, если быть точным, то для LJ Sync нужно поставить еще патч из его pending patches, а то синхронизированное туда приезжает тут же обратно, второй копией.

А если быть совсем точным, то LJ Sync не работает с PostgreSQL. REPLACE INTO {table}, убил бы нафиг....

Но. LJSync делает куда больше чем не нужно:

• Вытаскивает из ЖЖ записи, которые там появились независимо. Это хорошо, если есть адын standalone-блог и адын ЖЖ, но у меня два стандалона гадят в один ЖЖ.
• Темизирует look-and-feel Друпала "под ЖЖ". С синенькими заголовками комментариев и заголовками записей в ЖЖ-шном духе.
• Для всех ЖЖ-шных комментаторов заводится аккаунт на Друпале. Оно так и на MT у меня было, но на MT эти аккаунты были бесправные, а тут в них можно авторизоваться (если OpenID включить) ну и типа писать.

В качестве короткой заметки на тему вчерашнего и ряда следующих текстов.

Для Drupal есть модуль Pathauto, который делает человеко понятные урлы: заменяет пробелы на минусы (или подчеркивания), меняет ужасные /taxonomy/term/NNN на /tags/имя-тега и так далее.

Все из себя настраиваемое и вообще хорошее, если бы не одно но:

• Оно умеет транслитерацию (в частности, URL данного текста странслировался бы в ...i_transliteratsiya.....
• Оно умеет формировать URL-ы из кучи макросов (дата, рубрика и все такое), этого богатства более чем хватает для жизни.
• Но! Включение транслитерации - глобальное. Или мы транслитерируем все (URL заметок, теги и т.п.) или не транслитерируем ничего.

Короче, патч: pathauto-transliterate.diff.gz

Если в паттерн для формирования URL включить текст 'no-transliterate-me', то данный текст будет удален, а то что осталось - не будет транслитерировано.

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

К сожалению, модуль написан достаточно плотно, транслитерация делается на очень ранней стадии, поэтому сделать более удобные макросы по месту [notr-macro] и [macro] - сходу не получилось.

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

При случае, подумаю про эту тему еще.

Второй день собираю Qt 4.6-RC при помощи VS2008, с каким-то очень переменным успехом:

Если собирать Qt SDK, то ломается при сборке вебкита, moc генерирует файл нулевого размера. Ошибка висит в Qt-шном багтрекере со статусом "не удалось воспроизвести", гугление показало что она бывала и на Qt 4.5.2, хотя у меня 4.5.2 собирался без проблем.

Кроме того, не срабатывали такие вот строчки:

#if QT_VERSION >= 0x040400
    void unsupportedContent(QNetworkReply *reply);
    void downloadRequested(const QNetworkRequest &request);
#endif

При сборке варианта без Qtcreator наблюдался целый ворох странных проблем, тот же moc.exe создавался без прав на исполнение. По десятому разу вроде полегчало и конкретный WebKit вроде собрался без ручных пинков (с пинками, т.е. подменяя файл длины на нормальный - получалось и в первом случае, но неаккуратненько).

Одновременно узнал про jom, на 4-ядерном процессоре ошибки компиляции возникают вчетверо быстрее, ура!

Я вот как подумаю, сколько сил стоит поддержка Qt на всем чудовищном мировом зоопарке, так мне сразу хочется год эдак в 85-й.