Немого кино уже нет, звукового кино еще нет....

lexa - 26/Янв/2013 09:44

Вот есть некая программа, которая активно использует OpenGL.

Используется Qt5 и все было бы хорошо, если бы не моментики:

  • QWidget::showFullScreen() не работает на Mac OS X 10.6
  • Курсор в форме руки - остается таковым и при выносе мыши за окно программы (тоже на Mac, на винде все нормально).
По первому случаю - я засабмитил баг, прямо вот 1-го января. Но он все еще в состоянии Not Evaluated (что неудивительно, если посмотреть на график количества багов в Qt за последние 30 дней). По второму - вроде нашел багрепорт, им как-то занимаются.

Ладно, у меня ничего специфического от Qt5 нету, собираем все то же самое на Qt 4.8.4. Работает (ну, пришлось поменять QOpenGLProgram на QGLProgram и так далее в том же духе, но изменений - мало).

Но:

На операционках, запущенных под VMWare (и Windows и Mac) - валится в QGLFunctions::initializeGLFunctions(), судя по отладчику - GL-контекст в этом месте нехорош, дальше не разбирался).

При этом, Qt5 на этих же виртуальных машинах - работает, возможностей тамошнего OpenGL вполне хватает.

На настоящих железных компьютерах с настоящим OpenGL - версия собранная с 4.8 - работает, а неприятные мне баги на маках - отсутствуют. Фулскрин работает, курсор меняет форму как надо.

Ну и как с ними жить? Баги Qt5 явно быстро не починят. Багу Qt 4.8 - скорее всего тоже не починят. Не, ну я могу gl....() сам порезолвить, но обидно же ж.

Про гарантию OCZ

lexa - 25/Янв/2013 16:16

Обновление от 01.11.2014: У OCZ теперь есть пункт приема в Химках

Как нам писали читатели нашего бложека "У OCZ гарантия действует даже при покупке с ебая".

Я решил проверить (у меня был сдохший 3.5" OCZ Vertex2, бумажки от которого были утеряны, но 5-летняя гарантия еще не закончилась) и вот что получилось:

1. Создал Support ticket (по ссылке с этой странице, строчку "Поддержка в России, нажмите здесь" сначала не заметил) в котором написал все как было (OCZ Vertex 2,внезапно сдох, очень страдаю)

2. В течение примерно одного дня мне был создан RMA Case и присланы инструкции: возьмите диск без упаковки и всякой прочей ерунды, упакуйте, вышлите в Голландию по такому-то адресу, на конверте напишите RMA Number

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

4. На следующий день после получения мой диск выслали DHL-ем. Из Роттердама в Амстердам, примерно. И еще через день или два он в этот Амстердам дошел, за этим процессом я с увлечение следил трекингом DHL-я (и присылаемыми на E-mail нотифаями)

5. После чего - все заглохло больше чем на месяц. Я даже написал в поддержку OCZ перед новым годом, мне ответили "доставку мы аутсорсим и ничем конкретным помочь не можем". Но очень участливо, и, по всей видимости, если бы замена не приехала в более-менее разумное время (2-3 месяца) - выслали бы еще раз.

6. А сегодня - оно взяло и приехало. Просто в родное почтовое отделение, обычной почтой.

Короче, замена - работает. Присылают - ровно ту же модель, что и сломалась, сделать таким способом апгрейд со старого вертекса на новый - не выйдет. Понятно, бумажки лучше не терять (так бы я поменял в Москве, быстрее и бесплатно), но если утеряны, то оплачивать придется только пересылку в Европу. Да, таможенную стоимость мне указали реальную (197 евров).

P.S. Самый первый сдохший OCZ Vertex я разобрал, чтобы узнать что у него внутри (никаких бумажек исходно не было, с eBay). Теперь вот знаю что зря.

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) не пользуется):

Pages

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