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

Ну скорее всего, да. Сначала делали мыльницы, если я правильно помню. Потом стали делать RAW. Код для JPEG-ов взяли от мыльниц, а с RAW не прокатило, пришлось делать еще раз.

Рассылку пользователям RawDigger мы со временем сделаем, все узнают, никто не уйдет!

Мультикадровые, да еще и со строго фиксированным смещением - это очень богатая тема. И шумы и разрешение. И ДД.

То есть вот идеально бы, конечно, получить гибкие настройки в камере: "сдвинь так, сними столько-то кадров с такой-то вилкой".
И результат - необработанный нужен, а не с камерными фантазиями.

Только вот желающих на такую функциональность будет немного, потому что софтом это подперто (пока) плохо, а надеяться на софт от вендора тоже не приходится.

Но тема, повторяю, очень богатая.

Там же нет никаких 128, если верить истории про два квадратных кольца со смещением в полпикселя.
Там 2 раза по 16 полноцветных замеров. Всего - 32, со смещением по диагонали. Еще 32 надо придумать. До этого момента все ОК.

А вот как они придумывают пропущенное и отчего теряют полноцветные пикселы из тех 32, оставляя там по одному цвету - ну вот сложный вопрос.

1. Все-таки посмотрите про лампочку (новый пост)
2. Вот смотрите, расстояние между черными 1-5 - один "исходный" пиксель, т.е. два "мелких". А на результате стало "три мелких".

У вас в 1-м и 2-м проходе используются одинаковые номера. Поэтому вот 17 в результате - это из 1-го прохода или из второго?

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

Сори, перепутал 8-7 в "белых" исходниках. Ночью рисовал

Подсмотрел идею. Итак, после 8 замеров у нас диагонально-ориентированный 32Мп полноцветный массив. Легко и непринужденно превращаем его в горизонтально-вертикальный 64Мп массив вводя пустые ячейки на (0, 1/2) (1/2, 0) (1, 1/2), (1/2, 1) и т.п, где 1 - это шаг пикселя (3.8 микрона?).
Если зеленые 32Мп остаются там, где они замерены, а пустые ячейки заполняются красными и синими, интерполированными из 4х соседей, (первая строка - все пустые заполняем красными, следующая - все пустые синими, следующая - снова красными и т.п.), то как раз и получится 64-Мп байер. Изящно. Странно но довольно изящно.

Вы имеете в виду, что если заимствование шло бы блоками, было бы подобие шахтамки? Но оно может быть и не блоками. Может вы неправильно поняли мои слова про "сборку" итогового файла. Постарался изобразить. В случае построчного сдвига при дебаеризации разрывов быть не должно.

http://postimg.org/image/x4dtkvunx/

не совсем понял про один R и другие триплеты. У вас R1,R2... Это 4 разные экспозиции цвета за проход, у вас пиксель-элемент матрицы, а сенсель - цветовая составляющая RGB? Тогда почему в сенсель входят компоненты сенселей (триплетов RGB)?

там только один R сенсель с R1+R2+R3+R4, во всех остальных R сенселях в сумму входят другие компоненты R из других полноцветных триплетов {RGB}... но вообще не понятно зачем делать полноцветное что-то чтобы потом обратно делать баер ? только если для упрощеннения описания того что может происходить...

спасибо, скачиваю

http://dmitry-novak.livejournal.com/195257.html?thread=4993465#t4993465