Ну безусловно при выходе уровней за пределы физических возможностей сенсора, там уже вряд ли что-то сделаешь. Но до этого, поигравшись с аппаратными возможностями, фильтрацию шумов при разных средних уровнях освещенности можно уменьшить лучше, чем при пост-обработке софтом.
Вот и я о том же — при современной экспансии стерео-фото и 3D-видео в бытовой сегмент, все-таки, кмк, лучше купить специально для этого сделанную 3D-камеру и возможно расширять ее возможности аксессуарами, чем ковыряться с возможностями изначально не заточенных под это девайсов. Как для DIY с академическим интересом — да, это можно. Но для деятельности, где некогда распыляться на промежуточную подстройку и обработку — уже не комильфо.
>> А ISO можно будет и в фотошопе вытянуть, шум получится таким же.
Не совсем. Зависит от метода настройки ISO. При чисто софтовом будет то же, что и вытяжка в фотошопе. Но еще может быть аппаратный метод. Там все капельку сложнее. Получается эквивалент того, что мы на входы АЦП подключаем разные резисторные делители и подстраиваем коэффициенты усиления, таким образом настраивая чувствительность и борясь с «зашкаливанием» АЦП при разных диапазонах входных уровней сигнала.
В итоге получается конечно не сильно далеко от «вытяжки в фотошопе», но тем не менее — несколько чище и качественнее.
Кстати, на счет стереофоток я вроде уловил вашу идею по поводу «с разных краев объектива», но все-равно не очень понимаю. Объектив у нее довольно мал для нормальной стереобазы — это только для макро подойдет.
Стереонасадки, как для обычных камер ( пример1, пример2 ), я не верен, что подойдут, ибо простая оптика адаптеров не факт, что будет совместима с «угловой» оптикой этой камеры. Либо насадка должна быть со спецоптикой, которая и будет проецировать картинки как раз таки на края объектива — стоимость таких насадок сравнится со стоимостью камеры.
Еще как вариант — связка из двух таких камер на рейке с регулируемой стереобазой, синхронизатором затворов и постобработкой в софте. Но, соответственно — это дороже )
Ну коли так, значит быстрое движение выпадет из фич, я и не надеялся на спорт-режимы особо — эта же камера по сути аналог «мыльниц», только со своими плюшками, в отличии от обычных. Точечная вспышка(не куча расставленных по периметру пых) вредна будет и так и эдак — за счет теней на снимке получится эффект «на фоне фотообоев» для любой камеры.
Однако при недостаточной освещенности если обычная камера без пыхи тупо не успеет поймать фокус, то здесь по крайней мере этой проблемы по идее быть не должно. Что уже неплохо для определенных ситуаций.
В общем все это надо тестировать.
Ну это вы как-то из крайности в крайность )
До голограмм им еще далеко, данная камера для более простых вещей. Что же касается мультифокуса описанным вами методом — да, это конечно же можно сделать. Но придется каждое такое фото делать постановочным со всеми заморочками, таймингами и т.п. Динамику в движении снимать таким способом если не невозможно, то трудно. Здесь же — щелк, и пошел дальше. В этом вся прелесть — в простоте. И безусловно то, что они размазывают световое поле по 11 мегапикселям, даст в результате рендер картинки с постоянным фокусом гораздо меньшего разрешения, т.е. в отрендеренном результате будет далеко не 11 Мпкс — тут вроде все понятно, фотки на выходе по разрешению вряд ли сравнятся с фотками с профессиональных камер.
Тем не менее, надо дождаться полного обзора после продолжительного использования, чтобы понять, что можно получить на выходе, какого качества и в каких условиях как эта камера себя ведет — типа ограниченного освещения в помещении, вечером в сумерках, ночью на улице с кучей слепящей светящейся рекламы и без нее, ну и т.п.
К примеру, съемка простых репортажных фоток на выставках. Не для глянца, а просто для блога, где не нужно большое разрешение фоток в статье, достаточно приемлемого качества, просто не ниже определенного уровня. И если на автошоу, к примеру, на свете не экономят, там освещено все хорошо, то те же выставки собак/кошек проходят обычно в больших залах, где никто особо светом не занимается. Плюс собак в ринге заставляют бегать по кругу и поймать момент без преднастройки довольно затруднительно — если при беготне собак по кругу в объективе на фоне то светлое окно, то темная стена, то толпа народа в разноцветном одеянии. С обычной камерой качество можно получить, если притащить с собой кучу оборудования, штативы, организовать собственный свет. Если же есть только камера, получается хорошо не очень часто — то смазанно, то вспышка все портит, то еще что… Вот тут эта Lytro *возможно* даст необходимую простоту съемки при приемлемом качестве на выходе. Щелкнул и пошел дальше, без необходимости возиться с настройками и т.п.
В общем, ждем полного обзора, а там будет видно, на что оно годится, а на что — нет.
Точно. А лучше через 2-3 недельки.
С гаджетами почти всегда так — первые впечатления как правило ничего не стоят. Нужно поиграться подольше, пока не наиграешься, и уже потом обзор будет взвешенный, со всеми выявленными плюсами и минусами(хотя бы основными) и т.п.
Я тоже довольно давно на эту камеру облизываюсь и жду адекватных обзоров от людей, кто с ней уже наигрался и может сказать что-то существенное.
Так что присоединяюсь к совету. Автор, лучше спрячьте в черновики, и когда натестируетесь в разных условиях и с разными настройками или чем там еще, тогда и публикуйте, включая свое мнение о плюсах и минусах как технологии, так и конкретной реализации, в т.ч. о софте — с удовольствием почитаем.
Еще на eBay заказать можно.
В свое время взял оттуда сотню 2016 и сотню 2032 батареек для всяких мелких гаджетов типа светящегося ошейника для собаки и брелков сигналок. Обошлись обе сотни где-то в $10, при чем половина из них — доставка. И хватит такого набора на годы.
Зато у нас барыги такие продают местами по 200-600 рублей за штуку «потому что швейцарские и редкие».
Пы.Сы. Вообще, как я понимаю, вот эти или подобные базовые технологии лежат в основе 3D-карт и от Гугл и от Эппл:
Можно посмотреть ролик о том, как это все снимается и обрабатывается.
Ну и на Хабре уже была статья об вот этом сервисе, который построен на базе того, что описывается в ролике.
Ну когда на самом деле доберутся — еще не известно.
На картинке показана, как я понимаю, первая бета iOS6 с новыми «негугловыми» картами Минска.
И многие уже по новостным сайтам успели обсмеять Эппл, что мол покрытия нет, какой позор, ах-ах-ах.
Но не многие учитывают, что это всего лишь первая бета. Учитывая, что провайдером карт будет Том-Том, можно предположить, что к выходу релиза прошивки по крайней мере Том-Томовские схематические карты все-таки уже будут работать. Покрытие наших кириллических стран там конечно послабее Гугля, но далеко не так слабо, как на данном скриншоте.
3D конечно до наших краев доберется вероятно еще не скоро, но обычные схемы и спутник — должны по идее.
А пока в бета-версии(тем более в первой) разработчикам для тестирования в большинстве случаев вполне достаточно и американского покрытия карт. А там к релизу «будем посмотреть». Если к тому моменту не выложат карты — вот тогда да, можно будет высказать дружное «фи!»ю А до того момента — просто нет смысла это обсуждать.
А зачем изначально преувеличивать роль 3D или StreetView карт, чтобы потом охаять?
Кроме предварительных виртуальных прогулок по этим картам с целью наметить места «для погулять», так же в них полезно и обратное: когда вам изначально нужно попасть по такому-то адресу, кроме нахождения на схеме и прокладки маршрута, неплохо бы еще и заранее, хотя бы вскользь, осмотреть место прибытия, чтоб заранее понять — в какую именно дверь здания заходить, где здесь парковка, как организовано движение(дорожные знаки, разметка) и прочие нюансы, чтоб на месте не тупить, а сразу идти/ехать «по цели». Да даже простой пример — на Садовом нужно в определенный дом — глянул StreetView или 3D как он выглядит, наметил себе ориентир типа «такой низенький домик между двумя вот такенными, вроде поблизости такого же сочетания нет больше», и все, по навигатору как только встал на Садовое(читай финишная прямая) — больше не надо, создавая опасные ситуации, пялиться в навигатор и высчитывать в голове сколько ехать осталось — нужное место узнаешь издалека и четко к нему подрулишь.
Что StreetView, что 3D-карты вполне дадут приблизительную картину нужной местности, и даже учитывая различия картинок зимой/летом, все-равно более-менее позволят сориентироваться.
Для прогулочных задач в случае с 3D гораздо проще «пролететь над городом» и выбрать районы прогулок типа «где повыше небоскребы» и т.п. С одним только StreetView на уровне роста пешехода и плоскими спутниковыми снимками это сделать несколько сложнее/дольше.
Кроме прочего, представленные 3D-карты — это не совсем 3D модели с натянутыми текстурами. Это обработанная компом аэрофотосъемка, натянутая на каркас местности, построенный по принципам «стереозрения» из того же отснятого с воздуха материала.
Если угодно, раньше у гугля(в Google Earth) была просто карта высот и натянутая на нее текстура спутниковых снимков. Масштаб их позволял ориентироваться на местности только в целом. Удобно было в Крыму например видеть, где ехать придется по горам, а где по равнинам. А текущие 3D-карты — это уже более детализированная технология, издалека похожая по основным принципам на предыдущую, но дающая на выходе уже не просто карту высот, но более сложные рельефные поверхности с подробностями в масштабах города. Фотокачества детализации «моделей» пока что в общем-то никто от них и не требует.
Как-то так.
В любом случае, она вполне полезна, как опция — никто у пользователя не отнимает обычной схематической карты без излишних подробностей. То есть была бы понятна суть вопроса, если бы он звучал так:«Заменят ли 3D-карты обычные спутниковые и схематические?». Но такого вопроса ведь не стоит — никто ничего не заменяет, а лишь дополняет )
Если же говорить о сравнении 3D и StreetView карт между собой, то в условиях ограниченной скорости подключения(3G) последние дадут более фотореалистичную картинку конкретного места, но первые позволят быстрее «пробежаться» по всему маршруту(оптимизированная подгрузка рельефа и тайлов текстур более похожа на «классические» карты), рассмативая всю попутную местность с большей высоты без излишних фотоподробностей.
Ну так-то оно так, но это скорее уже к системным сервисам относится, чем к демону как таковому.
Здесь, как я понимаю, автор привел схему простейшей демонизации php-скрипта, главнейшая цель которой — отвязать скрипт от терминала и дать ему работать в фоне «вечно». Со своими обязанностями класс справляется.
Предложенные вами вещи конечно неплохо бы дописать(коль уж вываливаем на всеобщее обозрение в репозитарий), но пусть они тогда будут отключаемыми.
Ну может конфиг при создании класса передавать какой с настройками.
У меня еще при стартах демонов выполняются такие вещи:
Если IS_WIN, то демонизация не происходит — запускается просто как консольный скрипт. Винда — это отладочный полигон.
=====================
Ну и еще допишу, это уже не на ваш комментарий, а автору поста на заметку(лениво новый камент писать).
У меня при создании подробнейших логов(tcp-сервер все-таки, писать в логи всегда есть чего) как-то обнаружилось, что логи больно дофига места занимают. И соответственно потом при жалобах, что кто-то чего-то не смог разобраться в системе, когда надо лезть в логи и смотреть, чего там юзер куда клацал и куда ломился, оказывается, что скакать по большим логам в общем-то удовольствие сомнительное.
Поэтому были дописаны некоторые авто-функции:
Тыц сюда
function gen_log_subdir() {
$tmv=time();
return sprintf('%08X_', $tmv).date("dmY_His", $tmv);
}
function check_log_subdir($tsize=100000000) {
$root=$this->log_dir.$this->log_subdir;
$res=0;
if ($dir = @opendir($root)) {
while (($file = @readdir($dir)) !== false) {
$fn=$root.$file;
if (is_file($fn)) {
$res+=@filesize($fn);
if ($res>$tsize) break;
}
}
@closedir($dir);
}
$this->log_add=sprintf('%10u', $res);
return ($res<$tsize);
}
function get_log_subdir() {
$suf=($this->log_subdir=='')?'_':'';
while ($this->log_subdir=='' || !$this->check_log_subdir()) {
$this->log_subdir=$this->gen_log_subdir().$suf.'/';
}
$lsd=$this->log_dir.$this->log_subdir;
if (!file_exists($lsd)) mkdir($lsd);
return $this->log_subdir;
}
function log_subdir() {
return $this->log_dir.$this->get_log_subdir();
}
function print_log($str) {
$this->log_file=$this->log_subdir()."daemon.log";
$fp = @fopen ($this->log_file, "ab");
if (!$fp) return false;
if (@flock($fp, LOCK_EX)) {
if ($str!='') $str=date("[d-m-y H:i:s] ").'['.$this->log_add.']'.$str;
fputs ($fp, $str."\n");
@flock($fp, LOCK_UN);
} else {
@fclose ($fp);
return false;
}
@fclose ($fp);
return true;
}
Привожу их как есть, красиво форматировать «для всех» некогда. Впрочем это просто идея, реализация может быть и другой, более продуманной.
Смысл этих функций — писать логи, разбивая их на куски.
То есть мы при старте создаем субдиректорию с человекочитаемой временной меткой и символом '_' в конце имени, пишем в нее логи. Как только размер логов в этой субдиректории достигают заданного размера, мы генерим новую субдиректорию с временной меткой в имени, но уже без '_' в конце, и продолжаем писать логи уже в нее. И так далее.
Метка '_' в имени ставится только первой субдиректории при старте демона, поэтому глядя в подкаталог логов можно сразу видеть в какое время был старт(рестарт) демона.
Если нужно найти логи за определенное время, в списке поддиректорий сразу можно понять, в какую надо идти и какой лог смотреть. Это удобнее, чем гигабайтные портянки логов листать.
Подробные логи всегда дублируются общим неподробным. Туда пишутся только имена пришедших комманд и временные метки. В результате на 100метровую директорию неподробный лог метра четыре весит. По нему быстро можно глянуть, в какое точно время началась активность нужного юзера, а потом уже по этой метке найти в подробном логе все параметры комманд, ответы сервера и т.п.
Первые 8 HEX-символов это unix timestamp, который далее идет расшифрованным, как [uts_дата_время].
По меткам '_' видим, что демон стартовал 15.11.2011 в 16:29:01, работал несколько месяцев, был перезапущен 07.03.2012 в 13:35:28 (обновление исходников, поддержка новых комманд).
В основном коде сервака вызывается только функция print_log(), как-то так:
$daemon->print_log("alarm! very important tcp-client connected") ;
А там оно само разбирается, в какой лог в какой поддиректории писать.
В результате(пример из реальных данных) в неподробном логе появляется что-то типа:
Заголовок пакета — 16 байт. То есть каждая первая строчка HEX-лога.
Все, что передано в пакете после заголовка, «расшифровывается» сразу за дампом пакета.
Внешние утилиты и их вывод в консоль при надобности контролируются пайпами.
Шаблоны и прочую лабуду я динамически к демонам не подключаю. Предпочитаю не создавать себе проблем заранее. Шаблоны если нужны — их можно вместо прямого подключения парсить. Тут вам выбор и раздолье: хоть кусками фиксированной длины через парсер прогоняйте, чтоб лишнюю память не жрать. Как реализовать правильный парсер — отдельная тема. А то вы мне опять тут сейчас скажете «низя не в коем случае» ))
«core dumped» и «segmentation fault» у меня такая редкость, что можно если что в режиме консоли запустить и погонять.
У меня все и так замечательно и устойчиво работает. Кроном я простые скрипты запускаю, которые и нужно запускать кроном. Но крону — кроново, а демону — демоново. Накой мне крон, когда мне нужен демон?
А где указано, что deprecated? Не знал.
Я правда сигналами и не пользуюсь, завязываю все их на SIG_IGN, а демоны между собой общаются по TCP по своему протоколу. Так вроде глюков нет, все пучком.
«Грязные» — это какие? Какие логи ошибок лезут в STDOUT и которые нельзя при этом перехватить через хандлеры в set_error_handler() и set_exception_handler()?
PHP делался для веба, и в частности CLI-версия предполагает, что при запуске из-под сервака в CGI-режиме лишнее в STDOUT валиться не должно.
Поэтому указанными выше хандлерами можно перехватить почти все, кроме критических ошибок на этапе предкомпиляции скрипта — но тут скрипт и не запустится вообще.
P.S. под error_reporting функциями я имел в виду именно набор функций работы с error_reporting, а не саму функцию error_reporting().
P.S. ну еще можно error_reporting функции заюзать и отлавливать PHP-шные сообщения там и писать в файл. Тже метод, если нужно для отладки. Критические ошибки парсинга он при попытке запуска в консоль вывалит, остальные будут писаться куда надо.
Зачем? Смысл-то переназначения STDERR как раз в том, чтобы ошибки и ворнинги самого PHP туда валились. Добавляя put_err(), вы просто плодите функции print_log().
Ну я выше писал, я забил на этот глюк. Переназначение-то делаю, чтоб сокетам работать не мешало, но рельно этими файлами не пользуюсь.
Действительно, ПОКА. Вы, как я вижу, оптимист )))
Не, я вторым способом пишу обычно.
А иногда и обратный while применяю, где это выгоднее и допустим рекурсивный отсчет:
А, забейте, это внутренняя кухня PHP балуется )
Константы STDOUT/STDERR остались 2 и 3 соответственно, но связанные с ними дескрипторы ресурсов(видимые из скрипта) захлопнулись. Вот fprintf и не хочет в числовые дескрипторы писать. Ему объект ресурса подавай.
Связать опять дескрипторы с этими константами мы не можем — это ж мало того, что константы, так еще и системные.
Я тоже гонял это в разных вариантах. Не хочет и все тут.
Ну забил и юзаю только STDOUT-файл — ворнинги если есть, туда же валятся.
Да и тем более это крайняя редкость, сам код демона все-равно в отдельные логи все что нужно пишет.
Но тем не менее надо помнить — если уж STDOUT/STDERR закрыли, то надо с этим что-то делать. В закрытом виде бросать нельзя.
Иначе, если у вас в демоне сервер, он начнет акцептить клиентов и первые соединения попадут на дескрипторы STDERR/STDOUT, и тогда любой ворнинг может клиенту в сокет уйти вместо STDERR.
Не совсем. Зависит от метода настройки ISO. При чисто софтовом будет то же, что и вытяжка в фотошопе. Но еще может быть аппаратный метод. Там все капельку сложнее. Получается эквивалент того, что мы на входы АЦП подключаем разные резисторные делители и подстраиваем коэффициенты усиления, таким образом настраивая чувствительность и борясь с «зашкаливанием» АЦП при разных диапазонах входных уровней сигнала.
В итоге получается конечно не сильно далеко от «вытяжки в фотошопе», но тем не менее — несколько чище и качественнее.
Стереонасадки, как для обычных камер ( пример1, пример2 ), я не верен, что подойдут, ибо простая оптика адаптеров не факт, что будет совместима с «угловой» оптикой этой камеры. Либо насадка должна быть со спецоптикой, которая и будет проецировать картинки как раз таки на края объектива — стоимость таких насадок сравнится со стоимостью камеры.
Еще как вариант — связка из двух таких камер на рейке с регулируемой стереобазой, синхронизатором затворов и постобработкой в софте. Но, соответственно — это дороже )
Однако при недостаточной освещенности если обычная камера без пыхи тупо не успеет поймать фокус, то здесь по крайней мере этой проблемы по идее быть не должно. Что уже неплохо для определенных ситуаций.
В общем все это надо тестировать.
До голограмм им еще далеко, данная камера для более простых вещей. Что же касается мультифокуса описанным вами методом — да, это конечно же можно сделать. Но придется каждое такое фото делать постановочным со всеми заморочками, таймингами и т.п. Динамику в движении снимать таким способом если не невозможно, то трудно. Здесь же — щелк, и пошел дальше. В этом вся прелесть — в простоте. И безусловно то, что они размазывают световое поле по 11 мегапикселям, даст в результате рендер картинки с постоянным фокусом гораздо меньшего разрешения, т.е. в отрендеренном результате будет далеко не 11 Мпкс — тут вроде все понятно, фотки на выходе по разрешению вряд ли сравнятся с фотками с профессиональных камер.
Тем не менее, надо дождаться полного обзора после продолжительного использования, чтобы понять, что можно получить на выходе, какого качества и в каких условиях как эта камера себя ведет — типа ограниченного освещения в помещении, вечером в сумерках, ночью на улице с кучей слепящей светящейся рекламы и без нее, ну и т.п.
К примеру, съемка простых репортажных фоток на выставках. Не для глянца, а просто для блога, где не нужно большое разрешение фоток в статье, достаточно приемлемого качества, просто не ниже определенного уровня. И если на автошоу, к примеру, на свете не экономят, там освещено все хорошо, то те же выставки собак/кошек проходят обычно в больших залах, где никто особо светом не занимается. Плюс собак в ринге заставляют бегать по кругу и поймать момент без преднастройки довольно затруднительно — если при беготне собак по кругу в объективе на фоне то светлое окно, то темная стена, то толпа народа в разноцветном одеянии. С обычной камерой качество можно получить, если притащить с собой кучу оборудования, штативы, организовать собственный свет. Если же есть только камера, получается хорошо не очень часто — то смазанно, то вспышка все портит, то еще что… Вот тут эта Lytro *возможно* даст необходимую простоту съемки при приемлемом качестве на выходе. Щелкнул и пошел дальше, без необходимости возиться с настройками и т.п.
В общем, ждем полного обзора, а там будет видно, на что оно годится, а на что — нет.
С гаджетами почти всегда так — первые впечатления как правило ничего не стоят. Нужно поиграться подольше, пока не наиграешься, и уже потом обзор будет взвешенный, со всеми выявленными плюсами и минусами(хотя бы основными) и т.п.
Я тоже довольно давно на эту камеру облизываюсь и жду адекватных обзоров от людей, кто с ней уже наигрался и может сказать что-то существенное.
Так что присоединяюсь к совету. Автор, лучше спрячьте в черновики, и когда натестируетесь в разных условиях и с разными настройками или чем там еще, тогда и публикуйте, включая свое мнение о плюсах и минусах как технологии, так и конкретной реализации, в т.ч. о софте — с удовольствием почитаем.
В свое время взял оттуда сотню 2016 и сотню 2032 батареек для всяких мелких гаджетов типа светящегося ошейника для собаки и брелков сигналок. Обошлись обе сотни где-то в $10, при чем половина из них — доставка. И хватит такого набора на годы.
Зато у нас барыги такие продают местами по 200-600 рублей за штуку «потому что швейцарские и редкие».
Можно посмотреть ролик о том, как это все снимается и обрабатывается.
Ну и на Хабре уже была статья об вот этом сервисе, который построен на базе того, что описывается в ролике.
На картинке показана, как я понимаю, первая бета iOS6 с новыми «негугловыми» картами Минска.
И многие уже по новостным сайтам успели обсмеять Эппл, что мол покрытия нет, какой позор, ах-ах-ах.
Но не многие учитывают, что это всего лишь первая бета. Учитывая, что провайдером карт будет Том-Том, можно предположить, что к выходу релиза прошивки по крайней мере Том-Томовские схематические карты все-таки уже будут работать. Покрытие наших кириллических стран там конечно послабее Гугля, но далеко не так слабо, как на данном скриншоте.
3D конечно до наших краев доберется вероятно еще не скоро, но обычные схемы и спутник — должны по идее.
А пока в бета-версии(тем более в первой) разработчикам для тестирования в большинстве случаев вполне достаточно и американского покрытия карт. А там к релизу «будем посмотреть». Если к тому моменту не выложат карты — вот тогда да, можно будет высказать дружное «фи!»ю А до того момента — просто нет смысла это обсуждать.
Кроме предварительных виртуальных прогулок по этим картам с целью наметить места «для погулять», так же в них полезно и обратное: когда вам изначально нужно попасть по такому-то адресу, кроме нахождения на схеме и прокладки маршрута, неплохо бы еще и заранее, хотя бы вскользь, осмотреть место прибытия, чтоб заранее понять — в какую именно дверь здания заходить, где здесь парковка, как организовано движение(дорожные знаки, разметка) и прочие нюансы, чтоб на месте не тупить, а сразу идти/ехать «по цели». Да даже простой пример — на Садовом нужно в определенный дом — глянул StreetView или 3D как он выглядит, наметил себе ориентир типа «такой низенький домик между двумя вот такенными, вроде поблизости такого же сочетания нет больше», и все, по навигатору как только встал на Садовое(читай финишная прямая) — больше не надо, создавая опасные ситуации, пялиться в навигатор и высчитывать в голове сколько ехать осталось — нужное место узнаешь издалека и четко к нему подрулишь.
Что StreetView, что 3D-карты вполне дадут приблизительную картину нужной местности, и даже учитывая различия картинок зимой/летом, все-равно более-менее позволят сориентироваться.
Для прогулочных задач в случае с 3D гораздо проще «пролететь над городом» и выбрать районы прогулок типа «где повыше небоскребы» и т.п. С одним только StreetView на уровне роста пешехода и плоскими спутниковыми снимками это сделать несколько сложнее/дольше.
Кроме прочего, представленные 3D-карты — это не совсем 3D модели с натянутыми текстурами. Это обработанная компом аэрофотосъемка, натянутая на каркас местности, построенный по принципам «стереозрения» из того же отснятого с воздуха материала.
Если угодно, раньше у гугля(в Google Earth) была просто карта высот и натянутая на нее текстура спутниковых снимков. Масштаб их позволял ориентироваться на местности только в целом. Удобно было в Крыму например видеть, где ехать придется по горам, а где по равнинам. А текущие 3D-карты — это уже более детализированная технология, издалека похожая по основным принципам на предыдущую, но дающая на выходе уже не просто карту высот, но более сложные рельефные поверхности с подробностями в масштабах города. Фотокачества детализации «моделей» пока что в общем-то никто от них и не требует.
Как-то так.
В любом случае, она вполне полезна, как опция — никто у пользователя не отнимает обычной схематической карты без излишних подробностей. То есть была бы понятна суть вопроса, если бы он звучал так:«Заменят ли 3D-карты обычные спутниковые и схематические?». Но такого вопроса ведь не стоит — никто ничего не заменяет, а лишь дополняет )
Если же говорить о сравнении 3D и StreetView карт между собой, то в условиях ограниченной скорости подключения(3G) последние дадут более фотореалистичную картинку конкретного места, но первые позволят быстрее «пробежаться» по всему маршруту(оптимизированная подгрузка рельефа и тайлов текстур более похожа на «классические» карты), рассмативая всю попутную местность с большей высоты без излишних фотоподробностей.
Здесь, как я понимаю, автор привел схему простейшей демонизации php-скрипта, главнейшая цель которой — отвязать скрипт от терминала и дать ему работать в фоне «вечно». Со своими обязанностями класс справляется.
Предложенные вами вещи конечно неплохо бы дописать(коль уж вываливаем на всеобщее обозрение в репозитарий), но пусть они тогда будут отключаемыми.
Ну может конфиг при создании класса передавать какой с настройками.
У меня еще при стартах демонов выполняются такие вещи:
Если IS_WIN, то демонизация не происходит — запускается просто как консольный скрипт. Винда — это отладочный полигон.
=====================
Ну и еще допишу, это уже не на ваш комментарий, а автору поста на заметку(лениво новый камент писать).
У меня при создании подробнейших логов(tcp-сервер все-таки, писать в логи всегда есть чего) как-то обнаружилось, что логи больно дофига места занимают. И соответственно потом при жалобах, что кто-то чего-то не смог разобраться в системе, когда надо лезть в логи и смотреть, чего там юзер куда клацал и куда ломился, оказывается, что скакать по большим логам в общем-то удовольствие сомнительное.
Поэтому были дописаны некоторые авто-функции:
Смысл этих функций — писать логи, разбивая их на куски.
То есть мы при старте создаем субдиректорию с человекочитаемой временной меткой и символом '_' в конце имени, пишем в нее логи. Как только размер логов в этой субдиректории достигают заданного размера, мы генерим новую субдиректорию с временной меткой в имени, но уже без '_' в конце, и продолжаем писать логи уже в нее. И так далее.
Метка '_' в имени ставится только первой субдиректории при старте демона, поэтому глядя в подкаталог логов можно сразу видеть в какое время был старт(рестарт) демона.
Если нужно найти логи за определенное время, в списке поддиректорий сразу можно понять, в какую надо идти и какой лог смотреть. Это удобнее, чем гигабайтные портянки логов листать.
Подробные логи всегда дублируются общим неподробным. Туда пишутся только имена пришедших комманд и временные метки. В результате на 100метровую директорию неподробный лог метра четыре весит. По нему быстро можно глянуть, в какое точно время началась активность нужного юзера, а потом уже по этой метке найти в подробном логе все параметры комманд, ответы сервера и т.п.
Первые 8 HEX-символов это unix timestamp, который далее идет расшифрованным, как [uts_дата_время].
По меткам '_' видим, что демон стартовал 15.11.2011 в 16:29:01, работал несколько месяцев, был перезапущен 07.03.2012 в 13:35:28 (обновление исходников, поддержка новых комманд).
В основном коде сервака вызывается только функция print_log(), как-то так:
А там оно само разбирается, в какой лог в какой поддиректории писать.
В результате(пример из реальных данных) в неподробном логе появляется что-то типа:
А в подробном такое(две принятые комманды и отосланные ответы на них):
Заголовок пакета — 16 байт. То есть каждая первая строчка HEX-лога.
Все, что передано в пакете после заголовка, «расшифровывается» сразу за дампом пакета.
Шаблоны и прочую лабуду я динамически к демонам не подключаю. Предпочитаю не создавать себе проблем заранее. Шаблоны если нужны — их можно вместо прямого подключения парсить. Тут вам выбор и раздолье: хоть кусками фиксированной длины через парсер прогоняйте, чтоб лишнюю память не жрать. Как реализовать правильный парсер — отдельная тема. А то вы мне опять тут сейчас скажете «низя не в коем случае» ))
«core dumped» и «segmentation fault» у меня такая редкость, что можно если что в режиме консоли запустить и погонять.
У меня все и так замечательно и устойчиво работает. Кроном я простые скрипты запускаю, которые и нужно запускать кроном. Но крону — кроново, а демону — демоново. Накой мне крон, когда мне нужен демон?
Я правда сигналами и не пользуюсь, завязываю все их на SIG_IGN, а демоны между собой общаются по TCP по своему протоколу. Так вроде глюков нет, все пучком.
PHP делался для веба, и в частности CLI-версия предполагает, что при запуске из-под сервака в CGI-режиме лишнее в STDOUT валиться не должно.
Поэтому указанными выше хандлерами можно перехватить почти все, кроме критических ошибок на этапе предкомпиляции скрипта — но тут скрипт и не запустится вообще.
P.S. под error_reporting функциями я имел в виду именно набор функций работы с error_reporting, а не саму функцию error_reporting().
Ну я выше писал, я забил на этот глюк. Переназначение-то делаю, чтоб сокетам работать не мешало, но рельно этими файлами не пользуюсь.
Не, я вторым способом пишу обычно.
А иногда и обратный while применяю, где это выгоднее и допустим рекурсивный отсчет:
Константы STDOUT/STDERR остались 2 и 3 соответственно, но связанные с ними дескрипторы ресурсов(видимые из скрипта) захлопнулись. Вот fprintf и не хочет в числовые дескрипторы писать. Ему объект ресурса подавай.
Связать опять дескрипторы с этими константами мы не можем — это ж мало того, что константы, так еще и системные.
Ну забил и юзаю только STDOUT-файл — ворнинги если есть, туда же валятся.
Да и тем более это крайняя редкость, сам код демона все-равно в отдельные логи все что нужно пишет.
Но тем не менее надо помнить — если уж STDOUT/STDERR закрыли, то надо с этим что-то делать. В закрытом виде бросать нельзя.
Иначе, если у вас в демоне сервер, он начнет акцептить клиентов и первые соединения попадут на дескрипторы STDERR/STDOUT, и тогда любой ворнинг может клиенту в сокет уйти вместо STDERR.