blog.lexa.ru

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

В самом деле, имеет место некий фенОмен (который виден, например, по dE т.е. инструментально):

• C одной стороны, цифровые камеры в светах (но до начала блюминга) - высоколинейны. Т.е. отпрофилировав их в среднем тоне мы вправе ожидать приличных цветов и в светах.
• C другой стороны, практика это опровергает, если снять цветовую шкалу +2 (без всяких вылетов) и наложить профиль камеры, то цвет уползет достаточно сильно (по меньшей мере, dE вырастет в разы)

Я тут вижу несколько соображений:

• Во-первых, блюминг. И, наоборот, всякие антиблюминговые решения, которые должны характеристическую кривую загибать.
• Во-вторых, всякие игры RAW-конвертеров (которые тоже характеристическую кривую загибают).
• В-третьих, следующий интересный эффект:
  1. Давайте представим себе профилировочную таблицу, вроде ColorChecker SG. Вот на ней есть зеленый патч E9, который на 1.5-2 стопа (на глазок) ниже среднесерого.
  2. Уровень красного в этом зеленом будет еще на пару стопов ниже (красного в нем мало), потом у красного канала чувствительность на стоп-полтора хуже т.е. красным мы попадем куда-то в -5 от среднего тона (или -8 от самых светов).
     Это, на минуточку, вообще на пределе какого-то сигнала в красном.
  3. Но красный канал нужен, чтобы отличить сине-зеленый от зелено-синего т.е. в этом месте профиля красный будет с очень большим весом (т.к. сам сигнал - маленький).
  4. Но красный - зашумлен, в рассматриваемом месте он уже сильно нелинеен (по причине шума)
• Собственно, вот: профиль для таких "предельных" цветов будет как-то компенсировать нелинейность слабых каналов, а если мы переедем на 3 стопа вверх - то перекомпенсировать (ибо на три стопа вверх в красном канале уже все отлично).

Такие дела.

Покрупнее

На картинке

• слева - зеленый канал из фотографии мишени для оценки динамического диапазона, остальные каналы экспонированы меньше и жизни там больше.
  Получено программой 4channels из LibRaw, никаких преобразований кроме растягивания на полный диапазон.
  Кадр проэкспонирован так, чтобы основной фон был на грани переполнения, еще треть стопа и переполнение наступает.
• справа - тот же кадр, проявленный Adobe Camera Raw 5.3 с настройками default: стандартная яркость, экспокоррекция 0, остальное неважно.

Мы видим, что в зеленом канале жизнь есть. Да, детали на полстопа ярче фона видны плохо (чтобы их увидеть - нужно контраст поднять, но они там есть). А вот в проявленном RAW детали в светах пожрал хомяк ACR. Нет, если покрутить Exposure или Recovery, то все появится, но хочется обратить внимание на совершенно другое:

Рассматривал поканально тестовые шкалы (серое по серому с известным контрастом), усреднял, рисовал таблицы линейности, родил утверждение:

Ошибкой было бы думать, что на уровне экспозиции -7-7.5EV от точки насыщения зеленого можно получить какой-то разумный цвет.

Граждане фотографы (и примкнувшие к ним)!

А кто знает, где взять пленочку-тряпочку, которая была бы

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

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

Про "ткань серебрянка" и про "tafeta silver" я помню (и у меня обе две кажется даже есть в заначке), но может быть бывает что-то более блестючее? Всякие "светоотражающие пленки" я видел только на лавсане, хрустящие, но может быть бывает на полиэтилене?

После появления первой доступной реализации OpenCL (доступна для зарегестрированных NVidia-девелоперов с девелоперского сайта) все кинулись смотреть (и я тоже).

Накопали всякого интересного:

• Бинарное представление OpenCL-кода - это практически CUDA PTX (ссылки: PDF-текст про это, ветка форума к которой этот текст относится).
• Возможно подсовывание PTX-кода от CUDA в OpenCL (ссылки те же), смысл может быть в использовании тех CUDA extenstions, которых нет в OpenCL. Правда, при этом можно использовать просто CUDA т.е. смысла не очень много.

Кроме того, многих фишек CUDA просто нет в текущей реализации OpenCL, что огорчительно:

• Нет работы с mapped pinned memory (что появилось в CUDA 2.2). Т.е. требуются пересылки в память видеокарты даже там, где эта память - на самом деле системная память (ноутбучные видеокарты), да и вообще без пересылок удобнее.
• В CUDA есть взаимодействие с OpenGL, в OpenCL - нету (в спецификации есть, но пока не поддержано). В результате, пример nbody в OpenCL-реализации работает вчетверо медленнее на GTX280 (80GFLOP/s вместо 320), ибо весь пар уходит в пересылку результата на хост, а с хоста - на отрисовку.

Вообще, со всеми этими extensions все выглядит пока весьма огорчительно. Даже если они появятся в условном OpenCL 1.1+, придется писать по варианту программы под каждую видео-архитектуру. И на текущем разнообразии железа не видно выхода, слишком оно разное, чтобы из одной программы компиляцией получались эффективные решения под ATI и NVidia одновременно.

Простые юнит-тесты еще не делал, руки не дошли, пока только смотрел код из SDK.

Update Похоже, про nbody товарищи не правы. Т.п. в oclNBody какая-то работа с OpenGL objects есть. Либо недоделано, либо просто NBody нужно под OpenCL делать как-то иначе.

Update2 Предыдущий апдейт неверен, ибо (согласно Release Notes): 2. OpenCL - OpenGL Interop is not supported.