Торренты   
 
 


A3DTools - просмотр стерео через анаглифические очки с адаптивной коррекцией цвета и компенсацией гхоста

Какой вариант анаглифа считаете наиболее удачным?

Красно-голубой (red-cyan)   70%  70%  [ 61 ]
Зелено-малиновый (green-magenta)   9%  9%  [ 8 ]
Желто-синий (amber-blue)   20%  20%  [ 18 ]

Всего проголосовало : 87

A3DTools - это комплексное решение для просмотра стерео-контента через анаглифические очки любого типа: Red-Cyan, Green-Magenta, Amber-Blue(ColorCode). Обеспечивает просмотр фото в режиме слайд-шоу, просмотр видео в реальном времени, конвертирование видео в готовый анаглиф.
Основное преимущество программного пакета в уникальном алгоритме преобразования A3D-Anaglyph, обеспечивающем более качественную цветопередачу и существенно меньший уровень гхоста (двоения).
Программный пакет является бесплатным для некоммерческого использования.
Комментарии:

Пред.  1, 2, 3, 4, 5 ... 17, 18, 19  След.






samfednik
да я сам начинающий программист на паскале, месяц как начал разбираться :)
 

Вот, написал одну из функций,
Надо проверять, может samfednik поможете?
 

photoreal3d
Вам надо самому пробовать, там из-за какой-нибудь мелкой ошибки уже не открывается скрипт, т.е. дистанционно замучаешься (не работает).
Вот страничка с наглядными примерами использования шейдеров:
http://www.facewound.com/tutorials/shader1/
 

Шейдеры заработали!
Только быстродействие снизилось(((
 

photoreal3d
Странно, в плеерах при подключении шейдеров без тормозов даже Full OverUnder идёт:
http://torrents3d.ru/viewtopic.php?p=22260#22260
 

Перепробовал различные варианты кода для плагина на предмет быстродействия, остановился на окончательном варианте: преобразование цветовых пространств в виде расчетов в целых числах, адаптивная коррекция цвета и компенсация гхоста по таблицам (суммарный размер таблиц 256kB), использование Avisynth MT позволяет загрузить все ядра на многоядерных системах.
Написал простенькую программу для автоматической генерации скрипта A3DAvisynth. В окошке программы надо выбрать необходимые опции и перетащить любой видео-файл мышкой на окошко программы. В папке, где находится видео-файл появится файлик с расширением avs и именем, совпадающим с именем исходного файла. Ну а дальше, полученный скрипт можно перекодировать с помощью любой программы типа VirtualDub или AviDemux, или просто открыть в проигрывателе.
 

photoreal3d
Потому и загрузка низкая, процессор просто ждет пока очередное значение будет прочитано из памяти.
Это зависит от сервера, коим является ависинт. Ну и чуть-чуть (в случае работы с сервером) от компилятора.
boss-master
Да, массивы. Была мысль переделать на указатели...
Т.е. на списки? )) А смысла скорее всего большого нет, см. выше.
photoreal3d
И к самой программе (кстати обработка в пределах 15-20 fps - ОЧЕНЬ хороший результат, не слушайте никого и не заморачивайтесь, займитесь алгоритмом =) ).
Так вот. Что такое "адаптивная коррекция" ну, или, возможно неправильно написал, помню, что подобное упоминалось?
Каждый кадр считается по шаблону или шаблон динамический, т.е. изменяется в зависимости от картинки.
И второй вопрос, если играете с яркостью, то почему бы не перевести RGB в YUV - быстрая и простая операция.
P.S. Возможно я просто не въехал, но заинтересовало )
 

Stroodder
он играется не только с яркостью, но и с контрастностью, так что YUV не подходит.
долго ковырялся с x264 и выяснил вот какую штуку - при переводе в YV12, а именно в нем кодит x264 - происходит искажение оттенков (причем эта пакость идет именно по красному спектру) и сразу лезут гости. При этом в RGB все нормально кажет.
Если вычислить формулу "сдвига оттенков", то можно было бы подготовить исходник так, чтобы после сдвига - получился требуемый результат, я пока не нашел эту формулу, может кто разберется и отпишется.
 

Stroodder
Адаптивная коррекция - это изменение цветов в исходной стереопаре еще до преобразования в анаглиф с учетом особенностей конкретного типа анаглифа. Классические матрицы смешивания (хальфколор, дюбуа и т.д.) снижают мерцание за счет добавления к одному цвету части другого в пространстве RGB. Например, в ред-циане (255,0,0) заменяют на (255,40,40). В принципе, это не что иное как снижение насыщенности цвета, разбавления его белым. В частности, по этому, изменение насыщенности часто воспринимается как изменение яркости и контрастности, хотя это не одно и тоже. В способе подмешивания к одному каналу RGB части другого есть один минус - цвет сдвигается, например, голубой становиться зеленоватым и т.д. Мой алгоритм снижает конфликтность цветов в исходном стерео так, чтобы потом чистое разложение по каналам RGB на анаглиф дало сбалансированное по яркости левого и правого канала изображение. Для этого я все преобразования делаю в пространстве HSV, причем изменению подвергается только одна составляющая - насыщенность S, новое значение насыщенности Sn=f(H,S,V), т.е. зависит как от оттенка H (далеко не все насыщенные цвета являются конфликтными, например, желтый в red-cyan прекрасно смотрится), как от яркости V (темные цвета даже конфликтные перестают быть конфликтными) так и от исходной насыщенности (зачем снижать насыщенность у мягких пастельных тонов).
Использовать YUV заманчиво с точки зрения быстродействия, но пока у меня связи между тремя анаглифами и этим цветовым пространством в голове не сложилось, хотя не исключаю наличия потенциальных возможностей данного формата.
boss-master
Про x264 можно подробнее? Я в курсе, что все алгоритмы сжатия как-то анаглифы портят, но детально не разбирался. Чем x264 от того-же jpeg-а отличается? Там тоже яркость и цветоразностные сигналы, еще и с прореживанием.
 

photoreal3d
оговорился (писал уже поздно ночью) -- не контрастностью а насыщенностью же конечно ты играешься кроме яркости.
на счет х264 - дело не в нем, а в том, что он использует цветовое пространство YV12, в которое он переводит исходник, который поступает в него в другом цветовом формате. Так вот при переводе из RGB24 в YV12 появляются гхосты. Это легко можно увидеть использую прогу AvsP (оболочка ависинта), добавляя и убирая в конце скрипта converttoyv12. Там схема 4:2:0 - то есть цветовая компонента берется вроде как средняя из 4 смежных пикселей (как я понял)
кстати если увеличить размер изображения в 2 раза во всех направлениях при посмощи PointResize (2,2) и потом преобразовать в YV12, то гостей нет, но если потом обратно уменьшить к первоначальному размеру - они опять лезут
 

boss-master
photoreal3d
А природой всех пространств разве не RGB является, мы его в субпиксели и выводим? =)
Я, помню, когда из анаглифа переводил в стереопары, писал функцию для перевода в YUV только чтобы проще было сравнивать яркости пикселей в обоих ракурсах, ведь яркость - это просто ч.б. картинка в RGB, выдуманная для удобства. Можно и свою систему пересчета придумать напр.:
X=0.15*R+0.15*G+0.7*B
E=0.333*R+0.333*G+0.333*B
P=0.29*R+0.59*G+0.11*B
Это так, от балды и для примера. Название пространства читать только детям старше 18-ти. )
boss-master Проблемы с помехами связаны с количеством цифр после запятой.
и с кодеком, который может делать преобразования туда-сюда над пикселем не один раз. Хотя, это лишь предположение - из меня рипер, как из Жирика президент, лучшего кодека с отслеживанием движения чем XViD не видел еще.
Вообще яркость и еще раз яркость - залог ровного анаглифа, для визуализации яркости YUV и придумали.
P.S. HSV вообще придумали для веба, чтобы даже чайник смог цвет выбрать. )
Добавлено:
photoreal3d Т.е. коррекция не динамическая? У колоркода она динамическая, просчитывается каждый пиксель в кадре и заменяется на значение, которое, по их мнению, не дает засвечивания и гхоста.
 

Stroodder
когда начинаешь играть яркостью в разных ракурсах - в итоговом анаглифе идет искажение оттенка, сам проверял.
Красный в ред\циан анаглифе может быть красным, только если он будет мерцать, если добиться одинаковой яркости в ракурсах - это уже не будет красный.
What is YV12?
These are several different ways to represent colors. For example: YUV and RGB colorspace. In YUV colorspace there is one component that represent lightness (luma) and two other components that represent color (chroma). As long as the luma is conveyed with full detail, detail in the chroma components can be reduced by subsampling (filtering, or averaging) which can be done in several ways (thus there are multiple formats for storing a picture in YUV colorspace). YV12 is such a format (where chroma is shared in every 2x2 pixel block) that is supported by AviSynth. Many important codecs stored the video in YV12: MPEG-4 (x264, XviD, DivX and many others), MPEG-2 on DVDs, MPEG-1 and MJPEG.
The subsampling used by YV12 is also called "4:2:0" compared to "4:2:2" which is used by YUY2 and UYVY.
PS: у photoreal3d идет обработка каждого пикселя
 

Stroodder
когда начинаешь играть яркостью в разных ракурсах - в итоговом анаглифе идет искажение оттенка, сам проверял.
Блин, ребята, вы парами что ли ходите на форуме, как оландр с сиббоем?
Пытаюсь дать вам понять, что все уже придумано и куда копать. Анаглиф лично изъездил вдоль и поперек во всех его реинкарнациях, включая долби.
Искажения "оттенка" быть не может, в любом случае, при прямом преобразовании, т.к. яркость - это коэффициенты весов цветов (0-255\0-255\0-255).
 

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

ЗЫ: photoreal3d извини, что тему зафлудили
 

boss-master Ненадевая очков должен быть по логике ближе к синему (приеду, откопаю и проверю, если интересно). Ну а чего давать насчет красного - 255.0.0 и в путь )
Добавлено: Второпях не сразу въехал, засветка красного будет в любом случае, цвет встречается очень часто, в отличии, например от оранжевого и чисто синего. На мой взгляд в драйвере нвидиа сделано правильно - погасили все остальные цвета, картинка стала как бы с красной пеленой. А так, я противник ред-циана, только для ч/б рекомендовал бы.
P.S. Насчет динамической обработки, попробуйте просто откомпилировать массив в 16 млн. цветов и посмотрите на размер, колоркод разрабатывался в университете, работа была проделана колоссальная, если посмотреть на их матрицу. Там обработка нелинейная для каждого веса цвета и поэтому проще забить в массив, чем писать формулы. Иначе говоря, например если вес цвета, скажем 202, он заменяется из матрицы на 174 и т.д. для каждого пикселя и для каждого канала.
P.P.S. Вышеизложенное конечно же не умаляет трудов автора топика, привожу для того, чтобы можно было представить сколько корпели ребята над анаглифом, в буквальном смысле ручная работа проделана.
 

Stroodder
В моем алгоритме просчитывается каждый пиксель каждого кадра, если аналогию с матрицами проводить, то как-бы для разных областей одного кадра применяется разная матрица и для разных кадров эти матрицы меняются (это очень условно, т.к. реально никаких матриц нет, просто одному пикселю ставится в соответствие другой пиксель, такой, чтобы его оттенок сохранился а "засвечивание" снизилось).
Работу колоркодовцев уважаю, т.к. действительно далеко не все формулами можно описать, зависимости, заданные таблично и в науке часто применяются (сам к.т.н.), кроме того, сам подход колоркодовцев правильный - не обязательно сохранять оттенок пикселя, главное чтобы при просмотре в очках оттенок воспринимался таким, какой он есть в исходном изображении. Пример, допустим, что очки (пусть ред-циан) пропускают 30% красного, 40% зеленого и 7% синего (специально взял так, типа правый фильтр темнее чем надо), тогда цвет (255,255,0) через очки будет восприниматься как (255,170,0) что уже далеко не желтый, вывод: чтобы желтый в таких очках воспринимался как желтый надо вместо (255,255,0) выводить (170,255,0) - т.е. намеренно искажать оттенок.
 

photoreal3d Нет, погодите, каждый пиксель каждого кадра - это что значит?
Если Вы пишете что-то типа: if(125 >(int)R<255) {R=234};, то это не то конечно же, это уже линейное преобразование диапазона но никак не динамическое.
P.S. (понимаю, что задолбал уже пиэсами и колоркодом, потерпИте)
В колоркоде обрабатываются две матрицы и не rg/b, а rb/g, что, казалось бы выглядит нелогично, но, блин, они действительно все сделали правильно, сам выводил это в яркость и убедился, есть им за что деньги брать.
 

На мой взгляд в драйвере нвидиа сделано правильно - погасили все остальные цвета, картинка стала как бы с красной пеленой.
а поподробнее на счет этого можно написать. Это про 3дДискавери что-ли?
 

boss-master Да, конечно, про "открытие" нвидиа-торговцев.
 

Stroodder
Видимо мы разное с вами подразумеваем под понятиями "динамическое" и "статическое" (есть еще понятия "линейное" и "нелинейное"). Деление на "динамическое" и "линейное" лично мне не понятно, т.к. это разные категории. Если под понятием "динамическое" вы подразумеваете учет не только текущего цвета пикселя, но и учет изменения цвета пикселя от кадра к кадру - то у меня этого нет, алгоритм анализирует только текущий кадр, обработка последовательности кадров идет независимо друг от друга. Я под динамикой подразумевал, что преобразование зависит от содержимого кадра, более того, отдельные части кадра обрабатываются по разному в зависимости от того, какой цвет преобладает - в этом смысле, невозможно описать преобразования одной матрицей для всего кадра, и даже если каким-то образом вычислить матрицу, наиболее близко описывающую суть этих преобразований в кадре, для следующего кадра такая матрица будет уже другой.
Если говорить про линейное/нелинейное, то в моем алгоритме color_new=f(color), где color - исходный цвет пикселя, color_new - новое значение цвета пикселя которым исходное значение заменяется. При этом функция f - является нелинейной с точки зрения математики, т.е. не может быть приведена к виду f(x)=k*x+b, поэтому свое преобразование считаю нелинейным. Может быть я в чем-то не прав...
 

Страница 4 из 19

Пред.  1, 2, 3, 4, 5 ... 17, 18, 19  След.