RawDigger 1.2.12: поддержка инженерных камер

UPD: пост обновлен 23-07-2016 20:30 Msk

По (достаточно) многочисленным просьбам, мы добавили в RawDigger (и скоро добавим в FRV) поддержку задаваемых пользователем форматов данных. Не любых, конечно, а достаточно ограниченных:

  • 8, 10, 12 и 16 бит на пиксель
  • Нежатые
  • для 10 и 12 бит - поддерживаются не все потенциально возможные способы упаковки (а только те, которые умеет LibRaw для этих форматов).

Вот экспериментальная релизная версия с которой можно поиграться, если интересно:

Краткое описание "как этого сделать" (глава из будущей документации, войдет туда, когда будем не-бетой) в документации: http://www.rawdigger.ru/usermanual/preferences#customcameras

Версия "официально выпущена на Россию". В том смысле, что мы пару дней на RawDigger.com обновлять не будем (мы так всегда делаем), вдруг кто на что пожалуется.

Comments

Выражаю особую благодорность за создание данной возможности.

не понимаю, зачем нужна такая экзотическая хрень. хотите быстро просматривать рав? поставьте ssd

Такая экзотическая хрень нужна разработчикам камер и прошивок для них (включая всякие хаки, вроде DiagRAW)

Ну и пользователям подобных хак-прошивок.

Праздное любопытство -- а посему нет 14 бит? Вроде такие сенсоры бывают.

А не бывает 14-bit uncompressed.
То есть оно "бывает" (та же Sony), но пишут в 16-битном формате тогда, верхние два бита - нули.

Потому что экономия от упаковки копеечная, а геморой на распаковке - просто ой.

А, не знал. Хотя какой там гемморой -- ну битстрим вместо байтстрима, делов-то, всё семейство стандартов MPEG на самом низком уровне -- битовые поля, а не байтовые, и ничего, живут.

Не-не, MPEG и прочие подобные - они аппаратно поддержаны. И там API: туда нежатые байты, обратно - жатые. Программно на камерах, понятно, ничего не жмут, процессор слаб.

А когда что-то там конструируют (нашли на свалке сенсор и давай...) или хакают фирмварь готовой камеры, чтобы использовать сенсор неподобающим путем (CHDK, DiagRAW, всякие записи DNG из айфонов), то
- особого места чтобы разгуляться - нету.
- эффективность "на маленьких кусочках" - важна (откуда и появилась, похоже, запись "6 10-битных пикселов в 8 байтах" - эффективно ложится на 64-битную архитектуру, а 1/16 оверхеда - ну насрать)

И "14 бит плотных" (это сколько ж, 4 пиксела в 7 байт, верно?) - ну херовый очень кодек для современных 64-(и тем более 128-256-битных SIMD).
Какой нужно взять блок, чтобы оно эффективно на AVX2 ложилось (256 бит)? Я меньшего куска, чем 224 байта (это 128 пикселов зараз) не придумал, а столько регистров нету.

Add new comment