[MOD][Xposed] GyroscopeNoiseFilter - Xposed Framework Modules
Hi there,
GyroscopeNoiseFilter (previously: JitteryGyroFixForCardboard) is a module to reduce/eliminate the noise in unstable gyroscope that are found in some phones like the Moto G 2nd gen or Huawei Ascend G7. Basically, the app does the noise smoothing that app devs do, but here this module uses a system hook to apply the noise smoothing preprocessing for all apps, but the main goal here is specifically to remove jitter, not drift (although the filters may help, but there's no sensor fusion, yet).
This is particularly interesting for virtual reality (VR) or head-tracking apps because a noisy gyroscope will produce a feeling of dizzyness and nausea, but this can also be interesting for any app using the gyroscope because the output will be a lot smoother and accurate (particularly when the phone is held still).
The module was originally wrote by Kjos and the repo lives here:
https://github.com/Kjos/XposedJitteryGyroFix
The thread that started the module is on Reddit:
https://www.reddit.com/r/GoogleCardboard/comments/335ins/fix_for_jittery_gyroscopes_such_as_moto_g
Here is the latest version of the module, v1.4 (also attached to this thread):
https://github.com/lrq3000/XposedJitteryGyroFix/releases/download/v1.4/GyroscopeNoiseFilter_v1.4.apk
The module is also available directly from the Xposed repo:
http://repo.xposed.info/module/net.kajos.gyronoisefilter
=== DESCRIPTION ===
The gyroscope is the main sensor for head tracking / virtual reality apps.
However, it's common for phones' gyroscopes to be noisy, which in practice shows as jitter, and this can create a dizzyness feeling and nausea, particularly when standing still (the "camera" still moves around just like if you were at sea).
Android now offers "virtual" sensors, which use a method known as sensor fusion to avoid those noisy outputs by combining several sensors (usually: gyroscope, accelerometer, magnetometer).
However, it's up to each app dev to use these virtual sensors, and to implement further post-processing to smooth the sensor and reduce the noise.
This module adopts another approach: it hooks directly to the hardware gyroscope and it preprocess every outputs with smoothing filters before relaying the data to the apps.
Therefore, the noise is reduced or even eliminated of the gyroscope's output for every apps.
=== OPTIONS ===
This module currently implements a few different strategies to filter and reduce noise, which can be used complementary or alone (each option can be disabled):
1. Filter type: type of the filter that will be applied to reduce noise in the gyroscope output.
2. Filter size: the number of samples to use to compute the filtering. Usually, the bigger the filter is, the less jitter there will be but at the expense of some lag.
3. Filter optional value: value of the constant that configures some types of filters such as lowpass or additive smoothing.
4. Minimum value change threshold: prevents the phone from registering the new sensor's values if the difference to the median is smaller than the given threshold.
5. Stationary minimum value threshold: when stationary, prevents the sensor from moving if the change is below the given threshold (this is similar to min value change but here it only affects the stationary state, when you are not moving).
6. Rounding precision: round all sensor's values to the given decimal.
Options can be changed on-the-fly without having to restart the phone, and are instantly applied to the sensor, so that you can switch between this option screen and a VR app to test for the parameters that reduce the jitter the most for you.
Click to expand...
Click to collapse
I'm looking for feedback before we submit to the Xposed repo, so if you have any idea of a feature or if you spot a bug, feel free.
We are also looking for better filters, currently the best performing two types are the median filter and the one order low-pass filter, so if there's someone with some experience with noise reduction on the gyroscope (not the accelerometer), I'd be very interested to get some advices about that!
/EDIT: update v1.4.
Also, we found a great opensource app called GyroscopeExplorer (kudos to the dev) which implements all kinds of sensor fusion and with a very good documentation, so that's a great source of info to implement advanced filters, but, although they smooth the movement's noise and drifting issues, they do not fix jitter at all, so for the moment we won't implement these advanced filters. We are now focusing on supporting more apps, particularly the ones using the new Cardboard NDK API to access virtual sensors (this bypasses the usual SensorManager).
Sorry, I forgot to attach the APK directly to the thread, like it's usually done around here. That's now done.
Very interesting module.
I wonder if this would give better results when doing Photospheres with the Google Camera app.
Also, does this have any meaningful impact on cpu usage and battery draining ?
thanks!
edgrd said:
Very interesting module.
I wonder if this would give better results when doing Photospheres with the Google Camera app.
Also, does this have any meaningful impact on cpu usage and battery draining ?
thanks!
Click to expand...
Click to collapse
I never made Photospheres with the Google Camera app, but if it uses the Gyroscope and you experience some jitter, then the module should help yes.
About CPU, the module is quite light on resources. The exact usage mostly depends on the filter type and filter size, with the low-pass filter being the lightest on CPU (only a few additions and multiplications, so it's negligible). All the other options such as the "minimum value change" only do a single calculation so their CPU usage is also negligible. However, if you use the mean or median filters and with a big filter size (like 1000), you may notice a very very small CPU usage, but it will still be very low (the time of a summation over an array of the size you specified, so it's not that big).
I have experienced some small (but still perceived) input lag using the default filter (median), switching to the lightest one and decreasing filter size to 8 fixed it
Would be nice if this module was presented more as an improvement / upgrade to the default gyroscope output, other than a simple fix
And after the app matures a little bit, you could make it available on the Play store too, so more people get this benefit
thanks again :good:
Good idea, but I can’t make head or tail of it. Maybe you ought to include simple preset/config… (sophisticated, uniform, simple & powerful, extreme…etc.), so that punters with Cardboards don’t spend a week scratching their heads on figuring out values, stationary thresholds and precisions.
I get nauseous using both DK2 and smartphone HMDs - don’t know if it’s me or noisy gyroscopes.
Thank's for the feedback everyone
@edgrd: yes the median filter smoothes the gyroscope more but it adds a delay proportionally to the filter's size. The low-pass filter does not add any perceptible delay, and the filter size does not matter (it only uses the previous gyroscope's value, so the filter size is always 1. I have yet to find the calculation for a bigger low-pass filter - but it works already very well as it is).
Indeed this is more an improvement now than a fix, that's why we renamed the app now to GyroscopeNoiseFilter
@Lord Childe: thank's for the idea of presets, I thought about that but however I can't think of a way to provide presets, since the values you set entirely depends on your own gyroscope's values. So for the moment, it is advised to just try out different values and you can switch back and forth to a VR app of your choice to instantly see the effect. Maybe we could do some kind of automatic calibration (eg, don't move your smartphone for a few seconds and this will automatically detect the values of the jitter).
Personally, on my Huawei Ascend G7, I use the low-pass filter and the stationary minimum value change set at 0.2. All the others are at default. And yes, this helps greatly to reduce the nausea for me (because when the phone still moves while you are standing still, this produces a feeling similar to being sea-sick).
Does not work on Cyanogenmod 12.1 Moto G 2nd Gen
Hi folks,
Tried to get it working on my Moto G 2nd Gen running Cyanogenmod 12.1. I can set the values but the Google Cardboard app does not seem to be taking the filtered values.
I tried running the Gyroscope Explorer app and if I enable Mean Smoothing, the app (Gyroscope Explorer) shows smooth values. But still has no effect on the cardboard app.
arindammanidas said:
Tried to get it working on my Moto G 2nd Gen running Cyanogenmod 12.1. I can set the values but the Google Cardboard app does not seem to be taking the filtered values.
Click to expand...
Click to collapse
Yes indeed, this is the issue we are currently working on. It seems that there are currently two ways to get the head's position: using SensorManager/SystemSensorManager, or using the Cardboard SDK's own method. The latter seems to completely bypass the SensorManager, which is the usual way of accessing the gyroscope's values. Most cardboard's apps are still using the SensorManager to access the gyroscope, so for these apps, our module works correctly. But for newer cardboard's apps using the Cardboard SDK orientation provider, our module does not work.
This is a pretty tough problem, and I never developped a Cardboard's app. If someone with experience with developping a Cardboard app can give some help with some advices, this would really help us a lot!
We just updated the module, Arindammanidas. Please try the latest version (v1.5) and see if this fixes your issue:
http://repo.xposed.info/module/net.kajos.gyronoisefilter
https://github.com/lrq3000/XposedJitteryGyroFix/releases/tag/v1.5
If it doesn't fix your issue, please tell us what app and what version doesn't work with our module. We are aware that there are still a few apps that may not work, in particular Cmoar Cinema Pro v4.3 (but version Free is OK). We don't yet know why (the source is closed).
/EDIT: we narrowed down the issue, and it seems that only apps using Unity3d along with the Durovis Dive SDK for head tracking are not supported. It seems it's because they use their own native library to manipulate the sensors, so I'm not sure we can do anything about these apps...
I just uninstalled Xposed! I'll flash it back and report! Thanks a lot.
lrq3000 said:
We just updated the module, Arindammanidas. Please try the latest version (v1.5) and see if this fixes your issue:
http://repo.xposed.info/module/net.kajos.gyronoisefilter
https://github.com/lrq3000/XposedJitteryGyroFix/releases/tag/v1.5
If it doesn't fix your issue, please tell us what app and what version doesn't work with our module. We are aware that there are still a few apps that may not work, in particular Cmoar Cinema Pro v4.3 (but version Free is OK). We don't yet know why (the source is closed).
Click to expand...
Click to collapse
Hi, I tried out version 1.5 and it still gives me jitters in the google cardboard app demos. Probably the cardboard app is reading from somewhere else?
Which google cardboard app? Do you mean the treasurehunt? Normally, treasurehunt is supported. Is it another app you are talking about?
lrq3000 said:
Which google cardboard app? Do you mean the treasurehunt? Normally, treasurehunt is supported. Is it another app you are talking about?
Click to expand...
Click to collapse
I was talking about the demos on the cardboard app itself. When you open the Google Cardboard app, you have an option for some demos e.g. Windy Day, Google Earth etc.
These still have jitters.
You're correct, I totally forgot about those demo apps and I didn't try them. We will see what we can do. Thank you for the feedback.
Is there any way to reduce drift when using photosphere or taking panorama photographs in Google camera?
Hello, I have a 'lenovo k3 note "with android 5.0.1, this phone has no physical gyroscope, makes a software simulation using other sensors.
I've been playing some value to your program and seems to improve a bit, but keeps moving image when this stop.
I can change the way you treat the sensor data? Even without one hardware.
Moto G 2014
For those with a Moto G 2nd generation, what are your settings?
Dear developers.
Is it possible to put an inversion of some of the axes in this module?
Some Chinese smartphones (for example ZOPO ZP998, iOcean x8), the gyroscope's axis is inverted, and the manufacturer ignores requests to fix it.
AKSU78 said:
Dear developers.
Is it possible to put an inversion of some of the axes in this module?
Some Chinese smartphones (for example ZOPO ZP998, iOcean x8), the gyroscope's axis is inverted, and the manufacturer ignores requests to fix it.
Click to expand...
Click to collapse
Wow, I was about to post the same because I was impressed someone managed to change gyroscope values. Yes, I have the same problem, my spanish smartphone comes with the X axis inverted, so the sensor fusion makes strange things (gyroscope and magnetometer/accelerometer read oppossite values), although I think this could be another app instead of adding it to your noise filter one (because in my phone there's no jittery, only a changed axis. It could be solved by the developers, but at this time there's no patch).
Thanks a lot!
Related
[APP] SimplePiano V4.3 [21.06.10] [ VGA / WVGA / QVGA / HVGA ]
SimplePiano V4.3 SimplePiano with the SP_mickesjo WVGA Skin As the name suggests it's a simple piano application. I took over "CrisRowlands SimplePiano" after Cris decided to give up developing it (Original thread). The main reason I took over is because I wanted to implement multitouch. I own HTC HD2 so my emphasize was on the WVGA format, but the application should also support VGA resolution. It should be pretty easy to create skins for other resolutions as well... Features: WVGA, VGA, QVGA, HVGA versions. It has three octaves. Record and Playback. Dualtouch via the PinchToZoom events (not ideal but the best I could find...) Customizable skins. Customizable sounds (currently include Piano, Acoustic Guitar & Violin). Currently in develop: Continuous sliding of the keyboard view. Change the skn files to support arbitrary number of keys. CHANGELOG: 21.06.10(4.3) Added two single finger chord modes (Major and Minor) - Requires special skin. I don't like this solution so I didn't follow it. If anyone is interested in this please let me know... Added minimum note sustain length control (in milliseconds). If minimum sustain is not specified the full sample is played. Added support for looping over the sample (by looping over the sample) Two samples can be specified, one is played once in the beginning, and the second is played over and over until the key is released. If the second sample is not specified the first one is used for the loop. This feature requires appropriate sound samples to be available. Sounds are controlled via "Sound.lst" file. Different behavior of the notes (those mentioned above) can be controlled via this file. Added OK/Cancel button to the settings dialog. Vibration LED index can be now set via the "Device" tab in the settings dialog. Polyphony can control to the "Device" tab in the settings dialog. Fixed a problem where SimplePiano closed if an incompatible skin was chosen. Fixed issue where bitmaps were not always clipped to bounds. Fixed crash when sound file did not exist. Changed applications icon (thanks mickesjo) 11.06.10(4.2) Added some exception handling during initialization and a vga skin for the Default skin. Fixed the link to point here. 10.06.10(4.0) Initial release including the new features (dualtouch, recording etc. as desribed in this post). Screenshots: Skins: Default WVGA skin, MewSkin WVGA skin, MewSkin VGA skin, SP_mickesjo WVGA skin, Saplorer UI WVGA skin Settings Dialog Download: SimplePiano V4.3 (WVGA/VGA/HVGA/QVGA) Alternative Download(Uploading) (including mickesjo's skin and Osprey00's alternative piano sounds - thanks to Osprey00) Additional Skins: (must be installed in the same location as the main application) HVGA Rescale of the original skin (thanks to sam-2007 on post #130). MewSkin (WVGA/VGA) SP_mickesjo (WVGA/VGA/QVGA), thanks mickesjo. atlaswing created replacements key images, these can be found on post #47. HVGA version (thanks to sam-2007 on post #130). Saplorer UI (WVGA), thanks xclarinetistx Additional Sounds (thanks conantroutman): (must be installed in the same location as the main application) Violin Acoustic Guitar Piano Samples 8bit (lower quality) - these samples replace the default piano samples that comes with SimplePiano. Alternative piano samples (thanks to Osprey00) Rectangular QVGA (320x320) patch - extract the files from the zip files into the "Default" skin folder. Click to expand... Click to collapse Previous version: SimplePiano V4.2 (WVGA/VGA) For QVGA the modified default skin has to be installed too. Skins: Default (WVGA/VGA/QVGA)(CrisRownlands' original skin) MewSkin (WVGA/VGA) SP_mickesjo (WVGA/VGA/QVGA), thanks mickesjo Click to expand... Click to collapse Other Notes: If I may quote Cris: I hope you folks like it Feedback is appreciated, improvements can only happen if I know what you folks want. Click to expand... Click to collapse
Some documentation Some useful information about the *.skn files and the Sound.lst file. The *.skn files These files define the location of the different items on the screen. For each screen resolution the skin supports there should be one skn file. When a skin is chosen, SimplePiano search the skin directory for a compatible skn file and loads the skin according to its content. here's an example for a skn file Code: Display=0,0,480,800 This line declare the target resolution of the skin. It is given in the following format: 0,0,Width,Height Code: Name=mewskin The name of the skin, currently not used for anything. Code: Octave1=360,10,120,120 Octave1Image=OneNormal.png,OnePressed.png Each key should include those two lines. The first line describe the location and size of the image, using the following format: KeyName=Left,Top,Width,HeightThe second line points to the images to be used with this key. The following format is used: KeyNameImage=NormalStateImage, PressedStateImageWhere KeyName is one of the following: Octave1, Octave2, Octave3 Quit, Settings, Record, Replay, NormalKey1, ..., NormalKey8 SharpKey1, ..., SharpKey6All these keys must be specified. NormalKey# stands for the normal note keys (C,D,E,F,G,A,B & C) SharpKey# stands for the semitone keys (C#, Eb, F#, Ab, Bb & C#) In addition the toolbar background has to be specified as well: Code: Toolbar=360,0,120,800 ToolbarImage=Background.png unlike a regular key here only one image is supplied. In addition the optional chord modifier keys can be specified (using the same logic): Code: ChordMajor=-30,0,60,60 ChordMajorImage=MajorNormal.bmp,MajorPressed.bmp ChordMinor=-30,60,60,60 ChordMinorImage=MinorNormal.bmp,MinorPressed.bmp The Sounds.lst file This file defines the sounds to be used with the selected instrument. First of all it binds a note to a wav file. In addition different properties can be set for each note, as I'll explain below: Code: [1] The file is divided into octave, currently there are 4 octaves (since SimplePiano also includes C4 &C#4). Each octave is titled with its number. Code: C=Data\C1.wav, Loop=0 Then, the sound files for this octave are given. The following format is used: Note=FileName, Option1=value1, Option2=value2,...Note is one of the 12 notes in an octave. The following notation is used: C,Cs,D,Eb,E,F,Fs,G,Ab,A,Bb,B. Then a relative path to the sound file is specified. Followed by a list of parameters and values pairs separated by comas. These parameters are optional. The following parameters can be declared: Loop=#This specify how many times to loop over the sample (0 - plays the note once, -1 loop infinitely). If a non-zero value is given for a note, the note will be played as long as the key is pressed, once the key is released the playing will cease immediately. By default (if not specified) Loop=0. MinimumLength=#This specify the minimum length (in milliseconds) a note is to be played. If this value is -1 the sample will be fully played. any other (non-negative number), the note will be played at leas this amount of time. For example, if a value of 500 is specified, every touch on the keyboard will generate a 500ms sound. If the key is held longer than 500ms the sound will stop when the key is released (or the sample reaches its end). The default behavior depends on the "Loop" setting: If Loop=0 MinimumLength=-1. Otherwise MinimumLength=0.
Good job man Good luck with this I don't suppose you could maybe send me a copy of the source code etc? Maybe upload it & give me a link. The main reason I wasn't able to implement these features is because I don't know how. It would be quite interesting to learn about how you did it
good job on significantly improving chris' already nice work And dang you've beaten me to first reply
ephestione said: good job on significantly improving chris' already nice work And dang you've beaten me to first reply Click to expand... Click to collapse cris_rowlands said: Good job man Good luck with this I don't suppose you could maybe send me a copy of the source code etc? Maybe upload it & give me a link. The main reason I wasn't able to implement these features is because I don't know how. It would be quite interesting to learn about how you did it Click to expand... Click to collapse Thanks guys... Cris... no problems, just let me tidy the project a little...
I love your simple piono 4.1. Now 4.2 should be better than 4.1. Thanks for the updated version...
OP, thanks for the APP. I look forward to future updates once more of the bugs have been knocked out!
Update: added a download link to the mewskin, this is nicer looking especially for the VGA resolutions (but also on the WVGA). Kudos to the author (xxmewstarxx)... Just install the mewskin.cab after installing SimplePiano (no need to reinstall). Z.
for now, I vote for default to 0 interval between multitouch keypresses, instead of 300ms Not much of a big deal as you can change it yourself, yet if you already restarted to register multitouch, and you change that option later, you need to restart again I am also thinking about spanning through more than 3 octaves, and a different method of changing the octave that lets you do that faster and more easily, will report back when I have a better idea
Nice! Unfortunately the space on the screen ins't that much but if there was a way to "somehow" squeeze in and create spaces for Chord Symbols/Buttons and when these are being pressed, a chord is being played (a flat chords, an arpeggio). Said chord-sounds could be default-sounds distributed with the application or pre-recorded by the user. Something similar to those Casio-chords (or whatever they are called) which do the fingering for you. Another option could be that it played just the root of the chord so one could create some variety and a little base-line while playing the melody on the normal keyboard. The problem, I guess, is surely the space on the screen and the limit of two touches simultaneously. Just some thoughts....
ephestione said: I am also thinking about spanning through more than 3 octaves, and a different method of changing the octave that lets you do that faster and more easily, will report back when I have a better idea Click to expand... Click to collapse tilleke said: Nice! Unfortunately the space on the screen ins't that much but if there was a way to "somehow" squeeze in and create spaces for Chord Symbols/Buttons and when these are being pressed, a chord is being played (a flat chords, an arpeggio). Said chord-sounds could be default-sounds distributed with the application or pre-recorded by the user. Something similar to those Casio-chords (or whatever they are called) which do the fingering for you. Another option could be that it played just the root of the chord so one could create some variety and a little base-line while playing the melody on the normal keyboard. Click to expand... Click to collapse Well, as for the 3 octave limitation, that could be easily broken, just that I don't have the sounds... If someone's willing to generate them I'll include them in the application. About changing octaves I thought of two possibilities, one would be to just add two buttons at the end of the keyboard that moves one octave up or down. Another possibility is to create a slider above (or below) the keyboard on which you can slide left or right to change octaves. Sliding can also be continuous so that the first note is necessarily C. Such slider can also have some buttons to toggle chords buttons as tilleke suggeted... tilleke said: The problem, I guess, is surely the space on the screen and the limit of two touches simultaneously. Click to expand... Click to collapse I really hope HTC will release some proper API that supports real multitouch... Z.
tilleke said: Nice! Unfortunately the space on the screen ins't that much but if there was a way to "somehow" squeeze in and create spaces for Chord Symbols/Buttons and when these are being pressed, a chord is being played (a flat chords, an arpeggio). Said chord-sounds could be default-sounds distributed with the application or pre-recorded by the user. Something similar to those Casio-chords (or whatever they are called) which do the fingering for you. Another option could be that it played just the root of the chord so one could create some variety and a little base-line while playing the melody on the normal keyboard. The problem, I guess, is surely the space on the screen and the limit of two touches simultaneously. Just some thoughts.... Click to expand... Click to collapse zevele said: Well, as for the 3 octave limitation, that could be easily broken, just that I don't have the sounds... If someone's willing to generate them I'll include them in the application. About changing octaves I thought of two possibilities, one would be to just add two buttons at the end of the keyboard that moves one octave up or down. Another possibility is to create a slider above (or below) the keyboard on which you can slide left or right to change octaves. Sliding can also be continuous so that the first note is necessarily C. Such slider can also have some buttons to toggle chords buttons as tilleke suggeted... I really hope HTC will release some proper API that supports real multitouch... Z. Click to expand... Click to collapse I was thinking the exact same things regarding octave switching, more like automatic recognition, as in when you press a key near the border, the keyboard gets slided past the border of a X length to accomodate for the "direction" you're taking And tilleke suggestion is very interesting. Here's my take: just like you play two sounds together when you do multitouch, you don't need to really record a chord, you only need to play 3 sounds together. Example, put a swith on top, with three positions: 1) Normal 2) Major chord 3) Minor chord Then you press, say, C Cases: "normal" : the note C is played "major" : the notes C E and G are played "minor" : the notes C D# and G are played THe switch would be a slider onr, because a toggle one (1-2-3-1-2 and so on) would take too long if you need 1 and you're currently on 2.
Glad to see somebody picking up on this where Chris left off..... If you want more octaves I'd be happy to provide them. Just out of interest, are the samples in this version the same ones from Chris' original version?
conantroutman said: Glad to see somebody picking up on this where Chris left off..... If you want more octaves I'd be happy to provide them. Just out of interest, are the samples in this version the same ones from Chris' original version? Click to expand... Click to collapse More samples can't hurt, but at the moment I'm trying to solve the chords feature... The samples are the same ones from the previous version. Thanks, Z.
Totally awesome. Poor WM support. it seems like everyone writes off Windows platform as thou its limited, but if you had the support you show with this simple piano, the experience level and communication would be thought on a positive (note) about windows platform... GOOD JOB!!
Thanks zevele for the work! xda member TWolf has a FlashPiano that he stopped developing. The program itself has a great sample of 4 instruments in mp3 form, but I don't know enough about music to rename them. Maybe somebody here can take a look and rename the files. Here's the link and source code from TWolf: http://forum.xda-developers.com/showpost.php?p=2806409&postcount=126
Would be nice to include mellotron in this, like the Manetron for iPhone http://www.youtube.com/watch?v=pcIRG1X0VMs
dio62000 said: Would be nice to include mellotron in this, like the Manetron for iPhone http://www.youtube.com/watch?v=pcIRG1X0VMs Click to expand... Click to collapse Seeing these applications on the iphone just depresses me... they run so much better than on the windows mobile... Specifically to your question... If you mean playing several instruments in parallel, it shouldn't be to complicated to implement...
Okay, here's my idea for a solution for the chords feature, I've added two buttons below the keyboard one toggles a major chord and the other a minor. As all other buttons these can be moved and changed through the skin files. Please try it and let me know what you think... SimplePiano http://rapidshare.com/files/398328285/SimplePianoV43beta.CAB MewSkin http://rapidshare.com/files/398329265/mewskincabV43beta.CAB Thanks, Z.
Can this be hosted somewhere else? Rapidshare gives some of us problems and the the download limitation sucks. I can't download the v43beta after just downloading the v42 version. My suggestion is drop.io or dropbox... You can even use the free Skydrive for this. Thanks for the good work...
[Q] Panorama photography
I mentioned it briefly in another post and searched the forum - but found nothing. I am talking about the Sweep Panorama mode of the Xperia-S camera. Not the '3D' versions, the 'normal' (2D) sweep panorama - the last icon in the first ('Shooting mode') menu. I tend to experience problems with it and am not sure if everyone has observed the same. In Sweep Panorama mode, whatever direction of sweeping I choose, I tend to get error messages that either: - I am sweeping too fast, or - I am sweeping too slow, or - just 'Picture could not be taken' with no explanation why. I need to mention that I have plenty of sweeping experience on my previous Xperia X10 and on a Sony Nex camera - so I am sweeping really smoothly and at medium speed. Are the phone position sensors and accelerometers too sensitive? (And the camera software inadequately set to interpret them?). This is happening in roughly 3 out of 4 attempts (or even 4 out of 5) making the function hardly usable and very annoying. Ironically, while the X10 had no such function, I was using a 'beta' version (called Panorama Beta) as a standalone app, offered by Sony Ericsson on the Android Market (now Play Shop). Despite being a beta, that app worked flawlessly and never gave me such problems. I have many excellent panoramas from that, and some have even won photographic awards. I particularly like the 'vertorama' mode, i.e. vertical sweeping. With the camera in 'landscape' mode, this captures a square-ish rectangle - with a wider field of view and more scene detail, at highest possible resolution. To capture a square (or 4:3 'portrait') vertorama, you need to stop sweeping early - and the Beta app had a 'Stop' button. The new version integrated within the Xperia camera has no 'Stop' and expects you to make very long sweeps. I tried to stop by pressing the on-screen or physical shutter button, but that produces the above errors - or a very long and narrow rectangle, half of it greyed and the other half a blurry, low resolution panorama. Disappointed with the function, I wanted to use the standalone Panorama Beta app, but it doesn't appear in the Market. Is it withdrawn by Sony? (As no longer beta and included with newer firmware)? Or is it only not appearing for the Xperia-S - presuming you already have it? I tried taking a backed-up .APK from the X10 and 'restoring' (installing) it on the X-S, but it does not install. The install process starts normally, but when the blue 'thermometer' finishes, the message is: 'The app did not install' - with no further explanation. I imagine it discovers the newer version already installed and avoids a conflict with it? All other 'panorama' apps on the market are much worse, from primitive to utter rubbish. They are either not 'sweep' and ask you to take multiple separate shots, asking you to manually align them to on-screen guide marks, before running a 'stitch' operation (resulting in very poor blends with obvious fault lines). Or they shoot relatively smoothly, but the end image is very lo-res, small in size and out of focus. Among all of them the Photaf app was closest to 'working' but it's only horizontal and stitches are a hit-and-miss (most of the time a miss - too obvious). Can others, please, share experiences with the Sweep Panorama mode in the Xperia-S camera? Does it work for you or have you got similar problems? Has anyone found solutions? Any suggestions how to make the Beta standalone app install and work? (The new one isn't standalone, so I am not sure I'll be able to uninstall it, even when I root the phone). Thanks for any info!
The new Sweep Panorama sucks big time indeed. There's a modified APK of the beta floating around, I've been using it on my Arc S/Neo for ages, works just fine! Don't have my S yet, so can't try it, but you can give it a go: http://www.box.com/s/182e205dc19cbba235f7
Ambroos said: The new Sweep Panorama sucks big time indeed. There's a modified APK of the beta floating around, I've been using it on my Arc S/Neo for ages, works just fine! Don't have my S yet, so can't try it, but you can give it a go: http://www.box.com/s/182e205dc19cbba235f7 Click to expand... Click to collapse Thanks a lot - this is the same Panorama 'Beta' I loved on my X10, works well on the X-S. I'll now use it as main pano tool and hope Sony will fix their in-camera version with one of the firmware updates. Not sure if they read (or at least scour with spider-bots) this and similar sites for insight what needs fixing - if I knew a contact point I'd write to them but won't spend time researching their feedback channels... The S camera rocks otherwise, wish you to get yours soon!
I'll let them know whenever I get the chance
[Q] Decrease Resolution for Gaming?
Hello Tablet Z community, This is my first post in this devices forums since getting mine last week. It's a great device, love it, etc. I've never owned an Android device with a screen resolution this high so I've yet to encounter this problem - some of my games (specifically the emulator PPSSPP) have relatively low framerates (compared to my less powerful Samsung P6810 @ 800x1280). I know with computers in particular it's trivially easy to change resolutions in games/the OS, especially to increase FPS but I've never seen a method to do this on Android and Google searches turn up people mentioning device resolution without changing them. Does anyone know if it's possible to, ideally, force a different resolution for a particular application? A less than ideal solution would be a system wide change but I would be willing to endure temporarily to increase FPS. Any advice and suggestions would be greatly appreciated
I would be interested to know about this, iv just loaded ppsspp however havent been able to play any of the playable games listed, I did see a few videos of the xperia z playing well, however that has the same resolution and specs.
juzza87 said: Does anyone know if it's possible to, ideally, force a different resolution for a particular application? A less than ideal solution would be a system wide change Any advice and suggestions would be greatly appreciated Click to expand... Click to collapse That was recently discussed in this thread: LCD Density Changes and Results (With Pics)
Cat McGowan said: That was recently discussed in this thread: LCD Density Changes and Results (With Pics) Click to expand... Click to collapse This is very different, setting the DPI to a non-stock value just resizes the userspace, the resolution is fixed and unchangeable as the OP is thinking. Compared to a Windows PC where you can change the resolution, in Android you only have the ability to change the dpi, which states how large the pixel-to-screen size is. A smaller number indicates a smaller pixel-to-screen size, meaning the information shown on screen is sized for a laeger screen (making it smaller, since the screen is a fixed size). And a larger number has the reverse effect. Android UI guidelines set the optimal dpi for resolution vs. screen size, to mainain a similar experience across devices (similarly sized icons and fonts, etc). Again, this has nothing to do with adjusting the physical resolution of the device, which (to my knowledge) is not possible in Android.
daveid said: This is very different, setting the DPI to a non-stock value just resizes the userspace, the resolution is fixed and unchangeable as the OP is thinking. Compared to a Windows PC where you can change the resolution, in Android you only have the ability to change the dpi, which states how large the pixel-to-screen size is. A smaller number indicates a smaller pixel-to-screen size, meaning the information shown on screen is sized for a laeger screen (making it smaller, since the screen is a fixed size). And a larger number has the reverse effect. Android UI guidelines set the optimal dpi for resolution vs. screen size, to mainain a similar experience across devices (similarly sized icons and fonts, etc). Again, this has nothing to do with adjusting the physical resolution of the device, which (to my knowledge) is not possible in Android. Click to expand... Click to collapse Heh. Thanks for the schooling, but it was unnecessary, I didn't just fall off a turnip truck.
Thanks for the replies guys, at least now I know for sure..
Daydream Elements: Free VR Development Guidebook App
Daydream Elements by Google is a new, free app that serves as a guidebook, covering VR development basics. While those familiar with VR development would probably be disinterested in this new app, as it is so basic, it’s a great starting point for those unfamiliar with VR. The app showcases six examples of tips and tricks for VR development, complete with the pros and cons for their use. According to Upload VR, “three of these [examples] are concerned with locomotion. One details teleportation, another showcases smooth movement with restricted peripheral vision, and another shows third-person gameplay. Interestingly examples of all three of these types of experiences have hit Daydream in the past few months. Teleportation can be seen in the VR port of Layers of Fear, while the excellent Eclipse uses smooth movement. Meanwhile both Lola and the Giant and Along Together both used a third-person camera that followed a main character.” Google’s developer page outlines the following examples below: Locomotion: techniques for enabling navigating a VR environment Three ways to achieve locomotion: Teleportation is locomotion technique for apps using first-person perspective that allows the user to near-instaneously move to a target location. This technique reduces the simulator sickness that many users feel when the virtual camera moves. Tunneling is a technique used with first-person locomotion (such as walking ) where, during movement, the camera is cropped and a high-constract stable grid is displayed in the user’s peripheral vision. This is analogous to a user watching first-person locomotion on a television set. Chase Camera is a technique used with third- person locomotion, where the user is controlling a character. Standard third-person camera implementations are problematic in VR and contribute to simular sickness. Chase Camera offers predictable motion – camera rotation only occurs under user direction, and small character movements don’t move the camera at all. Menus and Virtual Controls: The Daydream controller only exposes two buttons to developers: the clickable touchpad, and the app button. For many developers, two discrete controls does not provide a rich enough set of commands for the games and applications that they would like to create. One solution is to present the user with virtual controls for the app’s command scheme. Click Menu provides the user with a radial menu of commands emanating from the cursor when the menu is invoked. Because users must click directly on options, this menu design trades the speed of a more gestural approach with the control of discrete clicks and scales well with complex command hierarchies. Swipe Menu leverages the Daydream controller touchpad to allow the user to quickly select between a small set of commands. This menu trades efficiency for accuracy and does not scale well to large number of commands. Rendering and Lighting: Performance is critical to VR apps but can be especially challenging on mobile GPUs. Many commonly available mobile shaders and per-pixel lighting solutions provide high quality results but perform poorly on mobile VR systems due to extremely high resolutions, rendering multiple views, distortion and general mobile performance issues. The Rendering & Lighting demo uses Daydream Renderer to showcase rendering effects that are typically difficult to achieve on mobile hardware. This scene demonstrates Daydream Renderer features like per-pixel lighting, tangent-space normal maps, dynamic shadows, realtime specular highlights, and reflections. Daydream Rendering and Lighting Demo included as part of Elements as a demonstration of the Daydream Renderer’s capabilities. The app also spells out all known issues, which you can find here. This app is definitely for newcomers to VR, however since many people are not yet familiar with the space, it seems like a user-friendly platform that encourages people to try their hand at developing. Source: appdevelopermagazine
GCam 7.2 for Android 10
Wanted to make a quick post about a version of GCam that I found that has both wide angle and slow motion working (seemed like in the past this was a big deal). The LibPatcher doesn't not appear to make any difference when changing the settings, and I know for sure that GeoLocation does NOT work on the phone with this mod. tigr: trCamera_V7.1.apk Download trCamera_V7.1.apk by tigr. www.celsoazevedo.com I attached my config file to the settings that I'm using. The image quality seems to be maybe slightly worse than the stock camera in good lighting, however this beats stock in low lighting even with just HDR+ Enhanced (which is a nice balance between speed and quality for low light). There are some settings that can only be turned on/off by adding them to the viewfinder, such as focus tracking (it's currently on w/ config file). There are some other interesting bits I didn't look into that makes it like a pro mode but I made it such that the viewfinder is clear of all shortcuts as using them too much can actually lock up the camera "Camera is busy" error. config file needs to be placed in /trCamera/XMLConfigs (should be made when opening app for first time) Last note, if you don't have GApps or microG (which has literally never worked for me except for this); this is a nice stub substitute that adds just enough for the camera to launch w/o issues. GitHub - lukaspieper/Gcam-Services-Provider: App faking only the absolute necessary Apis to use Gcam without Play Services App faking only the absolute necessary Apis to use Gcam without Play Services - GitHub - lukaspieper/Gcam-Services-Provider: App faking only the absolute necessary Apis to use Gcam without Play Ser... github.com