Related
Apologies for cross posting, also posted on HowardForums.
Does anyone know what the camera settings actually do? I mean specifics.
For instance-
Is changing saturation to 1 effectively converting the image to grayscale or is color data preserved?
When it comes to contrast, is 3 a linear curve? What sort of curve is applied at the other settings?
For sharpness, 3 is the default. Is changing the setting to 1 or 2 simply appying less sharpening, or is it actually softening/blurring the edges?
Are other image formats besides JPEG supported and just not enabled? Lossless formats perhaps?
I know we are not talking about an amazing camera, but I would love to be able to find a baseline to work from. The closest thing to raw, unaltered data with some level of consistency between each capture would be absolutely wonderful.
I see myself using the GPS Photo feature on the Tilt quite often, especially if I can tweak the camera settings.
Thanks!
hi guys,
i would really appreciate if any of you could tell me is just me or others facing the same problem. I've set the saving pictures taken as storage card but each time i take a ew photo, it shall show as unsupported format or corrupted file when i want to view t using pictures or resco photo viewer. why does it take so long to go back to camera after taking a picture especially if set it to storage card as default. hope any of you could help me. thanks.
I'm guessing your storage card is corrupt, try reformatting it.
You can change the amount of time the capture review stays on the screen, if that's the other issue you are having.
SlightlyTilted said:
I'm guessing your storage card is corrupt, try reformatting it.
You can change the amount of time the capture review stays on the screen, if that's the other issue you are having.
Click to expand...
Click to collapse
Yes absolutely right. I've never seen the point of reviewing the pics one at a time anyway. I've set mine to zero and it makes a huge time saving between pics.
Apologies to the OP for a somewhat hijacked thread - don't know the answers unfortunately.
Mike
Can someone who is running Cyanogen's 4.1.9999 pull a file off their device and post the contents for me here? I am having issues with my Market not showing updates in the "Downloads" section (though they appear when browsing or searching the Market). And was trying to come up with a solution that avoids wiping and reinstall apps. So, in my search I found the vending_preferences.xml located in /data/data/com.android.vending/shared_prefs directory. My file has the following contents, perhaps someone else (who doesn't have an issue with updates showing) has a different looking file?
Code:
<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
<int name="device_configuration_hash" value="-1071252813" />
<boolean name="local_db_sync_required" value="false" />
<boolean name="metadata_paid_apps_enabled" value="true" />
<long name="last_sync_time" value="1256002234287" />
<long name="last_tickle_id" value="1256039844956" />
<int name="SERVER_VERSION" value="1000" />
<long name="MARKET_LAST_HEARTBEAT_TIMESTAMP" value="1256039809975" />
<long name="MARKET_LAST_PENDING_DOWNLOAD_KICK" value="1255227202118" />
<string name="vending_tos_version">1.0.0</string>
<int name="reconciled_version" value="1620" />
</map>
Thank you.
EDIT - it was a system update issue, just like the other times, I guess this time no one else noticed it.. today, my market showed an update available as expected.
i don't know if i am having problems, but here is the file you requested.
Thanks, looks almost the same as me... The only way I would have known I had this issue (since 4.1.99 actually, maybe even 4.1.11.1) is that I use aTrackdog to keep tabs on my updates, and I still will check in the Market - Downloads section sometimes, and it shows apps as "Installed" but if I do a search it shows "Update Available". I do remember that this has happened globally twice (but no one else has mentioned this problem lately, so I was thinking I was alone here), once when the market first went "paid", and again at the launch of Cupcake.
So, logically thinking, with Donut coming out, I thought it was just a transition again. However, no one else (feel like a parrot, repeating myself) has posted about this, so I figured it was just me....
I do note one difference, wonder if I can remove that line in my file and see what happens (tomorrow when I am awake though)
<long name="MARKET_LAST_PENDING_DOWNLOAD_KICK"
does not appear in your file.
Lets use our community and collaborate around achieving a solution to a full market with all applications available for download with no restrictions based upon our current resolution.
Spawned from discussion from this thread
A Primer From jnadke
jnadke said:
It's a problem with the Android SDK.
Starting with 1.6, Google introduced screen sizes: Small, Medium, and Large. Our devices have Small Screens (along with the HTC Tattoo). The G1/Dream has a Medium screen, and the Droid/Nexus a Large screen.
The problem is the SDK defaults to Medium and Large screens. It's up to the application developer to test the application for Small screens and proactively add the indicator for Small screen support.
Most developers never bother to indicate the app can run on Small screens, so it gets excluded from your view.
I'm not sure if the small screen thing is linked to the /data or your Google user account. If I knew which, I'd figure out some way to spoof it, so we can get the full market on small screens. If it's on the /data somewhere, then that's a much easier fix.
The fact that clearing your /data and booting up a 480x320 fixes it, seems to indicate it's a value in the /data. It'd be interesting to do a dump of two /data directories with only the market resolution changed and see how they differ on a binary level. Then perhaps we can add a patch to the menu of NoMoRootfs (or a patch that's applied every bootup... or lock down the file that's modified).
If it's on the account, then either you'd have to intercept the Market App's data packet that indicates screen size and modify it proactively, or you'd have to change parts of the SDK to report the screen size as larger than it really is (this would be hard to do because apps use that interface too... you'd have to be able to detect if the request is coming from the Market App).
Click to expand...
Click to collapse
Here is the original 1.6 Vending.apk and de-compiled BakSmali source.
For those not familiar with smali/baksmali here is a short tutorial:
Download the baksmali/smali tools here
Make your changes in the source than recompile the changes back into the Vending.apk by doing the following:
1.) Make changes to files in source and use smali to re-assemble file:
# java -Xmx512M -jar smali.jar -o classes.dex out/*
2.) Then add classes.dex back into the APK with your favorite archive tool (Winzip, Winrar, etc) or via command line like this:
# zip Vending.apk classes.dex
3.) Push the new Vending.apk back out to your device and test out the Vending application.
# adb shell mount -o remount,rw /system
# adb push Vending.apk /system/app
# adb shell mount -o remount,rw /system
Ready set go!
EDIT: This has now been solved by moneytoo in the Tattoo forums
Links:
Link to moneytoo's thread on Tattoo forum
Mirror
myn said:
Lets use our community and collaborate around achieving a solution to a full market with all applications available for download with no restrictions based upon our current resolution.
Spawned from discussion from this thread
A Primer From jnadke
Here is the original 1.6 Vending.apk and de-compiled BakSmali source.
For those not familiar with smali/baksmali here is a short tutorial:
Download the baksmali/smali tools here
Make your changes in the source than recompile the changes back into the Vending.apk by doing the following:
1.) Make changes to files in source and use smali to re-assemble file:
# java -Xmx512M -jar smali.jar -o classes.dex out/*
2.) Then add classes.dex back into the APK with your favorite archive tool (Winzip, Winrar, etc) or via command line like this:
# zip Vending.apk classes.dex
3.) Push the new Vending.apk back out to your device and test out the Vending application.
# adb shell mount -o remount,rw /system
# adb push Vending.apk /system/app
# adb shell mount -o remount,rw /system
Ready set go!
Click to expand...
Click to collapse
Excited to see this solved! I know the brainpower is in this community to do it. Also, if this is solved I bet it could somehow be replicated/ported for tattoo or other qvga androiders and the vogue-android community would get a lot of praise for this.
Before someone chimes in, this is about getting the market to work without the 320x480 trick. The 320x480 trick tends to reset after a few days (which may help debugging if we can figure out why).
Fixing this Market/resolution issue is at the top of my wish.
jnadke said:
Before someone chimes in, this is about getting the market to work without the 320x480 trick. The 320x480 trick tends to reset after a few days (which may help debugging if we can figure out why).
Click to expand...
Click to collapse
interestingly, after using the 320x480 trick about a month ago, my market has not reset. I did it with plemen's evolution donut, an earlier version that had experimental settings in the build.prop which broke google voice (the program would not even run with that build for some reason). been using the same data.img, but various builds since then, and I have FULL market the whole time.
tatnai said:
interestingly, after using the 320x480 trick about a month ago, my market has not reset. I did it with plemen's evolution donut, an earlier version that had experimental settings in the build.prop which broke google voice (the program would not even run with that build for some reason). been using the same data.img, but various builds since then, and I have FULL market the whole time.
Click to expand...
Click to collapse
hrm.. Very interesting indeed..
tatnai said:
interestingly, after using the 320x480 trick about a month ago, my market has not reset. I did it with plemen's evolution donut, an earlier version that had experimental settings in the build.prop which broke google voice (the program would not even run with that build for some reason). been using the same data.img, but various builds since then, and I have FULL market the whole time.
Click to expand...
Click to collapse
Can you post the build.prop?
I was initially unaware of what the "temporary fix" was. It sounds a lot more like it's a server-side account flag that's being set.
I plan on making a temporary solution, until I can figure out what flag is being set and how to fix it.
jnadke said:
Can you post the build.prop?
I was initially unaware of what the "temporary fix" was. It sounds a lot more like it's a server-side account flag that's being set.
I plan on making a temporary solution, until I can figure out what flag is being set and how to fix it.
Click to expand...
Click to collapse
i don't know if the build.prop was the only thing that was changed on that build, but i think so. can't get to it tonight though, work is killing me, gotta dig through my stuff.
Just an FYI for you guys, the market/app size limitation is set by lcd.density.
mssmison said:
Just an FYI for you guys, the market/app size limitation is set by lcd.density.
Click to expand...
Click to collapse
Are you sure? What's your basis for thinking this? If you do a lcd_density of 140 @ 320x480 do the apps go away?
http://d.android.com/guide/practices/screens_support.html
from
http://market.android.com/support/bin/answer.py?hl=en&answer=165590
This page indicates that it's resolution-dependent.
Now, it's possible for certain apps to be missing due to density constraints:
The platform supports a set of resource qualifiers that let you provide size- and density-specific resources, if needed. The qualifiers for size-specific resources are large, normal, and small, and those for density-specific resources are hdpi (high), mdpi (medium), and ldpi (low). The qualifiers correspond to the generalized densities given in Table 1, above.
The platform also provides a <supports-screens> manifest element, whose attributes android:largeScreens, android:normalScreens, and android:smallScreens let you specify what generalized screen sizes your application supports. A fourth attribute, android:anyDensity, lets you indicate whether or not your application includes built-in support for multiple densities.
Click to expand...
Click to collapse
In 320x480 we use a lcd_density of 160.
The rubric says a 320x480 device should be 3.0" to 3.5". That means lcd_density of 164 - 192. You may be missing apps that require "mdpi" (unless the range is a little softer and 160 is in the "mdpi" range).
I could be that changing the density triggers an update to the market. If you cross a density threshold, you might trigger an update from "mdpi" to "ldpi", and it updates resolution as well. Perhaps that's why tatnai's change stuck for so long. He booted up in 320x480 at "ldpi" and when he changed to 240x320 he remained in "ldpi".
mssmison said:
Just an FYI for you guys, the market/app size limitation is set by lcd.density.
Click to expand...
Click to collapse
That actually makes 100% sense.
As most know I've been working on an app to change LCD Density and a few other things. One of the things I've noticed and the the Android SDK makes pretty clear for compatibility sake is the three different types of display targets all of which are linked back to density: http://developer.android.com/guide/practices/screens_support.html
The DisplayMetrics class also reflects this too:
http://developer.android.com/reference/android/util/DisplayMetrics.html
Code:
Constants
public static final int DENSITY_DEFAULT
Since: API Level 4
The reference density used throughout the system.
Constant Value: 160 (0x000000a0)
public static final int DENSITY_HIGH
Since: API Level 4
Standard quantized DPI for high-density screens.
Constant Value: 240 (0x000000f0)
public static final int DENSITY_LOW
Since: API Level 4
Standard quantized DPI for low-density screens.
Constant Value: 120 (0x00000078)
public static final int DENSITY_MEDIUM
Since: API Level 4
Standard quantized DPI for medium-density screens.
Constant Value: 160 (0x000000a0)
I can confirm tonight but if someone wants to now, try running 240x320 in 160 density confirming full market is supported.
I noticed that in 320×480 there are some apps I cannot find. Like an app says there are skins on the market so I click on it and it takes me to the market but it says it cannot be found. Running 320×480 lcd 160, want me to change my density to 164-192. Somewhere in there?
cp0020 said:
I noticed that in 320×480 there are some apparel I cannot find. Like an app says there are skins on the market so I click on it and it takes me to the market but it says it cannot be found. Running 320×480 lcd 160, want me to change my density to 164-192. Somewhere in there?
Click to expand...
Click to collapse
public static final int DENSITY_MEDIUM
Since: API Level 4
Standard quantized DPI for medium-density screens.
Constant Value: 160 (0x000000a0)
Click to expand...
Click to collapse
According to Myn, 160 should work, but you can give it a try.
Keep in mind the skin may be for high-density screens, like the DROID.
Does it matter which one? As long as its 164 and up?
myn said:
That actually makes 100% sense.
As most know I've been working on an app to change LCD Density and a few other things. One of the things I've noticed and the the Android SDK makes pretty clear for compatibility sake is the three different types of display targets all of which are linked back to density:
I can confirm tonight but if someone wants to now, try running 240x320 in 160 density confirming full market is supported.
Click to expand...
Click to collapse
It's linked to density and resolution, in my opinion.
Unfortunately, running 320x240 at 160 doesn't work all that great, I've tried it a long time ago as a test for fixing the market. The home screen gets all bunched up (the applications are all on top of each-other), and there's no app tray.
cp0020 said:
Does it matter which one? As long as its 164 and up?
Click to expand...
Click to collapse
Not really, I'd shoot for somewhere in the middle though, like 176 (I chose that because its divisible by 4, the screen should look better).
Wait, how can it be lcd density controlling the market? For the full market trick when people flash the 320×480 nbh and sign in they are still using there build with lcd density of 110-120. You see what I'm saying? Sorry I might not have a clue what I'm talking about lol
jnadke said:
Not really, I'd shoot for somewhere in the middle though, like 176 (I chose that because its divisible by 4, the screen should look better).
Click to expand...
Click to collapse
OK but just to be on the safe side should I backup my data and start fresh?
cp0020 said:
I noticed that in 320×480 there are some apps I cannot find. Like an app says there are skins on the market so I click on it and it takes me to the market but it says it cannot be found. Running 320×480 lcd 160, want me to change my density to 164-192. Somewhere in there?
Click to expand...
Click to collapse
The applications themselves define in their manifest the supported resolutions:
Code:
<manifest xmlns:android="http://schemas.android.com/apk/res/android">
<supports-screens
android:largeScreens="true"
android:normalScreens="true"
android:smallScreens="true"
android:resizable="true"
android:anyDensity="true" />
</manifest>
With appear to again correspond with the density:
Low density (120), ldpi
Medium density (160), mdpi
High density (240), hdpi
cp0020 said:
OK but just to be on the safe side should I backup my data and start fresh?
Click to expand...
Click to collapse
Ideally fresh data and a virgin gmail. But a non-virgin gmail should be suffice.
Hi everybody,
after beeing so glad that Motorola fixed the blue-tint issue they punished us with 12fps video recording in low light. But mostly I shoot videos in low-light-party conditions. So I searched around a bit (I'm not a developer or anything like that) and found a way for getting back to old settings and fps:
Open /system/etc/TICameraProperties.xml
Search for <prop-framerate-range-default>12000,30000</prop-framerate-range-default>
As you can imagine 12000 is 12fps and 30000 is 30fps. So there are two steps of framerates, depending on light situations.
Change 12000 to whatever you think is good, I changed it to 20000 so I have wonderful 20fps in low-light conditions.
Restart and have fun recording good videos
Please report if it works for you. Also someone more expierenced wants to have a look at the whole file, maybe there are other tweaks that can be applied.
Thanks everyone.
Have you tried filming in low light after doing this? Did you have any issues? I'm going to a concert tonight and wanna take video, but if this will mess up the camera at all (or bring back the blue tint) I'd rather not risk it...
Yes, I tried it with almost 20 Clips, since 3 hours, everything is allright! No blue-tint or anything! It's just better low-light-fps Just try it
I will have to compare the OEM file to the Leak file. I bought 2 droid 3's (with the BOGO deal). Maybe there are some obvious differences that I can post up.
---updated----
these are stock settings I found on the OEM software of the D3.
on line 50:
<prop-framerate-range-default>20000,30000</prop-framerate-range-default>
and on line 137:
<prop-framerate-range-default>24000,30000</prop-framerate-range-default>
<prop-framerate-range-values>(24000,30000)</prop-framerate-range-values>
Izeltokatl said:
I will have to compare the OEM file to the Leak file. I bought 2 droid 3's (with the BOGO deal). Maybe there are some obvious differences that I can post up.
Click to expand...
Click to collapse
I have stock still, and I just pulled the file up to see what the default was for this property on stock. It is 20000, so the OP set it to the original default.
Rotkaeqpchen said:
Hey together,
after beeing so glad that Motorola fixed the blue-tint issue they punished us with 12fps video recording in low light. But mostly I shoot videos in low-light-party conditions. So I searched around a bit (I'm not a developer or anything like that) and found a way for getting back to old settings and fps:
Open /system/etc/TICameraProperties.xml
Search for <prop-framerate-range-default>12000,30000</prop-framerate-range-default>
As you can imagine 12000 is 12fps and 30000 is 30fps. So there are two steps of framerates, depending on light situations.
Change 12000 to whatever you think is good, I changed it to 20000 so I have wonderful 20fps in low-light conditions.
Restart and have fun recording good videos
Please report if it works for you. Also someone more expierenced wants to have a look at the whole file, maybe there are other tweaks that can be applied.
Thanks everyone.
Click to expand...
Click to collapse
AWESOME!!
how would i go about doing this? do i need to root???
If someone would kindly walk me through this i woul be more than apprecitave
edit: hell, ill even paypal you five bucks XD
Those instructions are as easy as it can get. If you have no idea on how to follow it, you should turn away and get someone else to do it for you.
Sent from my DROID3 using Tapatalk
Izeltokatl said:
and on line 137:
<prop-framerate-range-default>24000,30000</prop-framerate-range-default>
<prop-framerate-range-values>(24000,30000)</prop-framerate-range-values>
Click to expand...
Click to collapse
The second values are for the frontfacing camera I guess.
Thanks for the values!
@Moderator: Please move this topic to general! Thanks!
eXecuter.bin said:
Those instructions are as easy as it can get. If you have no idea on how to follow it, you should turn away and get someone else to do it for you.
Sent from my DROID3 using Tapatalk
Click to expand...
Click to collapse
Wow, no need to be a tool. Let me explain myself. I have no idea if i have to be rooted or not, im assuming yes. From there i have no idea how to open /system/etc/TICameraProperties.xml or what program i would use to do so.
Thanks for being a proud upstanding member of this community, always ready to stand up and help another user. your mother would be proud.
`Ghost` said:
Wow, no need to be a tool. Let me explain myself. I have no idea if i have to be rooted or not, im assuming yes. From there i have no idea how to open /system/etc/TICameraProperties.xml or what program i would use to do so.
Thanks for being a proud upstanding member of this community, always ready to stand up and help another user. your mother would be proud.
Click to expand...
Click to collapse
Root Explorer is the de facto standard. If you want a free alternative, give File Expert a try (my issue with this one is it is shady when extracting zip files, Root Explorer is better IMO). Yes you need root because /system has to be mounted as r/w to edit the file.
Additionally: To open a file like a xml file you have to longpress on a file in root explorer and choose "open in text editor".
sic4672 said:
Root Explorer is the de facto standard. If you want a free alternative, give File Expert a try (my issue with this one is it is shady when extracting zip files, Root Explorer is better IMO). Yes you need root because /system has to be mounted as r/w to edit the file.
Click to expand...
Click to collapse
Okay cool. I see it in the market for 3.99. ill support the dev and buy it.
now i have no idea how to mount /system as r/w to edit the file. does rootexplorer help with that or let me input commands?
sorry for the questions as i have not done this before. everyone has to learn somewhere.
`Ghost` said:
Okay cool. I see it in the market for 3.99. ill support the dev and buy it.
now i have no idea how to mount /system as r/w to edit the file. does rootexplorer help with that or let me input commands?
sorry for the questions as i have not done this before. everyone has to learn somewhere.
Click to expand...
Click to collapse
In root expolorer, once you get to the directory in question, there is a R/W link in the top right hand corner, click it and it will make it Read/Write. At that point you can make changes to files within that folder (directory).
I would suggest making a backup of the file. I personally saved a copy on my SD card, mounted it, edited in my text editor on my PC and then copied back. Do this because its easier to edit files on a PC than on the phone, and so I dont mess up any other items. That and I have a permanent backup in case I screw something up.
I made the changes last night but haven't bothered to test yet. will do it tonight.
Izeltokatl said:
In root expolorer, once you get to the directory in question, there is a R/W link in the top right hand corner, click it and it will make it Read/Write. At that point you can make changes to files within that folder (directory).
I would suggest making a backup of the file. I personally saved a copy on my SD card, mounted it, edited in my text editor on my PC and then copied back. Do this because its easier to edit files on a PC than on the phone, and so I dont mess up any other items. That and I have a permanent backup in case I screw something up.
I made the changes last night but haven't bothered to test yet. will do it tonight.
Click to expand...
Click to collapse
when I long pressed and opened it in text editor, it automatically created a .bak of the original. Don't know if everyone will experience this, so like the above says, make a backup.
thanks guys. seems pretty simple. ill give it a shot.
im gonna oneclick root and hop to it!
It worked!!! Thank you!!
thankgod i can actually have non bluetint video/pictures and still keep my 20fps low light.
anyone try increasing the lowlight past 20??
btw my guess on why they decreased it to 12000 is maybe the processor has to work harder with the new white balancing and to even it out they lowered the fps.
Glad to hear that, I was so happy like you are now
Rotkaeqpchen said:
Glad to hear that, I was so happy like you are now
Click to expand...
Click to collapse
Thank you very much.
Someone get this man a beer.
Thanks ^^ but this forum has given me so much stuff and modifications, the real developers deserve the beer! But thanks anyway
Hi Guys,
I've fiddled around with the Camera application and found some other tweaks that some of you might like.
This goes hand in hand with Rotkaeqpchen's low light FPS tweaks above.
I've also modified the Camera apk to increase image quality above 100% which has a bug of fc on the Panorama mode so im trying to work that one out, modded application is attached if you wish to try it called MODDED-Cam-installer.zip, once extracted from zip copy to system\app folder on your phone.
Some more digging around found the following:
build.prop - found in System folder
----------
Increased video bitrate past the default 15mbp to over 30mbp is possible and looks really nice at 1080P, no stuttering with frames and in high quality audio.
Enabled slow and fast motion recording in the camera menu.
mp4(extention),h264,30(fps),30000000(bitrate),aac,128000,44100,2(audio channels)
ro.media.camcorder.1080p=mp4,h264,30,30000000,aac,128000,44100,2
ro.media.camcorder.720p=mp4,h264,30,15000000,aac,128000,44100,2
ro.media.camcorder.d1NTSC=mp4,h264,30,6000000,aac,128000,44100,2
ro.media.camcorder.vga=mp4,h264,30,4000000,aac,128000,44100,2
ro.media.camcorder.cif=mp4,h264,30,1500000,aac,128000,44100,2
ro.media.camcorder.qvga=mp4,h264,15,500000,aac,64000,44100,2
ro.media.camcorder.mms=3gp,h264,15,128000,amrnb,12200,8000,1
ro.media.camcorder.mmsres=qvga
ro.camcorder.zoom=true
ro.media.capture.maxres=8m
ro.media.capture.fast.fps=4
ro.media.capture.slow.fps=120
ro.media.capture.flash=led
ro.media.capture.flashMinV=3300000
ro.media.capture.torchIntensity=40
ro.media.capture.flashIntensity=70
ro.media.panorama.defres=3264x1840
ro.media.panorama.frameres=1280x720
ro.camcorder.videoModes=true <- This will enable fast and slow motion recording.
media_profiles.xml - found in Etc folder
-----------------
Increasing the following Max values will enable higher settings for the above to work:
<VideoEncoderCap name="h264" enabled="true"
minBitRate="64000" maxBitRate="30000000"
minFrameWidth="176" maxFrameWidth="1920"
minFrameHeight="144" maxFrameHeight="1080"
minFrameRate="1" maxFrameRate="120" />
TICameraCameraProperties.xml - found in Etc folder
-------------------------------
Still unknown as to what this file does, first appears to be info only on settings for the front and back cameras, as i've not had much luck in changing values like sharpness/brightness/contrast, file format etc.
Only thing I've been trying out is the low light tweaks, mine are currently set to:
<prop-framerate-range-values>(5000,30000),(10000,30000),(12000,30000),(15000,30000),(25000,30000),(25000,120000)</prop-framerate-range-values>
and
<prop-framerate-range-default>25000,30000</prop-framerate-range-default>
I don't know why all this couldn't have just been in the camera app like every other company, Motorola doesn't like to make anything easy.
Have fun.
Edit:
Easy Clockwork installers attached.
- MODDED-Cam-installer.zip - Modded Build.prop, Modded Media_profiles, Modded TiCamera and modded Camera app installer.
- ORIGINAL-Cam-installer.zip - Modded Build.prop, Modded Media_profiles, Modded TiCamera and original (dedexed) Camera app installer.
- DEFAULTS-Cam-installer.zip - Default Build.prop, Default Media_profiles, Default TiCamera and Default Camera app files installer.
Edit2:
Added 5.7.894 camera mod, increase speed, new icons and high image quality, Panorama mode has a bug.
Added huge APN list for GSM using countries, no more manual adding apn's.
Updated for 5.7.894:
-gps.conf
-media_profiles.xml
-TICameraCameraProperties.xml
-build.prop
Edit3:
DarkDroid rom power menu with reboot and screenshot functionality, camera quality mods etc, do not install this file unless you are running the Dark Droid rom 1.01-01/20/12 with framework 5.6.890, infact just download dpwhitty11's rom instead here:
http://forum.xda-developers.com/showpost.php?p=18424016&postcount=1
Instructions for ORIGINAL-Cam-installer.zip, MODDED-Cam-installer.zip and DEFAULTS-Cam-installer.zip:
1.Place the desired zip on your external sd card.
2.Restart phone into clockwork mod.
3.Choose install from zip.
4.Choose zip from sd card.
5.Go back to main menu and select reboot phone, done.
Manual copying to the desired directory must be done with these 5.7.894 files:
-BlurCamera5.7.894mod.apk
-apns-conf.zip
-gps.conf.zip
-media_profiles.zip
-TICameraCameraProperties.zip
-build.prop.zip
-smc
For the past 15 years I used Nokia mobiles, I was very happy the way Nokia named newly shot photos (e.g. 21062010128, i.e. 21 June, 2010 0128, the current date and then an increment number). This gave me a lot of flexibility in sorting, organising and finding photos (I know that the exif data of a photo does contain the photo shot time).
But sony, gives the numbers like 'DSC_0295'. Just the useless word DSC and an increment number. This gives me a lot of problems while finding and storing the photos. E.g. when I move some photos from my phone to a photo storing folder on my hdd, then the phone again starts naming photos like dsc0001, 002 etc. And when 2nd time I try to move these photos to my storing place, then I've to rename all the new photos so as to avoid to overwrite the earlier ones. What say fella!
VERY POOR SONY. Pls give us the proper naming method having date time included in photos title. It won't hurt you and help us a lot.
i agree with you but you can use another camera app from play store
That's because they use the same naming scheme as their Digital cameras, I think its because of the camera software, as DSC is Digital Still Camera? That prefix is common among most Digital cameras, even DSLRs from Nikon use the same naming scheme and even HTC Phones.. You can use image importing software to fix that otherwise yeah, the manual method works. You could folder them by date.
I haven't tried them but you could check this app https://play.google.com/store/apps/details?id=it.smartphoneapps.jcrename
or this one https://play.google.com/store/apps/details?id=cyb.satheesh.filerenamer .
They both claim that you can batch rename files. Hope it helps.
Use dropbox camera upload.. it changes filename to date from EXIF and you can keep using stock camera.
gerickjohn said:
That's because they use the same naming scheme as their Digital cameras, I think its because of the camera software, as DSC is Digital Still Camera? That prefix is common among most Digital cameras, even DSLRs from Nikon use the same naming scheme and even HTC Phones.. You can use image importing software to fix that otherwise yeah, the manual method works. You could folder them by date.
Click to expand...
Click to collapse
'The Free Photos & File Renamer' seems to be an alternative.
But my post was not a question. It was a remark regarding the deficiency of this file naming system of different manufacturers EXCEPT NOKIA!
Using 3rd party apps is never as efficient as the built in function. I don't know what is problem in implementing this thing in all sony devices. It is very very beneficial to many users.
And I know the full form of DSC. But what I don't know why they would write to the beginning of every photo shot. And particularly when there are problems in this (as enumerated in my starting post).
So, pls be kind enough to understand the spirit of my post before replying. Thanks all!
It appears you have a problem with the naming scheme because it makes it difficult to sort by date.
So in the default album app, pictures are already sorted by date.
In windows explorer you can easily set it to thumbnail then arrange by date as well....
I too think the current naming system is crap. As I file photos in folders and sometimes make a camera dump many times a day, there will be overlaps.
I'd rather see they'd be named something like this:
XXX_yyyyMMdd_hhmmss_nn.jpg
"XXX_" would be a prefix you yourself could choose. I would have it read "XZ_" because i take pictures with many different cameras and I'd like to tell the cameras apart. If no prefix is entered in the camera settings, it will be left out. (Default may be "DSC" if Sony so wishes, but please give us the choice.)
"_nn" would be a serial number (_01, _02...) IF there are multiple pictures on that same second. Otherwise the serial would be left out.
Don MC said:
I too think the current naming system is crap. As I file photos in folders and sometimes make a camera dump many times a day, there will be overlaps.
I'd rather see they'd be named something like this:
XXX_yyyyMMdd_hhmmss_nn.jpg
"XXX_" would be a prefix you yourself could choose. I would have it read "XZ_" because i take pictures with many different cameras and I'd like to tell the cameras apart. If no prefix is entered in the camera settings, it will be left out. (Default may be "DSC" if Sony so wishes, but please give us the choice.)
"_nn" would be a serial number (_01, _02...) IF there are multiple pictures on that same second. Otherwise the serial would be left out.
Click to expand...
Click to collapse
Agreed, it couldn't get any more stupid than this ****ed up naming scheme. Sony should really do something about it.
To be honest, I like the way it is. It is consistent, clean (not a buch of digits). Is specially helpful when filtering the good and bad photos on the computer, to them move or delete them... The Nokia method would make me really confused and bothered.
Felimenta97 said:
To be honest, I like the way it is. It is consistent, clean (not a buch of digits). Is specially helpful when filtering the good and bad photos on the computer, to them move or delete them... The Nokia method would make me really confused and bothered.
Click to expand...
Click to collapse
It would be great if we could choose how it names the pictures, wouldn't it?
I posted about this some time ago. Mainly because when I transfer photos to other place and delete them from phone, the camera starts counting from 0001 again. It's really bothersome if you upload photos to cloud directly from the phone.
Sent from my eXposed C6603
bloodsuckingcomputer said:
Agreed, it couldn't get any more stupid than this ****ed up naming scheme. Sony should really do something about it.
Click to expand...
Click to collapse
i think the DSC_xxxxx is for Digital Camera Shutter counts. it usually used in professional photographer to judge the life of lens and shutter etc. and sometime they make many shot in studio and it may less than a second 3-4 shot. so the dsc_xxxx may help them to tell their stuff which is the final desicion to be use as their project. compare to date they more prefer shutter count.
I would be ok with this naming scheme, because I had some Sony Cameras (DSC-P73, DSC-W120 and now DSC-HX5), but the biggest problem is either not storing the next photo number like the cameras do, relying just in the last number found instead (if you leave a DSC_1594.JPG in /sdcard/DCIM/100ANDRO, the next photo will named as DSC_1595.JPG), and not allowing you to change this number (except by doing the way I explained, which is very inconvenient).
why not looking in the exif tag?
DoubleYouPee said:
Use dropbox camera upload.. it changes filename to date from EXIF and you can keep using stock camera.
Click to expand...
Click to collapse
excellent suggestion!
I spent a few frustrated hours with my new Xperia ZR trying to figure out how to archive different project related pics in folders without messing everything and dropbox not only does that automatically so I have reasonably named photos now, but I don't even need to bother xfering the files over, using the cable to connect etc. As soon as I'm at home or at work on wifi it moves them over
many thanks!
cheers
V.
virtuvas said:
excellent suggestion!
I spent a few frustrated hours with my new Xperia ZR trying to figure out how to archive different project related pics in folders without messing everything and dropbox not only does that automatically so I have reasonably named photos now, but I don't even need to bother xfering the files over, using the cable to connect etc. As soon as I'm at home or at work on wifi it moves them over
many thanks!
cheers
V.
Click to expand...
Click to collapse
Yes
And then you write a .bat script to automatically move the photos based on EXIF information to your \pictures\ folder on HDD .
Never bother with organizing pictures again.
you are right
zopfan said:
For the past 15 years I used Nokia mobiles, I was very happy the way Nokia named newly shot photos (e.g. 21062010128, i.e. 21 June, 2010 0128, the current date and then an increment number). This gave me a lot of flexibility in sorting, organising and finding photos (I know that the exif data of a photo does contain the photo shot time).
But sony, gives the numbers like 'DSC_0295'. Just the useless word DSC and an increment number. This gives me a lot of problems while finding and storing the photos. E.g. when I move some photos from my phone to a photo storing folder on my hdd, then the phone again starts naming photos like dsc0001, 002 etc. And when 2nd time I try to move these photos to my storing place, then I've to rename all the new photos so as to avoid to overwrite the earlier ones. What say fella!
VERY POOR SONY. Pls give us the proper naming method having date time included in photos title. It won't hurt you and help us a lot.
Click to expand...
Click to collapse
ZOPFAN
You are right
I m having the same problem when organizing pictures... At least it should be squential from the beginnig of the phone life, like canon does. I think the nokia method is the best because it organises time oriented.
Like this ,its a mess... i dont want to lose time renaming fotos, and i need to put them in existent folders by subject...
PLZ if you find a solution, upgrade software or any app that can rename them by daTe will be great..
Thanx~
SONY XPERIA e4 DUAL, 2015
Nice necro-thread bumping...
And if we talk about topic its most... useless whining I heard. Every app and every system have sorting methods by date of creation/modify/name so dsc prefix is not a problem at all.
Also if you work with images for most of time, maybe you should use apps that deal with such prefix, even free IrfanView dont have problem with that.
Not to mention sorting by exif data, if you take image management serious you would know that there is such thing and this topic would be unnecessary, because there is looots of apps for that.