Выбор: беззеркальная камера со сменными объективами

Этот кусок кода используется везде, где используется RawSpeed (darktable из сколько-нибудь популярных программ. Ну и FastRawViewer, да).

Совершенно аналогичный по смыслу кусок кода (но гораздо хуже написанный в смысле понятности) используется везде, где для чтения RAW применяется исходник dcraw. Из популярных программ - ACDSee, FastStone (и много других, покажите программу и я скажу, есть там внутри dcraw или нету).

Совершенно аналогичный по смыслу кусок кода, чуть-чуть облагороженный из dcraw, используется везде, где для чтения RAW применяется библиотека LibRaw.

Совершенно аналогичный по смыслу кусок кода используется Adobe - это очевидно, если сравнить результаты Adobe DNG Converter и, к примеру, результаты unprocessed_raw из LibRaw.

ee2:

А можно посмотреть пример артефактов на контрастных границах?

Вот самый полный текст на эту тему: http://www.rawdigger.com/howtouse/sony-craw-arw2-posterization-detection
(смешно, но на русском его у нас нет, есть кусочки в моем блоге)

Ну да.
А если знаний чуть больше - добавьте в dcraw в функцию sony_arw2_load_raw() отладочную печать "ой-ой, меня вызвало", напустите на файл с БЗК и убедитесь - вызывается. Именно этот (по смыслу) код.

Или в darktable, где RawSpeed, где он не по смыслу такой, а ровно этот.

Def:

Мне одно интересно - вы действительно не понимаете своей ошибки, или сознательно решили продолжить ездить по ушам доверчивым пользователям?

Ну да, я "действительно не понимаю своей ошибки" - ставлю в отладчике breakpoint - и при чтении "файлов с БЗК" попадаю ровно вот в этот код. Сюрприз.

Я, видите ли, программы-библиотеки для чтения RAW немножко, самую чуточку, разрабатываю.

ee2:

Прикольно. Малопонятно, конечно, откуда такое влияние на весь блок 16х16. Похоже 7-битная дельта дополнительно как-то нормализуется к диапазону блока при сжатии, чистая дельта не должна так поганить блок целиком...

Там блок 32x1
Но если в этом блоке есть большой перепад яркостей (попал трек звезды и темное небо вокруг), то шаг дельты будет большой. Потому что нужно в 7 бит дельты закодировать большой размах т.е. единичный шаг надо делать большим.

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

Def:

[
да, теперь понятно, вы это делаете сознательно. Ну ладно, тогда последний вопрос, обьясните вот этот код (который я упоминал) и разойдемся:

код выделить все

if (bpp == {
in = &input;
this->startThreads();
return;
} // End bpp = 8

if (bpp == 12) {

Осталось выяснить, откуда берется значение bpp.

AlexTutubalin:

Осталось выяснить, откуда берется значение bpp.

так вы спорите и что то утверждаете не разобравшись вообще?
Выше по коду, в том же файле:

uint32 bitPerPixel = raw->getEntry(BITSPERSAMPLE)->getInt();

AlexTutubalin:

А дальше, сюрприз:

сюрприз выглядет так:

код выделить все

// Sony E-550 marks compressed 8bpp ARW with 12 bit per pixel
// this makes the compression detect it as a ARW v1.
// This camera has however another MAKER entry, so we MAY be able
// to detect it this way in the future.
data = mRootIFD->getIFDsWithTag(MAKE);
if (data.size() > 1) {
for (uint32 i = 0; i < data.size(); i++) {
string make = data[i]->getEntry(MAKE)->getString();
/* Check for maker "SONY" without spaces */
if (!make.compare("SONY"))
bitPerPixel = 8;
}
}

вы бы хоть коментарий почитали
bitPerPixel будет = 8 если в теге Exif.Image.Make не будет текста "SONY". Для бзк - он есть

Def:

bitPerPixel будет = 8 если в теге Exif.Image.Make не будет текста "SONY". Для бзк - он есть

Как приятно видеть истинного знатока программирования на C++!!!

Читаем тут: http://www.cplusplus.com/reference/string/string/compare/
===
Return Value
0 They compare equal
====

Соответственно !make.compare("SONY" ) - истинно, если строчка make в точности равна SONY

Сюрприз.

ee2:

Вот и я о том же.
Не понятно, когда вообще срабатывает (и срабатывает ли вообще когда-либо) bpp=12. По-моему у всех камер MAKE=Sony...

Так, по логике, это случай 12-битных (без тоновой кривой) данных с A900 и A850.

Я сейчас позавтракаю (с этой дискуссией все остыло уже нахрен и вообще полдень) и подсуну файлик, посмотрю.

ee2:

AlexTutubalin:

Так, по логике, это случай 12-битных (без тоновой кривой) данных с A900 и A850.

Что-то сомнительно, что они другой Make в EXIF кладут в этом случае.

Смешно (говорю же, отвратительный хак). У A900 в этом формате в Make "SONY " с пробелом на хвосте. То есть compare возвращает не 0.
А в BitsPerPixel в 12-битном формате - написано 12.

А в cRAW (жатом с потерями) формате - у A900 в BitsPerPixel правильно написано 8. То есть "Sony " не срабатывает, но верное значение и так прилетает из файла.

Вообще, надо это место переделать, потому что на соплях все. Битность же очевидна из размера - 1 или 1.5 байта на пиксель. Надо Клаусу написать....

Все, продолжение после приема пищи, а то помру за клавиатурой.

ee2:

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

Да, это видно только в экстремальных случаях, вроде вот этих звездных треков. Ну и какие-то следы видны на контрастных границах.

На самом деле, там надо добавлять случайный шум (средним) размером с половинку ступеньки дельты - и все будет не видно вовсе.