RawDigger 0.9.17 RC1

lexa - 25/Май/2013 21:32

Граждане фотографы!

Если вы за компьютерами - потестируйте пожалуйста RawDigger 0.9.17 RC1: берите настоящую 0.9.17, тестирование RC1 закончено.

Изменения:

  • Новый параметр настроек:

    Data Processing -> Selection/Sample stats: discard abnormal pixel values

    Если настройка включена, то при подчете статистики по selection или Sample отбрасываются 10% самых больших и 10% самых маленьких значений. Это позволяет фильтровать шум (грязь, небольшие блики) на снимках мишеней.

  • Поддержка новых камер:

    Canon: 100D (Rebel SL1), 700D (Rebel T5i)
    Fujifilm: X20 и X100S,SL1000, HS50EXR
    Sony SLT-A58
    Nikon: 1 J3, 1 S1, Coolpix A, Coolpix P330, D7100
    Olympus XZ-10
    Panasonic G6
    Pentax MX-1

  • Exiftool обновлен до версии 9.30
  • sRAW/mRAW файлы Canon обрабатываются библиотекой RawSpeed т.е. открываются быстрее.
Исправлены ошибки:
  • Исправлена проблема с автоматической установкой уровня черного на 12-битных файлах Sony (A900 и подобные)
  • Исправлена ошибка: при изменении Preferences и нажатии кнопки Apply, обновление содержимого экрана работало только один раз, повторное изменение того же параметра и нажатие Apply не имело эффекта.
  • При обработке большого количества файлов (drop на иконку многих файлов на Mac) exiftool не запускается, если уже есть запущенный exiftool.

Подземный стук возвращается!

lexa - 25/Май/2013 10:22

Две недели после установки таймера в HPET все было хорошо. А вчера подземный стук вернулся, а сегодня - повторился.

С теми же симптомами:

  • Cron встал.
  • "часы стоят" - при запуске top и подобного что рефрешится по таймеру - не рефрешится.
  • named: POKED TIMER в логах
  • cat /dev/urandom >/dev/null не поднимает частоту процессора, так и лежит на 200 (это, вероятно, оттого, что таймер стоит и powerd не просыпается)
  • Пакеты роутятся
  • при подаче нагрузки (утренние бэкапы) - оно не просыпается нормально. Вот сегодня туда вылилось ~40Gb бэкапа (из 90) и скорость записи по smb упала практически до нуля, пришлось ребутить эту FreeBSD.
Ну добавил еще:
kern.eventtimer.timer=HPET
kern.eventtimer.periodic=1
Но надежды мало - больше двух недель не менялось ничего - и тут вдруг началось.

Ну память еще поменяю, хотя в данной машине это делается лапароскопией.

Но что делать то? По всем прочим признакам - машина нормальная, процессор процессорит, следов битой памяти (вроде падений на компиляции) не видать.

Кто виноват и что делать? Linux - не предлагать!

LibRaw 0.15.1

lexa - 24/Май/2013 23:07
Вот кто видел версию .0, чтобы сразу работала? Правильно, никто!

LibRaw 0.15.1:

  • Исправлен неверный расчет максимума данных для файлов Panasonic
  • Проверка на выход за пределы буфера в коде коррекции экспозиции

Берут где всегда

Вопрос: фильтрация данных со снимков мишеней

lexa - 24/Май/2013 09:40
А вот проведу опрос (в каментах)

На снимках мишеней для профилирования бывает лишнее. Грязь на мишени, грязь на матрице и так далее. Это дело принято фильтровать и в RawDigger такая фишка запланирована.

Понятно как фильтровать: оценить все значения в квадратике, посчитать среднее/дисперсию, все пиксели, не влезающие в "окно" значений - выкинуть, пересчитать по невыкинутым.

Есть два варианта определения окна:

  1. Все что не влезает в окошко по "сигмам". Ну там ±2σ - пущаем, остальное - не пущаем.
  2. Установить лимит в штуках. Ну там по 10% верхних и нижних значений - отрезаем.
Результат будет - в нормальных условиях (пылинка не занимает больше 10% площади патча) - примерно одинаковым.

А вот как понятнее?

LibRaw 0.15.0 Release

lexa - 23/Май/2013 17:13
LibRaw 0.15 уже давно используется в боевых проектах (скажем, в RawDigger), собственно я ее ради RawDigger и правил на ходу и она всегда была "релизного качества".

Пришла пора эту релизность формально закрепить, а версию 0.14 начать предавать забвению.

Вот наиболее важные изменения, суммированные по всем бетам:

Поддержка новых камер

  • Adobe DNG: поддержка Fast Load DNG (LightRoom 4.x), поддержка lossy-compressed DNG (LR 4.x, необходима сборка с libjpeg 6+)
  • Canon: G1 X, SX220 HS, EOS 5D Mark III, EOS 650D, EOS 1D-X, 100D (Rebel SL1), 700D (Rebel T5i),6D,EOS M,G15, S110, SX50
  • Casio: EX-ZR100,EX-Z8
  • Fujifilm: X-E1,X20, X100S,SL1000, HS50EXR,F800EXR, XF1, X-S1, HS30EXR, X1-Pro
  • Imacon Ixpress 39Mpix: Multishot-файлы
  • Leica: D-LUX6 и V-LUX4
  • Nikon: D4, D3200, D800, D800E,1 J2, 1 V2, D600,1 J3, 1 S1, Coolpix A, Coolpix P330, Coolpix P7700, D7100
  • Olympus: E-M5, XZ-2, XZ-10, E-PL5, E-PM2
  • Panasonic: G5, G6, DMC-GF5, FZ200, GH3, LX7
  • Pentax: MX-1, K-5 II, K-5 IIs, K-30, Q10
  • Samsung: EX2F, NX20, NX210, поддержка нового firmware NX100
  • Sigma: SD15,SD1, SD1 Merill, DP1, DP1S, DP1X, DP2, DP2S, DP2X (только в Demosaic-pack-GPL2)
  • Sony: SLT-A58, RX-1, SLT-A99, NEX-5R, NEX-6, NEX-F3, SLT-A37, SLT-A57

Изменения в API

Об одном известном макроассемблере

lexa - 20/Май/2013 17:20
Вот есть такая dcraw.c, а в ней есть такие вот две строчки кода:
  unsigned int *data,pad[128],p;
  ...
  while (len--)
      *data++ ^= pad[p++ & 127] = pad[(p+1) & 127] ^ pad[(p+65) & 127];
И все было ничего в gcc 2.x...4.7, а вот 4.8 компилирует это место неправильно.

Я даже посмотрел генерируемые ассемблеры, увидел что разные, но за 30 секунд не разобрался (потому что константы 1 и 65 у 4.8 становятся 2 и 66 и надо внимательно смотреть в каком порядке там что инкрементится).

Переписал так:

  while (len--)
    {
      *data++ ^= pad[p & 127] = pad[(p+1) & 127] ^ pad[(p+65) & 127];
      p++;    
    }
Помогло. Но осадок - остался.

Вопросов у меня, собственно, два три:

  1. Куды жаловаться на gcc Действительно UB? Но ведь есть такое естественное знание, что сначала вычисление правой части, а потом уже присваивание к левой. Это ж поимеет в куче мест.
  2. Правильно ли я понимаю, что пересечение множеств "Linux с пакетами собранными 4.8" и "Фотограф в RAW" крайне мало отличается от пустого множества?
  3. А не отличается ли это место в C и в C++?
P.S. Помимо баланса белого, который поминается в в багрепорте, отваливается еще и декодирование файлов с Sony DSC-V3, Sony F828 и, возможно, еще каких-то (у меня таблички декодер - камера нету)

P.P.S. Если отвалится какая-нибудь криптуха или там MPEG-декодер - я совершенно не удивлюсь.

И еще про GPON

lexa - 20/Май/2013 11:46
Спрашивали? Отвечаем!

Позвонил сегодня в МГТС-овский call-центр, на предмет пробный интернет перевести в настоящий и узнать пин-код от их "личного кабинета", дабы с тарифами потом самому играться.

Несмотря на то, что формально (как написано на сайте) нужны паспортные данные телефоновладельца, а иначе за пин-кодом велено идти в офис, эти паспортные данные у меня не спросили (а я их, блин, узнавал, трудился). А спросили:

  • Номер договора (он есть в тех бумажках, которые дают при подключении к GPON)
  • Адрес установки телефона
Такие дела.

Upd: личный кабинет у них а-ля МТС. И даже еще более чудовищный.

Upd2: сменить телефонный тарифный план из кабинета нельзя. Только в офисе. Пропала моя идея поэкономить 59 рублей в месяц (безлимитный телефон + 200Mbit стоят дешевле, чем 400-минутный телефон + 200Mbit), я разорен.

Гасите свет! Они лезут на свет!

lexa - 18/Май/2013 09:04

До недавнего момента все новомодные камеры на Fuji X-Trans имели одну схему "небайеровской" мозаики.

Но вот с новыми камерами уже не так: X20 и X100S имеют две новых (отличающихся от старой и друг от друга) схемы. Тоже 6x6, уже хорошо, могли бы и 7x7 сделать и 9x11.

Компания Fujifilm передает приветы авторам конверторов. Особенно приятно им будет, если они какую-то оптимальную схему интерполяции захардкодили (для скорости, к примеру). Ну захардкодят еще парочку, делов то.

Что думают авторы конверторов о компании Fujifilm я боюсь и предполагать....

Upd: они отличаются сдвигом. Т.е. пожертвовав 2-3 строчками/столбцами с краю - можно свести эту физику к одному и тому же.

Про расторжение контракта на Стрим

lexa - 15/Май/2013 10:09

До GPON у меня был стрим. С GPON, естественно, несовместимый. Пришлось удалять.

Расторжение договора оказалось простым и легким:

  • 29-го апреля я подал им заявление на расторжение и возврат бабла. В офис МТС около метро. Там удивились, но приняли и выдали чек на 0.0 рублей, у них такой способ регистрации заявлений.
  • 1-го мая в личном кабинете договор пометился как расторгнутый, неиспользованные деньги за часть месяца вернулись на счет в Стриме.
  • 13-го мая остаток денег на счету обнулился и вылезло показанное выше сообщение.
  • Вчера деньги упали на счет.

С учетом праздников - вполне оперативно.

Можно ли деньги не возвращать, а зачислить на телефон - я не выяснял. Стандартного заявления такого нет, а на счет - ничем не хуже.

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

P.S. Понятно, что МГТС - это тот же МТС. И вот интересно было бы посмотреть через годик на отчетность. Понятное дело, Стрим исчезнет вместе с медью. А вот станет ли клиентов на интернет больше (чем было у Стрима+МГТС на полгода назад) или меньше - интересно.

Про Canon 6D: китайские батареи

lexa - 13/Май/2013 16:13

Интересовались?

Отвечаем: батареи DSTE, на которых написано "чипованые, совместимы с 5D3/60D" (6D - не упомянут) - на самом деле совместимы и с 6D тоже. В том смысле, что камера не ругается, уровень заряда показывает и все прекрасно.

Брал у этого продавца (у него же брал для Oly OM-D, да и много для чего еще). Торговаться сильно не пробовал, процентов 8-10 он скидывает легко.

P.S. Несмотря на ужасные крики прессы и блоггеров про Почту России, прохождение посылок у меня затянулось не безумно. Вместо стандартных 4 недель из ЮВА получилось 5 (из Кореи) и 7 (из Сингапура). Конечно, 12 дней по москве - это перебор, даже с поправкой на праздники, но до лета я успел, хотя уже начинал нервничать.

Просьба к владельцам 5D Mark III

lexa - 11/Май/2013 10:17

Уважаемые владельцы 5D Mark III!

Не могли бы вы

  1. Снять любой кадр в режимах mRAW (sRAW1) и sRAW( sRAW2) /В скобках - как эти режимы называются на 5D2, не в скобках - как на 6D, а как на 5D3 - не знаю/
  2. Расшарить его через dropbox для lexa@lexa.ru
?

Мои границы не будут знать благодарности. И наоборот.

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

Заранее спасибо!

P.S. Когда мне хватит - я тут напишу апдейт. Update: достаточно. Спасибо!

P.P.S. Бага (не у меня) проявляется с 6D, но код обрабатывающий mRAW в этом месте един с 5D3 и хочется проверить и эту камеру тоже. Update: проблема только с 6D (проблема в RawSpeed)

Olympus OM-D E-M5: динамический диапазон

lexa - 10/Май/2013 11:08

В рамках изучения свежеобретенного Olympus OM-D E-M5 (ну и название!), проделал ему операцию по определению "фотографического динамического диапазона".

Использовалась та же методика, что и для EOS 6D. Более того, случайно получилось так, что результаты по этим двум камерам вообще сравнимы с некоторыми (минимальными) оговорками:

  • Дистанция съемки была та же
  • Размер (в пикселях) у Oly на ~10% меньше (по линейному количеству пикселов в каждом направлении)
  • ЭФР оптики, наоборот, на 10% больше (использовался 75/1.8, а на EOS 135/2).
  • Поэтому детали получились практически одного размера (в пикселях снимка).
Как следствие, результаты по ДД сравнимы при одном и том же dpi печати, т.е. если на отпечатке с EOS видны какие-то детали, то при том же ДД эти же детали будут видны примерно так же при печати на ~10% меньше по линейным размерам.

Перебивать большую табличку в блог мне было лень, поэтому результаты привожу в виде графика:

Линии на графике отвечают четырем размерам деталей в тенях:

  1. Шрифт 12pt (размер цифр на снимке - 30 пикселов), черным по серому, контраст 0.5EV
  2. Шрифт 18pt (~50 пикселов на снимке), черным по серому, 1EV
  3. Шрифт 30pt (~70 пикселов), белым по серому, 1EV
  4. Шрифт 30pt, белым по серому, 1.5EV
Как и для 6D, первые три диапазона построены для светов, где ни один канал в сером не насыщен, а четвертый - для такой экспозиции светов, когда зеленый уже начал выбиваться (впрочем, разница в этом месте - всего 0.3EV).

К точкам на графике следует относиться не как к абсолютной истине. Снимки оцениваются глазами, по критерию читаемости, ошибка в +-снимок (т.е. 0.3EV) вполне вероятна.

О чем мы думаем глядя на эту кучу битого кирпича? А вот о чем:

Pages

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