Свежие комментарии

а почему рассматривается "виртуальная" чувствительность 25600 а а не "реальная" 6400 или 25600 "более реальна" нежели iso50?

Гугл пишет, что в 2004-м году запустили тестирование.

Чем кончилось - не пишет :)

А, вот еще википедия пишет, что есть.

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

Я не пропагандирую тотальное тестирование.
Я, к счастью, не видел случаев когда прям необходимы юнит-тесты. Подозреваю это свойственно тем фирмам, которые набирают всех подряд, лишь бы подешевше.

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

О. Это тоже клевый. Спасибо!

Посмотрю. По моему его и тогда не было.
А вот интересно посмотреть на мишень фошшистскую (с нетерпением терпеливо подождем). Я немного игрался с амазе. Там он легко на окошке лучше делался но в другом месте артефакты появлялись некоторые. Правда доолгггоо работало это все.
Но я думаю тут не только от демозаика зависит но и от аппарата и от пре демозаика. А это все было на основе dcraw.

В моих экспериментах, идущих прямо в настоящую секунду, DCB дает артефактов цвета сильно больше, чем AHD. Дальше по списку пока не прошел.

Подробности письмом в ближайшие дни, я думаю мне еще доковывать придется.

Но у меня мишень фошшистская, гораздо жестче чем первый пример по ссылке. Кстати, там первый файл, который с текстурой ткани, с мегашары уже удалили, у вас его нету, случайно?

Не-не, такой формализм (как по ссылке) точно не нужен. У двоих не идут тесты, у одного - не собирается, у остальных 13-ти все нормально.

Я соглашусь что для каждого проекта могут быть разные периоды когда можно вообще без тестирования, немного укрупнённых тестов, тотальный контроль. Конечно всё зависит в первую очередь от команды, насколько высока культура разработки, насколько сколько код получается ортогональным, от понимания необходимости SPOT, ну и конечно от самих решаемых задач.

И я считаю если идёт просмотр ста картинок вручную после каждой сборки, то это дело необходимо автоматизировать(это не про libraw, как там я не знаю, это в общем), по крайней мере такая мысль должна периодически возникать.

Кэп-mode: имхо надо всегда знать, принять как факт, что в коде будут ошибки, тогда и культура появляется и глубокое понимание тех преимуществ, которые дают средства автоматического поиска/выявления ошибок, ну хоть та же статическая типизация, и соответственно умение эффективно использовать эти средства.

Вдогонку.

Я не против тестирования, честно!, много раз видел от него пользу. Ну и вред тоже.

Но. По личному (~25-летнему, если fortran на перфокартах в школе считать) опыту вижу, что в относительно небольших проектах (несколько девелоперов x несколько лет или меньше) просто думать передней головой куда полезнее (в смысле расхода ресурсов), чем разводить полноценный тестовый стенд.
В частности по той причине, что тестовый стенд и ложные срабатывания тоже имеет в ненулевом количестве.

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

Но я стараюсь до такого не доводить.

Смысл же тестирования не только в контроле качества конечных изображений, но например также контроль того, чтобы тупо что-то не отвалилось: на каких-то тестах может работать, а на каких-то нет..
Например с помощью cmake/ctest/cdash легко настроить запуск сборки и тестирование одним скриптом разных конфигураций, в разных средах. Например я тестирую сборку и тесты в следующих конфигурациях [VS2005,VS2008,VS2010]x[x32,x64]x[Normal,OpenMP] на win, и [gcc41,gcc34]x[x32,x64]x[Normal,OpenMP] linux. И результаты едут в CDash, и чуть что - build error/warrning, test fail, mem leak (и другие прелести valgrind), сразу всё видно, и всё в одном месте.
Вот например в windows и linux fpu по-умолчанию находится в разных режимах точности, или например в VS C++ x64 нету _asm{} (алтернатива - линковка с masm и т.п. бинарниками), разный синтаксис asm'ских вставок у vs и gcc (intel и at&t), или ещё что-то env-зависимое, и уже другой результат, что-то не работает и т.п...

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

Я пробовал все алгоритмы что есть в darktable 0.7 на одном изображении. Меньше всего артефактов было на PPG и AHD,

Кстате, CMake это не только ценный мех, а ещё и CTest, CDash, CPack.
CTest+CDash позволят легко запускать тесты, делать им mem prof (valgrind/purify), coverage (только gcc), и отсылать результаты на сервер CDash (есть free public: http://my.cdash.org/ ).
А вот пример, к VTK они прикрутили visual diff с gold'ами:
http://www.cdash.org/CDash/testDetails.php?test=67528963&build=736817 . Как именно, наверное можно в VTK посмотреть. Если вам не нужно exact compare, можно и tolerance задать... (естественно такое можно и без CDash сделать..) Это должно немного убрать головной боли типа http://blog.lexa.ru/2010/06/06/beda_kol_sapogi_nachnet_pechi.html .
Кстати, а как как оно сейчас тестится? Или ещё нет гигиены?

Вот презентации
http://www.youtube.com/watch?v=8Ut9o4OdSC0
http://www.kde.org/kdeslides/CampKDE2010/CampKDE2010-MarcusHanwell.pdf

> разница между алгоритмами - минимальна.

Помнится, когда у меня еще был Canon 10D, я видел очень большую разницу между демосаикой RawShooter и всем остальным - у первого никогда не было лестниц на волосах и подобном. Удивил больше всего то, что после покупки адобой и превращения в ACR этот алгоритм, судя по всему, заменили на что-то менее хорошоее.

Вопрос - а нет ли каких-нибудь данных, что за демосаика была в равшутере или вообще хоть чего-то, позволяющее её сейсчас воспроизвести и воткнуть, например, в тот же либрав?

Что-то с ссылками не так.