Comments 38
Интересная идея! Финальное видео подтверждает жизнеспособность! Только ходить уткнувшись в девайс опасно для здоровья :D
Этой возможности иногда не хватает при чтении в транспорте.
Ещё к компенсации перемещений можно попробовать добавить вращения — они могут возникать, если, например, держать телефон одной рукой сбоку в ландшафтном режиме. Но возможно, появится куча некрасивых эффектов сглаживания из-за вертикальных и горизонтальных элементов интерфейса.
Занятно. Хотелось бы пользоваться. Но у меня CM11.
Матрицы фотоаппаратов уж лет 10 как стабилизируют.
Но там миллиметров достаточно.
Для хорошей стабилизации экрана не хватает места.
Но там миллиметров достаточно.
Для хорошей стабилизации экрана не хватает места.
Господа минусаторы — еще раз повторяю для идиотов:
Формально — это возможно.
1. Фактически — нет. Нужна гораздо большая амплитуда
2. И еще одно — мешает шлейф от перерисовки на экране.
Программно это сделать можно.
Но без конструктивно заложенных возможностей — толку от этого 0.
Только по практиковаться в программировании датчиков.
Формально — это возможно.
1. Фактически — нет. Нужна гораздо большая амплитуда
2. И еще одно — мешает шлейф от перерисовки на экране.
Программно это сделать можно.
Но без конструктивно заложенных возможностей — толку от этого 0.
Только по практиковаться в программировании датчиков.
иииии в конце-концов мы встречаем шлейфы при перемещении текста по фону. на разных экранах в разной степени, но везде есть. т.е. в результате "более стабильная", но размазанная картинка :)
такие вещи нужно решать не чисто программно.
Не, правда. Я не к тому, что "всё равно найдутся недовольные".
Идея клёвая. Реально вот направление мысли, реализация — молодцом.
Вот только конечный результат абсолютно беспомощен и бесполезен :) Но так что уже аппаратные ограничения.
при уровне вибрации, вызывающей шлейфы, вам явно не до чтения будет=))
Было б круто иметь такой модуль для Xposed
как батарея себя чувствует с новой прошивкой?
Не сочтите за не конструктивную критику.
1. Для глаз было 2 движущихся слоя, стало 3.
2. Датчики и реакция заметно отстают от реального движения.
В связи с этим нагрузка на глаза может стать еще больше
1. Для глаз было 2 движущихся слоя, стало 3.
2. Датчики и реакция заметно отстают от реального движения.
В связи с этим нагрузка на глаза может стать еще больше
У меня после просмотра видео — такое же ощущение. Стаблизация камеры, на которую ссылается автор — построена вообще по другому — на гироскопах. Здесь же есть задержка обработки, и изображение все-равно двигается, просто более плавно, чем «дергает» транспорт. Но, например, было ли для меня комфортнее читать текст таким образом — скорее всего нет.
«Более плавно» оно двигается только относительно экрана. Относительно глаз — рывками (ВЧ-составляющие движения не убираются из-за недостаточного быстродействия).
Ну и да, даже если бы удалось сделать идеально (скажем, датчик движения -> аппаратная обработка -> аппаратное смещение изображения на экране), и, допустим, сам экран достаточно быстродействующий — всё равно получили бы две проблемы:
1. Двигающаяся в поле зрения рамка экрана (и держащая её рука)
2. Голову-то при тряске тоже мотает! Т.е. как ни стабилизируй — картинка в поле зрения будет дёргаться. Привязываться надо к глазам, для этого крепить что-то на голову — что естественным образом приводит к идее очков.
Ну и да, даже если бы удалось сделать идеально (скажем, датчик движения -> аппаратная обработка -> аппаратное смещение изображения на экране), и, допустим, сам экран достаточно быстродействующий — всё равно получили бы две проблемы:
1. Двигающаяся в поле зрения рамка экрана (и держащая её рука)
2. Голову-то при тряске тоже мотает! Т.е. как ни стабилизируй — картинка в поле зрения будет дёргаться. Привязываться надо к глазам, для этого крепить что-то на голову — что естественным образом приводит к идее очков.
Автор, сделайте пожалуйста видео демонстрирующее одновременно 2 устройства — со стабилизацией и без. По последнему видео кажется, что изображение замыливается, но может быть без стабилизации вообще нечитаемо.
Вы точнее меня сформулировали мою мысль.
За собой заметил что в транспорте прислонившись к стеклю читать становится сложнее: голова начинает двигаться с частотой опоры, а рука с частотой туловища, которое прекрасно справляется со стабилизацией. Фактически получается тот же лишний «слой»
Мне интересно. Те, кому сложно читать в транспорте, прижимают локти к туловищу или нет?
За собой заметил что в транспорте прислонившись к стеклю читать становится сложнее: голова начинает двигаться с частотой опоры, а рука с частотой туловища, которое прекрасно справляется со стабилизацией. Фактически получается тот же лишний «слой»
Мне интересно. Те, кому сложно читать в транспорте, прижимают локти к туловищу или нет?
UFO just landed and posted this here
Сравнение между демо-1 и демо-2 вызывает желание создать демо-3 (идеальный вариант), когда текст просто жёстко зафиксирован :-) (т.е. обычный режим, без приложения :-))
Дорогой автор, закрепите в штативе камеру, которой снимаете демо. Прицепите к вашему девайсу какой-нибудь контролируемый источник вибрации (микроконтроллер с вибродвижком). Запилите в качестве опорной картинки какую-нибудь референсную — например, тупо клетчатое поле. Реализуйте на OpenCV вычисление функционала «качества сглаживания» — например, евклидову норму разницы между картинкой в статике и с подключенным источником вибрации, осредненную за некий период времени. Дальше можно любым алгоритмом многомерной оптимизации автоматически подкрутить ваши волшебные константы до минимума функционала, проходясь каждый раз по спектру. Двое-трое суток работы такой установки — и у вас профиль из десятка циферок для конкретного телефона, который можно (попробовать) продать производителю телефона за денюжку. Но для референсных моделей придется выложить в паблик, чтобы народ начал массово хотеть эту фишку ;)
В оболочку ОС я бы добавил такую функцию! Ведь люди читают текст не только в электронных книгах.
По последнему видео есть ощущение, что текст не стоит как вкопанный (как должно быть при стабилизации хорошей), а привязан на резинке (реагирует, но медленнее и меньше).
При таком раскладе становится только хуже читать, т.к. добавляется еще одно непредсказуемое движение в уравнения для мозга.
Хотелось бы узнать скорость реакции стабилизации. Т, е. вот начали Вы движение экрана — через сколько времени Ваш софт перерисует экран на новом месте? Наверняка же можете тех. данные по дебагу посмотреть?
По ощущениям там не больше 15к/с, для качественной стабилизации надо не меньше 120 к/с.
При таком раскладе становится только хуже читать, т.к. добавляется еще одно непредсказуемое движение в уравнения для мозга.
Хотелось бы узнать скорость реакции стабилизации. Т, е. вот начали Вы движение экрана — через сколько времени Ваш софт перерисует экран на новом месте? Наверняка же можете тех. данные по дебагу посмотреть?
По ощущениям там не больше 15к/с, для качественной стабилизации надо не меньше 120 к/с.
Вы правы в том, что изображение все таки не стоит на месте. В этом плане алгоритм требует доработки.
Здесь требуется разработка очень точной инерциальной системы позиционирования.
Вот здесь например обсуждение: http://stackoverflow.com/questions/7829097/android-accelerometer-accuracy-inertial-navigation
Насчет скорости реакции — она зависит от частоты опроса датчика, задержки между-процессного взаимодействия и задержки обновления UI. Основной параметр все таки частота опроса датчика — и она задана как SENSOR_DELAY_FASTEST, что должно давать 100 Гц.
Здесь также есть возможности для улучшений путем переноса реализации алгоритма из отдельного приложения в драйвер датчика.
Какая реальная задержка — нужно еще подумать как это можно измерить.
Здесь требуется разработка очень точной инерциальной системы позиционирования.
Вот здесь например обсуждение: http://stackoverflow.com/questions/7829097/android-accelerometer-accuracy-inertial-navigation
Насчет скорости реакции — она зависит от частоты опроса датчика, задержки между-процессного взаимодействия и задержки обновления UI. Основной параметр все таки частота опроса датчика — и она задана как SENSOR_DELAY_FASTEST, что должно давать 100 Гц.
Здесь также есть возможности для улучшений путем переноса реализации алгоритма из отдельного приложения в драйвер датчика.
Какая реальная задержка — нужно еще подумать как это можно измерить.
К сожалению, проблема — не дрожание телефона относительно Земли, а дрожание телефона относительно глаз. Т.е. стабилизировать изображение на экране — мало, надо стабилизировать движение головы. Как это можно сделать — лично мне непонятно, единственная идея — фронтальной камерой ловить положение глаз (что-то не соображу, даст ли это достаточно информации).
Но к подходу поставленной задачки вы подошли серьёзно, приятно было посмотреть =)
Но к подходу поставленной задачки вы подошли серьёзно, приятно было посмотреть =)
«Резинка» должна присутствовать в любом случае. Представьте себе — вы с устройством шагнули вперед, а изображение «осталось» в метре за вашей спиной. Это случай идеальной стабилизации. И ведь экран после воздействия колебаний никогда не вернется в прежнее положение, даже если у вас просто дрогнула рука. Так что в реальном устройстве изображение всегда будет стремиться занять центр экрана с тем или иным ускорением. А это ускорение будет восприниматься как та же «резинка».
Да, я понял, что вас больше напрягает скорость реакции прототипа на возмущение. Но даже с хорошей скоростью стабилизации эффект останется.
Да, я понял, что вас больше напрягает скорость реакции прототипа на возмущение. Но даже с хорошей скоростью стабилизации эффект останется.
Да, я понял, что вас больше напрягает скорость реакции прототипа на возмущение.Нам представляется это единственной проблемой.
При чем к тряске можно привыкнуть и адаптироваться, потому что организм как-то ускорения отслеживает головой и движения рук тоже, а вот добавление непредсказуемого движения экрана это жесть, организму не только за тряской придется следить (хоть как-то предсказуемой), но и за постоянно ползущим куда-то текстом.
Но даже с хорошей скоростью стабилизации эффект останется.Отчего же?
«Резинка» должна присутствовать в любом случае. Представьте себе — вы с устройством шагнули вперед, а изображение «осталось» в метре за вашей спиной.А не фиг ходить пялясь в экран, это надо вбивать ремнем с младенчества.
Отчего же?
Собственно, я об этом написал.
в реальном устройстве изображение всегда будет стремиться занять центр экрана с тем или иным ускорением. А это ускорение будет восприниматься как та же «резинка».
То есть — либо изображение постоянно улетает за пределы экрана, «ползёт», либо вы получаете «резинку». Но уже не по причине низкой FPS.
А не фиг ходить пялясь в экран, это надо вбивать ремнем с младенчества.
Да я, собственно, абстрактный пример привел, для иллюстрации явления.
Собственно, я об этом написал.Так мы об этом и спросили:) Отчего же будет стремиться? Само не будет. Алгоритмически это не нужно, надо просто прибить изображение к точке в реальном мире. Можно сделать кнопочку для центровки изображения, что бы иметь какой-то контроль и/или делать это при перелистывании страницы. Но постоянно ползающий текст это ппц.
Алгоритмически это нужно. Представьте: едете вы в автобусе, читаете книгу. Автобус тормозит, и текст на экране смартфона бодро улетает далеко за пределы экрана. Будете при каждом ускорении кнопку центрирования жмакать?
За пределы экрана — можно автоматом перерисовывать в 0 позицию если улетает дальше 20% экрана или можно дальше пределов экрана вообще не отпускать — достигло границ и все.
Лучше мы один раз при торможении нажмем кнопку, чем постоянно будем пытаться отследить уползающий текст. А он будет уползать именно постоянно, если сам режим уползания сделать.
Лучше мы один раз при торможении нажмем кнопку, чем постоянно будем пытаться отследить уползающий текст. А он будет уползать именно постоянно, если сам режим уползания сделать.
Sign up to leave a comment.
Стабилизация экрана в Android