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

> Фаззер - для end-user-ских приложений все-таки вторичен.
Как end-user скажу - меня он вообще не интересует. Это средство разаботки и тестирования по-моему.

Роман, мы же обсуждаем не лицензию - понятно что любой софт обложен лицензиями с головы до ног и по ним у всех все хорошо.

Сколько вот практику разработки, так уж получилось что на вашем примере (опенсорс, что уж там).

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

А хочу я сказать простые вещи (и раз уж вы подвернулись прочитать это на русском - выскажу уж все, что я думаю про RawSpeed), часть их написана выше, но я повторю уж в одном месте.

1. Ну хардкодить константы - ну вообще плохо. Просто вот плохая практика. M_PI еще можно (да и то), а уж хардкодить то, что прямо вот на днях менять (предельные размеры NEF) - ну вообще ни в какие ворота. Еще как-то можно было бы принять это в виде таблички, общей на библиотеку, но не в виде отдельных правок, по одной на формат, да и то. В виде cameras.xml - ну вообще прекрасно. Это, я впрочем, вам уже писал.
2. Ломать совместимость (с D850) - даже если камера формально не поддерживается - чтобы фаззер был счастлив - ну это вообще какая-то зацикленность на процессе разработки, а не на пользователе. А приоритетом должен быть все-таки пользователь.
   Почему поддержка "несуществующей" камеры может быть полезна - написано в первом комментарии под моим текстом. Это не говоря о том, что пользователи с удовольствием ковыряют опубликованные тестерами RAW от свежих камер - и если вы (как разрабочик) дали им такое средство - они с бОльшей вероятностью переключатся на ваш продукт.
   Понятно, что опенсорс-разработчики (многие) стараются не для пользователей, но блин....
3. Про хардкодинг других значений - написано выше.
   Если вас интересует результат, а не процесс - разбирать метадату все-таки правильнее, чем хардкодить, тогда с изрядной вероятностью новые камеры будут работать сразу.
4. Вообще же, я с большим огорчением смотрю на эволюцию проекта, потому что многие вещи делаются - как мне кажется со стороны - ради процесса разработки, а не ради результата (а результат - удовлетворение пользователей, а не разработчиков). То есть понятна радость C++-программиста, что он может взять и написать все на C++14, но это ограничивает круг допустимых компиляторов - и, следовательно, круг пользователей.

А смотрю в ваш код (и огорчаюсь) я по той простой причине, что проект мне не безразличен, он и исходно очень хороший и много всего туда привнесено нового-хорошего, в период "после Клауса". То есть вся вот эта критика, начиная с сегодняшнего крика души в комментариях на github/в моем блоге - это от огорчения, что вот хорошую вещь - для совершенно вторичной цели тестирования фаззером - прямо на глазах портят.

Цель же - не пройти все круги испытаний фаззером, а дать пользователям инструмент (darktable) с которым они могут работать. Фаззер - для end-user-ских приложений все-таки вторичен.

Это понятно. Но вот Вы если библиотеку делаете то надеетесь что ее использовать другие будут иначе смысл всего этого? Если делаете так делайте полноценно а не спустя рукава.

Ну я (кстати) согласен.

Если код виден людям, то многие вещи просто стыдно делать, это как в лифте пукать.

Хехе... судя по моему куцему опыту, проприетарщики от опенсорсников в этом не отличаются.
Более того, у них еще больше развиты скиллы заметания какашек под ковёр, а так же "хуяк-хуяк, и в продакшен".

Я, пожалуй, не готов такое видеть в коде даже в виде таблицы.

Я готов видеть такое в данных (cameras.xml) в виде камера=>список допустимых размеров (хотя и там бывают приколы, вероятно, после апдейта фирмвары), но с отдельным ключиком "что делать, если таки не" (а не просто исключение бросать).

А в таком виде - это просто ужас на крыльях.

И что удивительнее всего - этот ужас привнесен человеком, который *вроде бы* привносит в проект хорошие практики. CI, фаззер, C++14, всякие там правильные проверки. И вообще видно, что улучшает код.
Только вот иногда такое улучшение противоречит практике.

C точки зрения софтверного разработчика - это идиотизм...

Вы не поверите, но да:
https://github.com/darktable-org/rawspeed/commits/develop?after=6c2f70d1...

(не на все, конечно. DNG нет)

Кроме "купил новую камеру" есть важный (для некоторых из нас, по крайней мере) граничный случай: получил от компании мула на тестирование. Мул - это камера, которая выглядит достаточно похоже на серийную модель, но с отдельными элементами, которые тестируются для будущей модели. Такими элементом часто бывает сенсор :) Мулы и pre-production camera samples обычно пишут raw, но софта для его процессинга часто нет (случай c тем же D850). Куды крестьянину податься? Кто-то пошлет образцы в Adobe, но если поймают - накажут. А вот поддержка в third-party software - позволяет как избежать риска быть пойманным, так и вообще оставаться порядочным исполнителем соглашения о неразглашении.

Будет ли WB с таким ключиком?

> Возможно (краем уха что-то слышал), RPP использует на показе быструю демозаику half, а полноценную - только на выводе

Именно так. Для превью используется Half - полноразмерная демозаика только при генерировании результата.

Первый и третий варианты - "есть в наличии"

А "по второму вопросу" (имеет ли смысл использовать для исследования): вот в реальной жизни интереснее же объекты невысокого контраста и передача деталей в них (понятно, есть исключения). Поэтому вот мне кажется, что реальная "интересная фотографу" мишень должна иметь контраст ну скажем стоп. Может быть полтора (или наоборот 0.5). Но никак не черное на белом.

Открыл в rawdigger (1.2.21540 x64 mac PE) неразмытую мишень из статьи Ильи Борга - на масштабе более 100% получил "хроматические аберрации " даже на тексте названия мишени, не говоря уже о линиях самой мишени - там целый калейдоскоп. А rpp 4.8.0 (1823) категорически эту мишень масштабировать отказывается. Это специфика библиотеки libraw? Или это такой сложный для демозаика файл?(просмотр на матрице macbook air 11" - ear.2015 видеокарта intel HD 6000) Имеет ли смысл его напечатать и использовать в качестве мишени для исследования ДД?