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

не-а.

В том смысле, что тогда это было общим местом, но 7 лет прошло и каких-то разумных источников информации я за две минуты не нашел. Поищу еще.

Языком почесать - можешь, в этом я не сомневался.

Давай почешем. Какой перформанс ты планируешь получить на размере данных порядка гигабайта? Ну там типа 2D, 8192x8192, complex
Какая себестоимость будет у платки? Интерфейс какой?

А то тут одни выпускали акселератор для N-body задач, тоже наверное чувствовали себя крутыми, чморили С.

> Но вот как добиться контролируемости от Java и ее контейнеров?
> Я абсолютно не представляю и не представляю где бы мы взяли людей,
> которые бы это знали.

Могу дать reference ;)
Делается почти также, как в Це - выделяется большой массив и в этом массиве всё живёт.
Причём они данные в этом массиве даже паковали дефлэйтом (т.к. данных было слишком дофига) - всё равно получалось лучше, чем много миллионов объектов в работе у мусоросборщика.

Ой, ты не ушел? Радость какая!

Первый вариант не описан достаточно, чтобы его можно было всерьез обсуждать.

Это вы льстите себе, увы. В приличном обществе нельзя услышать фразу "я повозил его об".

Конкретно в SMB дело скорее в каких-то таймаутах, сколько не копируй память-память, так медленно сделать трудно (и я не вижу даже 50% CPU на двухгоршковой машине, а должно быть в таком случае).

Но общий вектор, конечно, верный.

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

Если мы по этому замеру снимем, то объект отрендерится туда, куда мы намеряли собственно снимая серую (белую) карту.
Если мы дадим экспопоправку в +3.2 стопа (пусть мы намеряли, что реальный серый отклик - 10.2% от максимума, как в моем эксперименте с 450D), то объект отрендерится в самый максимум, какой может быть без клиппинга в зеленом канале.

Теперь, допустим мы замеряли не основной объект, а самые света, где мы хотим получить следы фактуры (про highlight recovery забыли пока). В предыдущем абзаце ответ - дадим поправку +3.2 (относительно замера светов) и света окажутся ровно там, где мы хотим. Это, собственно, замер "как слайд снимали".

Headroom по двум другим каналам (при дневном свете) - больше.

Что будет с цветными объектами при дневном свете:
- зеленые в насыщение попадают раньше
- красные и синие - позже (при большей передержке относительно замера)

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

Что со вспышкой:
- т.к. светим мы на объект, а ярких светов обычно нет, то правильно дать вспышке коррекцию в плюс. Примерно +1. Но у современных камер много лишнего интеллекта, рекомендуют вспышечную коррекцию задавать на вспышке, а не на камере.

хм... теперь осталось посмотреть на A900, ибо в D3x типа не её exmor напрямую, а с другой "обвязкой" прибавляющей в том числе два бита к файлам. например если на A900 этого нет, значит источник -- в никоновской "обвязке".

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

В D3X та же фигня, см выше мой ответ Isoft'у

1) просто забыл константу :-)
3) пусть получил я некое эффективное ISO или запас, что с ним делать дальше? просто как FYI или всё же делать сдвиг при съемке?

У меня нету сейчас средней линейки под рукой.

Но очень же легко сделать самому, для конкретного значения ISO это дело минут эдак трех
- снимаем лист бумаги с офигенной передержкой, так определим диапазон значени
- снимаем тот же лист бумаги (равномерно освещенный, расфокусированной оптикой) по камерному экспонометру. Например, в RAW+JPEG

- офигачиваем полученные RAW-файлы программой 4channels из <a href=http://www.libraw.su/download#beta>LibRaw 0.7</a>, получаем линейные TIFF-ы, по одному на канал (4 на кадр)
- смотрим на файл .G.tiff (или .G2.tiff, они в большинстве случаев почти одинаковые), например фотошопом (в линейной гамме, grayscale). Для пересвеченного кадра видим там диапазон, для остальных - значения серого тона. Оно в линейной шкале, отчего отношение значений и будет запасом по экспозиции _в_разах_ (чтобы в стопы перейти - логарифмируем по основанию 2)
- смотрим на JPEG-и из камеры, там для перехода в линейную шкалу нужно дельту в степень 2.2 возводить.

три вопроса.
1) 18% в sRGB в гамма 1.8 это вроде не 18% в RAW. может быть нужно пересчитать % по гамме?
2) практический вопрос. получается, что ACR тоже делает для камер Canon пуш +2/3?
3) практический вопрос. правильно ли я понял, что рекомендуется всегда делать коррекцию экспозиции +2/3 при съемке и потом -2/3 в конвертере? смысл получается в том, что будет меньше шума и выше ДД.

вы правы в том, что стоимость разработки, время и надежность это тоже важные параметры, не менее важные, чем производительность. но нужно разделять общий код и hot spot код, который вызывают часто и его время 90% программы, такой код обычно идёт в библиотеки. так вот, я считаю, что такой код нужно писать по-уму, и если нужно даже на ассемблере.

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

нужно искать баланс и адекватные инструменты для своих задач, раз Java, С и asm существуют, значит это кому-то нужно. здесь я с вами снова соглашусь.

>Я могу взять FPGA и сделать FFT в железе, и чморить си.

Не можешь.