При полностью корректном механизме получения сертификата получатель отправляет в УЦ запрос сертификата, содержащий публичный ключ, и в ответ получает собственно сертификат. В этой схеме у УЦ нет никаких преимущественных возможностей взломать что–либо. Ключ вообще может быть неизвлекаемый.
В сервисах типа StartSSL я видел «упрощённый» механизм, где они могут сразу на сайте дать и сертификат, и ключ для сервера, правда, с комментарием, что это не очень безопасно, и корректный вариант там всё равно был.
Надо посмотреть, как будет у нас реализовано. В StartSSL можно было получить сертификат только на один поддомен, но, правда, таких сертификатов можно было заказать кучу и объединить потом через SNI, но как же это геморройно, да и OrenOSP больше 6 сертификатов в SNI не поддерживает, так что у меня, например, не влезло.
Если наш УЦ не будет пытаться нажиться на wildcard и множественных доменах в одном сертификате, это будет отлично, я считаю.
Лучше бы они Surface Pro поддержали, чем кучу барахла, которого у меня всё равно не было и нет.
У меня на нете стоят Pidgin, QQ, Skype. Про указанные Telegram и Viber я слышал только краем уха, но Telegram вроде бы нормальный. По мне, так нетбук — вполне себе мобильное устройство. На нём и MathCAD, и LabVIEW, и большинство IDE запустятся, если надо, и что–то специфичное именно для мобильных устройств могло бы работать.
Желания дополнительно к нетбуку покупать дорогой сканнер QR–кодов, бесполезный в остальных качествах, как–то не имею. Посканировать QR можно и на нетбуке. Я не знаю, насколько близки WhatsApp и WeChat, но вот сумасшедшие китайцы любят WeChat, у которого, в отличие от WhatsApp, из нормальных OS есть Mac OS X, правда, слишком новее, чем у меня под рукой, и мне, чтоб с ними пообщаться, пришлось ставить эмулятор Android и сканировать в нём QR–код с экрана, и тогда можно писать в браузере. Если у WhatsApp такая же система, то это уже множественный вход.
В общем, ну не понимаю я прикола не делать приложения для 3х основных OS. У Microsoft есть даже Project Islandwood, средство портирования iOS приложений на Windows, ну сделали бы хоть порт на Windows, Бог с ней с Ubuntu Touch или Nokia N900. Я не понимаю, почему эти разработчики выкобениваются.
Мда. Очень печально, что адскими проверками нельзя насладиться на архитектуре, которая реализует их аппаратно.
Интересно было бы сравнить Эльбрус+LCC и CHERI+BERI. CHERI поизвестнее LCC будет, однако внезапно Эльбрус у нас оказался более массовым, а я думаю, Эльбрусов выпущено гораздо больше, чем BERI.
Необходимость делать нативный порт обусловлена отсутствием стандартов на исполняемые программы. Есть у меня концепция, как на базе Wine, SOM и Cocoa сделать бинарный аналог Java.
Делать порты под зоопарк операционок, учитывая, что архитектура процессора практически везде какая–нибудь из ограниченного набора — это действительно не здоровая ситуация. Должно быть: одна архитектура — один файл.
Появись такая платформа — возможности экспериментировать с разными OS повысились бы.
На мой взгляд, дело не столько в отключении Интернета, сколько в легализации самоучек, которые поштурмовали двери ВУЗов, как обычно, что–нибудь случилось, не доучились, а потом вкусили прелести фриланса и забили на ВУЗ. Кому–то из них, может, и хотелось бы поделать ништяк, но вот как их с официальными 11ю классами — в НИИ? Ну или если на фрилансе учишься и получаешь деньги, и всё осмысленно, понятно, зачем нужно, то не у многих будет мотивация пять лет заниматься непонятно чем на вечерней форме, и это только для формальностей типа диплома, а ещё же магистратуру, наверное, надо пройти, чтоб попасть в НИИ. Тут надо что–то перекраивать под реалии мира разработчиков.
А вот либералы, которых всё никак не выпнуть не получается, — другое дело. Там, глядишь, и нежданчиков, могущих помешать окончить ВУЗ, и превращающих это занятие в аркадную игру типа «Супер Марио», станет поменьше, и перекройка–таки будет сделана.
У ТТК –ЗС такое есть только для сайтов из реестра. На уровне DNS домены перенаправляются на прокси. По HTTP прокси отдают всё, кроме запрещённых URL. По HTTPS тоже мог бы работать прокси, но вместо этого там заглушка с самоподписанным сертификатом, которая не даёт зайти вообще никуда. Вот на dotu.ru, например, вообще нельзя зайти из–за этого. Система перенаправления DNS кривая, там перенаправленные домены резолвятся хотя бы на прокси, а вот поддомены не резолвятся никак. То есть, если в реестре торчит пара–тройка URL с Обозреватель.ком и они честно блочатся, то на my.obozrevatel.com я не могу прочитать вообще ничего, и даже с первого раза не понятно, в чём проблема, в РосКомСвободе по my.obozrevatel.com нет никаких записей.
Обратной стороной их системы является то, что, если забить на их DNS, то вообще как будто ничего и не было.
RAD Studio Seattle now supports Windows RT API (Windows Runtime API)
Причём, ссылка на Windows Runtime API — внешняя, на MSDN. А хотелось бы поинтересоваться, как именно оно там взяло и начало поддерживаться? Я же помню, что в Metro у Delphi попасть не получилось, чужих туда не пустили. Ada не пустили, Delphi не пустили. Пришлось городить Metropolis для как бы Metro UI и костыльные прокси для Live Tile.
А тут бац — и
RAD Studio Seattle now supports Windows RT API (Windows Runtime API)
…без каких–либо комментариев. Что, вот так вот просто? Всё решилось? Как решилось? Почему раньше не решалось, а сейчас решилось? Или тут какой–то подвох?
помните планы большевиков старой закалки об Мировой революции?
Эмм? Вечная мировая революция была по планам меньшевиков, вроде тех, что были пассажирами парохода «Христиания-Фьорд», а у большевиков были планы строительства социализма в отдельно взятой стране
Извиняюсь, что не в тему, но мне кажется, лучше всего узнавать у вас. Прошу ответить отдельным постом или дать ссылки.
Я знаю, что есть куча разных технологий для отображения 3D. У NVidia свой стереодрайвер, у AMD раньше был iZ3D (на моей Win8 он вешает систему), и ещё там в комплекте к какому–нибудь монитору со встроенной поддержкой 3D может быть вообще что–то неведомое, не связанное с производителями видеокарт. Мониторы с линзовым растром представляют особый интерес, так как у них количество одновременных ракурсов может быть больше двух. И у разных производителей разное SDK. Вот мне бы больше понравилось, если бы я средствами OS мог управлять картинками для разных ракурсов (например, я хочу получить HDC окна для левого и правого глаза отдельно, но не вижу этого в WinAPI), но разработчики OS, видимо, не на одной со мной волне, и пихают в OS что–то другое, а стерео оставляют на откуп куче разных производителей, каждый со своим SDK. Что их объединяет — так это то, что Direct3D или OpenGL графика делаются 3D автоматически.
А если я не хочу эту автоматику, я не знаю, как быть. Может быть, я рейтрейсингом картинку генерю? Или, может быть, у меня игра–платформер с несколькими слоями, и я не хочу слои уровня делать текстурами, а хочу обойтись инструментами 2D графики. Или вот, захотелось мне DOSBox улучшить, чтобы режим Crystal Eyes в Duke Nukem 3D средствами DOSBox форвардился на современное 3D оборудование. А оно там может быть и с чередованием по строкам, по столбцам, шахматкой, а может быть с видеокарты два видеовыхода, а как на линзовом растре, я вообще не знаю.
Вот как мне, не имея всего зоопарка оборудования и зоопарка коммерческих драйверов для 3D, всё же сделать, чтобы у того, у кого есть 3D, моя программа работала хорошо?
Принцип адресации переменных аналогичен тому, который у вложенных функциий, которыми замыкания и являются.
В Delphi, начиная с 2009, статический анализатор выделяет одни локальные переменные на стеке, а другие — на куче, при вхождении в область кода, которая их использует. В принципе, если в теле метода есть несколько замыканий, использующих несвязанные переменные, то можно делать несколько таких объектов. Как точно сделано в последней версии, не знаю. Для значений–замыканий действует счетчик ссылок, и сами эти значения ссылаются на объекты в памяти с теми локальными переменными, которые им нужны, тоже считая ссылки. И что–то похожее сделано в Blocks в Objective-C 2.0 (2009 г.), только переменные, которые можно изменять в блоке, нужно помечать ключевым словом, а непомеченные переменные будут доступны только как const, скопированные при создании экземпляра замыкания. В языке Ада, начиная с 2005, замыкания есть, но только нисходящие, поэтому нет счётчика ссылок. Теоретически компилятор мог бы хранить нисходящее замыкание в виде двух указателей код–данные, но в AdaCore похимичили и обошлись одним указателем на динамически сгенеренный код. Не знаю всех подробностей реализации, но сделано корректно, без TLS каких–нибудь. Делал функцию, которая сначала бурит рекурсией стек на несколько кадров, а потом считает число Фибоначчи, вызывая замыкания из засевших на стеке предыдущих экземпляров себя. Работает.
Ничего из этого мне не кажется чем–то особо сложным. Сопоставимо со сложностью разработки компилятора.
Не буду утверждать, что сильно нужна такая возможность. В некоторых стилях написания кода нужна, а в зелёнопоточных (кажется, Active Oberon именно такой) вместо лапши коллбеков может быть обмен сообщениями по каналу. Вот когда нет ни того, ни другого, тогда, конечно, у избалованного современными языками программирования программиста получается фрустрация от невозможности найти что–то привычное на привычном месте.
И его зелёнопоточная модификация Sparkel, которая среди зелёнопоточных языков программирования примечательна тем, что зелёные потоки создаются не только явно, но и неявно поперёк любой синтаксической конструкции, допускающей это. Вот только в текущей реализации я там не увидел библиотек для HTTP, а сам не готов тратить время на прикручивание, а так бы портировал некоторые скрипты с node.js.
Хм. Ну тогда можно подумать над тем, чтобы поставить круговой поляризатор вертикально, перед разделителем. Впрочем, тот комментатор, наверное знает больше на эту тему.
В теории — это действительно сделать можно. Но как будете заполнять области открытия теперь уже возникающие над и под объектами? )
Я ещё раз говорю, я не рассматриваю такую тяжёлую артиллерию. Мы делаем с обоими кадрами проективное преобразование, и никаких областей дополнительных не появляется и не убавляется. Берём сцену, находим в ней несколько острых углов предметов, эти углы в каждом кадре после преобразований должны оказаться на одной горизонтали. Для каждого острого угла создаём уравнение для идеального случая. Идеальным он, скорее всего, не получится, так что вместо решения уравнения минимизируем сумму квадратов разностей левых и правых частей уравнений. Несколько степеней свободы придётся устранить другим способом. Так, например, вдоль оси, проходящей через центры обоих глаз, можно вращаться, оставляя парные точки на одной горизонтали. От этой степени свободы можно избавиться, добившись того, чтобы после преобразований пришлось как можно меньше обрезать. У проективного преобразования 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 по–разному, не очень понятно, что с этим делать. Наверное, перекладывать задачу разметки на библиотеки времени выполнения.
В сервисах типа StartSSL я видел «упрощённый» механизм, где они могут сразу на сайте дать и сертификат, и ключ для сервера, правда, с комментарием, что это не очень безопасно, и корректный вариант там всё равно был.
Надо посмотреть, как будет у нас реализовано. В StartSSL можно было получить сертификат только на один поддомен, но, правда, таких сертификатов можно было заказать кучу и объединить потом через SNI, но как же это геморройно, да и OrenOSP больше 6 сертификатов в SNI не поддерживает, так что у меня, например, не влезло.
Если наш УЦ не будет пытаться нажиться на wildcard и множественных доменах в одном сертификате, это будет отлично, я считаю.
У меня на нете стоят Pidgin, QQ, Skype. Про указанные Telegram и Viber я слышал только краем уха, но Telegram вроде бы нормальный. По мне, так нетбук — вполне себе мобильное устройство. На нём и MathCAD, и LabVIEW, и большинство IDE запустятся, если надо, и что–то специфичное именно для мобильных устройств могло бы работать.
Желания дополнительно к нетбуку покупать дорогой сканнер QR–кодов, бесполезный в остальных качествах, как–то не имею. Посканировать QR можно и на нетбуке. Я не знаю, насколько близки WhatsApp и WeChat, но вот сумасшедшие китайцы любят WeChat, у которого, в отличие от WhatsApp, из нормальных OS есть Mac OS X, правда, слишком новее, чем у меня под рукой, и мне, чтоб с ними пообщаться, пришлось ставить эмулятор Android и сканировать в нём QR–код с экрана, и тогда можно писать в браузере. Если у WhatsApp такая же система, то это уже множественный вход.
В общем, ну не понимаю я прикола не делать приложения для 3х основных OS. У Microsoft есть даже Project Islandwood, средство портирования iOS приложений на Windows, ну сделали бы хоть порт на Windows, Бог с ней с Ubuntu Touch или Nokia N900. Я не понимаю, почему эти разработчики выкобениваются.
Интересно было бы сравнить Эльбрус+LCC и CHERI+BERI. CHERI поизвестнее LCC будет, однако внезапно Эльбрус у нас оказался более массовым, а я думаю, Эльбрусов выпущено гораздо больше, чем BERI.
Делать порты под зоопарк операционок, учитывая, что архитектура процессора практически везде какая–нибудь из ограниченного набора — это действительно не здоровая ситуация. Должно быть: одна архитектура — один файл.
Появись такая платформа — возможности экспериментировать с разными OS повысились бы.
А вот либералы, которых всё никак не выпнуть не получается, — другое дело. Там, глядишь, и нежданчиков, могущих помешать окончить ВУЗ, и превращающих это занятие в аркадную игру типа «Супер Марио», станет поменьше, и перекройка–таки будет сделана.
Обратной стороной их системы является то, что, если забить на их DNS, то вообще как будто ничего и не было.
Я по этой теме не нашёл информации в wiki
Там только:
Причём, ссылка на Windows Runtime API — внешняя, на MSDN. А хотелось бы поинтересоваться, как именно оно там взяло и начало поддерживаться? Я же помню, что в Metro у Delphi попасть не получилось, чужих туда не пустили. Ada не пустили, Delphi не пустили. Пришлось городить Metropolis для как бы Metro UI и костыльные прокси для Live Tile.
А тут бац — и
…без каких–либо комментариев. Что, вот так вот просто? Всё решилось? Как решилось? Почему раньше не решалось, а сейчас решилось? Или тут какой–то подвох?
Эмм? Вечная мировая революция была по планам меньшевиков, вроде тех, что были пассажирами парохода «Христиания-Фьорд», а у большевиков были планы строительства социализма в отдельно взятой стране
Я знаю, что есть куча разных технологий для отображения 3D. У NVidia свой стереодрайвер, у AMD раньше был iZ3D (на моей Win8 он вешает систему), и ещё там в комплекте к какому–нибудь монитору со встроенной поддержкой 3D может быть вообще что–то неведомое, не связанное с производителями видеокарт. Мониторы с линзовым растром представляют особый интерес, так как у них количество одновременных ракурсов может быть больше двух. И у разных производителей разное SDK. Вот мне бы больше понравилось, если бы я средствами OS мог управлять картинками для разных ракурсов (например, я хочу получить HDC окна для левого и правого глаза отдельно, но не вижу этого в WinAPI), но разработчики OS, видимо, не на одной со мной волне, и пихают в OS что–то другое, а стерео оставляют на откуп куче разных производителей, каждый со своим SDK. Что их объединяет — так это то, что Direct3D или OpenGL графика делаются 3D автоматически.
А если я не хочу эту автоматику, я не знаю, как быть. Может быть, я рейтрейсингом картинку генерю? Или, может быть, у меня игра–платформер с несколькими слоями, и я не хочу слои уровня делать текстурами, а хочу обойтись инструментами 2D графики. Или вот, захотелось мне DOSBox улучшить, чтобы режим Crystal Eyes в Duke Nukem 3D средствами DOSBox форвардился на современное 3D оборудование. А оно там может быть и с чередованием по строкам, по столбцам, шахматкой, а может быть с видеокарты два видеовыхода, а как на линзовом растре, я вообще не знаю.
Вот как мне, не имея всего зоопарка оборудования и зоопарка коммерческих драйверов для 3D, всё же сделать, чтобы у того, у кого есть 3D, моя программа работала хорошо?
В Delphi, начиная с 2009, статический анализатор выделяет одни локальные переменные на стеке, а другие — на куче, при вхождении в область кода, которая их использует. В принципе, если в теле метода есть несколько замыканий, использующих несвязанные переменные, то можно делать несколько таких объектов. Как точно сделано в последней версии, не знаю. Для значений–замыканий действует счетчик ссылок, и сами эти значения ссылаются на объекты в памяти с теми локальными переменными, которые им нужны, тоже считая ссылки. И что–то похожее сделано в Blocks в Objective-C 2.0 (2009 г.), только переменные, которые можно изменять в блоке, нужно помечать ключевым словом, а непомеченные переменные будут доступны только как const, скопированные при создании экземпляра замыкания. В языке Ада, начиная с 2005, замыкания есть, но только нисходящие, поэтому нет счётчика ссылок. Теоретически компилятор мог бы хранить нисходящее замыкание в виде двух указателей код–данные, но в AdaCore похимичили и обошлись одним указателем на динамически сгенеренный код. Не знаю всех подробностей реализации, но сделано корректно, без TLS каких–нибудь. Делал функцию, которая сначала бурит рекурсией стек на несколько кадров, а потом считает число Фибоначчи, вызывая замыкания из засевших на стеке предыдущих экземпляров себя. Работает.
Ничего из этого мне не кажется чем–то особо сложным. Сопоставимо со сложностью разработки компилятора.
Не буду утверждать, что сильно нужна такая возможность. В некоторых стилях написания кода нужна, а в зелёнопоточных (кажется, Active Oberon именно такой) вместо лапши коллбеков может быть обмен сообщениями по каналу. Вот когда нет ни того, ни другого, тогда, конечно, у избалованного современными языками программирования программиста получается фрустрация от невозможности найти что–то привычное на привычном месте.
Я ещё раз говорю, я не рассматриваю такую тяжёлую артиллерию. Мы делаем с обоими кадрами проективное преобразование, и никаких областей дополнительных не появляется и не убавляется. Берём сцену, находим в ней несколько острых углов предметов, эти углы в каждом кадре после преобразований должны оказаться на одной горизонтали. Для каждого острого угла создаём уравнение для идеального случая. Идеальным он, скорее всего, не получится, так что вместо решения уравнения минимизируем сумму квадратов разностей левых и правых частей уравнений. Несколько степеней свободы придётся устранить другим способом. Так, например, вдоль оси, проходящей через центры обоих глаз, можно вращаться, оставляя парные точки на одной горизонтали. От этой степени свободы можно избавиться, добившись того, чтобы после преобразований пришлось как можно меньше обрезать. У проективного преобразования 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 по–разному, не очень понятно, что с этим делать. Наверное, перекладывать задачу разметки на библиотеки времени выполнения.