Forwarded from Tensor Banana
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
Hunyuan video2video и image2video
Эти воркфлоу используют HunyuanLoom (flowEdit) - эта штука преобразует входное видео в размытый движущийся поток (почти как controlnet). Обычный denoise тут не нужен, с ним картинка будет кипеть.
Для сохранения черт лица нужна лора на лицо. Без нее лицо будет другое. Куча лор на персонажей есть на civitai.
## video2video
Это самый простой воркфлоу, получается лучше всех. Использует HunyuanLoom (flowEdit). Для создания видео с Кеану использовал: skip_steps: 11, drift_steps: 15. Лора: 0.95 довольно хорошо передает его лицо под любым углом.
лору на Кеану: https://civitai.com/models/1131159/john-wick-hunyuan-video-lora
Воркфлоу video2video: https://github.com/Mozer/comfy_stuff/blob/main/workflows/hunyuan_video2video.json
## image+video 2 video
воркфлоу чуть посложнее: берет видео с движением (например, танец) и клеит его поверх статичной картинки. В результате хуньюань подхватывает движения.
видео с исходным танцем: https://civitai.com/images/50838820
лора на танцы: https://civitai.com/models/1110311/sexy-dance
Воркфлоу image+video2video: https://github.com/Mozer/comfy_stuff/blob/main/workflows/hunyuan_imageVideo2video.json
## image2video
самый сложный воркфлоу. Использует:
- HunyuanLoom (flowEdit)
- SAM2 comfyUI (можно и без него, но тогда маску, того что должно двигаться, придется рисовать пальцем)
- Видео белого шума: https://github.com/Mozer/comfy_stuff/blob/main/input/noise_8s.mp4
- Детальное описание вашей картинки.
- Воркфлоу image2video: https://github.com/Mozer/comfy_stuff/blob/main/workflows/hunyuan_img2video_sam_flow_noise.json
Именно динамичный шум позволяет создать движение. Без него движения в кадре не будет. Но шум понижает контраст выходного видео, поэтому я рисую его только на тех областях, которые должны двигаться.
Сгенерировать детальное описание вашей картинки на английском можно тут:
https://huggingface.co/spaces/huggingface-projects/llama-3.2-vision-11B
Установка
устанавливаем кастомные ноды в комфи, читаем их описание по установке:
https://github.com/kijai/ComfyUI-HunyuanLoom
https://github.com/neverbiasu/ComfyUI-SAM2 (опционально)
Замечания:
- 2 секунды видео на 3090 генерируются за 2 минуты (на 3060 - 7 минут).
- Главные параметры flowEdit: skip_steps (кол-во шагов из исходного видео или картинки, 1-4) и drift_steps (количество шагов генерации по промпту, 10-19).
- Конечное значение steps = skip_steps + drift_steps. Обычно выходит 17-22 для hanyuan fast модели. 10 шагов точно не хватит. Для обычной не fast модели будет больше (не тестил). Чем больше skip_steps тем более похожей на исходную картинку (или исходное видео) будет результат. Но тем меньше движения можно задать промптом. Если результат сильно размыт - проверяйте значение steps, оно должно быть равно сумме.
- Лучше всего получаются видео длиной 2 секунды (49 кадров). 73 кадра сложнее контролировать. Рекомендуемое разрешение 544x960.
- Есть два поля для промптов: Source prompt (описание вашей картинки) и Destination prompt (описание вашей картинки + движения в кадре).
Звук для вашего видео можно сгенерировать в MMAudio тут: https://huggingface.co/spaces/hkchengrex/MMAudio
Эти воркфлоу используют HunyuanLoom (flowEdit) - эта штука преобразует входное видео в размытый движущийся поток (почти как controlnet). Обычный denoise тут не нужен, с ним картинка будет кипеть.
Для сохранения черт лица нужна лора на лицо. Без нее лицо будет другое. Куча лор на персонажей есть на civitai.
## video2video
Это самый простой воркфлоу, получается лучше всех. Использует HunyuanLoom (flowEdit). Для создания видео с Кеану использовал: skip_steps: 11, drift_steps: 15. Лора: 0.95 довольно хорошо передает его лицо под любым углом.
лору на Кеану: https://civitai.com/models/1131159/john-wick-hunyuan-video-lora
Воркфлоу video2video: https://github.com/Mozer/comfy_stuff/blob/main/workflows/hunyuan_video2video.json
## image+video 2 video
воркфлоу чуть посложнее: берет видео с движением (например, танец) и клеит его поверх статичной картинки. В результате хуньюань подхватывает движения.
видео с исходным танцем: https://civitai.com/images/50838820
лора на танцы: https://civitai.com/models/1110311/sexy-dance
Воркфлоу image+video2video: https://github.com/Mozer/comfy_stuff/blob/main/workflows/hunyuan_imageVideo2video.json
## image2video
самый сложный воркфлоу. Использует:
- HunyuanLoom (flowEdit)
- SAM2 comfyUI (можно и без него, но тогда маску, того что должно двигаться, придется рисовать пальцем)
- Видео белого шума: https://github.com/Mozer/comfy_stuff/blob/main/input/noise_8s.mp4
- Детальное описание вашей картинки.
- Воркфлоу image2video: https://github.com/Mozer/comfy_stuff/blob/main/workflows/hunyuan_img2video_sam_flow_noise.json
Именно динамичный шум позволяет создать движение. Без него движения в кадре не будет. Но шум понижает контраст выходного видео, поэтому я рисую его только на тех областях, которые должны двигаться.
Сгенерировать детальное описание вашей картинки на английском можно тут:
https://huggingface.co/spaces/huggingface-projects/llama-3.2-vision-11B
Describe this image with all the details. Type (photo, illustration, anime, etc.), character's name, describe it's clothes and colors, pose, lighting, background, facial features and expressions. Don't use lists, just plain text description.
Установка
устанавливаем кастомные ноды в комфи, читаем их описание по установке:
https://github.com/kijai/ComfyUI-HunyuanLoom
https://github.com/neverbiasu/ComfyUI-SAM2 (опционально)
Замечания:
- 2 секунды видео на 3090 генерируются за 2 минуты (на 3060 - 7 минут).
- Главные параметры flowEdit: skip_steps (кол-во шагов из исходного видео или картинки, 1-4) и drift_steps (количество шагов генерации по промпту, 10-19).
- Конечное значение steps = skip_steps + drift_steps. Обычно выходит 17-22 для hanyuan fast модели. 10 шагов точно не хватит. Для обычной не fast модели будет больше (не тестил). Чем больше skip_steps тем более похожей на исходную картинку (или исходное видео) будет результат. Но тем меньше движения можно задать промптом. Если результат сильно размыт - проверяйте значение steps, оно должно быть равно сумме.
- Лучше всего получаются видео длиной 2 секунды (49 кадров). 73 кадра сложнее контролировать. Рекомендуемое разрешение 544x960.
- Есть два поля для промптов: Source prompt (описание вашей картинки) и Destination prompt (описание вашей картинки + движения в кадре).
Звук для вашего видео можно сгенерировать в MMAudio тут: https://huggingface.co/spaces/hkchengrex/MMAudio
Forwarded from DevFM
Ответ на задачу — проектируем динамическую фильтрацию
В прошлом посте описана задача, которую мы предлагали на собеседовании для разработчиков. Задача была такая: спроектировать фильтрацию результатов поиска товаров с учётом ограничений.
В задачах на проектирование чего-либо интервьюера интересует не столько сам ответ, сколько ход ваших мыслей. Вы можете не дойти до правильного ответа, или дойти с подсказкой. Рассмотрим потенциальные решения задачи и покритикуем их:
💡 Давайте присылать все данные на фронт и фильтровать там.
🚫 1кк записей передавать нецелесообразно. Более того, даже хранить фильтры на фронте не выйдет, так как они динамические и определяются конкретной выборкой. В любом случае, фильтровать должен бекенд.
💡В postgres можно спроектировать схему для хранения фильтров в связке со списком товаров, к которым эти фильтры можно применять.
🚫 Здесь не стали приводить конкретики, но отметим, что при таком подходе будут проблемы с динамическим обновлением счетчиков. А ещё такое решение несёт сложную ментальную нагрузку на разработчика.
💡Можно взять Elasticsearch или Manticore Search и подобное реализовать там.
❓По задаче требуется остаться с PostgreSQL и не вводить доп сущностей. Если можно поднять эластик, решение нормальное и можно обсудить детали.
💡Сведём задачу фильтрации к фасетному поиску. Для этого каждую единицу товара мы характеризуем набором конкретных признаков.
✅ В базе данных нам нужно завести отдельную колонку, где для каждого товара явно хранить набор его признаков и их значений. Для агрегации, подсчета количества и быстрого поиска по выбранным фильтрам можно использовать мощный механизм полнотекстового поиска.
Пример реализации такого решения с использованием полнотекстового поиска в postgres приведен в статье Faceted search using PostgreSQL full text search.
#database #skills #резюме
В прошлом посте описана задача, которую мы предлагали на собеседовании для разработчиков. Задача была такая: спроектировать фильтрацию результатов поиска товаров с учётом ограничений.
В задачах на проектирование чего-либо интервьюера интересует не столько сам ответ, сколько ход ваших мыслей. Вы можете не дойти до правильного ответа, или дойти с подсказкой. Рассмотрим потенциальные решения задачи и покритикуем их:
💡 Давайте присылать все данные на фронт и фильтровать там.
🚫 1кк записей передавать нецелесообразно. Более того, даже хранить фильтры на фронте не выйдет, так как они динамические и определяются конкретной выборкой. В любом случае, фильтровать должен бекенд.
💡В postgres можно спроектировать схему для хранения фильтров в связке со списком товаров, к которым эти фильтры можно применять.
🚫 Здесь не стали приводить конкретики, но отметим, что при таком подходе будут проблемы с динамическим обновлением счетчиков. А ещё такое решение несёт сложную ментальную нагрузку на разработчика.
💡Можно взять Elasticsearch или Manticore Search и подобное реализовать там.
❓По задаче требуется остаться с PostgreSQL и не вводить доп сущностей. Если можно поднять эластик, решение нормальное и можно обсудить детали.
💡Сведём задачу фильтрации к фасетному поиску. Для этого каждую единицу товара мы характеризуем набором конкретных признаков.
✅ В базе данных нам нужно завести отдельную колонку, где для каждого товара явно хранить набор его признаков и их значений. Для агрегации, подсчета количества и быстрого поиска по выбранным фильтрам можно использовать мощный механизм полнотекстового поиска.
Пример реализации такого решения с использованием полнотекстового поиска в postgres приведен в статье Faceted search using PostgreSQL full text search.
#database #skills #резюме
Telegram
DevFM
Задача на собеседовании — проектируем динамическую фильтрацию
Проводили собеседование на разработчика. Задачу для технической части взяли из практики, то есть это прямо то, чем в будущем предстояло заниматься собеседуемому, разве что с упрощением предметной…
Проводили собеседование на разработчика. Задачу для технической части взяли из практики, то есть это прямо то, чем в будущем предстояло заниматься собеседуемому, разве что с упрощением предметной…
Forwarded from Quant Valerian
Об командообразование в очередной раз
Закончил смотреть серию лекций Дмитрия Болдырева. Офигенно, рекомендую!🔥
Начинается всё с объяснения разницы между различными группами людей (команда, рабочая группа, сообщество и т.п.), отдельный акцент сделан на разнице между командой и рабочей группой. Дмитрий доходчиво объясняет за счёт чего команда работает эффективнее.
Спойлер: в команде люди друг друга подгоняют, помогают друг другу, готовы выходить за рамки своих должностных обязанностей. Мы это обсуждали в постах про культуру (см. пункты 3 - 5). А ещё люди в командах настолько хотят достигать целей, что часто придумывают оптимизации, шорткаты и другие способы повышения эффективности сами (см. конфликт там же).
Далее рассказывается о стадиях формирования команды. И здесь я узнал, что существуют десятки моделей, кроме всем известной модели Такмана, чем плоха конкретно такмановская интерпретация, а ещё в чем разница между изложенным материалом в лекциях и, собственно, теорией Такмана. Душнилам понравится💯
Рассказ о стадиях ведётся на конкретном примере бригады строителей ЛЭП в тайге. Всё, что с ними происходит, Дмитрий комментирует с т.з. орг психологиии логики . Это интересно и запоминается (потому что не абстрактно).
В последней лекции цикла всё суммируется, сжимается, а к каждой стадии Дмитрий прилагает рекомендации для руководителя. Это всё должно помочь в нелегком деле командообразования.
Очень понравилось, что многие моменты разложены по осям, и каждый квадрант Дмитрий разбирает отдельно. Например, в каких случаях стоит и не стоит пытаться сделать из рабочей группы команду, и как в обоих случаях оптимальнее всего регламентировать их работу. Люблю, когда покрыты все кейсы, однозначно лайк 👍
Если нет сил и времени смотреть всё, то must see последняя лекция в серии.
Закончил смотреть серию лекций Дмитрия Болдырева. Офигенно, рекомендую!
Начинается всё с объяснения разницы между различными группами людей (команда, рабочая группа, сообщество и т.п.), отдельный акцент сделан на разнице между командой и рабочей группой. Дмитрий доходчиво объясняет за счёт чего команда работает эффективнее.
Спойлер: в команде люди друг друга подгоняют, помогают друг другу, готовы выходить за рамки своих должностных обязанностей. Мы это обсуждали в постах про культуру (см. пункты 3 - 5). А ещё люди в командах настолько хотят достигать целей, что часто придумывают оптимизации, шорткаты и другие способы повышения эффективности сами (см. конфликт там же).
Далее рассказывается о стадиях формирования команды. И здесь я узнал, что существуют десятки моделей, кроме всем известной модели Такмана, чем плоха конкретно такмановская интерпретация, а ещё в чем разница между изложенным материалом в лекциях и, собственно, теорией Такмана. Душнилам понравится
Рассказ о стадиях ведётся на конкретном примере бригады строителей ЛЭП в тайге. Всё, что с ними происходит, Дмитрий комментирует с т.з. орг психологии
В последней лекции цикла всё суммируется, сжимается, а к каждой стадии Дмитрий прилагает рекомендации для руководителя. Это всё должно помочь в нелегком деле командообразования.
Очень понравилось, что многие моменты разложены по осям, и каждый квадрант Дмитрий разбирает отдельно. Например, в каких случаях стоит и не стоит пытаться сделать из рабочей группы команду, и как в обоих случаях оптимальнее всего регламентировать их работу. Люблю, когда покрыты все кейсы, однозначно лайк 👍
Если нет сил и времени смотреть всё, то must see последняя лекция в серии.
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Дмитрий Болдырев. Всё о командной работе
Канал об организации и управлении командной работой
Для связи: @d_boldyrev
Для связи: @d_boldyrev
Forwarded from Инженерообязанный🫡 | Блог Дата Инженера
#кейсы
🚨 Ребят, рассказываю про кейс, с которым столкнулся🚨 .
Вероятнее всего будет интересен Аналитикам из-за работы с Pandas, но Инженерам данных тоже к прочтению.🧑🎓
Вкратце, есть Дата Фрейм, и в нём 12к строк, и 22 колонки, и джоба работает абсолютно нормально, все преобразования работают за секунду, а заливка данных в GreenPlum 13 минут работает. Сами понимаете,12к строк всего, а если там будет 100к строк? Что тогда🤔 ? (Считать не нужно, вопрос риторический)
Пример кода загрузки в GreenPlum:
Оказывается, что при использовании стандартной функции to_sql, данные записываются в базу данных построчно, грубо говоря командой INSERT, а параметр chunksize задаёт через сколько строк сделать коммит в БД. При таком использовании время вставки 5к строк составляет:
Нам конечно же такая тема не понравилась, так как очень долго. Начал думать🤔 , что и как сделать так, чтобы ускорить данный процесс. В голову приходила только идея💡 сохранять данные в файл и использовать команду COPY. И в итоге, нарвался на статью от SQL-EX(ссылка). В общем и целом, там рассматривается 5 способов загрузки данных с помощью библиотеки Pandas в Postgres(если кто не знал 😳 для GreenPlum используется движок Postgresql, поэтому данные варианты подходили и нам). Выбрав самый быстрый способ🐆 , оказалось, что в параметр method можно передать свою функцию, где мы будет передавать логику сохранения файла(в нашем случае все сохраняется в памяти) и выполнения команды COPY, и что не мало важно, код был понятным для аналитиков. Код получился следующим:
В данном случае - время резко сократилось в +100500 раз, и чем больше данных, тем данный метод будет быстрее.
Это метод хорош, когда данных немного, от силы до пары гигабайт. Если данных больше, то лучше сохранять данные в сыром виде и уже с помощью PXF подгружать данные в GreenPlum.
‼️ Могу посоветовать сохранить к себе данную статью, чтобы при столкновении с подобной задачей, долго не искать как и что.(Для этого я его тут и сохранил😂 ).
Интересно, а GPT напишет такой код? Хмммм....
Вероятнее всего будет интересен Аналитикам из-за работы с Pandas, но Инженерам данных тоже к прочтению.
Вкратце, есть Дата Фрейм, и в нём 12к строк, и 22 колонки, и джоба работает абсолютно нормально, все преобразования работают за секунду, а заливка данных в GreenPlum 13 минут работает. Сами понимаете,12к строк всего, а если там будет 100к строк? Что тогда
Пример кода загрузки в GreenPlum:
def df_to_db_old(df, schema, table, force=False):
from sqlalchemy import text
engine = get_gp_engine() # get_gp_engine функция возвращающая движок от psycopg3
df.to_sql(con=engine,
index=False,
schema=schema,
name=table,
if_exists='append',
chunksize=16000)
# Создание DataFrame
df_5000_rows = pd.DataFrame(data)
df_to_db(df=df_5000_rows, schema='team_test', table='shust_test')
Оказывается, что при использовании стандартной функции to_sql, данные записываются в базу данных построчно, грубо говоря командой INSERT, а параметр chunksize задаёт через сколько строк сделать коммит в БД. При таком использовании время вставки 5к строк составляет:
Время вставки (1): 190.558109998703 секунд
Нам конечно же такая тема не понравилась, так как очень долго. Начал думать
def df_to_db(df, schema, table, force=False):
def psql_insert_copy(table, conn, keys, data_iter): #функция передаваемая в мотод
from io import StringIO
import csv
# получаем подключение DBAPI, которое может обеспечить курсор
dbapi_conn = conn.connection
with dbapi_conn.cursor() as cur:
s_buf = StringIO()
writer = csv.writer(s_buf)
writer.writerows(data_iter)
s_buf.seek(0)
columns = ', '.join('"{}"'.format(k) for k in keys)
if table.schema:
table_name = '{}.{}'.format(table.schema, table.name)
else:
table_name = table.name
sql = 'COPY {} ({}) FROM STDIN WITH CSV'.format(
table_name, columns)
cur.copy_expert(sql=sql, file=s_buf)
engine = gp_engine() # gp_engine функция возвращающая движок от psycopg2
df.to_sql(con=engine,
index=False,
schema=schema,
name=table,
if_exists='append',
method=psql_insert_copy)
df_to_db(df=df_5000_rows, schema='team_test', table='shust_test')
В данном случае - время резко сократилось в +100500 раз, и чем больше данных, тем данный метод будет быстрее.
Время вставки (2): 0.3825254440307617 секунд
Это метод хорош, когда данных немного, от силы до пары гигабайт. Если данных больше, то лучше сохранять данные в сыром виде и уже с помощью PXF подгружать данные в GreenPlum.
Интересно, а GPT напишет такой код? Хмммм....
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from ml4se
Mechanistic Interpretability
I have prepared a list of papers on Mechanistical Interpretability. If you have good links on this topic, please share them in the comments.
* 2021: A Mathematical Framework for Transformer Circuits
* 2022.06.27: Mechanistic Interpretability, Variables, and the Importance of Interpretable Bases
* 2022.09.14: Toy Models of Superposition
* 2022.09.24: In-context Learning and Induction Heads
* 2023.04.28: Towards Automated Circuit Discovery for Mechanistic Interpretability
* 2023.01.12: Progress measures for grokking via mechanistic interpretability
* 2023.05.24: Interpretability Dreams
* 2023.09: Sparse Autoencoders Find Highly Interpretable Model Directions
* 2023.10.25: Attention Lens: A Tool for Mechanistically Interpreting the Attention Head Information Retrieval Mechanism
* 2024.01.15: Sparse Autoencoders Work on Attention Layer Outputs
...
I have prepared a list of papers on Mechanistical Interpretability. If you have good links on this topic, please share them in the comments.
* 2021: A Mathematical Framework for Transformer Circuits
* 2022.06.27: Mechanistic Interpretability, Variables, and the Importance of Interpretable Bases
* 2022.09.14: Toy Models of Superposition
* 2022.09.24: In-context Learning and Induction Heads
* 2023.04.28: Towards Automated Circuit Discovery for Mechanistic Interpretability
* 2023.01.12: Progress measures for grokking via mechanistic interpretability
* 2023.05.24: Interpretability Dreams
* 2023.09: Sparse Autoencoders Find Highly Interpretable Model Directions
* 2023.10.25: Attention Lens: A Tool for Mechanistically Interpreting the Attention Head Information Retrieval Mechanism
* 2024.01.15: Sparse Autoencoders Work on Attention Layer Outputs
...
Forwarded from что-то на DL-ском