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

По-этому и нужен второй проход со сдвигом и последующая попеременная склейка. Она повышает яростное разрешение в 2 раза. Но итоговый рав 64мп все равно мыльный. По-этому jpeg даунсэмплят, применяя кривые и поднимая резкость.

Если у них центры пикселов совпадают (т.е. двигали на целый пиксел), то получится ерунда.
Яркостное разрешение у такой конструкции будет 16Mp, делать байер на 64 нет смысла. Так то понятно, что можно и один пиксел попилить сколь угодно мелко.

Скорее всего это флешреклама без flashblock грузит процессор.

Здравствуйте! Есть предположение, что алгоритм сборки 64мп файла из 8x16мп довольно прост. На это указывает диагональная штриховка в существующих примерах с движением. Камера получает две группы из по четыре 16мп файла до и после сдвига или как бы два полноцветных 4х16мп файла. Дальше происходит их виртуальная баеризация в два RGGB файла по 64мп. Потом из получившихся файлов склеивается один 64мп, в котором пиксели (или группы RGGB) поочередно берутся то из первого, то из второго виртуального файла. Виртуального в том смысле, что промежуточные файлы не создаются, я их привел для пояснения мысли, нужные значения, соответсвующие пикселям виртуального файла, сразу выбираются из имеющихся 8 исходных файлов. При переходе на новую строчку происходит смена первого исходного файла (до сдвига-после сдвига), отсюда диагональные штрихи).

Спасибо!
Всё страньше и страньше (ц)

Ну да, ORI - 16, ORF - 64
Максимумы, кстати, в разных местах. Т.е. можно наверное в ORF все резать, а потом по ORI (меньшего разрешения) восстанавливать света.

Ну вот хвастаюсь: на полуторагодовалом десктопе (с памятью и SSD, конечно), FRV показывает олимпусовский 64-Mpix файл за 0.12-0.15сек если я дал этому файлу в фоне прочитаться (т.е. на предыдущий файл лупился больше ~0.2сек).

Это по встроенному таймеру, который считает время процессинга, но не считает (ибо не может) время асинхронной (потому и не может) заливки данных в видеокарту. Реально, конечно, в районе 0.2-0.25сек на все. 4-5fps. Жить можно.

Померять нормально не могу, для этого нужно файлов двадцать.

Уточнение: мой девелоперский FRV, публичная версия пока эти файлы от этого олика не поддерживает. В релиз пойдем на следующей неделе, скорее всего.

А одиночный рав при этом - пожатый?

Да, большой Raw - нежатый. Даже более чем нежатый, 128 бит на 10 (12-битных) пикселов, т.е. 1/16-я просто мусора

И еще одно соображение. Насколько я понял, камера пишет 2 RAW-a, первый - отдельно (ORI?), затем большой ORF коротый в 7 раз толще одиночного рава. 1+7=8. Совпадение? Правильно ли рассматривать только большой ORF без первого ORI?

Консервативный потребитель: черная накидка, лупа....

Редактирование съемки == все действия до начала обработки выбранных кадров

Ну вот зеленый максимум на месте. Остальные - нет.

Подтверждаю Лешино сообщение про 36Мп - обрабатывать съемку с D800 можно на ноутбуке 2010года, он гудит и греется, но выдает где-то 4 кадра в минуту. ;)

А вот редактировать эту же съемку, если там больше 20 кадров, уже невозможно (в лайтруме). Так что я очень рад появлению FRV :)