Комментарии 38
Интересная идея! Финальное видео подтверждает жизнеспособность! Только ходить уткнувшись в девайс опасно для здоровья :D
Этой возможности иногда не хватает при чтении в транспорте.
Ещё к компенсации перемещений можно попробовать добавить вращения — они могут возникать, если, например, держать телефон одной рукой сбоку в ландшафтном режиме. Но возможно, появится куча некрасивых эффектов сглаживания из-за вертикальных и горизонтальных элементов интерфейса.
Но там миллиметров достаточно.
Для хорошей стабилизации экрана не хватает места.
Формально — это возможно.
1. Фактически — нет. Нужна гораздо большая амплитуда
2. И еще одно — мешает шлейф от перерисовки на экране.
Программно это сделать можно.
Но без конструктивно заложенных возможностей — толку от этого 0.
Только по практиковаться в программировании датчиков.
иииии в конце-концов мы встречаем шлейфы при перемещении текста по фону. на разных экранах в разной степени, но везде есть. т.е. в результате "более стабильная", но размазанная картинка :)
Не, правда. Я не к тому, что "всё равно найдутся недовольные".
Идея клёвая. Реально вот направление мысли, реализация — молодцом.
Вот только конечный результат абсолютно беспомощен и бесполезен :) Но так что уже аппаратные ограничения.
1. Для глаз было 2 движущихся слоя, стало 3.
2. Датчики и реакция заметно отстают от реального движения.
В связи с этим нагрузка на глаза может стать еще больше
Ну и да, даже если бы удалось сделать идеально (скажем, датчик движения -> аппаратная обработка -> аппаратное смещение изображения на экране), и, допустим, сам экран достаточно быстродействующий — всё равно получили бы две проблемы:
1. Двигающаяся в поле зрения рамка экрана (и держащая её рука)
2. Голову-то при тряске тоже мотает! Т.е. как ни стабилизируй — картинка в поле зрения будет дёргаться. Привязываться надо к глазам, для этого крепить что-то на голову — что естественным образом приводит к идее очков.
Автор, сделайте пожалуйста видео демонстрирующее одновременно 2 устройства — со стабилизацией и без. По последнему видео кажется, что изображение замыливается, но может быть без стабилизации вообще нечитаемо.
За собой заметил что в транспорте прислонившись к стеклю читать становится сложнее: голова начинает двигаться с частотой опоры, а рука с частотой туловища, которое прекрасно справляется со стабилизацией. Фактически получается тот же лишний «слой»
Мне интересно. Те, кому сложно читать в транспорте, прижимают локти к туловищу или нет?
Сравнение между демо-1 и демо-2 вызывает желание создать демо-3 (идеальный вариант), когда текст просто жёстко зафиксирован :-) (т.е. обычный режим, без приложения :-))
При таком раскладе становится только хуже читать, т.к. добавляется еще одно непредсказуемое движение в уравнения для мозга.
Хотелось бы узнать скорость реакции стабилизации. Т, е. вот начали Вы движение экрана — через сколько времени Ваш софт перерисует экран на новом месте? Наверняка же можете тех. данные по дебагу посмотреть?
По ощущениям там не больше 15к/с, для качественной стабилизации надо не меньше 120 к/с.
Здесь требуется разработка очень точной инерциальной системы позиционирования.
Вот здесь например обсуждение: http://stackoverflow.com/questions/7829097/android-accelerometer-accuracy-inertial-navigation
Насчет скорости реакции — она зависит от частоты опроса датчика, задержки между-процессного взаимодействия и задержки обновления UI. Основной параметр все таки частота опроса датчика — и она задана как SENSOR_DELAY_FASTEST, что должно давать 100 Гц.
Здесь также есть возможности для улучшений путем переноса реализации алгоритма из отдельного приложения в драйвер датчика.
Какая реальная задержка — нужно еще подумать как это можно измерить.
Но к подходу поставленной задачки вы подошли серьёзно, приятно было посмотреть =)
Да, я понял, что вас больше напрягает скорость реакции прототипа на возмущение. Но даже с хорошей скоростью стабилизации эффект останется.
Да, я понял, что вас больше напрягает скорость реакции прототипа на возмущение.Нам представляется это единственной проблемой.
При чем к тряске можно привыкнуть и адаптироваться, потому что организм как-то ускорения отслеживает головой и движения рук тоже, а вот добавление непредсказуемого движения экрана это жесть, организму не только за тряской придется следить (хоть как-то предсказуемой), но и за постоянно ползущим куда-то текстом.
Но даже с хорошей скоростью стабилизации эффект останется.Отчего же?
«Резинка» должна присутствовать в любом случае. Представьте себе — вы с устройством шагнули вперед, а изображение «осталось» в метре за вашей спиной.А не фиг ходить пялясь в экран, это надо вбивать ремнем с младенчества.
Отчего же?
Собственно, я об этом написал.
в реальном устройстве изображение всегда будет стремиться занять центр экрана с тем или иным ускорением. А это ускорение будет восприниматься как та же «резинка».
То есть — либо изображение постоянно улетает за пределы экрана, «ползёт», либо вы получаете «резинку». Но уже не по причине низкой FPS.
А не фиг ходить пялясь в экран, это надо вбивать ремнем с младенчества.
Да я, собственно, абстрактный пример привел, для иллюстрации явления.
Собственно, я об этом написал.Так мы об этом и спросили:) Отчего же будет стремиться? Само не будет. Алгоритмически это не нужно, надо просто прибить изображение к точке в реальном мире. Можно сделать кнопочку для центровки изображения, что бы иметь какой-то контроль и/или делать это при перелистывании страницы. Но постоянно ползающий текст это ппц.
Алгоритмически это нужно. Представьте: едете вы в автобусе, читаете книгу. Автобус тормозит, и текст на экране смартфона бодро улетает далеко за пределы экрана. Будете при каждом ускорении кнопку центрирования жмакать?
Лучше мы один раз при торможении нажмем кнопку, чем постоянно будем пытаться отследить уползающий текст. А он будет уползать именно постоянно, если сам режим уползания сделать.
Стабилизация экрана в Android