вторник, 2 июня 2020 г.

Hugin: перевод документации

Перевожу потихоньку документацию по Hugin.

Сама документация здесь — https://wiki.panotools.org/Hugin.

Перевод — https://github.com/shikhalev/hugin_doc_ru/wiki/Hugin.

  1. Объем там довольно большой, так что желающие присоединиться — welcome.
  2. Вики GitHub'а — не самый лучший движок для такого перевода, так что если кто порекомендует более удобный сервис, было бы интересно.
  3. В целом, мне не очень нравится оригинал... Он местами устаревший, местами малосогласованный, местами просто корявый. Так что если будет интерес, в дальние планы можно поставить написание вменяемого руководства.
  4. Отдельная боль — состояние локализации самой программы, надо бы тоже поучаствовать...

пп. 3,4 я точно в одиночку не потяну, а вот если будут еще желающие — с удовольствием.

пятница, 17 января 2020 г.

Новый модуль Darktable — «Уровни RGB»

Продолжаю изучать новые возможности Darktable 3.0. Пробежался по некоторым новым модулям, пока не впечатлен, но кое-что интересное нашлось. Модуль называется «Уровни RGB» и делает, в общем, то же самое, что и старый модуль «Уровни» (правда, без полностью автоматического режима), но с возможностью работы по отдельным каналам красного, зеленого и синего. Что это дает на практике, сейчас и рассмотрим.


вторник, 14 января 2020 г.

Новая базовая кривая в Darktable

Начинаю потихоньку изучать новые возможности в Darktable 3.0... Сегодня — довольно спорное (судя по форумам, как минимум) нововведение в настройках базовой кривой — «Сохранение цветов».

Чтобы составить собственное мнение, я взял несколько своих фотографий с настройками, отличающимися только базовой кривой (прочие настройки — это авто-уровни и локальный контраст по умолчанию, см. пост «Darktable — (не очень) быстрый старт»). Сюжетно фотографии разные, и новая настройка проявилась на них тоже по разному, подробности далее... Во всех случаях я сделал три варианта:

  • базовая кривая отключена;
  • базовая кривая включена, сохранение цветов отключено;
  • базовая кривая включена, сохранение цветов включено в варианте по умолчанию (других вариантов я делать не стал, поскольку там уже отличия на грани различимого).

Все снимки сделаны на Canon EOS 77D, базовая кривая — Canon EOS по умолчанию (не альтернативная). Как поведет себя новый механизм на других камерах с другими базовыми кривыми — не могу знать.


суббота, 11 января 2020 г.

Rack — основа веб-фреймворков в Ruby

Оригинал этой статьи опубликован в журнале «Системный администратор» №5 (150) за май 2015. Прошу обратить внимание на год — какие-то моменты могут расходиться с современными версиями языка и библиотек...

Библиотека Rack — простой объектный интерфейс для написания веб-приложений.

Слово «rack» в английском языке имеет множество значений, включая такие, как «пытка» и «разрушение»... Однако, надо полагать, название рассматриваемой библиотеки произошло от другой группы смыслов: «стойка», «штатив», «каркас» и т.д. Rack обеспечивает простой и в то же время удобный интерфейс, обеспечивающий взаимодействие между веб-сервером и приложением, позволяя программисту сосредоточиться исключительно на логике последнего.

Этот интерфейс достаточно низкоуровневый и не ограничивает разработчика каким-либо заранее заданным способом огранизации приложения и высокоуровневыми абстракциями. Соответственно, он и не предоставляет таких абстракций — это уже дело фреймворков, которые работают поверх него: Rails, Sinatra и других.

Darktable 3.0

Вышел. Пока общее ощущение, что отличия от 2.6 не принципиальны, надеюсь в ближайшее время разобраться с ними подробнее. Пока понравилось отображение системных (неотключаемых) модулей в истории и тайм-лайн в нижней панели в режиме обзора. Хотя, будет ли все это реально полезно — пока не понятно. Документации еще нет, впрочем базовые вещи от версии 2.6 недалеко ушли.

суббота, 21 сентября 2019 г.

Пингвин-фотолюбитель: 6. Darktable — (не очень) быстрый старт

Со времени моего прошлого поста про Darktable прошло, страшно подумать, три с лишним года. За это время и инструмент вырос (версия 2.6.2 сейчас у меня вместо 2.0.4), и я научился им лучше пользоваться.

Кстати, за это время вышла официальная сборка Darktable под Windows. Если кому не хочется пиратить Lightroom, а с винды не слезается — пользуйтесь. Правда, про стабильность/надежность ничего не знаю.

А еще я недавно с удивлением и радостью обнаружил в сети неплохой перевод «Руководства пользователя Darktable». Там по версии 2.4, но от 2.6 оно мало отличается, к тому же всегда в спорных моментах можно обратиться к актуальному англоязычному мануалу. Перевод же от всей души рекомендую в качестве обзора возможностей (и особенностей) программы. В дальнейшем я буду ссылаться на обе версии документации в виде «Термин[ru/en]».

Итак. Настоящим постом я хочу рассказать, какие я использую настройки для уменьшения телодвижений в процессе обработки фотографий, и какие же движения никто не отменял. Сразу скажу, что это а) мой личный опыт, б) только базовая обработка. Повторять страницы мануала нет никакого желания, а если говорить об осмысленном применении всех возможностей, то и компетентности.

среда, 17 июля 2019 г.

Поиздевался над железками

У меня было два HDD, два SSD, два внешних USB-диска (HDD) и сколько-то SD-карт. Не то, чтобы все это было нужно протестировать, но раз начал коллекционировать цифры MB/s, нужно идти в этом своем увлечении до конца. Единственное, что меня беспокоило — это флэшка-брелок. В мире нет ничего более бессмысленного и редко используемого, чем флэшка-брелок.

В общем, руководствуясь скорее бессонницей, чем необходимостью, замерил скорости чтения/записи для нескольких девайсов, которые оказались под рукой (ну и тех, что и так в корпусе компьютера). В первую очередь меня интересовали скорости имеющихся SD-карт, а также влияние на эти скорости USB-хаба и кард-ридера (у меня их два разных).

Способ тестирования

Замеры делались следующими командами (первая для записи, вторая для чтения):

# dd if=〈файл на tmpfs〉 of=〈файл на целевом устройстве〉 bs=1M count=1K oflag=sync
# sync; echo 3 > /proc/sys/vm/drop_caches ; dd of=〈файл на tmpfs〉 if=〈файл на целевом устройстве〉 bs=1M count=1K oflag=sync

Сам этот гигабайтный файл предварительно был сгенерирован из /dev/urandom посредством все того же dd. Непосредственно брать из /dev/urandom теоретически было бы лучше, но увы, он оказался медленнее, чем SSD. Использовать /dev/zero и /dev/null я не стал во избежание каких-нибудь оптимизаций со стороны системы.

Указанные команды выполнялись по несколько раз для каждого устройства, пока не начинали давать более-менее стабильный результат (стабильность определялась на глаз), после чего последние пять таких стабильных результатов усреднялись и округлялись до целых мегабайт. О некоторых интересных нестабильностях я напишу ниже. Отмечу, что в результатах десятичные, а не двоичные мегабайты, т.е. 1 MB = 1 000 000 B, впрочем, в стандартах и характеристиках от производителя обычно указываются они же.

Disclaimer: описанное в этом посте не является корректным тестированием и сравнением чего бы то ни было — очень многое делалось на глаз, а тестируемые девайсы находились в совершенно разных стадиях износа и заполненности. Да и нагрузка 1GiB кусками по 1MiB не соответствует ни реальным кейсам, ни любимым тестам производителей и обзорщиков. Зато удобна. В общем, автор в курсе, автор не претендуэ. Автора интересовало исследование скопившихся у него девайсов в текущем состоянии, способом, худо-бедно соответствующим текущим задачам (не всем).

tl;dr: в целом, результаты соответствуют ожиданиям, а китайские бренды (ORICO и noname) проявили себя вполне неплохо.

понедельник, 4 марта 2019 г.

Всё для людей!

Ковыряюсь тут с PostgreSQL и вот какую замечательную штуку обнаружил...

Собственно, про существование «updatable views» я знал, и давно. Но пока не доводилось использовать. И я думал, что для того, чтобы они заработали, нужно прописывать правила для всех действий. Однако нет — простые представления делаются изменяемыми автоматически, т.е. пишем, например:

... и всё, этого достаточно — можно обращаться к представлению something так же, как к таблице — вставлять, изменять, удалять по id.

Отдельно хочу обратить внимание на индекс с выражением where — он контролирует уникальность поля, но на записи с пометкой удаления этот контроль не распространяется, т.е. для того, кто работает с представлением, их как бы нет, без скрытых эффектов. И да, если мы попробуем запросить данные из something с сортировкой по name, при достаточно большом количестве записей этот индекс будет задействован, проверено.

Для полного счастья остаётся один штришок — таки переопределить одно правило:

Теперь удаление через представление будет лишь ставить пометку удаления в реальных данных.

Что это нам даёт? Например то, что мы можем дать «обычному» пользователю БД (скажем, тому, под которым ходит веб-приложение, находящееся в страшном и опасном диком интернете) права на представление и не дать непосредственно на таблицу, таким образом слегка себя обезопасив от некоторых непоправимых действий. Особенно, если это не просто приложение, а открытое API. А админка пусть ходит под более уполномоченным пользователем.

Почему это нельзя сделать на уровне приложения? Ну... Можно. Но мне представляется, что вопрос, как обрабатывать логическое удаление — через реальное удаление, или же через пометку, должен решаться на уровне хранения, а прикладной уровень стоит от него абстрагировать.

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

среда, 31 мая 2017 г.

Загадочный режим «P»

Две съемки, оба раза, чтобы не мудрствовать с настройками, поставил «P» и auto-ISO. Объектив один и тот же — Sigma 18-300 Contemporary. В первом случае почти все кадры сделаны с выдержкой 1/80 (у этого объектива стабилизация очень хорошая), открытой или почти открытой диафрагмой и ISO 100–200 (в особо темных случаях до 640). Во втором: 1/400–1/500, f/8–f/11 (!) и, соответственно, ISO от 1000 и выше (чаще ближе к 1600). Нет, стаб я во втором случае не отключал, все настройки были те же.

В общем, чудит автоматика иногда. Хотя тушка (Canon 600D), конечно, старовата уже...

четверг, 23 июня 2016 г.

Пингвин-фотолюбитель: Содержание

Вроде бы основные вещи, которые хотел написать об инструментарии фотолюбителя под Linux, я написал. Может быть, цикл и продолжится, особенно если появятся вопросы от читателей, но пока — предварительный итог.

Пингвин-фотолюбитель: 5. Стекинг

Первым делом, пожалуй, сошлюсь на источники: ключевым по теме данного поста стал англоязычный пост Barry Grussling — «Focus Stacking in Linux»; прочая информация получена из официального руководства enblend/enfuse. Собственно enfuse и будет нашим главным инструментом для стекинга.

Что такое стекинг? Это когда мы делаем несколько кадров одного и того же, в общем случае — с разными параметрами, а затем хитрый алгоритм собирает нам результирующую картинку. Например, если мы сделаем несколько снимков с разной экспозицией, то можем получить в результате что-то очень похожее на результат сведения HDR, о котором я говорил в предыдущем посте. С той лишь разницей, что собственно HDR-изображения (т.е. с динамическим диапазоном более 8 бит на канал) мы не получим, сразу приведение к 8-битному виду.

Кроме стекинга по экспозиции рассмотрим еще уменьшение шумов и стекинг по фокусу.

суббота, 18 июня 2016 г.

Пингвин-фотолюбитель: 4. HDR

HDR — High Dynamic Range — термин для обозначения технологий работы с диапазоном яркости, который превышает стандартный. Относительно любительской фотографии этим термином обычно обозначают создание HDR-изображений из нескольких снимков обычного диапазона, а также их сведение к стандартному RGB разными специфическими методами. Картинка сверху поста демонстрирует удачный пример применения таких технологий.

Строго говоря, RAW-файлы и 16-битные TIFF сами по себе являются HDR-изображениями, поскольку их глубина цвета превосходит стандартную однобайтную. Однако и ее как правило недостаточно, чтобы на одном снимке запечатлеть и яркое небо (не допустив пересветов) и какие-нибудь ближние затемненные участки. Кроме того, обычные мониторы все равно этот диапазон полностью отобразить не способны. В отличие от человеческого глаза, который очень хорошо адаптируется, рассматривая разные участки общей картины... К счастью, мозг при восприятии зрительной информации тоже хорошо адаптируется, и мы можем специальными программными методами построить картинку, которая будет выглядеть более естественно, чем просто взятая с камеры фотография. Ну, или совсем неестественно и сюрреалистично, что тоже можно использовать в качестве выразительного средства.

Итак, нас сегодня интересует программа Luminance HDR.