Это что же за сборщик мусора такой, который не умеет с циклическими зависимостями справляться? А что делать, если нужно использовать в обработчике element, а не только a и b?
Не знаю, как конкретно сделано у них, но рискну предположить, что камера и кинект непосредственно между собой никак не взаимодействуют. Скорее всего, камера и кинект оба подключены к компьютеру и одновременно снимают видео, в результате чего на компьютере получается поток видео+глубина. Остаются некоторые детали, например разные фокусные расстояния и нелинейные искажения у кинекта и камеры, но это можно исправить, если откалибровать камеру с помощью шахматной доски.
Действительно, тут нет sequence point нигде посередине, но мне казалось, что этот код нормально работает (видимо компилятор обычно компилирует это ожидаемым образом). Сравнение с i = i++ все-таки не самое правильное, тут такого сильного парадокса нет.
P.S.: промахнулся и поставил минус вместо плюса. Поставьте, пожалуйста, два плюса за меня.
1) Найти все замкнутые контуры.
2) Для каждого контура рассмотреть область, которую он ограничивает, и посчитать ее центр масс и центральные моменты второго порядка.
3) По формулам с той же страницы на википедии можно посчитать числа Θ, λ1 и λ2. Две лямбды — это длины полуосей эллипса, а Θ — это угол поворота главной оси. Кроме того, центр масс (x, y) будет определять центр эллипса. Понятно, что числа Θ, λ1, λ2, x, y однозначно задают эллипс.
4) Далее нужно проверить, насколько контур действительно похож на эллипс. Можно, например, посмотреть сколько пикселей принадлежит эллипсу, но не принадлежит контуру, или наоборот. Есть некоторый простор для фантазии и экспериментов.
5) Если контур действительно похож на эллипс, добавляем его к результату.
P.S.: 1 секунда на изображение 700x700 — многовато. Думаю, при грамотной реализации можно было бы выдавать как минимум 30 кадров в секунду даже на слабом компьютере.
<rant> Я далек от веб-разработки, но у меня такое ощущение, что все движется в не том направлении. В HTML не хватает нормальных средств для определения макета страницы. В былые времена, когда все делалось на таблицах, можно было без особых проблем, скажем, разбить страницу на три колонки и поставить height=100%, чтобы прибить футер к низу страницы. Таблицы были не особо универсальны, нарушали семантику, но работали достаточно надежно. Теперь все принято делать на DIV и CSS, якобы с целью отделения представления от семантики. Задумка хорошая, но модель позиционирования в HTML/CSS оставляет желать лучшего, не говоря уже про особенности ее интерпретации в различных браузерах. В результате появляется необходимость в каких-то вспомогательных элементах DIV, которые к семантике документа не имеют никакого отношения, и всяких невообразимых CSS-костылях. Сделать, например, более-менее приличную трехколоночную верстку, выглядящую одинаково хорошо во всех браузерах, представляется мне неоправданно трудной задачей. Работа HTML-верстальщиков — это, должно быть, настоящий кошмар. Стандарту HTML/CSS очень нужен какой-то более простой и гибкий способ задания макета страницы. </rant>
С точки зрения самого языка изменений немного. Пожалуй, наиболее видимое (с точки зрения программиста на Lua) отличие — теперь нет специальной переменной arg у функций с переменным числом аргументов, вместо нее нужно использовать многоточие. Также поменялась концепция «окружений» (environment) — функций setfenv/getfenv больше нет, и текущее окружение определяется специльной переменной с именем _ENV, находящейся в текущей области видимости.
С точки зрения реализации есть очень важное нововведние — функции lua_yieldk и lua_callk. Благодаря им можно передать управление из сопрограммы (coroutine) не только из кода на Lua, то и из C, с последующей возможностью продолжить сопрограмму. Это в том числе позволяет вызывает yield из метаметодов (что раньше делать было нельзя).
Кроме того, немного поменялось поведение таблиц со слабыми ключами (weak keys), но в большинстве случаев вам, скорее всего, это будет неважно.
Если есть проект, которому Вы хотели бы в будущем помочь, лучше выбрать его — не зря потратите время на изучение кода. Если просто хочется что-нибудь почитать, можно попробовать посмотреть на glib. Это хорошо спроектированная и документированная библиотека, на которой держится весь Gtk/Gnome и много еще что. В ней много всего интересного — от структур данных до работы с сокетами. Там тоже GNU-стиль отступов, но файл перед чтением всегда можно пропустить через indent с нужными опциями :).
Можно посмотреть на что-нибудь из известных сетевых демонов — apache или proftpd, например. Или на ядро Linux, если есть интерес (про его внутренности даже книжки есть).
Если хочется увидеть настоящий «хакерский» код на C с множеством макросов и сокращений, можно посоветовать интерпретатор языка Lua (http://www.lua.org/source/5.1/). С одной стороны — разбираться сложно, но с другой — все очень компактно и продумано до мелочей.
И K&R, и Allman оба хорошо читаются, и с табами по 4, и с табами по 8 (в последнем случае только если вы не делаете слишком много уровней вложенности).
По-моему, код GNU — не лучшее место для того, чтобы смотреть, как следует писать профессиональные программы. Как-то раз пришлось покопаться в gettext — там просто мрак. Глобальные переменные, файлы длиной в несколько тысяч строк, сплошное дублирование кода. Да и стиль выравнивания с фигурными скобками, вынесенными на два пробела, превращает код в абсолютно нечитаемую кашу. Не могу даже представить, кому пришло в голову использовать такой стиль.
Если кто вдруг решит действительно пользоваться, не забывайте, что подсмотреть можно с помощью обычных очков Polaroid (или любых других поляризующих), наклонив голову или очки под нужным углом.
Вы действительно могли бы так сказать в реальной жизни?
Flypaper — это же липкая бумага для ловли мух, какой еще самолетик.
Что, простите? Нельзя же фразеологизмы переводить дословно.
Альтернативный перевод из первого комментария действительно хорош.
P.S.: промахнулся и поставил минус вместо плюса. Поставьте, пожалуйста, два плюса за меня.
1) Найти все замкнутые контуры.
2) Для каждого контура рассмотреть область, которую он ограничивает, и посчитать ее центр масс и центральные моменты второго порядка.
3) По формулам с той же страницы на википедии можно посчитать числа Θ, λ1 и λ2. Две лямбды — это длины полуосей эллипса, а Θ — это угол поворота главной оси. Кроме того, центр масс (x, y) будет определять центр эллипса. Понятно, что числа Θ, λ1, λ2, x, y однозначно задают эллипс.
4) Далее нужно проверить, насколько контур действительно похож на эллипс. Можно, например, посмотреть сколько пикселей принадлежит эллипсу, но не принадлежит контуру, или наоборот. Есть некоторый простор для фантазии и экспериментов.
5) Если контур действительно похож на эллипс, добавляем его к результату.
Я бы рекомендовал вам для таких целей пользоваться библиотекой OpenCV. В ней есть все вам необходимое:
* Алгоритм Canny.
* Адаптивный порог
* Поиск замкнутых контуров
* Вычисление моментов дял контура
*… и многое другое. Полная документация доступна онлайн.
P.S.: 1 секунда на изображение 700x700 — многовато. Думаю, при грамотной реализации можно было бы выдавать как минимум 30 кадров в секунду даже на слабом компьютере.
С точки зрения реализации есть очень важное нововведние — функции lua_yieldk и lua_callk. Благодаря им можно передать управление из сопрограммы (coroutine) не только из кода на Lua, то и из C, с последующей возможностью продолжить сопрограмму. Это в том числе позволяет вызывает yield из метаметодов (что раньше делать было нельзя).
Кроме того, немного поменялось поведение таблиц со слабыми ключами (weak keys), но в большинстве случаев вам, скорее всего, это будет неважно.
Можно посмотреть на что-нибудь из известных сетевых демонов — apache или proftpd, например. Или на ядро Linux, если есть интерес (про его внутренности даже книжки есть).
Если хочется увидеть настоящий «хакерский» код на C с множеством макросов и сокращений, можно посоветовать интерпретатор языка Lua (http://www.lua.org/source/5.1/). С одной стороны — разбираться сложно, но с другой — все очень компактно и продумано до мелочей.