2015

Вот есть такая компания, Панасоник. Делает цифровые камеры, в числе прочего.

В этих цифровых камерах есть RAW. И есть, конечно же, JPEG.

В этих RAW тоже есть JPEG, внутри.

В этих JPEG, и в отдельных и в тех которые внутри RAW, есть EXIF. А внутри EXIF - MakerNotes, панасонико-специфичные.

Теперь следите за руками:

• Порядок байт в EXIF (Intel/Motorola, II/MM) задан там внутри, стандартным образом.
• В тех файлах, которые я держу вот в руках сейчас, он РАЗНЫЙ для EXIF внутри
...

1. Про разрешение и муар

На dpreview выложили файлик с Oly в компарометр. И сравнивают с D810, разумеется.

Я скачал оба файла, загнал в RawDigger, подогнал увеличение так, чтобы размеры были почти одинаковы и втыкаю вот в самом интересном месте, resolution target "цветное на цветном" (полноразмер по клику)

Нового я естественно не скажу ничего, все уже увидели:

• Olympus "мыльнее"
• "Настоящая" детализация в сложных случаях (magenta на зеленом, смотрим в ПНУ)
...

А точнее, не про саму камеру - в руках не держал, а про ее 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. Что мы приветствуем, если цена будет адекватной.

Есть вот такое мнение, что "компьютеры перестали становиться быстрее". Пару лет назад я его даже развеивал на хайлоаде, но в докладе упирал на SSE/AVX/итп.

Но тут понадобилось попрофайлить кой-чего на Core2 (у котогого aligned/unaligned access резко отличаются). Достал с полки старый свой макбук, 2007-го года, Core2 Duo, ~2.2гигагерца (могу ошибаться, по памяти пишу). Надо теперь собрать Qt. Вот Qt 5.3.2 собиралося у меня почти 7 часов (400 с чем-то минут по time), на двух ядрах.

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

Отобрал у жены ноут. Celeron T3100, то же поколение Сore2, 1.9гигагерца, винды. Вот 2010-я студия собирает, 5 часов уже прошло, до QtDeclarative добрались. Значит еще не меньше часа.

Для сравнения, i7-4770 собирает тот же Qt 5.3, судя по датам создания файлов, 36 минут. В 10 раз быстрее. Да, вдвое больше ядер, ~вдвое больше частота, но еще 2.5 раза просто от большей лучшести.

Это вот я к тому, что те кто гордо не апгрейдит свои Q6600, они на самом деле заметно отстали от.