Эзотерический поискФорумГрафика

Базовые примитивы

#0
0:05, 13 мая 2014
+ Построение линии в таблице координат: MMX-Optimized
+ Bitmap in four-sided polygon
+ Баннер
#1
4:37, 13 мая 2014

картинка не соответствует коду. код выполняет только скейлинг, а на картинке - вообще не афинное преобразование. и, ясное дело, ассемблер тут ну никак не упёрся, потому что компилятор сгенерит код лучше(скорее всего хотя бы векторизует что-нибудь).

#2
7:59, 13 мая 2014

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

+ фрагмент кода фильтра

Какрас делает то, что на картинке (натягивает видео другого потока на боковую стену в ортографической проекции.
До этого тупо использовал в цикле PlgBlt-GDI, но в режиме реального потока видео код сажал машину...
Заменил PlgBlt на свою x86_Line и дело исправилось...
Видео работы фильтра сейчас закачал.
Как видно, иногда происходит сбой и кадры видео исчезают с изображения. Я там запустил три фильма. На заднем плане - лестничная площадка (VirtualDub сутками пишет в режиме DVR через мой фильтр, который вверху ставит тайм-код. И выполняет пробные функции фильтрации Squirrel...)

#3
12:13, 13 мая 2014

Alikberov
> эту тему я создал для себя в первую очередь. Так как с крахами систем потерял
> кучу полезного кода собственной разработки. Пусть будет тут как в облаке.
Странная мотивация.
Suslik
> на картинке - вообще не афинное преобразование
Разве?

#4
14:29, 13 мая 2014

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

#5
2:54, 6 июля 2014

Mikle Странная мотивация.

Ну, как видите, на форуме, в отличие от облака, ТС можно и осудить. ;)

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

Это понятно. Но подобных фильтров я не встречал. Вот и пишу. А дыры там или щели - уже дело второе. Мне сейчас главное - набить фильтр как следует.
Он делается прежде всего для линейного монтажа. А погрешности линейных эффектов даже по телевиденью видны в прямом эфире на фоне голубой стены (видео по каналу СГУ).
Мне главное, чтобы работало. Хоть и как попало (как попало - не значит крах при каждом чихе), но быстро (я не китаец, чтобы код построения линии весил гигабайт и требовал час).
P.S.: Эта функция построения линии содержит всего две метки, как видите. Лет 6 тому назад подобный алгоритм содержал десяток меток и не умел натягивать изображение. Вот что значит практика... Учусь тихонечко...
Алгоритм доработал и теперь исключений минимум. Соответственно, дыр минимум. Лищь щели между отдельными линиями изредка...
К тому же, длина одной линии в таких случаях не может достигать миллионов пикселей, а считанные тысячи. Что в последствии даст возможность сначала строить таблицу координат пикселей одной линии, а затем уже в другом цикле рисовать по тем координатам.

P.S.: Написал функцию на ассемблере, которая делает то, что Вы ожидали: Из произвольной области второго четырёхугольника копирует пиксели в другую произвольную область первого четырёхугольника. Дан пример вызова...

Эзотерический поискФорумГрафика

Тема в архиве.