Про Olympus E-M5-2 и ее 63 мегапикселя

А точнее, не про саму камеру - в руках не держал, а про ее Hi-Res файлы (которые в руках держал уже), которые 40Mpix JPEG/63MPix RAW имею сказать (про саму камеру можно почитать/посмотреть кино у Дмитрия Новака).

  1. В качестве результата выдается баеровский файл размером 9280x6938. После обрезки рамки по рекомендациям олимпуса остается 9216x6912.
  2. Файл нежатый, 12 бит на пиксель, байеровская маска - стандартная олимпусовская.
  3. Таким образом, камера сама клеит 128 мегапикселей исходника (16Mpix x 8 кадов, если верить истории про 8 кадров) в 64 мегапикселя результата. По какой формуле, как, что, почему - неизвестно.
  4. У результата склейки есть странности. В частности, каналы R и B - странно порезаны, максимумы в них примерно 2000 +-несколько десятков, зависит от ISO (значения - после вычитания уровня черного), а в зеленом остаются ~3840 (аналогично, после вычитания черного).
  5. Таким образом, стандартный процессинг RAW (считающий камеру 12-битной с максимумом в 3840) даст окрашенные света (вроде розовых облаков, но для нормального освещения получается скорее желтое), процессинг надо менять. Или грубо (просто верхний практически стоп отрезать, что обидно) или помягче (отрезать после ББ, но тоже меньше чем ~полстопа не получится).
    Есть надежда, что firmware поправят в этом месте, если громко жаловаться.

Там еще много вопросов про этот режим и его применимость в реальной жизни, вместе с тем, я очень надеюсь что другие производители камер тоже ломанутся в эту нишу. Ибо одно дело - 64(40)Mpix мультишот, а совсем другое - если исходный сенсор мегапикселей в 40. Надеюсь в этом месте на Sony - они внутрикамерную стабилизацию для FF осилили, переделать ее под мультишот должно быть нетрудно. Могут быть патенты, конечно....

UPD (совсем про другое): судя по этому снимку, олимпус освоил производство L-bracket. Что мы приветствуем, если цена будет адекватной.

Comments

> если исходный сенсор мегапикселей в 40

...с шумами и дифракцией? Ну вон сапог якобы обещает 50 мегапукселей на ФФ.

16Mpix на micro4/3 - это 64Mpix на FF (при той же плотности пикселов), не вижу проблемы с шумами (на низких ISO) при таком размере пикселя. 28MPix APS (Samsung NX1) * 2.5 => 70Mpix FF.

Что касается дифракции/разрешения, то запас даже у совершенно позорной оптики еще огромный: http://vgrin.host56.com/photo/articles/pixels/index_r.html
(да, это центр кадра, на краях гораздо хуже "у позорной оптики", но не из-за дифракции, которая от позиции в поле кадра не зависит, а по причине позорности)

Там идет тестирование на байонете E-mount, а это с точки зрения дифракции сильно отличается чем для традиционных зеркалочных F-mount и EF. Я имею в виду что у этих байонетов сильно разный рабочий отрезок, следовательно, разное влияние дифракции. Поправьте меня если я не прав.

Там только один дальномерный объектив в тестировании, с коротким рабочим отрезком. Остальные - "с зеркальными". E-mount взят в качестве маунта потому что под него все переходники есть.

Ну и формально дифракция "в геометрической оптике" от рабочего отрезка никак не зависит

У меня насчиталось почему-то 61.2 мегапукселя (при том же размере пикселей, как у m43/16Mp) и 54 Мп, если брать размер пикселя, как у моей D7100.
Ну, на низких ISO проблем с шумами может и не будет, а что, высокие никому не нужны? Не везде с фонарем/вспышкой/штативом полезешь (и не везде пустят). У той же 7100 уже ISO3200 можно только от большой нужды использовать, у олимпусов с этим не лучше.
По статье: какие-то эти эксперименты с "440 Мп" неубедительные. Как можно для измерений использовать жыпеги с мыльницы, которая черт знает что с изображением творит? Ну вот на снимке в конце зверский шарпинг виден, например.

Ну да, он оговаривается, что камера делает USM и это видно по форме кривых.
С часами, как мне кажется (финальная картинка) - оно очень убедительно.

Что касается математики с расчетом мегапикселей, я не утруждал себя точным подсчетом, а исходил из отношения площадей сенсоров: 1:4 4/3:FF, 1:2.5 APS:FF, точность не нужна.

Высокие ISO - да, отдельная печаль, надо исходить из идеи, что высокое ISO и высокое разрешение одновременно - невозможны. А дальше - может быть биннинг (даже прямо в камере), может быть иметь две тушки (A7R и A7S если в номенклатуре сони). Не вижу в этом особой проблемы.

Покупать две тушки, носить две тушки, да, совсем никакой проблемы.

Этим для простых людей и хороши компромиссы.

Ну так "простым людям" у которых монитор 4-8 мегапикселей максимум - им и 36Mpix не надо и 50 не надо и 200 не надо. А нужна им, вот честно, "А7S со стабом", которая 12Mpix, но зато про освещение не надо думать от слова совсем.
Ну может быть, в расчете под 5K-мониторы, не 12Mpix, а 16.

Ну и не в вакууме эти мегапиксели - на фоне стоимости и веса оптики, которая эти 50Мпикс ФФ может разрешить - вторая тушка и не видна почти.

Так же цифрозадники делали когда-то, нет?

И продолжают делать.

Ойой, вы чё.

Новак - фрик на окладе у Олимпуса, он на них не первый год работает. Смотреть чего-то там у него - опасно для вашего кошелька.

Да вообще интернет опасен, спасу никакого нет!

Заметил на фото с движущимся фонариком (просто наблюдения, никаких выводов):
1) красный в ореоле от фонаря имеет четвертное разрешение, а на самом пятне света — как бы половинное по горизонтали, но не строго;
2) синий в ореоле от фонаря имеет четвертное разрешение, а на самом пятне света — как бы половинное по вертикали, но очень нечётко;
3) зелёные смешаны друг с другом в определённой пропорции, в зоне ореола создают подобие байера, а на самом пятне — подобие полного разрешения.

Ну вот да, "камера как-то клеит". Как именно - я пока не понимаю.

> считающий камеру 12-битной

сенсор панасоника в режиме с rolling electronic shutter вычитывает полный кадр в 10bit raw (см спецификации сенсора)... может быть склейка кадров заодно и делает там как-то 11/12 bit.

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

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

ну вот зеленого в два раза больше, может 10->12 для зеленого и 10->11 для остального ...

Два зеленых отдельно ж

перекрестное опыление :-)...

Скажите пожалуйста, почему 16МП РАВ весит 15МБ а 64 - 100? Глупый конечно вопрос, но все же. Первый пожатый, второй - нет? или во втором зарыта еще какая-то информация?

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

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

Да, хаффманом.

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

Совпадение - это если размеры.

В ORI я не вижу ничего такого, чего не было бы в ORF

Так один из них 16Мп, другой 64? или я неправильно понимаю обстановку?

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

Вдогонку. ORI - это первый кадр (см. у Новака в комментах архив с файлом с движущейся лампочкой)

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

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

Я не понимаю, как можно байеризовать полноцветный 16Mp файл в байеровский 64Mp.

Я имел ввиду, что есть 4 файла в сумме дающие по 16мп на цвет. Из них делается баеровская сетка на 64мп

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

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

> попеременная склейка.

зачем выкидывать сигнал-то ? если его можно использовать для повышения S/N ?

Его использование простой интерполяцей порубит контраст, которого и так не хватает. А на сложную (например сделать апсемплинг до 256мп, а потом даунсэмплинг в 64мп) не хватит ресурсов проц и памяти.

> Его использование простой интерполяцей порубит контраст, которого и так не хватает.

electronic rolling shutter приводит к дополнительному шуму считывания... так что выкидывание сигнала есть плохо.

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

Если вы у Новака в комментариях найдете кадр с лампочкой и туда посмотрите, то там видно что нет, не впрямую заимствуются пикселы, иначе в лампочке X8 не хватало бы части - а они есть.

RawDigger текущий эти кадры показывает с руганью на data error - не обращайте внимания, там Error в тех байтах, которые пропускаются и не участвуют в построении изображения.

Не совсем понял где искать лампочку, в lj пока не нахожу.

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

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

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

в конечном варианте 64мп - откуда берутся данные для синего сенселя обозначенного белой цифрой 8 например ?

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

Так как у вас в 1-м и 2-м проходе используются одинаковые значения (ну там 17-21), то лично я "за секунду" не понял ничего.
Ну а тратить время и въезжать - может кто и будет, но не я.

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

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

Черные цифры, исходник - первый проход. Белые второй. На самом деле вариантов чередования может быть много, в том числе все зеленый из файлов одного прохода. Это первый, который я набросал.

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

Если я правильно понял таблицу, в таком варианте у нас потеряется контрастная разница между R1,R2,R3,R4. Цвет будет собираться аж со всего квадрата RRRR. Как из такого варианта получить 64мп рава? И этот вариант не объясняет штрихи.

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

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

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

Возьмите снимок с движущейся лампочкой (тут выше по комментариям есть ссылка на ЖЖ Новака, на конкретный коммент). Очевидно, что на каждом из 8 исходных кадров лампочка в одном месте, а не в восьми. Теперь смотрим на байер на лампочке в 64-мпикс варианте: "все пикселы яркие".

То есть вот то, что исходные самплы остаются as is - не подтверждается. Оно там интерполирует все и с окном, которое захватывает больше чем "2x2", как мне кажется

(чтобы сказать точнее - нужны "детали в пиксель")

 

Вот я поподробнее написал что я имею в виду: http://blog.lexa.ru/2015/02/08/eshche_pro_oly_e_m5_mk2.html вторая часть.
Один сампл (из 8) с большими значениями - размазался на всю лампочку.

Убедили. Почему тогда Олимпус не взяли кратное значение для интерполяции 128->32? Так ведь проще считать, даже с учетом охвата большего, чем 2х2. И никакого мыла бы не было в помине...

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

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