RawDigger 0.9.14 RC1

lexa - 24/Янв/2013 13:02
Граждане фотографы!

А потестируйте, кому не лень, новый RawDigger:

  • RawDigger-0.9.14-RC1-RU-Setup.exe
  • RawDigger-0.9.14-x64-RC1-RU-Setup.exe
  • RawDigger-0.9.14-RC1-RU.dmg
Уже потестировали. Берем 0.9.14 отсюда и наслаждаемся.

Из новых фишек там есть вот такое вот (доступно через Menu-Selection-Selection Grid):

Если простыми словами, то появился инструмент для удобного замера цветных шкал. Натягиваете на шкалу сетку того же размера, размещаете углы, таким образом, чтобы красные квадратики попадали в ячейки мишени - и вуаля. Вуаля в том, что по одной кнопке (Selection to Samples) в таблице Samples оказываются ваши замеры, которые потом можно сохранять (в CSV и CGATS), смотреть гистограмму и все такое прочее:

А из нашего окна

lexa - 23/Янв/2013 11:11
зимняя радуга видна

В FB мне пишут что это гало такое.

Q: "OpenGL на CPU"?

lexa - 20/Янв/2013 12:20
Преамбула

Несмотря на долбанутость OpenGL-ного API (и, как следствие, огромное количество глупых ньюбских ошибок, которые я допустил), сам OpenGL мне очень понравился.

Вот, к примеру, код в RawDigger, который занимается визуализацией, это 500+ строк довольно нетривиального кода которые делают:

  • Raw Composite
  • Поканальный показ
  • Overexposure/Underexposure
На OpenGL шейдер, который делает ровно то же самое (ну, да, немножко поменьше, в RD есть всякие режимы 2x2 pixels) - это 11 строк кода, несколько строк определения переменных, ну и, да, еще строк 10 для формирования матриц-векторов на которые мы множим и с которыми сравниваем. Ну и работает "немножко" побыстрее.

К сожалению, выяснилось что полноценный OpenGL есть не везде и в новом проекте таки придется делать софтверный рендеринг.

Амбула

Вопрос, собственно, такой: а есть какой-то code generator, который питался бы чем-то вроде кода OpenGL шейдеров и порождал бы код на SSE+треды. И был бы заточен именно под Imaging.

Ну если быть точным, то я знаю уже про

  • ISPC, который я нежно люблю, но он все-таки не про Imaging (4 рядом лежащих компонента пикселя), а больше про скалярное. С пикселями там приходится чудовищно извращаться.
  • Halide - ровно про это, вот прямо таки заточен, но мне очень не хочется таскать с собой llvm runtime, а хотелось бы генерировать статический код при сборке проекта. Кроме того: Windows support is technically feasible, but we have not yet built or tested on Windows, а мне оно нужно исключительно под Винду, у маков и так все хорошо (даже софтверный рендеринг в виртуальной машине - работает и быстро).
  • llvmpipe - даже совсем OpenGL, но есть серия но:
    • Очень не хочется таскать с собой здоровенный llvm runtime
    • Судя по обсуждению в багзилле мозиллы, прикручивание llvmpipe в качестве software renderer есть процесс весьма сексуальный.
Вопрос мой: может быть есть, все-таки, какие-то оффлайновые кодогенераторы, которые сочетали бы оффлайновость ISPC и пикселе-заточенность Halide/Mesa3D?

Q: mmap() ?

lexa - 19/Янв/2013 20:50
А я вот извиняюсь, а Windows умеет mmap()-ать файлы с сетевого диска?

А макос?

Ну то есть у меня какое-то ощущение из прошлого, что нет, нельзя, но в доках такого ограничения не нашел.

Про батареи к UPS

lexa - 15/Янв/2013 22:48
Верно ли я понимаю, что сменные батареи к UPS с лейблом APC - есть чистый развод на деньги и плата за американский экологически-чистый свинец? И, соответственно, в 2.5 раза более дешевые "аналоги" - ничем не хуже?

О зонной системе в цифровую эпоху

lexa - 09/Янв/2013 19:10

Вот раздумываю я, как должна выглядеть зонная система в светах в эпоху цифры (когда никакого плавного загиба ХК в светах более не существует). И видится мне как-то так

Зона 5: примерно как экспонометр настроен. На 2.7-3.4 стопа вниз от уровня насыщения для большинства камер при дневном свете. Можно, например, жестко решить что 3 стопа от насыщения для зеленого канала, независимо от освещения, так еще проще.

Зоны 6-8: от экспонометра до насыщения одного из каналов.

Зона 9: насыщены 1-2 канала, по трепыханиям в оставшемся можно как-то восстановить яркостную составляющую, а цвет - только всесьма приблизительно (и, скорее всего, ошибочно).

Зона 10: как и завещал Адамс, без деталей. Все три канала - в насыщении.

С зонами 0-4 все не менее интересно. Как-то так, наверное:

Зона 0: все три канала "ниже шума", доверять яркости нельзя, все черное.

Зона 1: 1-2 канала "ниже шума", доверять яркости как-то можно, цвету - нельзя

Зоны 2-4: нормальная цветная картинка в тенях.

Понятно что нумерация зон несколько условная, между "зоной 1" и "зоной 9" запросто может оказаться как больше 7 стопов (малошумная камера, низкое ISO), так и меньше 7 стопов (все наоборот). Вряд-ли в этом случае осмысленно рисовать больше зон, просто "нормальные цветные зоны" будут чуть шире или чуть (или сильно) уже одного стопа. Это не говоря о том, что обе границы "зоны 1" можно провести только пролетарским чутьем.

Ну и "яркостные зоны", 9-я и 1-я, будут разной ширины для разных камер и разного освещения.

Хочу какого-то обсуждения, наверное.

Логарифмируя шум

lexa - 08/Янв/2013 18:52

Прислали тут темновой кадр с Canon 7D, снятый на ISO3200 (на 1/250s, если вдруг существенно). Стал я туда смотреть и несколько удивился....

Берем, значит, RawDigger, открываем этот файл, ставим уровень черного в 0, чтобы увидеть не только правую половинку пика, смотрим. Видим вот такое:

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

Берем и включаем логарифмическую вертикальную ось. И видим такое:

Ищем альфа-тестеров

lexa - 06/Янв/2013 15:24
Граждане отдыхающие цифровые фотографы!

Если вы:

  • cнимаете в формат RAW (или много снимаете в RAW),
  • имеете немного свободного времени для тестирования новой софтинки,
  • имеете компьютер и фотокамеру, удовлетворяющие описанным ниже требованиям,
то вы можете совершенно бесплатно поработать альфа-тестерами нового вареза.

А какого вареза - пока скажу только тестерам (открытое тестирование начнется, по моим ощущениям, не раньше, чем через пару месяцев).

Чтобы принять участие в этом развлечении, вам нужно

  • Зайти на сайт beta.libraw.com
  • Зарегистрироваться там, согласившись с правилами участия (которые сводятся к "не разглашать без разрешения")
  • Подождать, пока аккаунт будет мной подтвержден (о чем придет E-mail)
  • Установить пароль, скачать с сайта дистрибутив, попробовать, отреагировать.

Про Qt5 и VisualStudio 2012

lexa - 30/Дек/2012 12:41

Если в двух словах, то со связкой указанной в заголовке - счастья не получил, откатился на VS2010.

Если подробно:

  • Qt - собирается без проблем, работает.
  • qmake делает прекрасные работоспособные Makefiles
  • qmake -tp vc - делает .vcxproj которые зовут компилятор от 2010-й версии (нет, я не туп, пути стоят нормально, QMAKESPEC=win32-msvc2012) и проекты не собираются, линкер ругается что у меня мои объектники от 2010, а библиотеки - от 2012.
  • Предыдущую проблему поборол: QMAKESPEC=win32-msvc2010 qmake -tp vc, при первом открытии проекта его апгрейдим на 2012. Достает, но уже привык.
  • Макросы для отладчика (показ Q-types по человечески) - установились, но не заработали.
  • Последняя капля: при попытке прикрутить иконку к .exe (обычным способом: RC_FILE=resource.rc в .pro) - все сломалось с ошибкой "VTRES : fatal error CVT1100: duplicate resource. type:ICON, name:1, language:0x0409". Судя по гуглению, это привет от конверсии проекта из 2010 в 2012, этот самый .rc оказывается в двух местах прописан.
Короче, поживу с 2010-м вижуалом до Qt 5.0.1. Хотя 2012-й мне нравится больше.

О сортах RAW у Sony

lexa - 29/Дек/2012 16:46

Про тоновую кривую в новых камерах Sony я уже писал и повторяться не буду.

Но тут переписывался с Ллойдом Чамберсом на тему Sony RX1 (прежде всего, конечно, как щупать RawDigger-ом неподдерживаемые камеры, как уровень черного определить и т.п.) и обнаружил массу веселья в самом формате ARW, точнее в новых его версиях.

В камерах Sony используются три формата записи RAW:

  • "Старый ARW" - камеры поколения Sony A100-A290 (точный список не составлял, по ощущениям это именно "старые камеры"). Это обычное такое хаффмановское сжатие, без потерь.

    При использовании этого режима - RAW-файлы будут сильно разного размера, в зависимости от детализации и шума.

  • Нежатый 12-битный RAW. Просто пишутся 2 пикселя в 3 байта, без сжатия, без потерь, без прочих глупостей. Этот формат используется в A900 в режиме "большие файлы" (~36Mb + размер JPEG), в Minolta 5D, возможно в еще каких-то, опять же не изучал.

    При использовании этого режима размер файлов "примерно одинаковый", полтора байта на пиксель плюс размер JPEG-а и EXIF-блоков. Соответственно, с A900 получается 36-37-мегабайтный файл.

  • Формат "ARW2" (так его называет Dave Coffin, а за ним и я).

    Этот режим записи используется во всех новых камерах Sony: NEX-xx, SLT-Axx, RX1, RX100. Его можно включить и на A900 (никогда не было этой камеры, надеюсь что этот режим включился не насильно после апдейта фирмвари, а есть возможность переключения юзером).

    При использовании этого режима RAW-файл имеет размер "1 байт на пиксель" (+JPEG и EXIF, конечно). 24-мегапиксельная A99 или NEX7 (или A900 в этом режиме) выдают, соответственно, 24-мегабайтный файл.

Вот последний режим нам и интересен, потому что он (и только он?) используется в актуальных камерах.

Вот как выглядит исходный код кусочка декодера (тот кусочек, который собственно распаковывает) этого формата в библиотеке RawSpeed (в dcraw - то же самое по смыслу, но Dave Coffin - истинный хакер и всякими глупостями вроде getBits(7) не пользуется):

И об искусстве!

lexa - 27/Дек/2012 13:00
Да, фильм же вышел, как и обещали 12.12.12.

Дархатская котловина. Экспедиция в затерянный мир

Опять о современных CPU

lexa - 26/Дек/2012 10:52

Продолжаю набирать материал к вот этой презентации

Вот такой вот код (это автобаланс белого из dcraw в моем вольном изложении, слегка сокращенный, только для 4-компонентных а не байеровских изображений):

float sum[8],dsum[8]={0,0,0,0,0,0,0,0};
for (row=0; row < bottom; row += 8)
   for (col=0; col < right; col += 8) {
      for(i=0;i<8;i++) sum[i]=0.f;
      for (y=row; y < row+8 && y < bottom; y++)
        for (x=col; x < col+8 && x < right; x++)
          for(i=0; i<4; i++) {
            val = image[y*width+x][i];
            if (val > maximum-25) goto skip_block;
            sum[i] += val;
            sum[i+4]++;
           }
       for(i=0;i<8;i++) dsum[i] += sum[i];
skip_block: ;
   }
То есть, если простыми словами: берем блоки 8x8, если в этом блоке все пиксели имеют значения меньшие (maximum-25), то значения пикселов усредняем, если хоть один пиксел вылетает за указанный лимит - блок выбрасываем.

На моей тестовой 9-Mpix картинке (Nikon D800 "интерполированный в half") этот код работает 45-50 миллисекунд. Что для автобаланса белого как-то неприлично много.

Перепишем его тупо на SSE2:

Pages

Subscribe to blog.lexa.ru: все статьи