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

lexa - 22/Июл/2016 17:00

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

Andreichk - 22/Июл/2016 20:33

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

netopyrr - 23/Июл/2016 00:21

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

lexa - 23/Июл/2016 00:30

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

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

blacklion - 23/Июл/2016 13:50

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

lexa - 23/Июл/2016 13:57

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

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

blacklion - 23/Июл/2016 14:13

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

lexa - 23/Июл/2016 15:11

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

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

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