Хм. Ну тогда можно подумать над тем, чтобы поставить круговой поляризатор вертикально, перед разделителем. Впрочем, тот комментатор, наверное знает больше на эту тему.
В теории — это действительно сделать можно. Но как будете заполнять области открытия теперь уже возникающие над и под объектами? )
Я ещё раз говорю, я не рассматриваю такую тяжёлую артиллерию. Мы делаем с обоими кадрами проективное преобразование, и никаких областей дополнительных не появляется и не убавляется. Берём сцену, находим в ней несколько острых углов предметов, эти углы в каждом кадре после преобразований должны оказаться на одной горизонтали. Для каждого острого угла создаём уравнение для идеального случая. Идеальным он, скорее всего, не получится, так что вместо решения уравнения минимизируем сумму квадратов разностей левых и правых частей уравнений. Несколько степеней свободы придётся устранить другим способом. Так, например, вдоль оси, проходящей через центры обоих глаз, можно вращаться, оставляя парные точки на одной горизонтали. От этой степени свободы можно избавиться, добившись того, чтобы после преобразований пришлось как можно меньше обрезать. У проективного преобразования 8 степеней свободы, а для двух глаз — 16. С другой стороны, если мы ограничиваемся проекцией прямоугольника (2 степени свободы, где может проходить ось) на сферу (1 степень свободы для фокусного расстояния, мне кажется, общая для ракурсов), делаем поворот (3 степени свободы вращения) и снова проецируем с тем же фокусом на прямоугольник, так что ось попадает в фиксированное положение, у нас получается 2*2 + 1 + 2*3 — 1 = 10 степеней свободы, а не 16. Последняя -1 — это вращение вдоль оси, проходящей через глаза. 10 острых углов найти, и уже можно с чего–то начинать.
Ключевое слово «при каждой трансформации».
Под трансформациями я имел в виду увеличения и обрезания кадра. Предполагается, что инструментарий будет делать их синхронно и поддерживать метки. Ну, то есть, если кадр обрезан, то, зная, в каких точках были оси, можно посчитать, в каких координатах они окажутся после обрезания. Если увеличен, то пропорционально изменить фокус в пикселах и PPI. Ну и прочие преобразования, когда у кого–то ошибается простым образом.
Да, это делать можно. Подробнее про это было в 4-й части, посмотрите. )
Нет, про проективные преобразования там не было, а такую тяжёлую артиллерию, как реконструкция стереоизображения с другой шириной областей закрытия/открытия, я не имел в виду. Я, возможно, не так их назвал, но то, что я имею в виду, описывается формулами:
x2 = (a*x + b*y + c)/(d*x + e*y + f)
y2 = (g*x + h*y + i)/(d*x + e*y + f)
Тут 9 коэффициентов, но все их можно смаштабировать на ненулевой коэффициент, поэтому здесь только 8 степеней свободы. Здесь написано:
Отображение, обратное проективному, является проективным отображением. Композиция проективных отображений является проективным. То есть, множество проективных отображений образует группу.
Аффинное преобразование является частным случаем проективного.
А повороты и трансляции, являясь подмножествами множества аффинных преобразований, являются и проективными преобразованиями тоже.
Так вот, если прямоугольник, соответствующий одному кадру, поставить в пространстве на некоем расстоянии от фокуса, сделать какие–то повороты, а потом спроецировать на какую–то плоскость, или, наоборот, не вращать прямоугольник, а проецировать на другую плоскость, то с некоторой оговоркой это будет применение проективного преобразования. Оговорка касается точек, которые проецируются на полусферу за наблюдателем: в проективных преобразованиях изображение из затылка накладывается с поворотом на 180° на изображение из глаз. Это уже вопрос видимости, а не геометрии.
Если бы все было так просто ))). Начнем с того, что часто даже просто оценить диспаритет в реальном времени — крайне сложно (из-за того, что ракурсы разные по цвету, резкости и т.п.) и там еще много проблем.
А мне кажется, что просто. Вот, допустим, при съёмках любая вменяемая камера даёт изображение такое, что ось проходит через центр кадра, вот этот центр кадра и нужно вшить в метку. А если кадр как–то обрезается, то ось уже не в центр кадра попадает, а в другую точку, и инструменты, обрезающие кадр, должны эту метку поправлять. Далее, фокус должен вшиваться камерами. Насколько я понимаю, вся оптика находится на камерах, и сама камера по расстояниям между линзами может определить фокус в физических величинах и фокус в пикселах, и вшить их оба. Чтобы уменьшить количество степеней свободы, в которых нам нужно искать, как поправить кадр, более критичен фокус в пикселах.
Далее, при создании 3D нужно объединить две картинки с двух ракурсов, причём, после объединения оси (где через кадры проходят оси, должно быть понятно по ранее вшитой метке) должны быть разведены на некоторое количество пикселов — и при объединении мы просто вшиваем это число, а потом при каждой трансформации просто поддерживаем в актуальном состоянии. И без всяких карт диспаритета.
Objective-C со своей динамикой известен только лишь потому, что после того, как улеглась пена (а улегающаяся пена была представлена, например, Sun OBI, SGI Delta C++, эти темы обсуждались на конференциях USENIX), среди подобных подходов на плаву остался он один, и не в силу своих технических достоинств, а в силу кодовой базы, уже написанной на языке прошлого поколения. Отчасти IBM OS/2 и Apple Copland дружно сдохли, отчасти головокружение от Java, отчасти подход IBM к SOM «не доставайся же ты никому», отчасти очень малый период, когда программисты могли пощупать DTS C++, чтобы это отпечаталось в голове, и в open source проектах типа GObject был бы воплощён именно такой подход к ООП, а не тот, который в Delphi и C++.
Мне недавно удалось запустить компилятор DTS C++ от IBM, на Win8 x64 до сих пор работает, можно было бы сделать сравнение DTS C++ и Objective-C, чтобы понять, что мы потеряли. Мне вообще кажется, всем было бы лучше, если взять Foundation, AppKit и т. п. и заменить Objective-C на SOM и DTS C++ или его аналог, ускоренно повторивший эволюцию Objective-C. В WebObjects была относительно успешная замена всего на Java, в Cocoa-Java был относительно успешно работающий мост, позволяющий писать приложения на Java, из этого я делаю вывод, что возможности, не имеющие соответствия 1:1 между Objective-C и DTS C++, вроде poseAs, не помешают сделать такой переезд.
Касательно метапрограммирования, я думаю, чтобы как–то совладать с ним, можно было бы сделать возможность компилировать расширения языка в dll, и они бы манипулировали AST. Не везде будет достаточно, но тем не менее.
Языки типа ParaSail, Limbo, Erlang, Go, Rust, Cilk поднимают более общую тему — создание единого зелёнопоточного планировщика, потому что когда у каждого из этих языков планировщик свой, совмещать их все не очень очевидно, как. Пока получается только так, что у каждого из них планировщики на разных потоках OS. Подобно тому, как поверх ядер CPU работает планировщик OS, поддерживающих вытесняющую многозадачность, поверх потоков OS должен работать планировщик зелёных потоков, и у этих зелёных потоков должны быть свои зелёные мьютексы, зелёные условные переменные и т. п. Как я понимаю, такой планировщик есть у ParaSail, а у планировщиков остальных языков из списка другая модель многозадачного взаимодействия, что усложняет портирование программ, написанных в расчёте на потоки, мьютексы и условные переменные. Чтобы зелёные потоки не тратили время больше положеного, их, наверное, как–то размечать придётся, и компиляторы разных языков програмирования могут оценивать затраты CPU по–разному, не очень понятно, что с этим делать. Наверное, перекладывать задачу разметки на библиотеки времени выполнения.
Хорошо видны нелинейные искажения объектов сцены, которые невозможно исправить поворотом и которые вообще сложно исправить. Мы видим, что люди стоят вертикально, однако, с точки зрения воспринимаемой глубины их туловища заметно и “невозможно” наклонены. Этот средний план также явно снимался на side-by-side стереориг с конвергенцией осей камер.
Насколько я понимаю теорию, кадр кинокамеры — это не просто 2D картинка, а его можно считать этакой неполной панорамой. 2 кадра — это 2 неполных панорамы. Даже если оси сходятся или не лежат в одной плоскости, обе неполных панорамы можно поворачивать в нужном направлении по всем 3м осям вращения относительно центра каждой из них и так спозиционировать, чтобы всё–таки получить правильное стереоизображение. С точки зрения программной реализации, это будут проективные искажения, а не просто повороты кадров.
Проблемы, которые я вижу:
Чтобы 2D картинку посчитать куском панорамы, нужно знать фокус. В виртуальном пространстве помещаем картинку на этом расстоянии от центра, проецируем на сферу вокруг центра — и вот он, кусок панорамы. А в реальности фокус мы не знаем (ведь не знаем же?). Плюс, кадры могут быть так обрезаны, что для получения панорамы нормаль из центра на плоскость картинки должна попасть в некую точку, отличную от её центра. То есть, в общем случае для обоих кадров надо подбирать проективные искажения, которые бы сделали их соответствующими друг другу кадрами левый/правый.
По моему опыту обратной коррекции перспективы в GIMP, некоторые камеры дают подушкообразные искажения, прямые линии перестают быть прямыми, и всё становится сложнее. Но мне кажется, для стерео такие камеры должны заведомо не подходить, они будут портить все кадры.
В связи с этим у меня, как у программиста, рождаются мысли, что, чтобы ограничить подобные проблемы в будущем, в видеокадры должны внедряться метки, такие как фокус, центр картинки, а для 3D видео — максимальный параллакс, и инструменты должны эти метки понимать и не позволять делать некорректные операции.
Я верю в то, что рано или поздно, в несколько итераций, на планете единая глобальная культура сложится, и все языки каким–то образом продрейфуют к будущему глобальному языку, который, учитывая развитие техники, будет ещё и так построен, чтобы компьютеры могли лучше его понимать хоть голосом (фонетика), хоть текстом (семантика).
Но вот как прийти к этой глобальной культуре — это вопрос открытый, и мы видим попытки затоптать чужие огороды и пересадить всё со своего огорода вместо естественного перекрёстного опыления (блок или конгломерат).
Энтузиазма по-поводу «духовного» Эльбруса я не разделяю, мне сама идея национализации чего-либо кажется дурацкой.
Я в общем–то не про Эльбрус думал, а про то, что могло бы появиться при соответствующих условиях, кроме Эльбруса. Архитектура OpenRISC, а не SPARC, например.
У нас тоже могли бы быть свои Intel и AMD или ещё что–нибудь, не обязательно же два, будь у нас рынок требуемых размеров. Минимум 250 млн. населения, кажется, нужно, чтобы заниматься своими процессорами, чтобы сработал эффект масштаба. Плюс, Ливановы всякие там не должны гробить образование, Голодцы всякие там не должны кошмарить малый бизнес пенсионными регрессивными налогами; от Вашингтонского консенсуса нужно отказаться и дать длинных денег в экономику.
Лучше уж глобализация под американским флагом.
Ну тогда и просить нужно у дяденек американцев, чтобы что–нибудь сделали, чтоб от архитектуры одной отказаться, на другую перейти. Я не считаю реалистичным, чтоб с американцами такой разговор задался, поэтому всякие там американские флаги считаю чем–то бесполезным применительно к этому вопросу. Если вам один человек что–то не делает, вы берёте другого. Если американцы что–то не делают, значит, без американцев надо разобраться. Логично же.
Во-первых, можете перечислить пару принципиальных моментов, почему уходящая вдаль от плоскости экрана картинка будет ухудшаться с точки зрения визуального восприятия? (у меня это было в 1 и 4 частях).
Crosstalk и разница между аккомодацией и конвергенцией. Первое лечится поиском хорошего оборудования, про второе у меня есть только статистика по себе. Моя статистика, увы, ограничивается увлечением Duke Nukem 3D в 2004м году, который кроме VGA и VESA режимов имел ещё один секретный, включающий красно–синий анаглиф режим. А также поддержкой 3D в драйверах NVidia тех же годов, с которой я, например, проходил MDK 2. С тех пор я с 3D не сталкивался, но вот запомнилось мне, что монитор становился как бы окном, через которое необычно хорошо всё видно (нет DOF нигде), и про проблемы с аккомодацией прочитал только из вашей статьи, по своему опыту такого не помню.
Во-вторых, как по-вашему будут восприниматься «вылеты», если и без того «плоское тридэ» убрать далеко за экран?
При реконструкции условий кинотеатра — так же. Так как поверхность ТВ ближе, чем экран кинотеатра, вылет может поверхность ТВ не пересечь. Не знаю, можно ли это почувствовать и надо ли.
Вот интересно, значит ли это, что SOM после стольких мытарств по левым архитектурам и супердорогим серверам вернётся на тёплый ламповый x86, да ещё и на Linux?
Собственно, история вопроса такова:
После некоторых событий, к которым можно добавить смерть IBM OS/2 и Apple Copland, SOM был определён внутри IBM на z/OS. О нём можно и сейчас почитать документацию на сайте IBM. Я видел аналогичные PDF'ки для OS/2 и AIX, но тут, похоже, самые последние версии документации. Так, например, оттуда я узнал, что при написании эмиттеров можно применять SOMClassMgr, чтобы затенять своими классами некоторые классы, объекты которых создаются извне пользовательского кода, а в документации для AIX эта часть отсутствовала.
CUPERTINO, Calif. (BUSINESS WIRE) August 20, 1996 Tandem Computers Incorporated today announced the availability of the first fault-tolerant, scalable CORBA 2.0-compliant object request broker with transaction services. Tandem's product called NonStop® Distributed Object Manager (NonStop DOM), is a fusion of the company's high-performance transaction processing software with IBM's SOMobjects(tm) 3.0 object management technology, an emerging standard for enterprise distributed object computing.
NonStop CORBA 2.6.1 is HP's NonStop implementation of OMG's CORBA 2.6 specifications, fully leveraging NonStop fundamentals. NonStop CORBA 2.6.1 is a consolidation of NonStop DOM, NonStop JORB, and NonStop JTS/OTS
Теперь у этой истории, видимо, появляется продолжение в виде Linux, Windows и Xeon. То, что есть somFree — это замечательно, но если из закромов IBM, Apple или HP что–нибудь выйдет, будет интересно посмотреть.
Т.е. если какой-то фильм был “слишком плоским” на вашем экране (а ровно эта проблема наиболее волнует желающих посмотреть в 3D на маленьком экране), то он таким же “плоским” и останется, просто сдвинется, например, за экран.
Я с этим не могу согласиться. Параллакс в абсолютных величинах увеличивается линейно, а глубина зависит от разницы между параллаксом и расстоянием между глаз обратно пропорционально, так что задвигая за экран, мы должны увеличивать воспринимаемую глубину, выводя параллаксы на другие участки гиперболы.
Чисто по логике, если зритель сидит перед домашним ТВ так, что для каждого глаза телесный угол поверхности ТВ больше телесного угла поверхности экрана в настоящем кинотеатре, то на этом ТВ заведомо можно воспроизвести условия, аналогичные условиям посетителя кинотеатра.
При этом может потребоваться не только изменять параллакс, но и уменьшать картинку, так что не вся поверхность ТВ окажется задействованной. Может быть и обратное, домашний ТВ при попытке смоделировать условия кинотеатра окажется дыркой в заборе. Условия воспроизвести–то можно, но всё изображение не поместится.
Если обработать ваши данные о параллаксах, можно прикинуть, какой угол по горизонтали должна занимать поверхность ТВ или экрана кинотеатра для нормального восприятия, умножить тангенс этого угла на предполагаемое расстояние до экрана, добавить расстояние между глаз и получить минимальную ширину ТВ, который не будет дыркой в заборе при попытке посмотреть 3D по–нормальному. Или, наоборот, если ТВ уже есть, отнять от его ширины расстояние между глаз и поделить на тангенс минимального угла восприятия и получить оптимальное расстояние, на котором нужно смотреть 3D на этом ТВ (если сесть ближе, придётся уменьшать картинку — меньше задействованная площадь, меньше разрешение изображения).
По метаклассам есть хорошая книжка «Putting metaclasses to work». Оба её автора участвовали в разработке IBM System Object Model, пользовались опытом SmallTalk и CLOS, и то, что они сделали, и им, и мне кажется лучшим на текущий момент. Их модель метаклассов была позаимствована в Python.
Отвечая Tensho: у Objective-C был брат–близнец DTS C++, вполне себе компилируемый. Только вместо objc.dll som.dll, и синтаксис более нормальный*. И метаклассы есть, конечно. Никак это компилируемости не вредит, даже наоборот, снимает типичные для компилируемого языка проблемы хрупкого базового класса.
Мне даже, может быть, удастся найти и запустить компилятор под Windows. В IBM VisualAge C++ v3.6 эта возможность уже вырезана. VisualAge C++ v3.5 я в сети в виде установщика не нашёл, зато есть патч, который, может так получиться, содержит в себе достаточно файлов, чтобы запустить компилятор.
*Моё мнение основано на том факте, что, несмотря на рост количества разработчиков на Objective-C за счёт iOS, в появляющихся новых языках программирования синтаксис SmallTalk никто так и не начал использовать. Исключение составляют языки, заточенные под компиляцию для iOS (Oxygene, Swift).
В относительно новых Squid есть директива url_rewrite_program, где кроме URL и SOURCE_ADDRESS можно ещё получать ещё что–то. Мне кажется, можно получать и заголовки, например, Referer.
Если у нас скрытый сайт ведёт не на скрытый (это может быть LINK REL, IFRAME, IMG, A), можно сначала 303м перенаправить на свой сервер, а потом JavaScript'ом проверить, является ли окно окном верхего уровня, и если да, то по таймеру перенаправить на желаемый адрес. Это на случай, если мы просто перешли по ссылке A. Остальные способы (IMG, IFRAME) в этом случае должны ломаться.
А rewrite_program можно обойти, написав так, что скрипт rewrite_program ничего не увидит.
С точки зрения Концепции Общественной Безопасности, запрещать доступ к несекретной информации неприемлемо, посколько это способствует поддержанию калейдоскопического мировоззрения. Ну, то есть, чтобы набрать информацию по какому–то предмету, нам может потребоваться 3% одного произведения, 12% другого, 21% третьего, 1% четвёртого, пятого, шестого, седьмого, 0.3% восьмого, девятого, десятого и т. д., а платить нужно за 100% каждого произведения. Те, кто посредством, например, ссудного процента паразитируют на кредитно–финансовой системе, не будут иметь проблем с платёжной стеной, а у толпы в нижней части толпо–элитарной пирамиды, да и у элиты в середине пирамиды до некоторой степени такие проблемы возникнут. Так они и ходят с калейдоскопом в голове.
Михалков, как можно видеть, пытается создать кинематограф на здоровых началах. Ну или относительно здоровых. В «Солнечном ударе» много здоровых идей, но при этом столько сцен пития и курения, что своих детей я на такое кино не сводил бы. Если бы в фильме все, включая антагонистов, были трезвенниками, любой ответственный человек отнёсся бы с пониманием и уважением к этой условности. Жаль, что Михалков не сторонник КОБ, а всего лишь православный. Впрочем, зная, как работает нарколобби по своему краю, я бы предположил, что это не принципиальное решение режиссёра, а условие предоставления денег, ну а Михалков, будучи всего лишь православным, позволил себе согласиться.
Просто ищет, где бы выбить денег на кино. Предположение, что кино якобы должно себя окупить, не выдерживает критики. И кино, и наука — часть чего–то большего, общий вклад в будущее. Надо оптимизировать общественную систему как целое, думая хотя бы на одно поколение вперёд, а не разбивать систему на административно обособленные единицы, где каждый сам за себя и только со своего «участка» имеет краткосрочный доход. Если бы кредитно–финансовая и общественная системы были устроены иначе, такой проблемы со съёмками не было бы не потому что деньги были не нужны, а потому что не было бы искусственного дефицита, который в таких количествах приходится заливать выбитыми на кино деньгами.
Это такая игра со стульями, где человек постоянно больше, чем стульев, и в основное время приходится думать, как бы лично тебе хватило стула, и лишь немногие ещё в свободное время задаются вопросом, куда постоянно пропадают стулья, ведь по расчётам должно хватать на всех с избытком.
В частности, выражение «подать автору на покушать» нашим цивилизованным потомках, которые будут есть как дышать, не задумываясь, смогут ли они делать это завтра, послезавтра, через месяц, через год, будет такой же дикостью, как некогда крепостное право.
Не на ровном. 20 лет перед этим помурыжили, дали пространству имён забиться. Со скрипом международные имена неспешно протащили. И только потом открыли gTLD, пока ещё не поздно.
А вообще, страны ШОС, БРИКС или другого объединения могли бы собраться и договориться о создании своих TLD, чтобы они друг у друга резолвились, а остальные страны–изгои типа Канады и Испании потом либо признали эти TLD, либо своим непризнанием создали проблемы своим жителям и организациям, и, возможно, вынудили бы провайдеров резолвить домены по собственной инициативе. «Открыли gTLD, пока ещё не поздно» — именно в этом смысле.
Создал тему на форуме OberonCore. Среди участников форума могут быть общие знакомые по Excelsior и Академгородку. Интересно, как родилась идея таких по–челябински суровых мер безопасности.
Во–первых, не безполезны, во–вторых, в Китае не дураки и смотрят, как живут росияне. То есть, чем больше в относительно свободной Росии путают берега, тем щедрее китайцы на фаервол для себя. И наоборот. Моё мнение.
По поводу 2. Среди концептуалов бытует мнение, что 1949-1953, а после этого к власти пришли троцкисты и начали разворачивать Союз обратно (марксизм, вообще говоря, как и фашизм, и либерализм, не про то, чтоб люди счастливо жили), и то, чего Союз достиг после смерти Сталина — это последействие.
Проблемы с отношением к Советскому Союзу проистекают из неразличения политики Сталина по искоренению эксплуатации человека человеком и марксизма–троцкизма, сплошь и рядом окружавшего его, и которые у него так и не хватило сил одолеть.
Я ещё раз говорю, я не рассматриваю такую тяжёлую артиллерию. Мы делаем с обоими кадрами проективное преобразование, и никаких областей дополнительных не появляется и не убавляется. Берём сцену, находим в ней несколько острых углов предметов, эти углы в каждом кадре после преобразований должны оказаться на одной горизонтали. Для каждого острого угла создаём уравнение для идеального случая. Идеальным он, скорее всего, не получится, так что вместо решения уравнения минимизируем сумму квадратов разностей левых и правых частей уравнений. Несколько степеней свободы придётся устранить другим способом. Так, например, вдоль оси, проходящей через центры обоих глаз, можно вращаться, оставляя парные точки на одной горизонтали. От этой степени свободы можно избавиться, добившись того, чтобы после преобразований пришлось как можно меньше обрезать. У проективного преобразования 8 степеней свободы, а для двух глаз — 16. С другой стороны, если мы ограничиваемся проекцией прямоугольника (2 степени свободы, где может проходить ось) на сферу (1 степень свободы для фокусного расстояния, мне кажется, общая для ракурсов), делаем поворот (3 степени свободы вращения) и снова проецируем с тем же фокусом на прямоугольник, так что ось попадает в фиксированное положение, у нас получается 2*2 + 1 + 2*3 — 1 = 10 степеней свободы, а не 16. Последняя -1 — это вращение вдоль оси, проходящей через глаза. 10 острых углов найти, и уже можно с чего–то начинать.
Под трансформациями я имел в виду увеличения и обрезания кадра. Предполагается, что инструментарий будет делать их синхронно и поддерживать метки. Ну, то есть, если кадр обрезан, то, зная, в каких точках были оси, можно посчитать, в каких координатах они окажутся после обрезания. Если увеличен, то пропорционально изменить фокус в пикселах и PPI. Ну и прочие преобразования, когда у кого–то ошибается простым образом.
Нет, про проективные преобразования там не было, а такую тяжёлую артиллерию, как реконструкция стереоизображения с другой шириной областей закрытия/открытия, я не имел в виду. Я, возможно, не так их назвал, но то, что я имею в виду, описывается формулами:
x2 = (a*x + b*y + c)/(d*x + e*y + f)
y2 = (g*x + h*y + i)/(d*x + e*y + f)
Тут 9 коэффициентов, но все их можно смаштабировать на ненулевой коэффициент, поэтому здесь только 8 степеней свободы.
Здесь написано:
А повороты и трансляции, являясь подмножествами множества аффинных преобразований, являются и проективными преобразованиями тоже.
Так вот, если прямоугольник, соответствующий одному кадру, поставить в пространстве на некоем расстоянии от фокуса, сделать какие–то повороты, а потом спроецировать на какую–то плоскость, или, наоборот, не вращать прямоугольник, а проецировать на другую плоскость, то с некоторой оговоркой это будет применение проективного преобразования. Оговорка касается точек, которые проецируются на полусферу за наблюдателем: в проективных преобразованиях изображение из затылка накладывается с поворотом на 180° на изображение из глаз. Это уже вопрос видимости, а не геометрии.
А мне кажется, что просто. Вот, допустим, при съёмках любая вменяемая камера даёт изображение такое, что ось проходит через центр кадра, вот этот центр кадра и нужно вшить в метку. А если кадр как–то обрезается, то ось уже не в центр кадра попадает, а в другую точку, и инструменты, обрезающие кадр, должны эту метку поправлять. Далее, фокус должен вшиваться камерами. Насколько я понимаю, вся оптика находится на камерах, и сама камера по расстояниям между линзами может определить фокус в физических величинах и фокус в пикселах, и вшить их оба. Чтобы уменьшить количество степеней свободы, в которых нам нужно искать, как поправить кадр, более критичен фокус в пикселах.
Далее, при создании 3D нужно объединить две картинки с двух ракурсов, причём, после объединения оси (где через кадры проходят оси, должно быть понятно по ранее вшитой метке) должны быть разведены на некоторое количество пикселов — и при объединении мы просто вшиваем это число, а потом при каждой трансформации просто поддерживаем в актуальном состоянии. И без всяких карт диспаритета.
Мне недавно удалось запустить компилятор DTS C++ от IBM, на Win8 x64 до сих пор работает, можно было бы сделать сравнение DTS C++ и Objective-C, чтобы понять, что мы потеряли. Мне вообще кажется, всем было бы лучше, если взять Foundation, AppKit и т. п. и заменить Objective-C на SOM и DTS C++ или его аналог, ускоренно повторивший эволюцию Objective-C. В WebObjects была относительно успешная замена всего на Java, в Cocoa-Java был относительно успешно работающий мост, позволяющий писать приложения на Java, из этого я делаю вывод, что возможности, не имеющие соответствия 1:1 между Objective-C и DTS C++, вроде poseAs, не помешают сделать такой переезд.
Касательно метапрограммирования, я думаю, чтобы как–то совладать с ним, можно было бы сделать возможность компилировать расширения языка в dll, и они бы манипулировали AST. Не везде будет достаточно, но тем не менее.
Языки типа ParaSail, Limbo, Erlang, Go, Rust, Cilk поднимают более общую тему — создание единого зелёнопоточного планировщика, потому что когда у каждого из этих языков планировщик свой, совмещать их все не очень очевидно, как. Пока получается только так, что у каждого из них планировщики на разных потоках OS. Подобно тому, как поверх ядер CPU работает планировщик OS, поддерживающих вытесняющую многозадачность, поверх потоков OS должен работать планировщик зелёных потоков, и у этих зелёных потоков должны быть свои зелёные мьютексы, зелёные условные переменные и т. п. Как я понимаю, такой планировщик есть у ParaSail, а у планировщиков остальных языков из списка другая модель многозадачного взаимодействия, что усложняет портирование программ, написанных в расчёте на потоки, мьютексы и условные переменные. Чтобы зелёные потоки не тратили время больше положеного, их, наверное, как–то размечать придётся, и компиляторы разных языков програмирования могут оценивать затраты CPU по–разному, не очень понятно, что с этим делать. Наверное, перекладывать задачу разметки на библиотеки времени выполнения.
Насколько я понимаю теорию, кадр кинокамеры — это не просто 2D картинка, а его можно считать этакой неполной панорамой. 2 кадра — это 2 неполных панорамы. Даже если оси сходятся или не лежат в одной плоскости, обе неполных панорамы можно поворачивать в нужном направлении по всем 3м осям вращения относительно центра каждой из них и так спозиционировать, чтобы всё–таки получить правильное стереоизображение. С точки зрения программной реализации, это будут проективные искажения, а не просто повороты кадров.
Проблемы, которые я вижу:
Чтобы 2D картинку посчитать куском панорамы, нужно знать фокус. В виртуальном пространстве помещаем картинку на этом расстоянии от центра, проецируем на сферу вокруг центра — и вот он, кусок панорамы. А в реальности фокус мы не знаем (ведь не знаем же?). Плюс, кадры могут быть так обрезаны, что для получения панорамы нормаль из центра на плоскость картинки должна попасть в некую точку, отличную от её центра. То есть, в общем случае для обоих кадров надо подбирать проективные искажения, которые бы сделали их соответствующими друг другу кадрами левый/правый.
По моему опыту обратной коррекции перспективы в GIMP, некоторые камеры дают подушкообразные искажения, прямые линии перестают быть прямыми, и всё становится сложнее. Но мне кажется, для стерео такие камеры должны заведомо не подходить, они будут портить все кадры.
В связи с этим у меня, как у программиста, рождаются мысли, что, чтобы ограничить подобные проблемы в будущем, в видеокадры должны внедряться метки, такие как фокус, центр картинки, а для 3D видео — максимальный параллакс, и инструменты должны эти метки понимать и не позволять делать некорректные операции.
Но вот как прийти к этой глобальной культуре — это вопрос открытый, и мы видим попытки затоптать чужие огороды и пересадить всё со своего огорода вместо естественного перекрёстного опыления (блок или конгломерат).
Я в общем–то не про Эльбрус думал, а про то, что могло бы появиться при соответствующих условиях, кроме Эльбруса. Архитектура OpenRISC, а не SPARC, например.
У нас тоже могли бы быть свои Intel и AMD или ещё что–нибудь, не обязательно же два, будь у нас рынок требуемых размеров. Минимум 250 млн. населения, кажется, нужно, чтобы заниматься своими процессорами, чтобы сработал эффект масштаба. Плюс, Ливановы всякие там не должны гробить образование, Голодцы всякие там не должны кошмарить малый бизнес пенсионными регрессивными налогами; от Вашингтонского консенсуса нужно отказаться и дать длинных денег в экономику.
Ну тогда и просить нужно у дяденек американцев, чтобы что–нибудь сделали, чтоб от архитектуры одной отказаться, на другую перейти. Я не считаю реалистичным, чтоб с американцами такой разговор задался, поэтому всякие там американские флаги считаю чем–то бесполезным применительно к этому вопросу. Если вам один человек что–то не делает, вы берёте другого. Если американцы что–то не делают, значит, без американцев надо разобраться. Логично же.
Crosstalk и разница между аккомодацией и конвергенцией. Первое лечится поиском хорошего оборудования, про второе у меня есть только статистика по себе. Моя статистика, увы, ограничивается увлечением Duke Nukem 3D в 2004м году, который кроме VGA и VESA режимов имел ещё один секретный, включающий красно–синий анаглиф режим. А также поддержкой 3D в драйверах NVidia тех же годов, с которой я, например, проходил MDK 2. С тех пор я с 3D не сталкивался, но вот запомнилось мне, что монитор становился как бы окном, через которое необычно хорошо всё видно (нет DOF нигде), и про проблемы с аккомодацией прочитал только из вашей статьи, по своему опыту такого не помню.
При реконструкции условий кинотеатра — так же. Так как поверхность ТВ ближе, чем экран кинотеатра, вылет может поверхность ТВ не пересечь. Не знаю, можно ли это почувствовать и надо ли.
Собственно, история вопроса такова:
После некоторых событий, к которым можно добавить смерть IBM OS/2 и Apple Copland, SOM был определён внутри IBM на z/OS. О нём можно и сейчас почитать документацию на сайте IBM. Я видел аналогичные PDF'ки для OS/2 и AIX, но тут, похоже, самые последние версии документации. Так, например, оттуда я узнал, что при написании эмиттеров можно применять SOMClassMgr, чтобы затенять своими классами некоторые классы, объекты которых создаются извне пользовательского кода, а в документации для AIX эта часть отсутствовала.
Кроме IBM и Apple, было ещё одно направление, куда ушёл SOM: www.thefreelibrary.com/Tandem+Delivers+Enterprise+Transaction+Processing+Capabilities+to...-a018607143
Tandem потом был куплен Compaq, а Compaq — HP. На сайте HP дела обстоят хуже, чем у IBM, я там больше путаюсь, и ещё там прокисают ссылки. По ссылке, очередной новый адрес которой мне не очень хочется искать, было написано: h20223.www2.hp.com/nonstopcomputing/cache/76695-0-0-0-121.html?404m=cache-ccto0
Теперь у этой истории, видимо, появляется продолжение в виде Linux, Windows и Xeon. То, что есть somFree — это замечательно, но если из закромов IBM, Apple или HP что–нибудь выйдет, будет интересно посмотреть.
Я с этим не могу согласиться. Параллакс в абсолютных величинах увеличивается линейно, а глубина зависит от разницы между параллаксом и расстоянием между глаз обратно пропорционально, так что задвигая за экран, мы должны увеличивать воспринимаемую глубину, выводя параллаксы на другие участки гиперболы.
Чисто по логике, если зритель сидит перед домашним ТВ так, что для каждого глаза телесный угол поверхности ТВ больше телесного угла поверхности экрана в настоящем кинотеатре, то на этом ТВ заведомо можно воспроизвести условия, аналогичные условиям посетителя кинотеатра.
При этом может потребоваться не только изменять параллакс, но и уменьшать картинку, так что не вся поверхность ТВ окажется задействованной. Может быть и обратное, домашний ТВ при попытке смоделировать условия кинотеатра окажется дыркой в заборе. Условия воспроизвести–то можно, но всё изображение не поместится.
Если обработать ваши данные о параллаксах, можно прикинуть, какой угол по горизонтали должна занимать поверхность ТВ или экрана кинотеатра для нормального восприятия, умножить тангенс этого угла на предполагаемое расстояние до экрана, добавить расстояние между глаз и получить минимальную ширину ТВ, который не будет дыркой в заборе при попытке посмотреть 3D по–нормальному. Или, наоборот, если ТВ уже есть, отнять от его ширины расстояние между глаз и поделить на тангенс минимального угла восприятия и получить оптимальное расстояние, на котором нужно смотреть 3D на этом ТВ (если сесть ближе, придётся уменьшать картинку — меньше задействованная площадь, меньше разрешение изображения).
Отвечая Tensho: у Objective-C был брат–близнец DTS C++, вполне себе компилируемый. Только вместо objc.dll som.dll, и синтаксис более нормальный*. И метаклассы есть, конечно. Никак это компилируемости не вредит, даже наоборот, снимает типичные для компилируемого языка проблемы хрупкого базового класса.
Мне даже, может быть, удастся найти и запустить компилятор под Windows. В IBM VisualAge C++ v3.6 эта возможность уже вырезана. VisualAge C++ v3.5 я в сети в виде установщика не нашёл, зато есть патч, который, может так получиться, содержит в себе достаточно файлов, чтобы запустить компилятор.
*Моё мнение основано на том факте, что, несмотря на рост количества разработчиков на Objective-C за счёт iOS, в появляющихся новых языках программирования синтаксис SmallTalk никто так и не начал использовать. Исключение составляют языки, заточенные под компиляцию для iOS (Oxygene, Swift).
Если у нас скрытый сайт ведёт не на скрытый (это может быть LINK REL, IFRAME, IMG, A), можно сначала 303м перенаправить на свой сервер, а потом JavaScript'ом проверить, является ли окно окном верхего уровня, и если да, то по таймеру перенаправить на желаемый адрес. Это на случай, если мы просто перешли по ссылке A. Остальные способы (IMG, IFRAME) в этом случае должны ломаться.
А rewrite_program можно обойти, написав так, что скрипт rewrite_program ничего не увидит.
Михалков, как можно видеть, пытается создать кинематограф на здоровых началах. Ну или относительно здоровых. В «Солнечном ударе» много здоровых идей, но при этом столько сцен пития и курения, что своих детей я на такое кино не сводил бы. Если бы в фильме все, включая антагонистов, были трезвенниками, любой ответственный человек отнёсся бы с пониманием и уважением к этой условности. Жаль, что Михалков не сторонник КОБ, а всего лишь православный. Впрочем, зная, как работает нарколобби по своему краю, я бы предположил, что это не принципиальное решение режиссёра, а условие предоставления денег, ну а Михалков, будучи всего лишь православным, позволил себе согласиться.
Просто ищет, где бы выбить денег на кино. Предположение, что кино якобы должно себя окупить, не выдерживает критики. И кино, и наука — часть чего–то большего, общий вклад в будущее. Надо оптимизировать общественную систему как целое, думая хотя бы на одно поколение вперёд, а не разбивать систему на административно обособленные единицы, где каждый сам за себя и только со своего «участка» имеет краткосрочный доход. Если бы кредитно–финансовая и общественная системы были устроены иначе, такой проблемы со съёмками не было бы не потому что деньги были не нужны, а потому что не было бы искусственного дефицита, который в таких количествах приходится заливать выбитыми на кино деньгами.
Это такая игра со стульями, где человек постоянно больше, чем стульев, и в основное время приходится думать, как бы лично тебе хватило стула, и лишь немногие ещё в свободное время задаются вопросом, куда постоянно пропадают стулья, ведь по расчётам должно хватать на всех с избытком.
В частности, выражение «подать автору на покушать» нашим цивилизованным потомках, которые будут есть как дышать, не задумываясь, смогут ли они делать это завтра, послезавтра, через месяц, через год, будет такой же дикостью, как некогда крепостное право.
А вообще, страны ШОС, БРИКС или другого объединения могли бы собраться и договориться о создании своих TLD, чтобы они друг у друга резолвились, а остальные страны–изгои типа Канады и Испании потом либо признали эти TLD, либо своим непризнанием создали проблемы своим жителям и организациям, и, возможно, вынудили бы провайдеров резолвить домены по собственной инициативе. «Открыли gTLD, пока ещё не поздно» — именно в этом смысле.
Проблемы с отношением к Советскому Союзу проистекают из неразличения политики Сталина по искоренению эксплуатации человека человеком и марксизма–троцкизма, сплошь и рядом окружавшего его, и которые у него так и не хватило сил одолеть.