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

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:

Литий в самолете

lexa - 25/Дек/2012 11:35

Тема лития в почте (а точнее, в самолете) получила такое вот продолжение:

Где-то в середине ноября я затарился очередной пачкой литиевых енерджайзеров с прицелом на следующий летний сезон. Сегодня они приехали. Трекинг до Москвы - вот такой вот:

Судя по времени от Сингапура до России и по точке входа в Россию, ехало оно наземкой через Китай и Казахстан. Тот же отправитель весной - слал нормальной авиапочтой, т.е. на попытку маленько поэкономить это не похоже.

Такие дела.

LibRaw 0.15.0-Beta3

lexa - 24/Дек/2012 22:18
Вышла LibRaw 0.15-Beta3, доступна в обычном месте.

Никаких серьезных внутренних изменений нет, только поддержка новых камер:

  • Canon 6D и EOS M
  • Casio EX-ZR100
  • Fujifilm X-E1
  • Leica D-LUX6 and V-LUX4
  • Nikon P7700
  • Olympus XZ-2
  • Panasonic G5
  • Samsung EX2F
  • Sony RX-1

Ёж - птица гордая

lexa - 22/Дек/2012 20:40
Дети притащили с благотворительного аукциона

Хозяйке на заметку: Qt, OpenGL и PBO

lexa - 20/Дек/2012 13:34
В режиме записок: на этой проблеме впустую потерял дня два минимум, если не больше. Вот, чтобы никогда более, запишу.

Вот есть QGraphicsView, направленный в QGLWidget. Есть еще QGraphicsScene, у которой с помощью drawBackground() рисуем нужное нам (картинку).

Этот самый drawBackground() использует текстуры, одну или много, текстуры залиты через PBO.

Дальше - пытаюсь вывести на эту Scene другие объекты. Ну, как в документации написано, к примеру так:

QLabel *label = new QLabel("Bla-Bla");
scene->addWidget(label);
(ну чуть побольше кода, потому что прозрачность, возможность двигать, но смысл именно такой)

Результат:

  • Если объекты выводятся, окно открывается и т.п. до создания "моих" текстур (которые рисуются на фоне) - то все отлично.
  • Если все разлеглось так, что свои текстуры и PBO я создал до первого показа (даже не создания) объекта на Scene, то жопа, при добавлении элемента к сцене получаем такое: 
    texture upload failed, error code 0x502
И так пробовал, и сяк и об косяк, потерял не меньше двух дней (ну то есть - не работает, пытаемся создать свой пример, там работает, из примера переносим код к себе - не работает и так с десяток раз). И, внезапно, ответ нашелся:

Если вы работали с QOpenGLBuffer, то прежде чем отдать управление в Qt - сделайте ему release(). Иначе будет нехорошо.

И ведь натыкался я уже на подобное, но с VBO: если не отцепить их, то вообще ничего не работает.

Об эффективном использовании современных CPU

lexa - 16/Дек/2012 18:30

Практика вот к этой презентации:

Берем 36Mpix файлик с D800, распаковываем егонный RAW в 16-битный однокомпонентный битмеп, дальше начинаем процессить.

Процессим без "интерполяции", т.е. 4 пикселя исходного байера образуют один выходной пиксель (режим half_size у LibRaw/dcraw). Получаем такие вот времена:

  1. LibRaw::dcraw_process() плюс формирование RGBA-битмепа: 420ms.
  2. Перепишем этот самый dcraw_process() на SSE3, процессить будем в плавучке (с эмуляцией особенностей dcraw), выдаем такой же 8-битный RGBA: 110ms (и более-менее понятно где еще выиграть миллисекунд 20).
  3. Добавим в предыдущий суп еще: подсчет RAW-гистограммы и сохранение исходного float-битмепа нетронутым (и без дублирования по памяти), т.е. баланс белого и конверсию цвета делаем два раза, один раз для подсчета гистограммы результирующего файла, а второй раз - прямо на вывод. 180ms.
Это все был один поток. Распараллелим его:
  1. "распараллеленный dcraw_process": 130ms (так в RawDigger сделано, тамошний RGB render устроен именно так, но гистограммы и статистика в эти 130ms не входят, равно как и битмеп для показа там готовится иначе и потому дольше).
  2. "распаралеленный ассемблерный dcraw_process": не делал, ожидаю <50ms (потому что вариант с двойным вычислением, как следующий, но без гистограмм - 57ms).
  3. параллельная ассемблерная версия с гистограммами, сохранением float RAW: 75ms
Сравнивая последний вариант с последовательным C-шным, нужно понимать, что в C-шном варианте еще где-то 200ms придется на гистограммы и еще 200 на конверсию int16 - float. То есть реальное ускорение от SSE и параллельной обработки - раз в 10 (75ms против 800). И это оптимизированный C-шный, в LibRaw это место заметно пооптимизировано в сравнении с исходным dcraw.

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

О процессинге RAW: плавучка или целое

lexa - 14/Дек/2012 12:54
Обработка RAW в плавучке позволяет избавиться от артефактов вылета за диапазон, да и вообще получить более качественную картинку.

Тем интереснее обратные случаи.

Возьмем вот такой вот кадр:

Это D800 с его приколами в светах, вот на света и посмотрим.

Если обработать картинку dcraw (или LibRaw, которая дает побитово такой же процессинг, если автоматическое определение максимума отключить), то в светах в "середине верха кадра" мы увидим такое вот:

Про Mac и 32 бита

lexa - 11/Дек/2012 18:26

Ваяю потихоньку новый варез для фотографов (пока не скажу какой). Делаю его на Qt5, вот так вот решил.

В связи с этим встает вот такой вот вопрос:

  • Qt5 не билдится как Universal Binary, обещают починить, но там есть препятствие в лице v8 (насколько понял из чтения мейлинг-листов).
  • Qt5 поддерживает Mac OS X начиная с 10.6. Эта самая 10.6 вроде бы требует 64-bit capable CPU (это по комментариям в Qt-шном багтрекере, где обсуждают отсутствие UB). Хотя в Википедии пишут, что 64-bit only - только с 10.7
  • Посмотрел в статистике RawDigger: 32-битных Маков 1%. Не от числа вообще компьютеров а от числа маков. У меня, понятно, статистика смещенная и кривая, но какая уж есть.
Собственно, вопрос: а что будет, если я в мак-версии дропну 32-битность? Целевая аудитория вареза - фотографы, как обычно. Теоретически, это заденет модели 2006-го года и некоторые макмини 2007, но их же должен быть вот тот самый 1%?

По-моему, этот вопрос мы уже обсуждали в этом бложике "вообще", но может у кого есть объемная статистика?

Если в одном месте убудет, в другом - обязательно прибудет

lexa - 10/Дек/2012 14:11

Интересно, когда кулеры станут больше материнских плат?

P.S. mini-ITX как идея - очень понравилось!

О маках у фотографов

lexa - 08/Дек/2012 13:56

Статистика даунлоадов RawDigger 0.9.13 (в процентах)

OSRU (75% - россия+украина)EN (45% США-Канада, остальное - европа)
Windows, x645248
Windows, x323719
Mac1132

Забавно, да.

P.S. Сумма в последней колонке не совпадает т.к. дробные части разлеглись неудачно, .3, .4 и .3.

LibRaw 0.15.0-Beta2

lexa - 04/Дек/2012 18:07
По традиции, анонсирую LibRaw 0.15-Beta2

Полный changelog доступен у библиотеки в гнезде, а тут я остановлюсь только на самом существенном:

  • Поддержано 20 новых камер:
    • Canon: G15, S110, SX50
    • Fujifilm: F800EXR, XF1
    • Nikon: 1 J2, 1 V2, D600
    • Olympus: E-PL5, E-PM2
    • Panasonic: FZ200, GH3, LX7
    • Pentax: K-5 II, K-5 IIs, K-30, Q10
    • Sony: SLT-A99, NEX-5R, NEX-6
  • RawSpeed может использоваться не только для байеровских данных, но и для полноцветных (3-цветные DNG, sRAW).
    Правда если вы захотите использовать эту фишку, то вам придется запатчить RawSpeed. Тот же патч положен в дистрибутив LibRaw (в каталоге RawSpeed).
    Пользы от RawSpeed достаточно много даже для нежатых DNG: к примеру, 60-мегабайтный 3-цветный нежатый DNG распаковывается за 130мс родным кодом LibRaw и за 70мс - при помощи RawSpeed.
  • В API добавились флажки, позволяющие понять - использовалась ли библиотека RawSpeed, а если да, то к чему это привело.
  • В очередной раз перебраны потроха (интересно только тем, кто в них копается, сам LibRaw API не изменился)
    • В 0.15-Alpha-Beta1 в imgdata.rawdata были два указателя: raw_image указывал на буфер с байеровскими данными, а color_image - на буфер с 4-компонентными RGBG. Ну то есть для байеровских RAW первый был не нулевым, а для полноцветных - второй.

      В Beta2 этот самый color_image ращеплен на два: color3_image ненулевой если в буфере (на который он указывает) лежат 3-компонентные данные, а color4_image - если данные надо рассматривать как 4-компонентные.

    • Введенный в Alpha4 параметр imgdata.sizes.raw_pitch (шаг строк в RAW-буфере) теперь в байтах, а не в пикселях. И один и тот же raw_pitch используется для доступа к imgdata.rawdata.raw_image, color3_image, color4_image
    Кому интересно совсем в деталях - читайте исходник LibRaw::raw2image() и понятно будет все.

Pages

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