Где там красные линии то все же? Что за странные М в качестве единиц для осей? Километры что ли? А почему они разные на двух картинках, они же только фильтрацией отличаются? И что то мутное-цветное смещающееся внутри черной линии это предсказанная траектория?
На мой взгляд вы решаете нерешаемую задачу. Ориентацию с точностью до одного градуса можно получить, но скорость - вряд ли Будет гравитация у вас не 9.81 а 9.79 (локальная аномалия или просто высота большая) И получите вы за 8 минут скорость большую на 8 метров в секунду Позиция будет в километровой погрешности за 2 минуты
Вам надо либо знать скорость (Доплер, по поверхности или как то так) либо какие то визуальные ориентиры иметь, тогда можно что то сделать.
Не знаю, насколько хорош Калман - по моему опыту не слишком, но может я его просто готовить не умею. Возможно. Даже наверняка, учитывая что обычный ahrs у меня давал результаты лучше, чем Калман с кватернионами. Но у меня просто не real time задача, я занимаюсь постобработкой, так что мне проще - с калманом я повозился чуть, при прыжках GPS он совсем что то у меня глючил. Ведь с gps оно как - долгое время он может нормально соответствовать траектории. Ну да, ошибка 20 метров, но со всеми инерциальными датчиками согласован, фильтр считает его достаточно надежным... А потом как появился еще один спутник, так куда нибудь упрыгает - и все ориентации и скорости с ума сходят. Калман же рассчитан на случайное блуждание, а в случае gps это не так. Но тут явно есть большие специалисты чем я в этой теме. Не про это хотел написать.
Так вот, точнее всего у меня предсказывались биасы при попытке согласовать датчики с физикой с помощью поиска траектории, которая минимизирует ошибки датчиков - просто с помощью градиентного спуска по ошибке. Но и тут не без сюрприза - процесс может сходится к разным траекториям. И в какой то момент, уменьшение ошибки дает ухудшение траектории. Что как бы говорит о том что только по данным иму посчитать ничего не получится
Да, я видел код, думал раз вы разбирались с этим handshake то может знаете как это определить Вообще похоже что у заблокированных по dpi доменов просто нулевой трафик в ConnectionInfo Но надо еще посмотреть
А как то можно выяснить, чем закончился tls handshake? У меня сейчас вот www.google.com блокируется по dpi Каждый раз выяснять что именно в этот раз пришло в голову ростелекому заблокировать не хочется, хорошо бы автоматом получать список адресов. А там где не сработала фрагментация, можно было бы и на роутер маршрут автоматом прописывать
Трансформеры это как минимум не свертка В случае свертки использовать dilation может и не имеет смысла, по крайней мере на задачах классификации, там уменьшение разрешения вполне естественная операция - которая кстати ведет ровно к тому же, на каждом уровне берется окно в два раза шире В случае же трансформера использование только части токенов на порядки повышает скорость обучения при небольшой (на самом деле не знаю какой и есть ли вообще) деградации качества.
И что же, вы считаете, если на 100млн параметров трансформер нормально сходится, то на миллиард перестанет сходится? Это вряд ли. Кстати для изображений это даже более важно чем для текста, если рассматривать изображение как последовательность токенов, то никакой разумный трансформер не будет в состоянии учесть все предыдущие токены. Отсюда опять все эти костыли, когда за токен принимается кусок 16х16 или сначала используется сверточная нейросеть. Ну костыль же?
Но это же так естественно использовать в качестве соседей не все токены, а лишь какую то выборку - точки на расстоянии 1,3,7 и тд, тогда получается относительно небольшое количество соседей по которым идет обогащение, при этом уже на 8 уровнях пиксель получает полную информацию для генерации. На картинке пример - слева там начальная последовательность-изображение, справа реальное, по центру то что предсказала нейросеть-трансофрмер. Ну круто же! Это не мутный автоэнкодер или вае, реальная же цифра получилась. При этом такая генерация работает сильно быстрее чем всякие диффузеры, так что готовьтесь, скоро картинка как последовательность станет трендом. Главное от обогащения по всем токенам уйти
Люди склонны выдумывать себе проблемы, а потом героически их решать. Какой вообще смысл грузить все эти 10000 векторов контекста в модель? Смысл нулевой абсолютно, там соседние вектора почти не отличаются друг от друга, и каждый из них несет вполне себе понимание контекста. Достаточно использовать весьма ограниченное количество токенов, на первом уровне трансформера ближайшие, на втором - каждый второй, на третьем - каждый четвертый На шестнадцатом - каждый 32000ый При нормальном обучении и достаточной емкости вектора эмбединга эти вектора сами по себе впитают весь контекст своего уровня, без необходимости что то создавать дополнительное Я пробовал использовать 32 токена - такую модель довольно просто обучить на обычной видеокарте, результаты вполне сравнимы с тем что получается у авторов из Language Modeling Is Compression (для их игрушечных моделек, для миллиардных ресурсов нет) Кстати, если вы посмотрите на результаты работы, то там есть еще один интересный вывод - модель с токенезацией работает хуже чем модель работающая напрямую с байтами
Так не работает. Сетка говорит, что если купить акцию сейчас по такой цене, то даже с учетом комиссии, ее можно будет продать позже дороже. Это все что знает сеть. Если купить акцию позже или по другой цене - не факт, что получится какая то прибыль. При этом это же участки с движением, то есть если не смог купить акцию в эту минуту, то через минуту уж точно не сможешь
Странно, у меня на акциях прекрасно все сходится. Проблема начинается дальше, данные свечи != цене акции, купить (или продать) по такой цене в половине случаев нереально, даже если сместить цену на десятую часть процента.
Вас же не удивляет, что всякие диффузеры генерят осмысленную картинку? Значит в целом нейросети уже научились определять, что именно на картинке изображено. В случае stable diffusion этим занимается сетка clip - она по картинке делает эмбеддинг, и по фразе делает эмбеддинг и сличает, насколько эти эмбединги похожи. При генерации меняет картинку так, что бы ее эмбединг был сильнее похож на текстовый.
Тут собственно почти тоже самое, что мешает натренировать сеть искать кусок изображения, который при свертке clip даст эмбеддинг максимально похожий на текстовый?
Clip при этом тренировалась не на классах, а на картинках с описанием. Конечно, если нигде в этом наборе объект который вы ищете не встречался, то clip и yola из статьи не сработает. И сейчас все сетки с открытым множеством находят много лишнего, но думаю еще не много и это доделают.
Для декорирования видео у карты какой то свой отдельный блок, его загрузка рисуется в Taskmanager Windows. Не знаю уж, что вы оптимизировали в языках, но если натравить на ртсп ffmpeg и брать кадры через пайп то уже 60 камер по 1280х720 полностью загружают современные видеокарты. Именно карту, все остальное свободно. Cuda при этом не используется, только блок декодирования. И неважно, кто запускает ffmpeg, у меня есть проект с с++ и python, от языка это не зависит, ведь вся нагрузка в другом процессе. Вытащить из пайп кадры может любой калека
В общем как-то совсем ваша информация с моим опытом не стыкуется. 40 fullhd просто кладут карту на лопатки, даже при дешифровки пяти кадров в секунду.
Я а этом году примерно таким же занимался, мне надо было положение велосипедиста найти. GPS, даже со всеми базами, прыгает в довольно большом радиусе, особенно во дворах. С помощью датчика на колесе и 6доф удалось довольно точно трек получить. Получилось, что локально направление очень точно выдаётся, а глобальное уплывание легко корректируется по GPS (если взять удаленные точки трека, то даже если у gps будет большая ошибка, в целом, угол будет правильный, и относительно него можно гироскоп скорректировать). В результате, когда в Москве в центре GPS совсем выключили, оказалось что он не особо то и нужен - достаточно задать несколько ключевых точек трека, что бы он лег на карту
Фотографии не совпадают из-за вращения земли, такое же вращение происходит во время съёмки панорамы - а съёмка панорамы хорошо изучена и для неё существует много готовых библиотек. В целом поиск параметров совмещения кадров там делается примерно так же, как у вас, но никакой триангуляции там не делается, вместо этого вычисляются характеристики объектива (в идеале их можно посчитать заранее), проективная проекция переводится в цилиндрическую, после чего фотографии уже можно усреднять и избавляться от шума попиксельно. Думаю такой подход сильно повысит качество и даст возможность детектировать движущиеся объекты
Четвертое измерение интересная штука. Я вот подумал, что если точка движется равномерно по виртуальной оси У (четвертое измерение, движение по которому мы не воспринимаем) начиная с какой то точки (скажем один) на нашей реальной оси Х, то расстояние от центра координат до этой точки будет менятся как sqrt(kt^2 + 1) Вторая производная тут везде положительная, так что для нас движение будет выглядить с ускорением
Учитывая собственные вектора, любое ортогональное преобразование расскладывается на инвариантные размерности и плоскости вращения. Другое дело, что плоскостей вращения может быть две
Где там красные линии то все же? Что за странные М в качестве единиц для осей? Километры что ли?
А почему они разные на двух картинках, они же только фильтрацией отличаются?
И что то мутное-цветное смещающееся внутри черной линии это предсказанная траектория?
На мой взгляд вы решаете нерешаемую задачу.
Ориентацию с точностью до одного градуса можно получить, но скорость - вряд ли
Будет гравитация у вас не 9.81 а 9.79 (локальная аномалия или просто высота большая)
И получите вы за 8 минут скорость большую на 8 метров в секунду
Позиция будет в километровой погрешности за 2 минуты
Вам надо либо знать скорость (Доплер, по поверхности или как то так) либо какие то визуальные ориентиры иметь, тогда можно что то сделать.
Не знаю, насколько хорош Калман - по моему опыту не слишком, но может я его просто готовить не умею. Возможно. Даже наверняка, учитывая что обычный ahrs у меня давал результаты лучше, чем Калман с кватернионами. Но у меня просто не real time задача, я занимаюсь постобработкой, так что мне проще - с калманом я повозился чуть, при прыжках GPS он совсем что то у меня глючил. Ведь с gps оно как - долгое время он может нормально соответствовать траектории. Ну да, ошибка 20 метров, но со всеми инерциальными датчиками согласован, фильтр считает его достаточно надежным... А потом как появился еще один спутник, так куда нибудь упрыгает - и все ориентации и скорости с ума сходят. Калман же рассчитан на случайное блуждание, а в случае gps это не так. Но тут явно есть большие специалисты чем я в этой теме. Не про это хотел написать.
Так вот, точнее всего у меня предсказывались биасы при попытке согласовать датчики с физикой с помощью поиска траектории, которая минимизирует ошибки датчиков - просто с помощью градиентного спуска по ошибке. Но и тут не без сюрприза - процесс может сходится к разным траекториям. И в какой то момент, уменьшение ошибки дает ухудшение траектории. Что как бы говорит о том что только по данным иму посчитать ничего не получится
Да, я видел код, думал раз вы разбирались с этим handshake то может знаете как это определить
Вообще похоже что у заблокированных по dpi доменов просто нулевой трафик в ConnectionInfo
Но надо еще посмотреть
Ко всем доменам плохо
Кое что перестает работать
А как то можно выяснить, чем закончился tls handshake?
У меня сейчас вот www.google.com блокируется по dpi
Каждый раз выяснять что именно в этот раз пришло в голову ростелекому заблокировать не хочется, хорошо бы автоматом получать список адресов.
А там где не сработала фрагментация, можно было бы и на роутер маршрут автоматом прописывать
Трансформеры это как минимум не свертка
В случае свертки использовать dilation может и не имеет смысла, по крайней мере на задачах классификации, там уменьшение разрешения вполне естественная операция - которая кстати ведет ровно к тому же, на каждом уровне берется окно в два раза шире
В случае же трансформера использование только части токенов на порядки повышает скорость обучения при небольшой (на самом деле не знаю какой и есть ли вообще) деградации качества.
И что же, вы считаете, если на 100млн параметров трансформер нормально сходится, то на миллиард перестанет сходится? Это вряд ли.
Кстати для изображений это даже более важно чем для текста, если рассматривать изображение как последовательность токенов, то никакой разумный трансформер не будет в состоянии учесть все предыдущие токены. Отсюда опять все эти костыли, когда за токен принимается кусок 16х16 или сначала используется сверточная нейросеть. Ну костыль же?
Но это же так естественно использовать в качестве соседей не все токены, а лишь какую то выборку - точки на расстоянии 1,3,7 и тд, тогда получается относительно небольшое количество соседей по которым идет обогащение, при этом уже на 8 уровнях пиксель получает полную информацию для генерации. На картинке пример - слева там начальная последовательность-изображение, справа реальное, по центру то что предсказала нейросеть-трансофрмер. Ну круто же! Это не мутный автоэнкодер или вае, реальная же цифра получилась. При этом такая генерация работает сильно быстрее чем всякие диффузеры, так что готовьтесь, скоро картинка как последовательность станет трендом. Главное от обогащения по всем токенам уйти
Люди склонны выдумывать себе проблемы, а потом героически их решать.
Какой вообще смысл грузить все эти 10000 векторов контекста в модель?
Смысл нулевой абсолютно, там соседние вектора почти не отличаются друг от друга, и каждый из них несет вполне себе понимание контекста.
Достаточно использовать весьма ограниченное количество токенов, на первом уровне трансформера ближайшие, на втором - каждый второй, на третьем - каждый четвертый
На шестнадцатом - каждый 32000ый
При нормальном обучении и достаточной емкости вектора эмбединга эти вектора сами по себе впитают весь контекст своего уровня, без необходимости что то создавать дополнительное
Я пробовал использовать 32 токена - такую модель довольно просто обучить на обычной видеокарте, результаты вполне сравнимы с тем что получается у авторов из Language Modeling Is Compression
(для их игрушечных моделек, для миллиардных ресурсов нет)
Кстати, если вы посмотрите на результаты работы, то там есть еще один интересный вывод - модель с токенезацией работает хуже чем модель работающая напрямую с байтами
Я не сравнивал, не знаю про разноцветный и на боку, но локальная Florence круто текст распознает. На выходе правда не структура, а строки и координаты
Это где это в дифузере трансформер? Нет его там
Wandb уже все? Какие есть альтернативы?
Так не работает. Сетка говорит, что если купить акцию сейчас по такой цене, то даже с учетом комиссии, ее можно будет продать позже дороже. Это все что знает сеть.
Если купить акцию позже или по другой цене - не факт, что получится какая то прибыль. При этом это же участки с движением, то есть если не смог купить акцию в эту минуту, то через минуту уж точно не сможешь
Странно, у меня на акциях прекрасно все сходится. Проблема начинается дальше, данные свечи != цене акции, купить (или продать) по такой цене в половине случаев нереально, даже если сместить цену на десятую часть процента.
Запустил ваш "туториал"
Как и предполагалось, такая модель не может ничего путного выдать.
После 1000 эпох аккуратность 45%
Строка на входе
From fairest creatures we desire increase,
That thereby beauty's rose might never die,
But as th
Строка на выходе
oeueaonne ehaee nhre eai a ene andee ne
aahenhahe e e ae nrh seaeue aeneehad e ea n
aaurhaneahe
А пример будет, что такая модель может написать? Бессмысленный набор символов? Или несвязанные слова?
Чуда ожидать не стоит, но все же...
Вас же не удивляет, что всякие диффузеры генерят осмысленную картинку? Значит в целом нейросети уже научились определять, что именно на картинке изображено. В случае stable diffusion этим занимается сетка clip - она по картинке делает эмбеддинг, и по фразе делает эмбеддинг и сличает, насколько эти эмбединги похожи. При генерации меняет картинку так, что бы ее эмбединг был сильнее похож на текстовый.
Тут собственно почти тоже самое, что мешает натренировать сеть искать кусок изображения, который при свертке clip даст эмбеддинг максимально похожий на текстовый?
Clip при этом тренировалась не на классах, а на картинках с описанием. Конечно, если нигде в этом наборе объект который вы ищете не встречался, то clip и yola из статьи не сработает. И сейчас все сетки с открытым множеством находят много лишнего, но думаю еще не много и это доделают.
Вот тут еще пример такой сетки
https://ashkamath.github.io/mdetr_page/
Для декорирования видео у карты какой то свой отдельный блок, его загрузка рисуется в Taskmanager Windows. Не знаю уж, что вы оптимизировали в языках, но если натравить на ртсп ffmpeg и брать кадры через пайп то уже 60 камер по 1280х720 полностью загружают современные видеокарты. Именно карту, все остальное свободно. Cuda при этом не используется, только блок декодирования. И неважно, кто запускает ffmpeg, у меня есть проект с с++ и python, от языка это не зависит, ведь вся нагрузка в другом процессе. Вытащить из пайп кадры может любой калека
В общем как-то совсем ваша информация с моим опытом не стыкуется. 40 fullhd просто кладут карту на лопатки, даже при дешифровки пяти кадров в секунду.
Я а этом году примерно таким же занимался, мне надо было положение велосипедиста найти. GPS, даже со всеми базами, прыгает в довольно большом радиусе, особенно во дворах. С помощью датчика на колесе и 6доф удалось довольно точно трек получить. Получилось, что локально направление очень точно выдаётся, а глобальное уплывание легко корректируется по GPS (если взять удаленные точки трека, то даже если у gps будет большая ошибка, в целом, угол будет правильный, и относительно него можно гироскоп скорректировать). В результате, когда в Москве в центре GPS совсем выключили, оказалось что он не особо то и нужен - достаточно задать несколько ключевых точек трека, что бы он лег на карту
Для распознавания лиц, стоит посмотреть в сторону insightface, вполне прилично работает
Фотографии не совпадают из-за вращения земли, такое же вращение происходит во время съёмки панорамы - а съёмка панорамы хорошо изучена и для неё существует много готовых библиотек. В целом поиск параметров совмещения кадров там делается примерно так же, как у вас, но никакой триангуляции там не делается, вместо этого вычисляются характеристики объектива (в идеале их можно посчитать заранее), проективная проекция переводится в цилиндрическую, после чего фотографии уже можно усреднять и избавляться от шума попиксельно. Думаю такой подход сильно повысит качество и даст возможность детектировать движущиеся объекты
Четвертое измерение интересная штука. Я вот подумал, что если точка движется равномерно по виртуальной оси У (четвертое измерение, движение по которому мы не воспринимаем) начиная с какой то точки (скажем один) на нашей реальной оси Х, то расстояние от центра координат до этой точки будет менятся как sqrt(kt^2 + 1) Вторая производная тут везде положительная, так что для нас движение будет выглядить с ускорением
Учитывая собственные вектора, любое ортогональное преобразование расскладывается на инвариантные размерности и плоскости вращения. Другое дело, что плоскостей вращения может быть две
А ведь в четырехмерном пространстве может быть вращение сразу в двух плоскостях, если оно примерно одинаковое, то изатропия вроде будет...