Да, ты умрешь

#music

Да, баян, и что?

youtube.com/watch?v=yydNF8tuVmU

#cinema #video

This Invention Made Disney MILLIONS, but Then They LOST It!

Да, заголовок кликбейтный, но отчасти справедливый.

В современном кинопроизводстве широко используется техника зелёного экрана. Концептуально подход прост: снимаем актёров и действие на фоне цвета, который есть только на фоне, а потом при обработке удаляем его и получаем только передний план, к которому можно подставить любой фон. К сожалению, у этого подхода есть ряд недостатков. Именно, отделить цвет экрана от всего остального иногда поразительно сложно. У нужных элементов могут быть цвета, близкие к цвету экрана, отделение экрана от тонких деталей типа волос крайне сложно и толком не автоматизируется, на блестящих объектах могут быть отблески экрана, отделение экрана в присутствии элементов, которые размыты из-за движения, затруднено. Ну и из-за сложности в обработке с зелёным экраном крайне сложно снимать полупрозрачные вещи.

Несколько десятилетий назад Disney выпустил фильм, в котором при помощи монтажа был подставлен другой фон для съёмок. При этом актёры активно двигались, а некоторые носили полупрозрачные элементы одежды. Тем не менее, в картинке не было присущих гринскрину артефактов. Как же они это сделали?

Для того, чтобы добиться этого результата, создатели фильма фактически сделали более точную вариацию на тему зелёного экрана. Именно, они освещали фон лампой, работающей на парах натрия. Отличительной особенностью спектра натрия является то, что в видимой части спектра его излучение сконцентрировано в очень узкой полоске возле света с длиной волны 589 нанометров. Другие объекты на сцене могут всячески отражать, преломлять и поглощать (в том числе и частично) свет, но на длину электромагнитных волн это не влияет. А это значит, что для того, чтобы отделить фон от всего остального, достаточно отфильтровать из картинки свет со специфичной длиной волны.

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

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

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

Ну, допустим, #ml (#meme)

Source

#prog #rust #itsec

Security advisory for the standard library (CVE-2024-24576)

TL;DR: если вы не вызываете bat-файлы на Windows с пользовательскими аргументами, то вас это не касается.

В Windows аргументы командной строки передаются в процессы не массивом, а цельной строкой, парсить которую процесс должен сам. В Windows API команда для запуска процессов обрабатывает .bat-файлы как вызов cmd.exe /c [bat file], и cmd разделяет строку на аргументы немного иначе, чем libc. Так как это API используется в std в Command, это поведение протекает в пользовательский код: при запуске Command с .bat-файлом с непроверенными аргументами из-за того, как cmd обрабатывает аргументы, можно добиться исполнения произвольного shell кода.

"Игра престолов" — хороший сериал.

Говорят.

#prog #rust #article

Improve performance of you Rust functions by const currying

TL;DR: иногда для конкретных значений аргументов код может быть оптимизирован лучше, чем в общем случае. Вместо того, чтобы выделять руками оптимизированную версию, можно сделать вариант функции, которая принимает аргумент (или несколько) как const generic и выставить в публичный интерфейс функцию, которая бранчится по этому аргументу и для значений, способствующих оптимизации, вызывать функцию с const generic.

Автор также предлагает процедурный макрос, который позволяет автоматизировать написание нужного для этого бойлерплейта

Тупой #лингво #meme про капусту

#prog #rust

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

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

При разработке большого проекта избежать дублирования зависимостей сложно. Это не является неизбежностью, поскольку cargo старается по возможности выбирать одну версию библиотеки, которая удовлетворяет всем ограничениям на версию, но всё же это порой случается — особенно, если в зависимостях где-то ограничение на версию сверху. Иногда на это могут быть обоснованные причины — например, когда используются две разные мажорные версии библиотеки, у которых из общего в основном только название — но чаще это просто увеличивает технический долг.

Убирать дубликаты зависимостей не всегда так же просто, как просто вызвать cargo update (говорю по своему опыту), но и оставлять их в долгосрочной перспективе не стоит. Не всегда можно сразу одним разом убрать дубликаты, но даже если и можно, то это часто может стать блокером для внесения других изменений в кодовую базу. С другой стороны, если за этим не следить, новые изменения могут добавить новые дубликаты зависимостей, только увеличивая время компиляции и технический долг.

Один из способов контролировать технический долг — это зафиксировать его состояние и убедиться, что он не растёт. Конкретно в данном случае это решение довольно простое: вынести список дубликатов зависимостей в отдельный файл, который включается в репозиторий, и вставить в CI проверку, которая будет сравнивать этот список с реальным списком дубликатов.

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

Самый насущный из практических вопросов: куда положить нужный код? Возможно, наиболее идеологически правильным было бы отнести это в отдельную стадию внешнего линтинга, но это значит, что нужный код нужно или иметь в качестве уже собранного бинарника и каким-то образом подтягивать его, или собирать во время сборки. Оба подхода усложняют CI, особенно первый. Всех этих хлопот можно избежать, если включиться в шаг, который уже подразумевает компиляцию кода и его запуск. Именно, нужный код можно поместить в тесты, и он будет автоматически запускаться во время cargo test. В этом случае код для проверки будет запускаться автоматически для каждого нового изменения (вы же запускаете тесты в CI, верно?) и завалит тесты в случае изменения списка дубликатов, достигая нужной нам цели.

Второй по важности момент — как именно получать список дублирующихся зависимостей. Для этого можно использовать cargo, и если вы разрабатываете проект на Rust, почти наверняка вы уже его используете, поэтому это не приносит новых зависимостей для сборки. Нам понадобится cargo tree (команда доступна с версии cargo 1.44) с ключом -d (--duplicates). Задача кажется простой, но тут есть пара тонкостей, о которых стоит упомянуть. ⬇️