I'd like to request more control on Bitmaps.
Feature #1 - Instead of having a 0-100% value for scaling that controls X and Y axis together, you should allow X and Y be controlled independently. I think this is easily achievable.
Thanks again
Related
ive seen people talk about some anti-shake feature and i was looking my htc mozart up and down and couldnt find it. now some days later ive read some more and it seems not only each brand got its own exclusive software for wp7 they also have exclusive camera features.
so i think its time to see which one got what feature and whats missing and why, maybe we also find a way to change that.
please provide info about your camera app like:
Company
Modell
Availible Settings Photo/video
HTC
Mozart
Scene
-vertical
-horizontal
-sport
-beach
-backgroundlight
-candlelight
-macro
Effect
-Grey
-Negative
-Sepia
-Solar
Resolution
-1M (640x480)
-2M (1600x1200)
-3M (2048x1536)
-5M (2592x1944)
-8M (3264x2448)
Measuring Mode (Messmodus)
-center zone
-average
-sport-measuring
Flicker Adjustment
-Auto
-50hz
-60hz
Also 3 buttons for Light on the right Side.
Ill Update This Thread
maybe you should include video settings too.
I have the omnia 7. I will put the default setting on top since settings don't save.
Omnia 7
Camera
AF mode
-Normal
-Macro
White Balance
-Automatic
-Incandescent
-Fluorescent
-Daylight
-Cloudy
Image Effect
-None
-mono
-negative
-sepia
-antique
-green
-blue
Contrast
-Medium and 2 settings below and 2 above (total = 5)
Saturation
-Medium and 2 settings below and 2 above (total = 5)
Sharpness
-Medium and 2 settings below and 2 above (total = 5)
EV
- From -2 to +2 (Total = 5)
ISO
- Auto, 50, 100, 200, 400, 800
Metering
-Centre weighted
-Matrix
-Spot
Photo Quality
-High
-Low
-Medium
Wide dynamic range
-Off
-On
Photo Resolution
-5M, 3M, 2M, VGA
Antishaking
-Off
-On
and Video settings seem to be the same more or less
Using AndroSensor, I get the following output from my HD2:
800x480
160 dpi (custom set)
Logical Density: 1.0
X DPI: 254
Y DPI: 254
Refresh Rate: 60Hz
32-Bit colour
Which looks fine. But the One X gives:
1280x720
320dpi
Logical Density 2.0
X DPI: 345.0566
Y DPI: 342.23157
Refresh Rate: 58Hz
32-Bit colour
Why are the X and Y DPI values different? Should they not be the same for a square pixel ratio?
Also, a minor thing but why a refresh rate of 58Hz and not 60? Is AndroSensor just not reading it right?
The reason I ask about the X/Y DPI thing, is that the screen jumping bug looks like a monitor trying to autofit a non-native resolution signal, and perhaps this is related somehow?
Or are the physical pixels not square?
I have no idea but I'm going to post here so this thread is not forgotten in time cuz if this is related to the screen flickering issue (that isn't really gone with 1.28 OTA) I think it deserves more attention
Dave Trouser said:
But the One X gives:
1280x720
320dpi
Logical Density 2.0
X DPI: 345.0566
Y DPI: 342.23157
Refresh Rate: 58Hz
32-Bit colour
Click to expand...
Click to collapse
None of those DPI values are correct for the screen anyway which is roughly 312dpi.
The odd values are from DisplayMetrics in Android itself. Android tries to be device independant and a lot of the "pixel" values are actually Density Independant Pixels which need to be converted to physical pixels.
I don't think this is significant. My One X has exactly the same values and it doesn't have the screen corruption or tearing at all.
It makes sense then. The refresh rate is meant to be at 60, not 58, or else you get flicker. I remember seeing an identical problem on a monitor recently, where the refresh was slightly off 60 and caused flickering. This could be what's causing it. I will run a test on my other HTC One X that seems bug free to see if it is also running at 58. The one I'm posting from is currently doing 58.
Hii to All for first...
Nexus 5
I created a widget with the CPU frequency:
- The widget always displays the maximum frequency: that is, in 2265;
- The value is not updated
- By measuring programs of the CPU the true value is lower than that displayed by the widget.
How can you have a true value?
Jazz__75 said:
Hii to All for first...
Nexus 5
I created a widget with the CPU frequency:
- The widget always displays the maximum frequency: that is, in 2265;
- The value is not updated
- By measuring programs of the CPU the true value is lower than that displayed by the widget.
How can you have a true value?
Click to expand...
Click to collapse
Just to clear up a possible source of error: which variable did you use to output the CPU frequency? There are three available in Zooper: #SCPUMIN# = Minimum Frequency, #SCPUMAX# = Maximum Frequency, #SCPUCUR# = Current Frequency.
Also keep in mind that Zooper only updates its widget data every few seconds, so there might be always be a little lag between the real and the displayed data.
I only use #SCPUCUR# = Current Frequency
Upsate are set to less possible!!
Instrument: Spyder4 — LCD (generic)
Correction: EDR for OLED created with primaries R, G, B, White <OLEDFamily_20Jul12.ccss>
Measured luminance: 268.8 cd/m²
Profile whitepoint XYZ (normalized): 246.12 258.29 285.13 (95.29 100 110.39), CCT = 6572K
Measured black luminance: 0.4969 cd/m²
Contrast: 541:1
Measured vs. assumed target whitepoint ΔE*00: 0.62
Average ΔE*00: 0.91
Maximum ΔE*00: 1.77
✔ Nominal tolerance passed
✔ Recommended tolerance passed
XYZ Lut + Matrix
How to add to FireFox
about:config ->
gfx.color_management.display_profile -> /sdcard/jem.icm
gfx.color_management.enablev4 -> true
gfx.color_management.mode -> 1
Restart FireFox
This profile improves shadow detail, highlights, removes the green tint and corrects gamma.
http://petapixel.com/2012/06/25/is-your-browser-color-managed/ - Verify that its working
You can compare with the default browser at http://www.lagom.nl/lcd-test/all_noprofile.php
Rec709 Bt.1886 video profile coming when an android video player finally supports icc or 3d lut.
Hi all,
first things first i dont have a problem its just a question out of curiousity.
I was i the App "Easy DPI Changer" to change the DPI scaling on my OP3 to 480.
That was when i saw the "Display Info" Page was showing a Resolution of 2064x1080, which in it self is a strange meassure.
Everywhere i checked (and how i remembered it) the OP3 & 3T where using a Panel with a Resolution of 1920x1080p.
Now my question, where are the other 144 pixel coming from?
Do i have some naughty pixels that make babys when im sleeping? (that would be the new definition of creepy though)
Or (the more likly one) is it because i dont use the on-screen Buttons and the that space is used?
Thanks in advance and happy weekend
DeMon
Your second assumption is correct. The absence of navigation bar causes the app to assume the physical screen size (or so called resolution) wrongly. Here we see the app trying to add or subtract its available pixels (for example, on yours its 1920x1080, on mine with navigation bar, it's 1790x1080).
The way I (or anyone) can know it's the navigation bar is due to the only number increasing or decreasing is the physical vertical size. So, how do we know precisely what's causing the size to increase apart from assuming it? Maths, that's what.
First, we should know that everything on your screen is displayed in a metrics known as 'dp', density-independent pixels. This metric relies on the dpi, pixel density per inch. Thankfully, this metric can be easily converted to dp, with the formula of:
px = dp * (dpi / 160)
Thanks to the peeps at the Android Developer Support Site for supplying the formula.
So, we have our formula and metrics. Let's insert the numbers.
We know the size of navigation bar is constant, 48dp, whichever or whenever you are, as long as it has a navigation nar, it's 48dp. Of course, some ROMs have a feature to resize this to your willing. But, we aren't going to factor that, we're going to what the standard says.
Then, the DPI is a pretty easy variable to figure out, it's 480.
Punch the numbers and you have:
px = 48 * (480 / 160)
px = 48 * 3
px = 144
Voilà. 144 pixels. Add this to our original vertical resolution, 1920, and we have 2064. Funny thing is that even if you set this to a different DPI, it still works. Let's try the case on mine. I have 48dp navigation bar height with 432 DPI.
px = 48 * (432 / 160)
px = 48 * 2.7
px = 129.6
Add up that 129.6 to 1790 and we'll have, well, 1919.6 but you can round that up to 1920.
I can also consider those pixels making babies, that isn't off the logic.
Cheers!
F4uzan said:
Your second assumption is correct. The absence of navigation bar causes the app to assume the physical screen size (or so called resolution) wrongly. Here we see the app trying to add or subtract its available pixels (for example, on yours its 1920x1080, on mine with navigation bar, it's 1790x1080).
The way I (or anyone) can know it's the navigation bar is due to the only number increasing or decreasing is the physical vertical size. So, how do we know precisely what's causing the size to increase apart from assuming it? Maths, that's what.
First, we should know that everything on your screen is displayed in a metrics known as 'dp', density-independent pixels. This metric relies on the dpi, pixel density per inch. Thankfully, this metric can be easily converted to dp, with the formula of:
px = dp * (dpi / 160)
Thanks to the peeps at the Android Developer Support Site for supplying the formula.
So, we have our formula and metrics. Let's insert the numbers.
We know the size of navigation bar is constant, 48dp, whichever or whenever you are, as long as it has a navigation nar, it's 48dp. Of course, some ROMs have a feature to resize this to your willing. But, we aren't going to factor that, we're going to what the standard says.
Then, the DPI is a pretty easy variable to figure out, it's 480.
Punch the numbers and you have:
px = 48 * (480 / 160)
px = 48 * 3
px = 144
Voilà. 144 pixels. Add this to our original vertical resolution, 1920, and we have 2064. Funny thing is that even if you set this to a different DPI, it still works. Let's try the case on mine. I have 48dp navigation bar height with 432 DPI.
px = 48 * (432 / 160)
px = 48 * 2.7
px = 129.6
Add up that 129.6 to 1790 and we'll have, well, 1919.6 but you can round that up to 1920.
I can also consider those pixels making babies, that isn't off the logic.
Cheers!
Click to expand...
Click to collapse
Wow didnt thought of this kind of extended answer. Thanks for that .
This explains so much
so long
DeMon