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

Вспомнил петушиное слово: SOF3

Там ошибочки у меня, похоже, при расчете offset но суть думаю понятна.

А нельзя ли несколько видоизменить задачу? Т.е. вместо вычислений координат назначения по индексу источника вычислять индекс перебирая координаты.
Т.е. нечто вроде (псевдокод):
int col;
int row;
int iLastSliceX0 = width - cr2_slice[2];
for(row=0;row

Нет, считывание идет по столбцам. А кодирование дальше - по строкам.

Т.е. выливают в какой-то буфер(ы) и их кодируют. В промежуточные буфера, которые потом склеивают.
В-принципе, если хранить дальше в нескольких буферах, а не в одном, то тоже удобно. Гы :)

Вообще же jpeg-овское кодирование, которое потоком, хоть и с маркерами рестарта, но все одно - переменной битности, это зло ужасное в век многоядерности.

Ссылка полезная, а сама схема - идиотская. Лучше бы сделали тайлами с известными началами-концами бинарных данных, как в DNG.

Нет, не нацело. Там как устроено в CR2: K слайсов шириной L и один шириной M. Высота у всех H.
Вот картинка: http://lclevy.free.fr/cr2/#lossless

Если мы номер пикселя делим на H*L, то мы получаем номер слайса. Он может быть ошибочным (если M много меньше L) и его надо округлить до K+1.

Уф.

Но все это почти неважно т.к. можно прекалькулировать оффсеты (по числу строк т.е таблица получается размером (K+1)*H (10-20 тыс). А внутри одной строчки слайса - просто декрементировать и все.
Мда. Кодом проще написать. Следите за апдейтами LibRaw.

b8 - 60770

ну и там можно совокупность запросов a5, a7, b5, b8 и так далее.

а если написать пост в блоге с заголовком "a5 b7 b8" с внутренними ссылками ссылающимися сами же на него, и с парой ссылок с вхождением этого анкора из каких-то старых постов... то да, эксперимент будет интересный :-)

Там цифровой CFA, берет один компонент из трех, нет места для ошибки.

это фиолетовый.
И в идеале фильтр вообще не должен бы там пропускать ("лекции от Шадрина" про гамут, базис и прочую почухрень помнишь? - там всё "математикали прувед", между прочим)

А 380-440 - это что?

:-))
чего тебе непонятно ?

давай возьмём первый попавшийся кэнон 40Д:

синий, это 440-485нм; отклик - от 3.5 до 4.9
зелёный, это 500-565нм; отклик - от 3.0 до 3.2
красный, это 625-740нм; отклик - от 2.3 до 2.8

соотв. "в самом синем" у нас ~4.5 попугаев, "в самом зелёном" ~3.2, и "в самом красном" ~2.5 попугая.
для "остальных никонов" та же самая картинка.
чего тут непонятного ? :-))

строго говоря, на ДХО даётся два значения: для экрана и для печати.
Соотв. для экрана они намеряли 13.91 EV (угу, прям с точностью до четвёртого знака :-)), что даёт 12503 DN. Т.е. вполне укладываются в 16316 (хоть и со скрипом).

14.12 EV они намеряли для отпечатка (downsample to 8Mp ==> 8"х12" @300dpi)
если вспомнить "формулу Зейса" (1730px на диагональ), то получается, что визуальный пиксель отпечатка формируется примерно из 6px исходника. Т.е. теоретически мы можем поднять "эффективную разрядность" отпечатка на up to 2 EV

Да я сам себя проверяю. Я не волшебник, я только учусь. Спасибо.

В том смысле, что для данной конкретной мишени это получится идеальное восстановление если тупо скопировать имеющийся байеровский сэмпл в недостающие на этом цвете. А grayscale для визуального контроля.