суббота, 6 марта 2021 г.

О ресайзе PNG на примерах

Недавно мне задали такой вопрос:

Иван, как-то довелось делать resize png-картинки в Gimp. По сравнению с Photoshop качество хуже. Можешь тут подсказать?

Фотошопа у меня нет, сравнить не могу, поэтому попробую рассмотреть вопрос несколько по другому — какие способы ресайза мы имеем в Linux, пусть не «из коробки», но с минимальными трудозатратами. И что нам со всем этим богатством делать...

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

Для начала, чтобы много не писать о сути проблемы вообще, сошлюсь на хабрастатью «Ликбез: методы ресайза изображений». Она старая, но в плане основ и теории достаточно хорошо всё описывает. Более подробно, но на английском, можно почитать на сайте ImageMagick: статьи «Resampling Filters» и «Resampling by Nicolas Robidoux». Если Photoshop не использует новейшие достижения искусственного интеллекта (это не шутка, различные AI-методы сейчас активно применяются в обработке изображений), то правильный выбор фильтров и параметров позволит получить результат не хуже.

Что же касается формата PNG, то тут есть два соображения: во-первых, область применения — как правило, в PNG сохраняют не фотографии, а изображения с чистыми цветами и четкими границами, а во-вторых, применимость его к финальному результату — запросто можно при уменьшении картинки получить файл большего объема...

В общем, я взял два типичных, как мне кажется, случая, когда применяется именно этот формат: уменьшение скриншота (небольшое, чтобы можно было говорить о читаемости) и увеличение иконки (тут — в разы). Экспериментировать я буду с применением GIMP и ImageMagick.

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

суббота, 6 февраля 2021 г.

Нетехническое, зато про фото

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

Тем не менее, некоторые задачи телефон покрыть не может в силу чисто физических ограничений, и вычисления тут мало помогут, если помогут вообще. Задачи эти, конечно, интересны далеко не всем, но многим, а насколько многим — это как раз вопрос... Поводом для некоторого оптимизма для меня стал, как ни странно, анонс Sony α1 — обратило на себя внимание постоянное подчеркивание такой инновации, как автофокус по глазам птиц. Понятно, что сама Sony α1 относится как раз к сегменту очень дорогих исключительно для профи, но анонсы и реклама флагманов всегда работают на линейку в целом, так что можно полагать, что маркетологи Sony действительно обратили внимание на определенный сегмент, а именно — любителей бёрдвотчинга и съемок природы вообще. Сегмент поменьше, чем (в доковидные времена) сегмент казуальных туристов, на которых ориентировалась реклама любительских камер до сих пор, но, видимо, достаточный, чтобы в Sony о нем задумались.

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

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

Фанаты телефонофото (а такие есть) могут возразить, что вот еще чуть-чуть и вычислительная фотография разовьется до такой степени, что сможет закрыть и эту нишу. Нет, ребята, съемка дикой природы не может обойтись без габаритных телевиков — и не надо про «телеобъективы» в современных смартфонных сборках, не дают они 300-400mm ЭФР, что вообще-то самый минимум — и без коротких выдержек одним кадром, что требует более-менее большой матрицы (что, в свою очередь, увеличивает габариты потребных объективов), поскольку эта самая дикая природа шевелится быстро и непредсказуемо, более-менее приемлемые снимки начинаются при выдержках от 1/400s. Вычислительная фотография тут может, конечно, разгуляться — если ей дать исходники с хорошей видеокамеры (видеовозможности вышеупомянутой Sony α1 как раз достигли этого уровня), но никак не с телефона.

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

Всем бобра.

воскресенье, 6 декабря 2020 г.

Новая железяка

Приобрел на Али очередную железку, сегодня руки дошли проверить.

Железка называется UTHAI G01 и представляет собой USB-хаб с кардридером для установки в системный блок на место дисковода (коих уже давно никто не использует, а место в корпусах по прежнему отводят). Интересна эта штука тем, что в отличие от большинства подобных у нее кардридер работает действительно через USB 3.0, а не 2.0. Чаще всего подобные устройства не имеют собственного хаба, USB 3.0 тупо выводят с кабеля, а кардридер цепляют на отдельный кабель USB 2.0; здесь же на входе только один синий кабель (и плюс питание — многопиновый разъем для SATA).

Хоть я его и покупал недавно (заказывал на 11.11), сейчас по ссылке выше «товар недоступен». Впрочем, на Али есть аналоги (можно поиском по «33S50-RTK»), но не совсем такие же — без подписей почему-то — отличается ли что-то сущностно, я не знаю, цены примерно похожи.

Итак, оно дошло, установлено, работает. Проверять я решил так же, как это делал с различными носителями в посте «Поиздевался над железками», т.е. померял так же посредством “dd” скорости чтения и записи. Для теста использовал рабочую SD-карту Transcend и внешний диск ORICO MagiBox, которые уже тестировал ранее на этом же компьютере, так что результаты должны быть максимально адекватны для сравнения. Поскольку на проверяемом девайсе есть порт USB Type-C, его я тоже попробовал. Замеры показали (в MB/s):

 Запись  Чтение
Карта SDXC Transcend посредством кардридера 22 95
ORICO MagiBox через USB Type-A 19 136
ORICO MagiBox через USB Type-C 12 40

Последняя строка наводит на некоторые подозрения, не правда ли? Я залез в KDE Info Center, устройства USB — и правда, подключение по Type-C пошло через USB 2.0 Hub. Для полной ясности проверил телефоном, как с этих портов идет зарядка: с Type-A — 1300mA, с Type-C — 330mA... Телефон, правда, был заряжен на 70% и явно брал не полную доступную мощность, но по разнице видно, что и по питанию Type-C в данном устройстве работает по стандарту USB 2.0.

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

А теперь вернемся к первой строке. Тут тоже удивление, но уже приятное — скорость чтения 95MB/s вместо 80MB/s ранее. Как, почему? Не знаю... Вообще, в планах есть тестирование аналогичное прошлому, но на копировании набора реальных равок, поскольку выяснилось, что там результаты порядком отличаются от синтетики через “dd”. Надеюсь в скором времени собраться и проверить теперь уже и новый кардридер.

Из недостатков именно кардридера пока могу отметить только то, что карточки нужно вставлять кверх ногами, т.е. картинкой вниз. У MagiBox, кстати, та же фишка — может, у них там в Китае так принято?..

PS. Что печально, но не вина собственно кардридера: во-первых, у меня на материнской плате всего один вывод внутреннего USB 3.0, то есть подключить пришлось вместо выводов USB на корпусе, которые теперь не делают ничего, получается; во-вторых, место под флопповод явно проектировали «на отвали», видимо, потому что ими все равно давно никто не пользуется — очень неудобно было прикручивать, при том, что в остальном корпус весьма неплох, и размещение внутри продумано; ну, и в-третьих, было бы удобней, если б он питался от молекса — свободный конец питания SATA у меня нашелся, но предпоследний и неудобно расположенный, а вот молексов дополна, и они не используются.

вторник, 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), конечно, старовата уже...