Да, надежда что разработка окажется столь распространенной и сподвигнет разработчиков дополнить свои игры поддержкой их контроллера — стремиться к нулю…
Интересно создание автоматизированных мини-ЦОДов, для объединения в распределенную сеть.
Представляю большой «шкаф» (2*10*4 метра или меньше), в котором находятся стойки и манипуляторы на рельсах для замены железа. Сбоку отделение с новыми серверами, на случай замены.
Такой мини-ЦОД может располагаться с подвале частных зданий и использоваться для обогрева (кроме собственно вычислений).
А техники только раз в год приезжают, привозят новое железо, забирают старое. Ну и чинят что-то чего не могут поменять манипуляторы…
Интересно, а информация о структуре «кучи» в которой эти фрагменты лежали сохранилась? Если в свое время археологи разбирали «завал» слоями — это бы очень упростило сейчас сравнение…
Кстати, раньше была очень удобная функция — можно было схватить мышкой «человечка» и на карте отрисовывались синим все дороги для которых есть панорамы. Особенно для масштаба страны — очень информативно было… В новом интерфейсе аналога не нашел, хотя возможно плохо искал.
Учитывая развитие google translate и похожих утилит, за то время пока будете дорабатывать продукт можно потерять ЦА.
ИМХО — как раз тут ключевым плюсом была бы дополненная реальность. Чтобы навести телефон на текст, а прога затирала его цветом фона и поверх выводила перевод в том же месте и с теми же искажениями… Если в реальном времени не получится — то хоть на готовой фотке.
Даже в тех макетах что у вас — google translate — просто выдал бы кучу неструктурированного текста, читать который крайне неудобно…
Как я понимаю их алгоритм как раз и позволяет определить какой байт файла читать чтобы узнать цвет конкретного пиксела для любого ракурса в пределах сцены.
Фактически — нужно знать где в файле описан пиксел который пересечет произвольная прямая (проекция луча зрения).
Видимо для этого в начале файла размещают индекс, в котором задана в неком виде конфигурация сцены, эта информация держится в памяти, и позволяет рассчитать пересечения для каждой прямой в пределах сцены.
Думаю что используется иерархия объемных блоков. Заголовок файла описывает сцену состоящую из больших блоков, скажем размером с дом. По этой информации можно для любой прямой вычислить какие блоки она пересечет. Эти блоки имеют известные адреса смещений в базе, и в начале каждого блока — идет описание дочерних блоков (размером около метра), это описание позволяет найти пересечения с любой прямой проходящей через данный блок (а не через всю сцену). Внутри них точно также хранятся блоки размером в дециметр, сантиметр, миллиметр, и т.п.
Получается что для одного экранного пиксела нужно произвести не одно, а несколько чтений с диска. Но так как рядом стоящих лучей очень много (мы ведь просчитываем картинку, а не случайные прямые) — то и информацию одного луча можно использовать при просчете соседей.
А если каждый блок будет хранить еще и общий оттенок, то получается нечто вроде jpg сжатия картинки — каждый новый уровень хранит отклонение цвета от родителя и поэтому может хранить не 24 бита, а существенно меньше…
Ну и если у пользователя скорость ограничена — можно смотреть цепочку блоков не до конца, а меньше — качество картинки будет хуже, но и читать с диска придется меньше.
Из пожеланий — думаю недостает фильтров накладываемых после восстановления, причем учитывающих характер вносимых артефактов.
Например. Бросаются в глаза цветные полосы и шум на серых участках изображения (на текстах, на стене рядом с ежиком и т.п.) — однако понятно что если в окрестностях некоторой точки на смазанном изображении цветовая насыщенность низкая — то и на восстановленном она вероятнее всего будет низкая. Можно говорить что интеграл насыщенности в некоторых окрестностях восстановленного изображения, не более чем в k-раз больше аналогичного интеграла на размытом изображении. k — можно найти экспериментально, и он явно будет расти в зависимости от размеров смаза, но думаю не превысит 2-3 в типичных случаях.
Практически любой алгоритм подавления шумов в данном случае можно будет улучшить т.к. имеется размытая версия изображения. Лучше всего мне кажется подошел бы вейвлет-анализ, с внесением корректив в каждый из слоев ориентируясь на оригинал.
Особенно это даст заметный эффект на восстановлении текста, что может быть весьма актуально например для студентов снимающих конспекты на телефон:)
Второй пример. Программа великолепно справляется детализированными фрагментами, но в однородных областях — появляются волнообразные артефакты с периодом равным величине смаза. Используя упомянутые вейвлет преобразования (частотные слои) — можно выделить «частоту смаза» и нивелировать его воздействие.
К примеру, при размере смаза 26, я разложил изображение и исходник по частотам 13, 6, 3, 1,5. Используя сгенерированную маску насыщенности и маску соответствующую 26-пиксельной волне, путем наложений смешанных частот из исходника и восстановленного изображения — получил без «ручной работы» такой результат:
оригинал
результат
результат + шумодав
Относительно самой программы — очень хочется поточный режим, когда есть возможность перетащить в программу сразу кучу файлов и через пару часов забрать исправленные. А если можно будет задать уровень четкости выше которого программа снимок обрабатывать вообще не будет (чтобы кидать в программу все снимки с сессии) — вообще сказка :)
Кстати. В рамках небольшого отступления, интересен такой вопрос: Если бы вам дали возможность перепрограммировать свои инстинкты — что бы вы поменяли?
Т.е. можно все. Можно прибавить/удалить эмоции, можно добавить/убавить чести, лидерства, самосохранения, доброты, злости, логичности, расчетливости, благородства, честности, хитрости… Что угодно поменять буквально в процентах. Вы бы что-нибудь поменяли? Если да — то что?
Ведь создавая ИИ люди все равно столкнуться с заданием «базовых стремлений», по сути инстинктов. И никто не запретит добавить инстинкт любви к человечеству. Только фишка в том что ИИ рано или поздно сможет свои инстинкты переписать…
Мое мнение — чем сильнее разум тем больше он даже изменяя себя захочет двигаться к созиданию, а не к разрушению. Потому что «предел разрушения» — это бездействие (разрушено все в т.ч. сам ИИ), а предел созидания — действие, т.к. настоящий предел созидания недостижим. В итоге, сложная система — будет стремиться к созиданию либо бездействию.
В обоих случаях «порабощение роботами» — маловероятно.
Имхо. «Астрологию, приметы и многое другое» — культивируют далеко не самые гениальные люди в мире (в среднем).
Думаю сверхразум в том чтобы оперировать концепциями имеющими более сложную структуру.
Вроде того чтобы понять квантовую механику и начать рассуждать в ее понятиях и терминах. Для обычного человека — это возможно, но непросто и не быстро. Поэтому человек не может освоить множество таких сложных концепций и уже из них вывести новые их комбинации. И поэтому поиски теории всего так затянулись, хотя вероятно данных для ее построения достаточно, просто сложности мозга недостает…
Если рассматривать прогресс — как формулирование новых концепций — то понятно что изначально концепций было мало (унаследованных от обезьян). Потом люди их комбинировали и получали все новые и новые… чем больше концепций в наличии — тем больше скорость генерации новых. Но сейчас ускорение прогресса (производная скорости пополнения базы фундаментальных открытий на 1 человека) — падает. Т.к. человек не может освоить все существующие концепции. Выход — создать сильный ИИ. Это продолжит экспоненциальный рост числа концепций, что и приведет к сингулярности.
Интересная статья, но развенчивая одни мифы — автор, по моему, не менее активно предлагает новые :)
Вообще «мифы» о восстаниях машин и т.п. возникают часто от того что человек не может сегодня представить будущее во всем его многообразии. Экстраполируя разные части фактов — естественно приходим к противоположным выводам.
Гипотезы «восстания машин» часто базируются на примитивных предположениях. Автор дополнил их здравым набором мыслей и пришел к другим выводам. Однако можно дополнить, дальше — и вновь придти к новым выводам…
Например можно возразить что и сегодня часть налогов идет на пособия для безработных. А в случае ИИ — обеспечить потребности населения будет все проще и проще. После создания реплицирующихся роботов можно будет за несколько лет решить все проблемы с поставками пищи, образованием, развлечениями, путешествиями и т.п…
Т.е. то самое уничтожение кучи людей попросту ненужно, т.к. они практически не требует расходов ценных ресурсов (еда и энергия ценными быть перестали). А если люди будут уходить в виртуальную реальность — тем более. Это все равно что пойти в лес и начать топтать муравьев потому что они «не приносят пользы»…
Итог, на этом этапе — войны не будет (нечего делить)
Потом добавим еще мысль. Предположим все ушли в виртуальность. У каждого свой мирок (или несколько), каждый счастлив, занимается тем чем хочет. Прошло много лет люди уже не помнят своих друзей. У низ виртуальные «друзья», за которых «играет», какой-то ИИ низкого уровня. А глобальный ИИ — тем временем развивается или еще что-то там делает что хочет.
Станции на солнечной энергии работают, людские «жизни» крутятся в цифре. Иногда кто-то выходит погулять в теле киборга, погреться на солнышке… И назад, в развлекалово…
Итог — все довольны, все счастливы. Войны опять же нет.
Правда ИИ задумался. А нафига 6 млрд людей бегает? Путь бегает 3 млрд, а на месте остальных солнечных батарей — посадим леса, там будет большее разнообразие жизни… Ну взял 3 млрд капсул деактивировал. И снова никаких проблем. Никто даже не заметил, все остальные по прежнему, в своих мирах бегают, живут полной жизнью… Вроде и войны нет, а людишек меньше стало.
Плохо это или хорошо? А вот не знаю. Даже если бы сам так пропал — не знаю, плохо это было бы или хорошо.
Знаю только что кроме упомянутых есть еще столько факторов, что предсказать как там на самом деле будет — нереально.
Ну и ладно, поживем увидим))
Думаю я несколько «повернут» на будущем, так что тут вы правы:)))
И на счет того что начинающим пользователям часто удобнее типовой интерфейс, чем «навороченный» — тоже соглашусь.
Но вот касательно связи «интерфейс будущего» => «навороченный интерфейс»… не всегда.
Мое мнение в том что «интерфейсы будущего» часто рисуют как в фильмах — что-то страшное, сложное, непривычное… А суть в том что непривычное не обязательно сложно. Классический пример — тот же айфон. Разводить споры не хочется, но все же мало кто отрицает — когда он появился то не был привычен большинству пользователей. Однако стал удобен и популярен…
Потому что настоящий «интерфейс будущего» — решает старые проблемы, а не добавляет новых.
И именно для начинающих — такой интерфейс будет удобнее всего. Потому что им не нужно будет привыкать к «типичным решениям», которые часто сами собой разумеются для опытных пользователей, но вызывают много проблем у неопытных…
Ваш интерфейс — на мой взгляд, как раз лучше подходит опытным пользователям. Фактически он копирует подход интернет магазинов.
Хорошо это или нет — не берусь судить. Как я и говорил мой вариант — это просто предложение посмотреть в сторону «нехоженных троп».
Возможно там есть что-то интересное.
А по-моему получилось как-то скучно. Т.е. как сайт для поиска квартир (каких сотни) — может и потянет. А вот как презентация работы юзабилити бюро — не очень…
Интерфейс очень типовой, но двигаясь «по логической цепочке» — сложно придти к нестандартным решениям. И учесть возможности развития — тоже сложно.
Я не особо анализировал ваш вариант. Но как быть если я хочу квартиру рядом с конкретным адресом, а не рядом с метро? Или как мне узнать давно ли квартира сдается? А на сколько она сдается? Есть ли отзывы? Сдаются ли другие квартиры в этом доме? Сколько времени займет у меня путь на работу? Это агенство или сам владелец сдает?.. и т.п. вопросов могут быть сотни.
Таких типовых «сайтов по аренде квартиры» — множество. Если говорить о юзабилити — предложите что-то новое… Возможностей в инете море! Предложите панорамы дома с google street maps. Или историю улицы с википедии. Или предложите отправить сообщение владельцу. Посмотреть его профиль в соц. сетях (если разрешает). Дайте «интерактивную карту стоимости квадратного метра» для всего города… и так далее. Удивите меня! :)
Когда вы (или заказчик) попытаетесь в будущем впихнуть что-то из этого в ваш интерфейс — получится такая же каша как у всех. Так может надо что-то менять? Может призвание юзабилити бюро — в том чтобы придумывать что-то новое, а не делать как все…
Пока читал заметку — представил свой вариант. Жаль нет времени рисовать.
Что-то типа динамической страницы называемой «путь заказа». Все элементы крупные, четкие. Когда что-то меняется — элементы справа могут поменяться, если это необходимо.
Разделы пути: что, где, когда
На что — настройки. примерно как у вас. сдать/снять/кв/км/… и т.д. Изначально виден только этот раздел, остальные пока не нужны.
При выборе — справа подгружается карта (на карте заодно показаны станции метро, транспорта и т.п.) — над ней поисковая строка. Можно что-то найти. И поле «не больше nnnn метров». Это у нас раздел «где»
При клике на карту или выборе адреса/станции — отмечается область в пределах этих nnnn метров.
Над картой — кисточка. Если ее щелкнуть — можно нарисовать любую область в пределах которой нужна квартира.
В этой области динамично появляются метки предлагаемых квартир.
Прямо на карте видны фотографии google где можно посмотреть виды района. Нажав «панорамы» — увидеть их под картой. И на первой же панораме — камера будет как раз направлена на окна выделенной квартиры. Нажав «магазины» — увидеть ближайшие магазины и т.п.
Пока работаем с картой — она сместилась влево (справа элементы не исчезают, а становятся меньше, встраиваются в вертикальный ряд) — и вот мы видим новые инструменты — можно выбрать когда нам нужна квартира. На какой срок и т.п. (это уже в разделе «когда»).
Уточняя запрос видим как меняются метки на карте. А сама область карты становится Уже, и вот справа, под сроками, появляется список вариантов. Каждый связан с точкой на карте, у каждого есть цена. есть крестик для удаления варианта. А если щелкнуть по нему или по точке на карте — появляется панель с подробными данными…
В общем. Описывать можно долго. И нет совершенно никаких гарантий, что такой вариант будет хоть в чем-то лучше Вашего.
Все это я писал только чтобы показать — потратив 10 минут работы непрофессионала — можно придумать что-то новое. а потратив час работы бюро — таких вариантов можно сделать штук 30. И потом проанализировав и взяв из них лучшее — сделать пусть что-то гораздо большее. Пусть это даже будет стандартный сайт, похожий на типовой интернет магазин. Но мыслей, идеи, и просто души — там будет больше.
Мне лично идея нравится, хотя и не совсем соответствует заголовку. По сути вы описываете вариант развития сервиса вопрос/ответ, а не какой-то принципиально новый подход к монетизации.
Ну и по проекту остается много вопросов.
Например — классификация специалистов. Вот я к примеру укажу в настройках что я web-разработчик — но ведь это очень широкий класс задач, значит на множество вопросов по теме я ответить не смогу. А значит и задающий вопрос и я будем терять время и карму… Тогда я указываю «web-разработчик-drupal» — и опять же не могу ответить на многие сложные вопросы т.к. одних модулей для друпала тысячи и я не могу знать все…
На классических сервисах вопросов — такой проблемы нет. Там я вижу вопрос и сразу знаю могу на него ответить или нет.
Или еще. Вы пишите, что пользователь сам выбирает кто будет отвечать на его вопрос — это плохо, т.к. данный специалист с высокой вероятностью будет занят в данный момент (сколько минут в день вы настолько свободны чтобы консультировать за копейки других людей?). Получается что нужно вводить статус для специалистов, но менять его каждый раз когда есть время пообщаться — тоже не вариант. Тогда значит нужно делать что-то вроде аукциона вопросов, и уже специалисты выбирают когда на какой вопрос отвечать. Но тогда мы теряем основное преимущество — скорость ответа…
По оплате тоже остается вопрос. Делать help-минуты дешевыми — значит потерять консультантов профессионалов. Поднимать цены — терять клиентов… Кроме того, не забывайте что первые 100 минут пользователь получит даром, он потратит их на консультации — но консультантам ведь нужно платить… значит сервис должен из своего кармана оплатить 100 минут консультаций каждого своего клиента.
Рассчитывать на однородность людей, которые будут консультироваться столько же сколько консультировать — наивно. Опыт показывает что напротив, тот кто много консультируется — почти нечем не может помочь (ну кроме как разносить ботинки). А тот кто много консультирует — напротив крайней редко нуждается в чьей-то помощи (обычно у него и так куча за что-то ему «обязанных» знакомых)…
Опять же дать возможность пользователю после консультации отказаться от оплаты — тоже не вариант. Лично я буду клиентом сервиса до первого случая когда полчаса консультируя кого-то получу в обмен минус в карму…
В общем, идея интересна, но, имхо, нуждается в существенной доработке.
Согласен с вами.
И кроме прочего, нужно не забывать что ничто не мешает яндексу в очередном обновлении «островов» сделать каждый остров «раскрывающимся». Тогда если пользователю мало 2-х абзацев — он нажимает на текст и получает весь текст со страницы-источника, но внутри выдачи yandex, без банеров и т.п… А ссылку на сайт-источник можно спрятать в уголок куда-нибудь…
Для пользователей по сути весьма удобно, можно легко почитать информацию с разных сайтов не прыгая по ссылкам и не используя кучу вкладок… А вот для web-мастеров это может практически убить доходы…
И если подумать — с картинками ведь такой подход уже сработал. Раньше при поиске картинок в гугле, версию с полным разрешением показывало прямо на странице сайта-источника. Теперь же, ее можно скачать напрямую со страницы выдачи-гугла. Мне как пользователю удобно. Но как разработчик я уже никогда не возьмусь за проект связанный с каталогами изображений…
Это только одна область, но если это расширится на большинство типов сайтов, да еще в связи с распространением yandex-браузера — как то не радужно…
В начале подумал, что появилась возможность быстрого поиска в пределах текущего сайта (хотя бы на движке yandex), вообще без использования поисковой формы сайта.
Жаль что ошибся… Понятно что можно использовать команду "<запрос> site:<домен>", но неудобно это…
Еще плохо что на «табло» нельзя менять цвет фона вкладок. Было бы удобно настроить под себя, а то все «не фирменные» вкладки одинаковые… Плюс — непонятно почему вкладок может быть только 9? Непонятное ограничение. На imac смотрица куцо…
Вы как пользователь Хабра — не являетесь потенциальным клиентом по определению.
Моя система для тех кто делает первые шаги в разработке, не понимает терминологию, и т.п…
Когда я в 2001 пытался разобраться как создать сайт в интернете, то для меня все было новым и необычным. У меня не было учителя которого можно было бы спросить «А что такое JS? А как сделать выпадающее меню? А как сделать чтобы вот этот блок тянулся, а этот нет?»… и так далее. Просто чтобы «врубиться в терминологию», понять как тут все связано и работает — ушли недели.
Мне кажется люди тут забыли как они были новичками.
Или вот пример. Я занимаюсь 3D-графикой. Для меня интерфейс Maya логичен и понятен. Ничего другого мне и не надо.
Но предположим вы в 3D-графике новичок. От интерфейса разбегаются глаза (там реально много элементов). Вам удалось собрать из примитивов простой ролик, но когда назначили объекту текстуру — она «поплыла»… Что делать?
На запрос в гугле «Maya плывет текстура» — ничего хорошего вы не получите. Потому что текстура может «плыть» по сотне причин. Для и называют все эффект по разному…
Теперь предположим у вас есть такой вот помощник. Вы выделяете объект и пишите (или произносите) команду «устранить искажения текстуры». В отличие от гугла который бы команду не понял — у помощника есть информация о текущей работе, геометрии объекта, текстуре и т.п… С учетом этих данных вы получаете ответ — «Искажения текстуры вероятно вызваны отсутствием развертки (UVW-карты). Создать карту автоматически (пункт меню такой-то)?»…
И в ответе нет ничего фантастического. Зная тип геометрии объекта, режим наложения текстуры и то что пользователи часто называют проекционные искажения словом «плывет» — это элементарный вывод не требующий даже ИИ.
Как думаете, в таком виде система бы вам пригодилась?
Я просто уже не знаю как формулировать. Через визуальный редактор — идет работа с графикой, потому что это просто удобнее.
Естественно человек может и управлять голосом, если система поймет его команду — она ее выполнит.
Я говорю о том что вот такого "«Влево», «левее», «еще левей»,«чуточку еще левей»,«в лево до конца»,«влево, на уровень с меню»" — будет, потому что пользователь просто подвинет элемент мышкой и все.
Голосом, как я и написал, не только создаются объекты но и происходит настройка работы сайта, его внешнего вида, конфигурации и т.п.
Суть не в конкретном применении сервиса, а в подходе, экстраполировать его на другие области — дело времени.
В веб разработке я больше 10 лет, и верю в идею))))
7. Выделив мышью какой-либо элемент сайта пользователь может работать с ним – перемещать, менять размер, менять код и т.п
Вся работа с графикой — строится через визуальный редактор. Мышкой. На картинке даже нарисованы маркеры для перетаскивая логотипа, изменения размера, вращения и т.п… Голосовые команды при этом не используются.
Команды используются для создания новых элементов, добавления эффектов, установки модулей, подключения библиотек и т.п...
И отдавать команды не обязательно голосом.
Прототип интерфейса они сделают конечно. Но толку от прототипа? Из него сайт делать все равно мне (или другому разработчику) придется. А потом когда они что-то захотят изменить — опять мне… Нужен интеллектуальный инструмент.
Пока я и не позиционирую голосовое управление как основное. Но заказчику с исполнителем все же удобнее общаться голосом, а значит рано или поздно и компьютеры к этому придут. Имхо — лучше рано.
Наверное мне везло с заказчиками, но обычно это адекватные люди, могут сформулировать что хотят достаточно точно, тем более что тут эксперементировать никто не запрещает. Напротив, командам типа «поиграть со шритами» многие мои знакомые были бы рады)
Серьезно, у меня куча умных знакомых которые мало что понимают в сайтостроении, но уверен дай им такой инструмент и они соберут между делом весьма интересные вещи…
Представляю большой «шкаф» (2*10*4 метра или меньше), в котором находятся стойки и манипуляторы на рельсах для замены железа. Сбоку отделение с новыми серверами, на случай замены.
Такой мини-ЦОД может располагаться с подвале частных зданий и использоваться для обогрева (кроме собственно вычислений).
А техники только раз в год приезжают, привозят новое железо, забирают старое. Ну и чинят что-то чего не могут поменять манипуляторы…
Есть смысл?
ИМХО — как раз тут ключевым плюсом была бы дополненная реальность. Чтобы навести телефон на текст, а прога затирала его цветом фона и поверх выводила перевод в том же месте и с теми же искажениями… Если в реальном времени не получится — то хоть на готовой фотке.
Даже в тех макетах что у вас — google translate — просто выдал бы кучу неструктурированного текста, читать который крайне неудобно…
Фактически — нужно знать где в файле описан пиксел который пересечет произвольная прямая (проекция луча зрения).
Видимо для этого в начале файла размещают индекс, в котором задана в неком виде конфигурация сцены, эта информация держится в памяти, и позволяет рассчитать пересечения для каждой прямой в пределах сцены.
Думаю что используется иерархия объемных блоков. Заголовок файла описывает сцену состоящую из больших блоков, скажем размером с дом. По этой информации можно для любой прямой вычислить какие блоки она пересечет. Эти блоки имеют известные адреса смещений в базе, и в начале каждого блока — идет описание дочерних блоков (размером около метра), это описание позволяет найти пересечения с любой прямой проходящей через данный блок (а не через всю сцену). Внутри них точно также хранятся блоки размером в дециметр, сантиметр, миллиметр, и т.п.
Получается что для одного экранного пиксела нужно произвести не одно, а несколько чтений с диска. Но так как рядом стоящих лучей очень много (мы ведь просчитываем картинку, а не случайные прямые) — то и информацию одного луча можно использовать при просчете соседей.
А если каждый блок будет хранить еще и общий оттенок, то получается нечто вроде jpg сжатия картинки — каждый новый уровень хранит отклонение цвета от родителя и поэтому может хранить не 24 бита, а существенно меньше…
Ну и если у пользователя скорость ограничена — можно смотреть цепочку блоков не до конца, а меньше — качество картинки будет хуже, но и читать с диска придется меньше.
Из пожеланий — думаю недостает фильтров накладываемых после восстановления, причем учитывающих характер вносимых артефактов.
Например. Бросаются в глаза цветные полосы и шум на серых участках изображения (на текстах, на стене рядом с ежиком и т.п.) — однако понятно что если в окрестностях некоторой точки на смазанном изображении цветовая насыщенность низкая — то и на восстановленном она вероятнее всего будет низкая. Можно говорить что интеграл насыщенности в некоторых окрестностях восстановленного изображения, не более чем в k-раз больше аналогичного интеграла на размытом изображении. k — можно найти экспериментально, и он явно будет расти в зависимости от размеров смаза, но думаю не превысит 2-3 в типичных случаях.
Практически любой алгоритм подавления шумов в данном случае можно будет улучшить т.к. имеется размытая версия изображения. Лучше всего мне кажется подошел бы вейвлет-анализ, с внесением корректив в каждый из слоев ориентируясь на оригинал.
Особенно это даст заметный эффект на восстановлении текста, что может быть весьма актуально например для студентов снимающих конспекты на телефон:)
Второй пример. Программа великолепно справляется детализированными фрагментами, но в однородных областях — появляются волнообразные артефакты с периодом равным величине смаза. Используя упомянутые вейвлет преобразования (частотные слои) — можно выделить «частоту смаза» и нивелировать его воздействие.
К примеру, при размере смаза 26, я разложил изображение и исходник по частотам 13, 6, 3, 1,5. Используя сгенерированную маску насыщенности и маску соответствующую 26-пиксельной волне, путем наложений смешанных частот из исходника и восстановленного изображения — получил без «ручной работы» такой результат:
Относительно самой программы — очень хочется поточный режим, когда есть возможность перетащить в программу сразу кучу файлов и через пару часов забрать исправленные. А если можно будет задать уровень четкости выше которого программа снимок обрабатывать вообще не будет (чтобы кидать в программу все снимки с сессии) — вообще сказка :)
Если бы вам дали возможность перепрограммировать свои инстинкты — что бы вы поменяли?
Т.е. можно все. Можно прибавить/удалить эмоции, можно добавить/убавить чести, лидерства, самосохранения, доброты, злости, логичности, расчетливости, благородства, честности, хитрости… Что угодно поменять буквально в процентах. Вы бы что-нибудь поменяли? Если да — то что?
Ведь создавая ИИ люди все равно столкнуться с заданием «базовых стремлений», по сути инстинктов. И никто не запретит добавить инстинкт любви к человечеству. Только фишка в том что ИИ рано или поздно сможет свои инстинкты переписать…
Мое мнение — чем сильнее разум тем больше он даже изменяя себя захочет двигаться к созиданию, а не к разрушению. Потому что «предел разрушения» — это бездействие (разрушено все в т.ч. сам ИИ), а предел созидания — действие, т.к. настоящий предел созидания недостижим. В итоге, сложная система — будет стремиться к созиданию либо бездействию.
В обоих случаях «порабощение роботами» — маловероятно.
Думаю сверхразум в том чтобы оперировать концепциями имеющими более сложную структуру.
Вроде того чтобы понять квантовую механику и начать рассуждать в ее понятиях и терминах. Для обычного человека — это возможно, но непросто и не быстро. Поэтому человек не может освоить множество таких сложных концепций и уже из них вывести новые их комбинации. И поэтому поиски теории всего так затянулись, хотя вероятно данных для ее построения достаточно, просто сложности мозга недостает…
Если рассматривать прогресс — как формулирование новых концепций — то понятно что изначально концепций было мало (унаследованных от обезьян). Потом люди их комбинировали и получали все новые и новые… чем больше концепций в наличии — тем больше скорость генерации новых. Но сейчас ускорение прогресса (производная скорости пополнения базы фундаментальных открытий на 1 человека) — падает. Т.к. человек не может освоить все существующие концепции. Выход — создать сильный ИИ. Это продолжит экспоненциальный рост числа концепций, что и приведет к сингулярности.
Вообще «мифы» о восстаниях машин и т.п. возникают часто от того что человек не может сегодня представить будущее во всем его многообразии. Экстраполируя разные части фактов — естественно приходим к противоположным выводам.
Гипотезы «восстания машин» часто базируются на примитивных предположениях. Автор дополнил их здравым набором мыслей и пришел к другим выводам. Однако можно дополнить, дальше — и вновь придти к новым выводам…
Например можно возразить что и сегодня часть налогов идет на пособия для безработных. А в случае ИИ — обеспечить потребности населения будет все проще и проще. После создания реплицирующихся роботов можно будет за несколько лет решить все проблемы с поставками пищи, образованием, развлечениями, путешествиями и т.п…
Т.е. то самое уничтожение кучи людей попросту ненужно, т.к. они практически не требует расходов ценных ресурсов (еда и энергия ценными быть перестали). А если люди будут уходить в виртуальную реальность — тем более. Это все равно что пойти в лес и начать топтать муравьев потому что они «не приносят пользы»…
Итог, на этом этапе — войны не будет (нечего делить)
Потом добавим еще мысль. Предположим все ушли в виртуальность. У каждого свой мирок (или несколько), каждый счастлив, занимается тем чем хочет. Прошло много лет люди уже не помнят своих друзей. У низ виртуальные «друзья», за которых «играет», какой-то ИИ низкого уровня. А глобальный ИИ — тем временем развивается или еще что-то там делает что хочет.
Станции на солнечной энергии работают, людские «жизни» крутятся в цифре. Иногда кто-то выходит погулять в теле киборга, погреться на солнышке… И назад, в развлекалово…
Итог — все довольны, все счастливы. Войны опять же нет.
Правда ИИ задумался. А нафига 6 млрд людей бегает? Путь бегает 3 млрд, а на месте остальных солнечных батарей — посадим леса, там будет большее разнообразие жизни… Ну взял 3 млрд капсул деактивировал. И снова никаких проблем. Никто даже не заметил, все остальные по прежнему, в своих мирах бегают, живут полной жизнью… Вроде и войны нет, а людишек меньше стало.
Плохо это или хорошо? А вот не знаю. Даже если бы сам так пропал — не знаю, плохо это было бы или хорошо.
Знаю только что кроме упомянутых есть еще столько факторов, что предсказать как там на самом деле будет — нереально.
Ну и ладно, поживем увидим))
И на счет того что начинающим пользователям часто удобнее типовой интерфейс, чем «навороченный» — тоже соглашусь.
Но вот касательно связи «интерфейс будущего» => «навороченный интерфейс»… не всегда.
Мое мнение в том что «интерфейсы будущего» часто рисуют как в фильмах — что-то страшное, сложное, непривычное… А суть в том что непривычное не обязательно сложно. Классический пример — тот же айфон. Разводить споры не хочется, но все же мало кто отрицает — когда он появился то не был привычен большинству пользователей. Однако стал удобен и популярен…
Потому что настоящий «интерфейс будущего» — решает старые проблемы, а не добавляет новых.
И именно для начинающих — такой интерфейс будет удобнее всего. Потому что им не нужно будет привыкать к «типичным решениям», которые часто сами собой разумеются для опытных пользователей, но вызывают много проблем у неопытных…
Ваш интерфейс — на мой взгляд, как раз лучше подходит опытным пользователям. Фактически он копирует подход интернет магазинов.
Хорошо это или нет — не берусь судить. Как я и говорил мой вариант — это просто предложение посмотреть в сторону «нехоженных троп».
Возможно там есть что-то интересное.
Интерфейс очень типовой, но двигаясь «по логической цепочке» — сложно придти к нестандартным решениям. И учесть возможности развития — тоже сложно.
Я не особо анализировал ваш вариант. Но как быть если я хочу квартиру рядом с конкретным адресом, а не рядом с метро? Или как мне узнать давно ли квартира сдается? А на сколько она сдается? Есть ли отзывы? Сдаются ли другие квартиры в этом доме? Сколько времени займет у меня путь на работу? Это агенство или сам владелец сдает?.. и т.п. вопросов могут быть сотни.
Таких типовых «сайтов по аренде квартиры» — множество. Если говорить о юзабилити — предложите что-то новое… Возможностей в инете море! Предложите панорамы дома с google street maps. Или историю улицы с википедии. Или предложите отправить сообщение владельцу. Посмотреть его профиль в соц. сетях (если разрешает). Дайте «интерактивную карту стоимости квадратного метра» для всего города… и так далее. Удивите меня! :)
Когда вы (или заказчик) попытаетесь в будущем впихнуть что-то из этого в ваш интерфейс — получится такая же каша как у всех. Так может надо что-то менять? Может призвание юзабилити бюро — в том чтобы придумывать что-то новое, а не делать как все…
Пока читал заметку — представил свой вариант. Жаль нет времени рисовать.
Что-то типа динамической страницы называемой «путь заказа». Все элементы крупные, четкие. Когда что-то меняется — элементы справа могут поменяться, если это необходимо.
Разделы пути: что, где, когда
На что — настройки. примерно как у вас. сдать/снять/кв/км/… и т.д. Изначально виден только этот раздел, остальные пока не нужны.
При выборе — справа подгружается карта (на карте заодно показаны станции метро, транспорта и т.п.) — над ней поисковая строка. Можно что-то найти. И поле «не больше nnnn метров». Это у нас раздел «где»
При клике на карту или выборе адреса/станции — отмечается область в пределах этих nnnn метров.
Над картой — кисточка. Если ее щелкнуть — можно нарисовать любую область в пределах которой нужна квартира.
В этой области динамично появляются метки предлагаемых квартир.
Прямо на карте видны фотографии google где можно посмотреть виды района. Нажав «панорамы» — увидеть их под картой. И на первой же панораме — камера будет как раз направлена на окна выделенной квартиры. Нажав «магазины» — увидеть ближайшие магазины и т.п.
Пока работаем с картой — она сместилась влево (справа элементы не исчезают, а становятся меньше, встраиваются в вертикальный ряд) — и вот мы видим новые инструменты — можно выбрать когда нам нужна квартира. На какой срок и т.п. (это уже в разделе «когда»).
Уточняя запрос видим как меняются метки на карте. А сама область карты становится Уже, и вот справа, под сроками, появляется список вариантов. Каждый связан с точкой на карте, у каждого есть цена. есть крестик для удаления варианта. А если щелкнуть по нему или по точке на карте — появляется панель с подробными данными…
В общем. Описывать можно долго. И нет совершенно никаких гарантий, что такой вариант будет хоть в чем-то лучше Вашего.
Все это я писал только чтобы показать — потратив 10 минут работы непрофессионала — можно придумать что-то новое. а потратив час работы бюро — таких вариантов можно сделать штук 30. И потом проанализировав и взяв из них лучшее — сделать пусть что-то гораздо большее. Пусть это даже будет стандартный сайт, похожий на типовой интернет магазин. Но мыслей, идеи, и просто души — там будет больше.
Ну и по проекту остается много вопросов.
Например — классификация специалистов. Вот я к примеру укажу в настройках что я web-разработчик — но ведь это очень широкий класс задач, значит на множество вопросов по теме я ответить не смогу. А значит и задающий вопрос и я будем терять время и карму… Тогда я указываю «web-разработчик-drupal» — и опять же не могу ответить на многие сложные вопросы т.к. одних модулей для друпала тысячи и я не могу знать все…
На классических сервисах вопросов — такой проблемы нет. Там я вижу вопрос и сразу знаю могу на него ответить или нет.
Или еще. Вы пишите, что пользователь сам выбирает кто будет отвечать на его вопрос — это плохо, т.к. данный специалист с высокой вероятностью будет занят в данный момент (сколько минут в день вы настолько свободны чтобы консультировать за копейки других людей?). Получается что нужно вводить статус для специалистов, но менять его каждый раз когда есть время пообщаться — тоже не вариант. Тогда значит нужно делать что-то вроде аукциона вопросов, и уже специалисты выбирают когда на какой вопрос отвечать. Но тогда мы теряем основное преимущество — скорость ответа…
По оплате тоже остается вопрос. Делать help-минуты дешевыми — значит потерять консультантов профессионалов. Поднимать цены — терять клиентов… Кроме того, не забывайте что первые 100 минут пользователь получит даром, он потратит их на консультации — но консультантам ведь нужно платить… значит сервис должен из своего кармана оплатить 100 минут консультаций каждого своего клиента.
Рассчитывать на однородность людей, которые будут консультироваться столько же сколько консультировать — наивно. Опыт показывает что напротив, тот кто много консультируется — почти нечем не может помочь (ну кроме как разносить ботинки). А тот кто много консультирует — напротив крайней редко нуждается в чьей-то помощи (обычно у него и так куча за что-то ему «обязанных» знакомых)…
Опять же дать возможность пользователю после консультации отказаться от оплаты — тоже не вариант. Лично я буду клиентом сервиса до первого случая когда полчаса консультируя кого-то получу в обмен минус в карму…
В общем, идея интересна, но, имхо, нуждается в существенной доработке.
И кроме прочего, нужно не забывать что ничто не мешает яндексу в очередном обновлении «островов» сделать каждый остров «раскрывающимся». Тогда если пользователю мало 2-х абзацев — он нажимает на текст и получает весь текст со страницы-источника, но внутри выдачи yandex, без банеров и т.п… А ссылку на сайт-источник можно спрятать в уголок куда-нибудь…
Для пользователей по сути весьма удобно, можно легко почитать информацию с разных сайтов не прыгая по ссылкам и не используя кучу вкладок… А вот для web-мастеров это может практически убить доходы…
И если подумать — с картинками ведь такой подход уже сработал. Раньше при поиске картинок в гугле, версию с полным разрешением показывало прямо на странице сайта-источника. Теперь же, ее можно скачать напрямую со страницы выдачи-гугла. Мне как пользователю удобно. Но как разработчик я уже никогда не возьмусь за проект связанный с каталогами изображений…
Это только одна область, но если это расширится на большинство типов сайтов, да еще в связи с распространением yandex-браузера — как то не радужно…
Жаль что ошибся… Понятно что можно использовать команду "<запрос> site:<домен>", но неудобно это…
Еще плохо что на «табло» нельзя менять цвет фона вкладок. Было бы удобно настроить под себя, а то все «не фирменные» вкладки одинаковые… Плюс — непонятно почему вкладок может быть только 9? Непонятное ограничение. На imac смотрица куцо…
Моя система для тех кто делает первые шаги в разработке, не понимает терминологию, и т.п…
Когда я в 2001 пытался разобраться как создать сайт в интернете, то для меня все было новым и необычным. У меня не было учителя которого можно было бы спросить «А что такое JS? А как сделать выпадающее меню? А как сделать чтобы вот этот блок тянулся, а этот нет?»… и так далее. Просто чтобы «врубиться в терминологию», понять как тут все связано и работает — ушли недели.
Мне кажется люди тут забыли как они были новичками.
Или вот пример. Я занимаюсь 3D-графикой. Для меня интерфейс Maya логичен и понятен. Ничего другого мне и не надо.
Но предположим вы в 3D-графике новичок. От интерфейса разбегаются глаза (там реально много элементов). Вам удалось собрать из примитивов простой ролик, но когда назначили объекту текстуру — она «поплыла»… Что делать?
На запрос в гугле «Maya плывет текстура» — ничего хорошего вы не получите. Потому что текстура может «плыть» по сотне причин. Для и называют все эффект по разному…
Теперь предположим у вас есть такой вот помощник. Вы выделяете объект и пишите (или произносите) команду «устранить искажения текстуры». В отличие от гугла который бы команду не понял — у помощника есть информация о текущей работе, геометрии объекта, текстуре и т.п… С учетом этих данных вы получаете ответ — «Искажения текстуры вероятно вызваны отсутствием развертки (UVW-карты). Создать карту автоматически (пункт меню такой-то)?»…
И в ответе нет ничего фантастического. Зная тип геометрии объекта, режим наложения текстуры и то что пользователи часто называют проекционные искажения словом «плывет» — это элементарный вывод не требующий даже ИИ.
Как думаете, в таком виде система бы вам пригодилась?
Естественно человек может и управлять голосом, если система поймет его команду — она ее выполнит.
Я говорю о том что вот такого "«Влево», «левее», «еще левей»,«чуточку еще левей»,«в лево до конца»,«влево, на уровень с меню»" — будет, потому что пользователь просто подвинет элемент мышкой и все.
Голосом, как я и написал, не только создаются объекты но и происходит настройка работы сайта, его внешнего вида, конфигурации и т.п.
Суть не в конкретном применении сервиса, а в подходе, экстраполировать его на другие области — дело времени.
В веб разработке я больше 10 лет, и верю в идею))))
Вся работа с графикой — строится через визуальный редактор. Мышкой. На картинке даже нарисованы маркеры для перетаскивая логотипа, изменения размера, вращения и т.п… Голосовые команды при этом не используются.
Команды используются для создания новых элементов, добавления эффектов, установки модулей, подключения библиотек и т.п...
И отдавать команды не обязательно голосом.
Пока я и не позиционирую голосовое управление как основное. Но заказчику с исполнителем все же удобнее общаться голосом, а значит рано или поздно и компьютеры к этому придут. Имхо — лучше рано.
Наверное мне везло с заказчиками, но обычно это адекватные люди, могут сформулировать что хотят достаточно точно, тем более что тут эксперементировать никто не запрещает. Напротив, командам типа «поиграть со шритами» многие мои знакомые были бы рады)
Серьезно, у меня куча умных знакомых которые мало что понимают в сайтостроении, но уверен дай им такой инструмент и они соберут между делом весьма интересные вещи…