Свежие комментарии

>Что же касается замены умножения сложением, то я ниасилил.
При умножении логарифмы же складываются.
Вся "бяка" и макроскопическая разница integer vs float - она же появляется при умножениях, а не при сложениях.

>Почему "дебайеризация - это умножение"?
А что же ещё? (сорри конечно что задаю такой вопрос автору libraw). Есть входные raw-числа, есть матрица преобразования в rgb. Одно на второе умножается.

>Ну и выигрыш от замены умножения сложением мне непонятен.
Выигрыш по точности. У float, типа, все биты что-нибудь значат. А у integer впереди или сзади может быть куча ненужных нулей.

>Речь о том, что "неоднократно приходилось читать и слышать", что точность float избыточна и 16-битных целых достаточно "разница если и будет, то микроскопическая". См. начальный пост.
А она - макроскопическая.

Напоминает интернет-флейм a la Margulis на тему 8 и 16 бит. Тогда Маргулис предложил что-то типа пари - ему дают 8-битную картинку (но не генерированную а реальную фотку), последовательность осмысленных действий по коррекции в шопе в 16-битном режиме с возвратом на 8 бит, он делает тоже самое без перевода в 16 бит и если разница будет заметной - Маргулис проиграл.

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

Так вот, эти целочисленные вычисления с 16-ю битами и макроскопической разницей проявились на генерированной картинке что не удивительно, не так ли?

Потом, когда говорят о 16 битах - на самом деле говорят о них, или например о 12 битах? Ну например, после ацп идут 12 бит - их дополняют старшими нулями или например сдвигают на пару бит, делая и старшие и младшие нули?

>А если 32 бита, то зачем мучаться с целыми, если в плавучке не медленнее и более приспособлено к реальным потребностям изображений в смысле постоянности относительной ошибки.

А вопрос ещё есть другой все-таки. А вот если сохранить ту же битовую длину (16 бит) но перевести в логарифмический вид на время вычислений - тоже станет лучше?

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

То есть вроде как бы выходит, что почвы утверждать "точность float избыточна и 16-битных целых достаточно "разница если и будет, то микроскопическая". - нет. Единственное - скорость, но как ты говоришь скорость уже хорошая.

Может те кто утверждают, не видели логарифмической линейки? Иногда наглядность доставляет.

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

Скажем, взять 16-битный вход, преобразовать в 32-битный, сдвинуть на 10 бит, дебайрить целочисленно, сдвинуть обратно на 10 бит, преобразовать обратно в 16-бит - будет же лучше чем чем всё считать в целочисленных входных 16 битах?

Але, пиковая производительность SSE на i7 - 8 операций на такт в плавучке.
И это гораздо быстрее, чем целые на CPU.

Парой - не обойдется, посмотри на разницу.

ну у нас как бе не 16 их в запасе?
разница не показатель, 1 бит ошибок накопили и потом усилили.

Но зачем, если правильно реализованные вычисления в плавучке, как минимум, не медленнее (хотя и муторнее в реализации)
ой ли? что, плавучка стала быстра как целые? и давно?
а эти SSE2 тоже в плавучке? и тоже быстрые?

имеется в виду, при том же количестве бит?

Я не в теме какие именно там вычисления, но при длинной цепочке сложений/вычитаний и при большом разбросе значений погрешность может отразится и на целых.

Тоже хочу попробовать.. новую версию друпа.

Не, тут дело не в переполнении, а в вычитании.

Парой - не обойдется, посмотри на разницу.

Но зачем, если правильно реализованные вычисления в плавучке, как минимум, не медленнее (хотя и муторнее в реализации)

Можно многое, только будет ли от этого достаточно толка, чтобы оправдать затраты времени на очередное "изобретение колеса"?

а что, тупо пару бит в целых числах не добавить?

Это при редактировании коммента.

Видел много раз, руки не доходят посмотреть внимательнее (тем паче, что все работает при этом - сообщение редактируется). Забейте.

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

Получается - не может.

Вообще, фотографирование радуги (можно - искусственной) дает массу поводов для размышления. Печальных.