В D70 Сжатый NEF? Видны артифакты сжатия.

Цитата:

от: delx
Цитата:

от:amateur_andy
В NEF не теряется НИ ОДНОГО бита информации.

?? Посмотрите исходники от DCRAW, например. По ссылке приведенной Alex Dumenko как раз и объясняется что происходит. Сомневаюсь, правда, что при этом теряется что либо кроме фотонного шума.

Подробнее

В указанной статье упоминается, что файлы от Кенон больше, чем получаемые в NEF. Это очевидно, только почему-то автор забывает, что Никон пишет jpg в отдельный файл, а Кенон хранит его в CRW. Если взять исходники и "вырезать" только "чистую сырую RAW информацию" из NEF-a и CRW, то получаемый объем будет примерно одинаковый (примерно, потому, что используются немного разные модификации алгоритма Хофмана).
Далее, все желающие могут выполнить очень простой эксперимент - сфотографировать черный лист бумаги. Если бы, как говорится в статье в NEF-e хранились бы только 10 бит, а 2 шумовых бита "теряются" (откуда и получается lossy сжатие), то для "черного листа" потребовалось бы всего 2-3 бита на пиксель (2 еще шумовых + максимум один информационный). Причем для такого сжатия не потребовалось бы изобретать ничего нового, можно было бы использовать любой имеющийся алгоритм сжатия. Следовательно, фотография черного листа занимала бы в районе 1.5-2.2 Mb. Реально она занимает 3.0-3.7 Mb. Следовательно хранится 4-5 бит на пиксель (4 шумовых + один информационный). Получаем, что 4 шумовых бита честно хранятся в NEF-e.
А, кому уж совсем не лень, могут "поковыряться" с кодом программы :)
P.S.
Готов признать свои ошибки и заблуждения, если меня в этом убедят :)

Цитата:

от: amateur_andy
Готов признать свои ошибки и заблуждения, если меня в этом убедят :)

Да чего там разубеждать, смотрите исходный код от dcraw.c и все становится ясно как день. Там есть массив curve[] в котором хранится кривая, например, и функция nikon_compressed_load_raw которая его заполняет и использует. Встроенный JPEG вообще никак не влияет здесь.

Thom Hogan вполне человеческим языком объясняет: "Basically, the camera takes the highlight data and places them into groups (essentially a rounding of many of the data points), producing the equivalent to somewhere between 9 and 10 bits of data. When this is returned to 12-bit form, there's a bit of posterization in the highlight data. The reason this works as a visually lossless scheme is that our eyes really can't resolve more than about an 8-bit value can produce (and our eyes aren't linear in response to light, either). For the most part it isn't a big thing that the compression loses data, though there may be some post-processing manipulations that will render slightly differently because of the data rounding." Более детально по ссылке приведенной ув. Alex Dumenko.

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

Цитата:

от: delx
Цитата:

от:amateur_andy
Готов признать свои ошибки и заблуждения, если меня в этом убедят :)

Да чего там разубеждать, смотрите исходный код от dcraw.c и все становится ясно как день. Там есть массив curve[] в котором хранится кривая, например, и функция nikon_compressed_load_raw которая его заполняет и использует. Встроенный JPEG вообще никак не влияет здесь.

Подробнее

Хорошо, будет время посмотрю внимательно на эту функцию. Но на первый взгляд это обычный lossless алгоритм с использованием аппроксимирующей кривой. Для набора данных строится аппроксимирующая кривая, которая задается своими коэффициентами. После этого для каждой точки вычисляется разность между значением "кривой" и истинным значением. Далее эта разность сжимается с помощью Хофмана (хотя для разности лучше использовать арифметическое кодирование).
В "декодирующей" части по известным коэффициентам кривой вычисляется значение в точке и к нему добавляется корректирующая поправка из сжатых разностей, получаем истинное значение без потерь.

Цитата:

от: amateur_andy
Но на первый взгляд это обычный lossless алгоритм с использованием аппроксимирующей кривой.

На первый и на второй взгляд все возможные 12-битные значения выдаваемые АЦП (12бит=4096 возможных значений), собираются в таблицу, после чего это таблица ужимается до 683 значений (9.5бит примерно).

Далее в NEF файлы пишутся индексы из этой таблицы (0..682) в слегка закодированном виде. При раскодировании соответственно подставляются числа из таблицы

image[row*width+col-left_margin][FC(row,col)] = curve[diff] << 2;

О поправках речь не идет.

Цитата:

от: VETO
Недавно готовя файлы для печати А4 заметил артифакты сжатия особенно сильно проявляющиеся на пошаговой интерполяции. :(

Отсюда поподробнее: интерполяцию чем делали? Что интерполировали(NEF или???)? Использовали ли к.-либо шумодав?

Цитата:

и на распечатке а4 тоже

На чем печатали? Как готовились снимки к печати?

P.S. Как уже сказали, хорошо бы также на образец взглянуть. Думаю, что проблема в постобработке, а не в NEF.

P.P.S. To ALL: Господа! Обсуждение как-то слишком ушло в сторону теории ;).

Цитата:

от: delx
Цитата:

от:amateur_andy
Но на первый взгляд это обычный lossless алгоритм с использованием аппроксимирующей кривой.

На первый и на второй взгляд все возможные 12-битные значения выдаваемые АЦП (12бит=4096 возможных значений), собираются в таблицу, после чего это таблица ужимается до 683 значений (9.5бит примерно).

Подробнее

Вы, абсолютно правы, только, если Вы обратили внимание это самое магическое число 683 не константа в декодере, а берется из NEF файла. Вы можете гарантировать, что если получаемая "сырая" картинка будет содержать больше возможных значений сенсоров, чем это самое 683, то в NEF файле будет не 1300 на этом месте или 2000?
Если у вас всего два значения 0 и 4095, то логично построить хэш-таблицу (кривую, кластеры и т.п.) только из двух строчек, а не из 4096-ти. Так, что я пока не вижу доказательства того, что здесь lossy алгоритм.
Но, послушаем Александра, здесь все же не технический форум, а фотографический, и не стоит лезть в технические дебри.
Сегодня дома сделал фотографию с закрытым объективом в темноте. Размер файла 4.3 Mb, т.е. 6 бит на точку, если к ним добавить 2.5 (12-9.5) бита, которые якобы "теряются", то получаем 8.5 бит. Далее фраза из "Обыкновенного чуда", "Ну, барин в таком случае одному не справиться, тут помощники нужны ..." ...чтоб написать такой плохой алгоритм сжатия "черного" квадрата. :)

Цитата:

от:amateur_andy
. Вы можете гарантировать, что если получаемая "сырая" картинка будет содержать больше возможных значений сенсоров, чем это самое 683, то в NEF файле будет не 1300 на этом месте или 2000?

Подробнее

Во всех NEF файлах от D70 что я видел, снятые в разное время разными людьми, таблица всегда содержит ровно 683 одинаковыз значения. По всей видимости входит в прошивку аппарата. Т.е. то что NEF у D70 lossy и алгоритм сжатия очень примитивный (по сравнению с Кэноном где при тех же или меньших размерах файла кодируются не 9.5, а все 12 бит) - это 100%.

Но видимых артефактов появляться от такой компрессии не должно.

Цитата:

от: delx

Т.е. то что NEF у D70 lossy и алгоритм сжатия очень примитивный (по сравнению с Кэноном ...

Так бы сразу и сказали :)
То, что Кэнон "круче" никто не спорит :) Боже упаси :)

Размер сенсорной матрицы у D70 2014 на 3040 (реальный размер на выходе еще меньше 2000 на 3008 пикселов),
при 9.5 битах получаем максимальный размер, без какого-либо сжатия не должен превосходить 6.9 Mb (6.75 Mb если считать реальные пикселы). Вам прислать nef файл c D70 размером 7.07 Mb (7,421,051 bytes)? Обычный пейзаж "фишаем"... специально за размером файла не гонялся...

Цитата:

от:amateur_andy
без какого-либо сжатия не должен превосходить 6.9 Mb (6.75 Mb если считать реальные пикселы). Вам прислать nef файл c D70 размером 7.07 Mb (7,421,051 bytes)? Обычный пейзаж "фишаем"... специально за размером файла не гонялся...

Подробнее

Методика Кена Роквелла - оценка алгоритмов по размеру файлов ? :)

В NEF-е от Д70 кроме собственно 3040x2014 пикселов имеется аж два встроенных JPEGа (один 570x360, около 30к, второй 3000x2008, 700-800к, который камера на экранчике при просмотре показывает), EXIF данные, всякие Maker Notes, эта несчастная таблица преобразования (683*2=1.3Kb), куча всяких пустых полей на многие килобайты и т.д.

Было б о чем спорить, на самом деле. Есть бесплатная и всем доступная программа-разжиматель аж о 10 строках на С которая разбирает NEF файлы от D70. Алгоритм действительно очень примитивный. Посмотрите и убедитесь, размеры файлов тут вообще ни причем.

Цитата:

от: delx

Методика Кена Роквелла - оценка алгоритмов по размеру файлов ? :)

В споре с оппонентом приходится использовать его аргументы :)
Вы сами написали "Nef файл lossy ... 100%" - это из серии "Учения Маркса верно, потому, что оно верно" :)
Далее Вы написали, что вы не встречали nef файлов с размером таблицы больше 683 ... Это тоже надо воспринимать как научно доказанный факт? :)
Может у Никона такие плохие сенсоры, что они физически не могут дать больше 9.5 бит? :) Это же проблема сенсора, а не алгоритма сжатия и от этого сам алгоритм не становится lossy :)

Цитата:

от: delx

В NEF-е от Д70 кроме всего прочего имеется встроенный JPEG (килобайт 700-800, который камера на экранчике при просмотре показывает),

Не .. это в CRW jpg пишется внутри, а D70 его пишет отдельно, в nef совсем маленькая превьюха кило на 30.

Цитата:

от: delx

EXIF данные, всякие Maker Notes, эта несчастная таблица преобразования (683*2=1.3Kb) и т.д.

Ну не мелочитесь :)) 1.3 Kb на фоне не понятно откуда взявшихся, как минимум, 200 Kb. :)

Цитата:

от:delx

Было б о чем спорить, на самом деле. Есть бесплатная и всем доступная программа-разжиматель аж о 10 строках на С которая разбирает NEF файлы от D70. Алгоритм действительно очень примитивный. Посмотрите и убедитесь, размеры файлов тут вообще ни причем.

Подробнее

Так, чтоб судить lossless алгоритм или lossy надо видеть программу "сжиматель", а не "разжиматель". А ее, увы, даже за деньги не продают ...

Цитата:

от: amateur_andy
Может у Никона такие плохие сенсоры, что они физически не могут дать больше 9.5 бит? :) Это же проблема сенсора, а не алгоритма сжатия и от этого сам алгоритм не становится lossy :)

Я не думаю что у Никона установлен такой хитроумный 12-разрядный АЦП, который может выдать значение curve[600]=2978, и curve[601]=2990 и не может выдать ни одно из промежуточных 2979-2989.

Правильно проэкспонированные несжатые NEF-ы от D100 содержат все промежуточные значения, в чем легко убедиться при помощи того же DCRAW.
Цитата:

от: amateur_andy
Не .. это в CRW jpg пишется внутри, а D70 его пишет отдельно, в nef совсем маленькая превьюха кило на 30.

Один JPEG, 570x300, обычно находится со смещения 0x1FB0, второй, 3000х2008, со смещения 0x20000. У Кэнона сделано подобным образом что в CRW, что в CR2 т.к. читать весь RAW файл с карточки и конвертировать для просмотра и увеличения на экранчике неэффективно.
Цитата:

от: amateur_andy
Так, чтоб судить lossless алгоритм или lossy надо видеть программу "сжиматель", а не "разжиматель". А ее, увы, даже за деньги не продают ...

Такую программу "сжиматель" вам задаром напишет школьник на уроке информатике в 10 классе. На первом курсе института за такой "сжиматель" будут ставить тройку, авансом :)

Цитата:

от:delx

Такую программу "сжиматель" вам задаром напишет школьник на уроке информатике в 10 классе. На первом курсе института за такой "сжиматель" будут ставить тройку, авансом :)

Подробнее

Обратную функцию к данному алгоритму - это и ежу понятно, что напишет :)
Только опять же, нет доказательства, что это lossy, даже, наоборот Вы сами доказали, что алгоритм lossless :)
Т.к. если истинный "сжиматель" равен обратной функции от приведенного "расжимателя", то после "расжатия" получим множество совпадающее с исходным :) Значит алгоритм lossless :)
Чтоб докаэать его lossy надо видеть, есть ли в "сжимателе" дополнительные "жучки", которые два разных значения V1 и V2 преобразуют к одному, а потом уж применяют функцию сжатия.
То, что в D100 другие значения это тоже ничего не значит, возможно для устранения муара в D70 применяется дополнительное размазывания сигнала по соседним ячейкам. Да возможна куча причин по которым "сырой" nef файл содержит 9.5 бит на пиксель. Может Никон научился аппаратно "убирать" шумовую добавку соседних сенсоров и т.п.
Просто, я не вижу причин, чтоб солидная фирма "обманывала" по мелочам. Для RAW данных нет единого формата, но как бы де-факто считается, что это данные без потерь. А, вот, то, что Никон может пытаться скрыть "слабость" своих сенсоров не способных регистрировать сигнал с точностью больше 9.5 бит, на мой взгляд более логично.
Может по этой причине Никон в D2X использует CMOS?

Цитата:

от: amateur_andy
Только опять же, нет доказательства, что это lossy, даже, наоборот Вы сами доказали, что алгоритм lossless :)

Брр, 4096 возможных значений яркости переводят в 683, и это Вы называете "lossless"? Все значения 2978-2990 приводят либо к 2978, либо к 2990.

Т.е. не может быть такого файла от D70 со стандартной прошивкой в котором яркость некоторого пиксела будет составлять 2985. С D100 может быть, с D70 - нет.
Цитата:

Просто, я не вижу причин, чтоб солидная фирма "обманывала" по мелочам.

Зачем обманывать - Никон честно сказал что Compressed NEF "virtually lossless". Старшие камеры вроде D2H и D100 умеют писать и несжатый - все честные 12 бит. В D70 эту функциональность обрезали.

А NEF поправить это дело нехитрое - кадры с длинными выдержками обрабатываются неотключаемым шумодавом, о чем в деталях написано в http://www.astrosurf.com/buil/d70v10d/eval.htm и даже рассказывается как победить :) Кэнон, по слухам, свои CRW немножко шарпит. Все выживают как могут :)

Цитата:

от: delx
Цитата:

от:amateur_andy
Только опять же, нет доказательства, что это lossy, даже, наоборот Вы сами доказали, что алгоритм lossless :)

Брр, 4096 возможных значений яркости переводят в 683, и это Вы называете "lossless"? Все значения 2978-2990 приводят либо к 2978, либо к 2990.

Подробнее

Ага ... брр :)
Кто вам сказал, что аппаратура в D70 способна регистрировать эти самые 2985? Может у них порог регистрации с шагом 4 или 8? Вы знаете внутренности? Лично я - нет...
Я уж не говорю про тот факт, что можно придумать алгоритм перераспределения сигнала между соседними ячейками, чтоб значение каждой ячейки "загнать" в нужную группу, а потом все это учесть на этапе реконструкции RGB изображения по матрице Байера...

Цитата:

от: delx

Т.е. не может быть такого файла от D70 со стандартной прошивкой в котором яркость некоторого пиксела будет составлять 2985. С D100 может быть, с D70 - нет.

А, Вы уверены, что в D100 был именно сигнал? А не случайный шум в сенсоре от, которого просто решили избавиться, показав тем самым истинную "силу" своих сенсоров?

Цитата:

от: delx

Зачем обманывать - Никон честно сказал что Compressed NEF "virtually lossless".

Можно ссылку на сайт Никона?

Цитата:

от: delx

Все выживают как могут :)

Вот в этом я с Вами полностью согласен :)

Цитата:

от: amateur_andy
Кто вам сказал, что аппаратура в D70 способна регистрировать эти самые 2985? Может у них порог регистрации с шагом 4 или 8? Вы знаете внутренности?

Какая разница какие там внутренности? С помощью данной реализации алгоритма и данной таблицы в 683 значения невозможно закодировать более 9.5бит. Даже если АЦП выдает 12 битный сигнал без шума вообще.

То что младшие биты в светах содержат в основном шум, это конечно так.
Цитата:

от: amateur_andy
Можно ссылку на сайт Никона?

nikon.com.sg. В руководстве от D100 на странице 44 написано:

Comp. NEF (Raw) In this mode, NEF images are compressed using a virtually “lossless”
algorithm that reduces file size by approximately fifty to sixty
percent without affecting image quality. More time is required to
process images before they are saved to the memory card.

Заодно зачем бы Никону и в D2H вставлять переключалку compressed/uncompressed NEF, если они оба lossless :)

Извиняюсь что как автор темы отсутствовал, просто работа так прижала что не шелохнуться было :(
сделал пару скриншотов, левый это скриншот в NC без обработки( кроме баланса цвета) шарпинк на нуле соответсвенно,далее файл сохранен как TIFF 16bit и открыт в шопе. После пошаговой интерполяции(шаг 50пикселей) на 135% появились артифакты ввиде сетки примерно 5х5 мм на формате А4. На сильные шумы не обращать, снималось при 1600iso и лампочке 60ват.
Вот такие пироги :( Даже и не знаю что думать
http://www.hafra.hotmail.ru/Test_artifac.jpg ~250kb

Не издевайтесь пошаговой интерполяцией!!!
какой лох это придумал вааще..

Вы хоть понимаете что интерполируя на +50 пикселей вы создаёте решётку с 50 ячейками в которой будут неравномерности.. 1/50 кадра на а4 это как раз 4*6 мм.

пошаговую можете использовать например в полтора раза тогда вы вносите неравномерность в каждый второй пиксель и как бы разнообразите этим рисунок.. а это самый настоящий муар вы получили..
да и вообще все эти пошаговые интерполяции - миф, никакого выигрыша в качестве нет. растягивайте сразу на всё а потом накладывайте спецэффекты чтобы разнообразить картинку, если это вообще надо.. для а4 с DSLR и растягивать особо не надо.

Цитата:

от: delx
Цитата:

от:amateur_andy
Кто вам сказал, что аппаратура в D70 способна регистрировать эти самые 2985? Может у них порог регистрации с шагом 4 или 8? Вы знаете внутренности?

Какая разница какие там внутренности? С помощью данной реализации алгоритма и данной таблицы в 683 значения невозможно закодировать более 9.5бит. Даже если АЦП выдает 12 битный сигнал без шума вообще.

Подробнее

Привет,
пока, что из всех Ваших аргументов не видно, почему алгоритм становится lossy. С математической точки зрения алгоритм lossless, он получает «внешний» параметр, исходя из этого параметра «расжимает» данные. Это алгоритм будет работоспособным и будет lossless даже если битность сенсора станет не 12, а 24-ти, и вместо 683 он будет получать 100000 и т.п. и т.д.
Теперь рассмотрим физическую сторону. У любого прибора, включая сенсор, есть такой параметр, как погрешность регистрируемоего сигнала. Рассмотрим простой пример, пусть эта погрешность равно одному проценту. Тогда для сигнала величиной в 1 получаем истинное значение от 0.99 до 1.01. А для сигнала со значением 4000 разброс уже будет от 3960 до 4040. И даже сам Господь Бог не скажет, какое же из значений в этом диапазоне является «физически истинным».
Т.е. можно построить пару аппроксимирующих кривых, которые будут очень близко подходить к «сигналу» при малых значениях и расширяться при больших.
И, если инженерам фирмы Никона, удалось убедить своих босов использовать некие «физические» принципы в своих алгоритмах, то, лично я, только еще больше начну уважать фирму Никон. Но, я в этом сомневаюсь, почему, чуть ниже.
Далее, как Вы выразились, гениальный алгоритм, используемый Кэноном, на самом деле ни, что иное, как стандартный Хофман, описанный в любом учебнике, и включающий в себя максимум строчек 30. Теперь скажите из каких соображений фирма Никон стала использовать lossy алгоритм с той же степенью сжатия, что и хорошо известный lossless алгоритм?
Больше года работаю в аналогичном подразделении, правда, не у Никона, и если я скажу боссу, что у меня есть lossy алгоритм, дающий даже 20% выигрыша по сравнению с lossless, то я буду отправлен в долгую сексуальную прогулку. И, босс будет прав, так как ни один инвестор не даст добро на это. Я присутствовал много раз на демонстрации алгоритмов инвесторам. У них есть калькулятор, чтоб вычислить степень компрессии, и программа «fc /b», чтоб побитно сравнить файлы. И если будет потерян, хоть один бит, то сексуальные процедуры обеспечены. Как говорят инвесторы, они начнут рассматривать «virtual lossless» только начиная со степени компрессии в 32(!) раза. И ради 1-5% «экономии» (степень компрессии 1.01-1.05 по сравнению с Хофманом) никто бы не стал изобретать «virtual lossless».
Хотя, конечно же, нельзя исключить и вашего варианта :) в этом мире все возможно :)

[quot] пока, что из всех Ваших аргументов не видно, почему алгоритм становится lossy[/quot]
Не похоже, чтобы Вы когда нибудь имели дело с алгоритмами.
Преобразование F(x) с обратным ему X(f) является lossy, если найдется такое x, что X(F(x)) != x. В случае с NEF такие x есть. О чем спорим дальше ?

Цитата:

от:amateur_andy
И если будет потерян, хоть один бит, то сексуальные процедуры обеспечены. Как говорят инвесторы, они начнут рассматривать «virtual lossless» только начиная со степени компрессии в 32(!) раза. И ради 1-5% «экономии» (степень компрессии 1.01-1.05 по сравнению с Хофманом) никто бы не стал изобретать «virtual lossless».

Подробнее

Не, ну конечно подорвать Вашу веру в торжество и гений инженеров Никона, даже если их собственное признание "virtually lossless" не убеждает, то что я могу. Вот такое "lossless" преобразование, из 4096 отсчетов делает 683 - новое слово не то в арифметике, не то в английском языке.

А самое вероятное объяснение тут простое - если Вы посмотрите на алгоритм, то он поражает своим примитивизмом и заточенностью под один процессор (распараллелить не получится). Использование его вместо Хоффмана вероятно объясняется тем что добавлять Compressed NEF решили в последний момент, когда реализовывать аппаратные решения было поздно. У процессора стоящего в Nikon D100 даже эта элементарная табличная подстановка занимает почти 40 секунд на кадр (скорость сжатия ~100кб/с), Хоффман занял бы неделю. Большие карточки тогда были дороги, позволить ближайшему конкуренту создавать файлы вдвое меньше было недопустимо. Слепили что могли.

С D70 Никон конечно мог уже сделать аппаратное решение, но жалоб у клиентов не возникало, размер файла устраивает (даже влупили внутрь 3000x2000 JPEG для ускорения увеличения на экранчике, сошло с рук. D100 конвертировал RAW каждый раз). Поэтому, видимо, решили третий формат NEF-ов не разводить.