суббота, 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.

пятница, 17 июня 2016 г.

Пингвин-фотолюбитель: 3. Панорамы

Для склеивания панорам нам понадобится программа с гордым именем Hugin. Имя действительно гордое, ибо дано в честь Хугина — одного из воронов Одина.

На КДПВ, конечно, не сам Хугин, а некий современный его сородич. Будем считать, потомок.

Устанавливать программу я рекомендую опять же свежую версию из PPA — «ppa:hugin/hugin-builds». На момент написания поста актуальна версия 2016.0.0. Вообще-то, тут у меня накладочка — Hugin отказался заводиться на виртуалке, как свежий, так и из основного репозитория. Судя по всему, ему не хватило драйверов видеокарты. Так что гарантировать, что свежая версия работает под Linux Mint лучше старой, я не могу. Скрины будут с моей основной системы, т.е. Gentoo.

RAW-файлы Hugin, к сожалению, читать не умеет, поэтому склеивать будем из 16-битного TIFF, предварительно полученного посредством Darktable.

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

Пингвин-фотолюбитель: 2б. Краткое примечание к краткому замечанию

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

среда, 15 июня 2016 г.

Пингвин-фотолюбитель: 2а. Краткое замечание к предыдущим сериям

Как я уже говорил, «проявку» RAW можно делать и в пакетном режиме — из командной строки, например, посредством UFRaw. Более того, можно натравить на RAW-файл и ImageMagick, а следовательно — мой скрипт, описанный в предыдущем посте. Впрочем, ImageMagick препоручит конвертацию консольной версии UFRaw.

А теперь я хочу продемонстрировать, почему так делать не надо.

Пингвин-фотолюбитель: 2. Командная строка и пакетная обработка

Коротко о главном: главный обработчик изображений из командной строки, равно как и в пакетном режиме, у нас по прежнему пакет ImageMagick. КДПВ справа взята поиском по его названию в «картинках Google», помимо демонстрации некоторых возможностей там и пингвин присутствует.

Кроме того, нам понадобятся минимальные знания оболочки GNU Bash и замечательная утилита для работы с данными EXIF (Exchangeable Image File Format — стандарт, позволяющий добавлять к изображениям метаданные, в первую очередь, когда и чем снято) — exiftool.

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

понедельник, 13 июня 2016 г.

Пингвин-фотолюбитель: 1. «Проявка» RAW-файлов

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

К сожалению, в репозиториях Linux Mint находится довольно древняя версия Darktable — 1.4, поэтому я рекомендую добавить PPA «ppa:pmjdebruijn/darktable-release» с последними стабильными версиями и устанавливать оттуда (информация взята с официального сайта). Старой версией тоже можно пользоваться, но новая лучше. Актуальная версия, о которой и пойдет речь — 2.0.4.