Вдогонку про Nikon D5200

Я был неправ, когда писал что у Nikon D5200 нет тоновой кривой. Это в RawDigger тоновой кривой нет при работе через RawSpeed (а я про это постоянно забываю). А в этих файлах - очень даже есть.

Вот такая вот (синяя линия):

Эта кривая очень сильно отличается от кривой D5000/D5100, она достаточно близка к "идеальной" кривой, показанной красной линией. Идеальная - это зависимость яркости от L (в Lab) т.е. если бы была использована красная, то на каждую единичку L приходилось бы одинаковое количество градаций в камере. Порадуемся же за Nikon.

В остальном - все обычное, примерно как в D5100: 11.6 бита (3072 градации всего), странная загогулина наверху кривой.

Обращаю внимание, что клеточки на графике - "квадратные", 512 единиц по каждой из сторон. Для удобства чтения.

Comments

Имеет ли это значение, кроме как для компрессии?

Никакого. Просто я там где-то написал, что тоновой кривой нет, а она - есть.

Ну и можно не ступеньки считать по картинке, а просто посмотреть на кривую.

оффтопик: а я правильно понимаю, что на классических интеловых процах одно ядро не может обеспечить трансфер по памяти быстрее примерно 2.5 GB/s?

Неправильно.
Я бы сказал, что 20-25Gb/sec на одном ядре - это нормальная величина для *современных* горшков.

Вот, я мерял: http://blog.lexa.ru/2011/09/08/opyat_pro_movntps.html 22Gb/sec на i7-2600K

боже, по ссылке свершенно не читабельно. скриншот делать?

ну вот я читаю Intel 64 and IA-32 Architectures Optimization Reference Manual старница 61

The LLC consists of multiple cache slices. The number of slices is equal to the number
of IA cores. Each slice has logic portion and data array portion. The logic portion
handles data coherency, memory ordering, access to the data array portion, LLC
misses and writeback to memory, and more. The data array portion stores cache
lines. Each slice contains a full cache port that can supply 32 bytes/cycle.

From the processor cores and the GT view, the LLC act as one shared cache with
multiple ports and bandwidth that scales with the number of cores. The LLC hit
latency, ranging between 26-31 cycles, depends on the core location relative to the
LLC block, and how far the request needs to travel on the ring.

ну и получаю, что ядро из L3 кэша будет получать данные примерно со своей частотой

Табличка (да и код) показываются у меня тремя браузерами нормально (FF, IE, Chrome), скриншот не нужен.

То что ты процитировал - это про кэш. Не хочу разбираться, там все очевидно что сложно и случаи разные бывают.

А я вот тебе говорю, что movntps (т.е. мимо кэша) работает со скоростью 22Gb/sec у меня (на объеме данных на ~2 порядка больших, чем L3 cache).

> Табличка (да и код) показываются у меня тремя браузерами нормально (FF, IE, Chrome), скриншот не нужен.

там весь текст очень мелкий. очень. в 18 FF.

> А я вот тебе говорю, что movntps (т.е. мимо кэша)

а оно мимо кэша? а то по картинкам мимо кэша не бывает

>а оно мимо кэша? а то по картинкам мимо кэша не бывает

В мане на команду пишут:

The non-temporal hint is implemented by using a write combining (WC) memory type protocol when writing the data to memory. Using this protocol, the processor does not write the data into the cache hierarchy, nor does it fetch the corresponding cache line from memory into the cache hierarchy.

а, еще -- ты говоришь про запись.
а с чтением что?

насчет мелкости -- откуда-то zoom взялся.

Ну вот в той же табличке есть copy: 11Gb/sec. Так как пишем со скоростью 22, значит, получается, читаем тоже 22Gb/sec, тогда вместе будет 11.

Подскажите, какими средствами можно из 3 разных RAW файлов достать 3 разных канала, собрать их в однин файл и интерполировать.

Вынуть - с помощью программы 4channels из LibRaw.

Дальше - не знаю.

Ну это да. Тут недавно кто-то предлагал отдельные каналы уншарпить до интерполяции, интересно как. Просто мне пришла идея, экспонировать каналы по отдельности, своего рода альтернатива магента-фильтру.

Ну я вот думаю, что экспериментировать вообще надо в Матлабе или чем-то похожем (а данные туда собрать через 4channels).

А когда заработает - ну запрограммировать на чем-то. На Halide, к примеру.

"Просто мне пришла идея, экспонировать каналы по отдельности,.."
От меня эта идея давно уже ушла. :)
Причин несколько:
- Как это сделать в камере для одномоментной экспозиции?
- 3 экспозиции?! - А совмещать потом как? (Или у Вас НЕ зеркалка?)
- Поканальные экспонометрические кривые - НЕ ПРЯМЫЕ,=>, тени/середина/света разъедутся по балансу белого.

Или в последнем утверждении я не прав???
Тогда почему фотошопом правятся практически все фотографии, даже если не надо фотоЖабить?
Можно, конечно, кастомный профиль наваять, для ВСЕХ источников света... ;)

На хоботе я уже пару раз предлагал побаловаться объективом ЯнпольКолор, который для печати.
Им какой любое освещение можно скомпенсировать прямо при съёмке!
Но народ сразу сливался. :( И почему бы?!.. Стоит копейки. Не из-за дырки же!.. :D

Как мне кажется, все эту "непрямоту" видят и правят, но при съёмке лень об этом вспоминать.

Ну, как дебайерезировать pgm* мозайку я нашёл, например, плагин к ImageJ есть. Но как 4 разных картинки собрать в мозайку, вопрос открытый. С матлабом для меня сложно заморачиваться, я не кодер, я фотолюбитель)

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

А ещё, может быть вы знаете, как чб мозайку превратить в цветную мозайку, без дебаера, аналог RAW composite с отключенным 2x2 pixel в RawDigger?

Ну я бы - если бы встала такая задача - это место бы напрограммировал.

Готовых средств не знаю, но это не означает что их вообще нет, просто не знаю.