I thought we could use an organized thread for focusing on getting the camera to work on 4.2-based ROMs for the Galaxy Player 5. Right now, there are three iterations of CM10.1 threads, and discussion is also going on in other ROM threads. I'm basically putting this here so we can all talk about it in one place and not have to dig every time we need to find a piece of information that was previously mentioned.
I'll update the OP as more information surfaces.
Things that we already know
http://forum.xda-developers.com/attachment.php?attachmentid=1988153&d=1369421491 this fixes camcorder for the rear camera. Source
Speculation
The image sizes could be off because our CM10.1 was ported from the other Galaxy S devices. Source
The Galaxy Stellar also uses a 3.2MP camera and has native 4.0.4. This could possibly be of use.
Other things that could be potentially useful
https://sites.google.com/site/jaiprakashgogi/professional this is the website for the person who develops the driver for the s5K5CCGX sensor. We could try contacting him to see if he could help us out.
The developer profile says that he developed for Qualcomm Snapdragon powered devices so the drivers are likely to be incompatible with our Exynos SoC. However, if our front facing camera is 1.3 MP, I think we might be able to use the drivers from the Galaxy Tab
Supermaster34 said:
The developer profile says that he developed for Qualcomm Snapdragon powered devices so the drivers are likely to be incompatible with our Exynos SoC. However, if our front facing camera is 1.3 MP, I think we might be able to use the drivers from the Galaxy Tab
Click to expand...
Click to collapse
Nope, our Front-Facing is a measly 0.3MP VGA cam like the other Galaxy S phones.
halomademeapc said:
Nope, our Front-Facing is a measly 0.3MP VGA cam like the other Galaxy S phones.
Click to expand...
Click to collapse
Well that put a spanner in my plan. I guess the next step from here is to work out why the FFC saves pictures but the RFC doesn't. There must be a difference in the method they use to store the image, but we need to locate where the code specifies the method of saving the image
Supermaster34 said:
Well that put a spanner in my plan. I guess the next step from here is to work out why the FFC saves pictures but the RFC doesn't. There must be a difference in the method they use to store the image, but we need to locate where the code specifies the method of saving the image
Click to expand...
Click to collapse
In cm10 the saving of grey images was fixed by changing the postview sizes in the header[1]. There are also other random places values are hardcoded into the HAL[2]. One interesting thing is that we are using the HAL's from two different sources in jellybean, so they have different problems: crespo on cm10 and p5 on cm10.1 (EDIT: I see JackpotClavin switched to crespo... This is all very confusing), so possibly compare/combine the two to find what is causing each problem.
For video recording (media_profiles.xml) we need to figure out what the actual numbers are for our device, and not just take them from somewhere else. Plus, they have to align with the HAL. The same applies to OpenMAX codec libraries. Last, don't forget that at some point we will need to get the torch working, too.
EDIT: I saw the discussion on the other thread and decided to move it here
Supermaster34 said:
I don't think changing the resolution will fix it. I just tried taking a photo with the resolution set to 1.3 MP, but it didn't work. I think the issue is when the image is being saved as the width and height both come up as 0 and even when the flash is forced on, the image details say no flash. If we look at how the front facing camera saves the image, we could compare it with how the rear facing camera is set to save the image and modify it to match. I'm not entirely sure that this would work, but it might be worth a try
Click to expand...
Click to collapse
Does any EXIF data save? I don't think it does, so that's another item on our todo list (and saving GPS information in the pictures). Our FFC is the 3DFX, which is the exact same as crespo, so it should work perfectly with no modifications. Therefore, any issues are caused by something else, like media_profiles.xml. This is what happens when I talk without checking... I tried the FFC, and everything works perfectly AFAIK: EXIF and location data save (although it was using network location, it should work exactly the same with GPS). So no worries or breakage there.
android1234567 said:
Yeah I just looked at the resolutions and some of them are the same as before. I also noticed that some ISOs that aren't supported by our sensor were added in, so I put my hand in front of the camera to lower the ISO and lo and behold it actually took a picture and made the capture sound instead of hang on taking the picture like it usually does. But after that it just hung and didn't save the picture, so you're right that the camera isn't saving the image correctly.
Click to expand...
Click to collapse
Do we have a definitive list of which ISO's our camera does support? I would assume the only way to know is from a different camera HAL, but the only other device with the S5K5CCGX uses blobs. I guess we could look in the stock app, or use trial and error if there was no other list.
Supermaster34 said:
At least we're making some progress. I think we have the same camera hardware as the Galaxy Tab and I believe it has CM10.1 so it might be worth having a look at their source or just trying to use their drivers as I think they also have the Exynos 3 single SoC
Click to expand...
Click to collapse
zaclimon said:
Depends which gtab you're talking about. The Gtab P1 (original) uses the sony isx005 which we have. I think the galaxy tab 10.1 do have your sensor, it would need to be checked further.
Your back cam is s5k5ccgx
Your front cam is s5ka3dfx
Hope it helps.
EDIT: the galaxy tab 10.1 do use the same sensor as you, you can check there: https://github.com/CyanogenMod/android_kernel_samsung_p4/blob/cm-10.1/arch/arm/configs/pershoot_samsung_p4-jb_defconfig#L1939
EDIT2: Hmm the galaxy tab 10.1 do use tegra chipset so maybe it's not a good choice, but you can look into the p1 drivers and take a look of their s5k5ccgx drivers here: https://github.com/CyanogenMod/android_kernel_samsung_p1/blob/cm-10.1/drivers/media/video/s5k5ccgx.c
Click to expand...
Click to collapse
Yes, they use Tegra blobs. They look self-contained, so I was thinking they might be possibly portable; say, take their blobs and their kernel driver and see if those together work on our camera. What's interesting in looking at all of the different kernel drivers is the different firmwares for different devices, and how some say different megapixel ratings than others, almost as if there were different cameras with the same model, or someone at Samsung was doing a lot of copypasting.
android1234567 said:
Think I found a solution: https://github.com/humberos/android...mmit/5bab5c8c8797f96855b777e6c2328d341187014e
Click to expand...
Click to collapse
Supermaster34 said:
This is the code across a few devices:
Nexus S + 5.0 atm - 4.2
Code:
int SecCamera::interleaveDataSize = 5242880;
GTab - 4.2
Code:
int SecCamera::interleaveDataSize = 0x33F000;
Galaxy S - GB I think
Code:
int SecCamera::interleaveDataSize = 4261248;
I have no idea what these numbers mean, but could 0x33F000 be some sort of memory address location?
Also why is there an 8 thanks per day limit?!
Click to expand...
Click to collapse
Well, 0x33F000 is 3403776 in decimal (for comparison). It is the size of a memory buffer, and its value has to do with a few things: Image resolution, image format (i.e. extra space for metadata or less space because of hardware JPEG compression), and pixel format (i.e. bits per pixel, like YUV, RGB888, RGB565, etc.). So at 2048 by 1536 pixels, that 3MP is exactly 3145728 pixels; I don't see where that number comes from.
android1234567 said:
It'll work! On the Galaxy Tab the number was previously 4261248 then it was changed to 0x33F000! The number is universal across devices as long as they have the same camera Nexus S has a different camera so the number is different.
Click to expand...
Click to collapse
It should be linear relative to image size, but it doesn't seem to be, which is confusing.
android1234567 said:
I'll do that now . I have all the CM10.1 source and device tree on my laptop because I need it to build kernels. I'll also clean up some ISOs and resolutions while I'm at it. If it works then we can merge the video changes that got the camcorder working and have fully functional CM10.1
Click to expand...
Click to collapse
A tip to save lots of disk space and time by building only what you need:
Code:
mmm -B device/samsung/venturi_usa/libcamera
android1234567 said:
I'm going to combine the Galaxy Tab HAL with the current HAL we're using, retaining the FFC code we have right now.
Sent from my HTC Sensation 4G using xda app-developers app
Click to expand...
Click to collapse
Sounds like a good idea. I will see where I can get starting on Tuesday or so.
android1234567 said:
I'm trying to build with my camera changes but I get this error after a little while:
Code:
No rule to make target `/home/sultan/cm10.1/out/target/product/venturi_usa/obj/SHARED_LIBRARIES/libs3cjpeg_intermediates/export_includes'
Anyone know how to fix it?
Click to expand...
Click to collapse
You need the hardware/samsung repo:
Code:
<project name="CyanogenMod/android_hardware_samsung" path="hardware/samsung" remote="github" />
If you already have it, try running
Code:
mmm hardware/samsung/exynos3/s5pc110/libs3cjpeg
P.S. We can't keep the discussion in one place if we aren't keeping it in one place...
[1] https://github.com/Mevordel/android...mmit/1cad68704bcd856638357e0b18118b46c8f198ba
[2] https://github.com/Mevordel/android...mmit/e6f4507fac8768d9a62c54ee375cdfd584aad889
Mevordel said:
In cm10 the saving of grey images was fixed by changing the postview sizes in the header. One interesting thing is that we are using the HAL's from two different sources in jellybean, so they have different problems: crespo on cm10 and p5 on cm10.1, so possibly compare/combine the two to find what is causing each problem.
For video recording (media_profiles.xml) we need to figure out what the actual numbers are for our device, and not just take them from somewhere else. The same applies to OpenMAX codec libraries.
Click to expand...
Click to collapse
A fix has already been found for video recording in CM10.1 and it changes the media profiles file, so we don't have to worry about that
We already have our fix for the camera without even touching the libcamera (for the 3.0 kernel). Here's the commit if ever you want to check it:
https://github.com/bbelos/android_kernel_samsung_aries/commit/ab11000777e4363460ccaebe3221a721252c4f56
@Mevordel
Not going to quote your entire post because that would be ridiculous, but thanks x1000 especially for those 2 commits
it's very reassuring knowing that we have another person helping who has done this before
zaclimon said:
We already have our fix for the camera without even touching the libcamera (for the 3.0 kernel). Here's the commit if ever you want to check it:
https://github.com/bbelos/android_kernel_samsung_aries/commit/ab11000777e4363460ccaebe3221a721252c4f56
Click to expand...
Click to collapse
This pretty much completely confuses me... Is CONFIG_SAMSUNG_GALAXYS defined for your device? A lot of what was added looks to be support for the P1. Is that because you took some of the code from the P1?
android1234567 said:
@Mevordel
Not going to quote your entire post because that would be ridiculous, but thanks x1000 especially for those 2 commits
it's very reassuring knowing that we have another person helping who has done this before
Click to expand...
Click to collapse
Thank you. I still have no idea what much of this does, but I will spend some time this month looking into it.
Final post for the day:
I decided to look into the kernel-side driver for some explanation for a few of these magic numbers, and here's what I found staring us in the face this whole time (drivers/media/video/s5k5ccgx.c):
Code:
/* Default resolution & pixelformat. plz ref s5k5ccgx_platform.h */
#define FORMAT_FLAGS_COMPRESSED 0x3
#define SENSOR_JPEG_SNAPSHOT_MEMSIZE 0x33F000 //3403776 //2216 * 1536 384000 33F000
#define POLL_TIME_MS 10
#define DEFAULT_RES WVGA /* Index of resoultion */
#define DEFAUT_FPS_INDEX S5K5CCGX_15FPS
#define DEFUALT_MCLK 24000000 /* 24MHz default */
#define DEFAULT_FMT V4L2_PIX_FMT_UYVY /* YUV422 */
#define INNER_WINDOW_WIDTH 143
#define INNER_WINDOW_HEIGHT 143
#define OUTER_WINDOW_WIDTH 320
#define OUTER_WINDOW_HEIGHT 266
/*
* Specification
* Parallel : ITU-R. 656/601 YUV422, RGB565, RGB888 (Up to VGA), RAW10
* Serial : MIPI CSI2 (single lane) YUV422, RGB565, RGB888 (Up to VGA), RAW10
* Resolution : 1280 (H) x 1024 (V)
* Image control : Brightness, Contrast, Saturation, Sharpness, Glamour
* Effect : Mono, Negative, Sepia, Aqua, Sketch
* FPS : 15fps [user=366900]@full[/user] resolution, 30fps [user=355664]@vga[/user], 24fps [user=3621271]@720p[/user]
* Max. pixel clock frequency : 48MHz(upto)
* Internal PLL (6MHz to 27MHz input frequency)
*/
So the 0x33F000 is the correct value, and the postview defines in SecCamera.h (not to mention the rest of the values) need to be updated with those here.
The only problem is that some of the information is wrong. The resolution stated in the comment is 1.3MP, the beginning of the file says 2.0MP, but we know (and the resolution list later in the file confirms) that it is a 3.0MP sensor. Meh.
Mevordel said:
Final post for the day:
I decided to look into the kernel-side driver for some explanation for a few of these magic numbers, and here's what I found staring us in the face this whole time (drivers/media/video/s5k5ccgx.c):
Code:
/* Default resolution & pixelformat. plz ref s5k5ccgx_platform.h */
#define FORMAT_FLAGS_COMPRESSED 0x3
#define SENSOR_JPEG_SNAPSHOT_MEMSIZE 0x33F000 //3403776 //2216 * 1536 384000 33F000
#define POLL_TIME_MS 10
#define DEFAULT_RES WVGA /* Index of resoultion */
#define DEFAUT_FPS_INDEX S5K5CCGX_15FPS
#define DEFUALT_MCLK 24000000 /* 24MHz default */
#define DEFAULT_FMT V4L2_PIX_FMT_UYVY /* YUV422 */
#define INNER_WINDOW_WIDTH 143
#define INNER_WINDOW_HEIGHT 143
#define OUTER_WINDOW_WIDTH 320
#define OUTER_WINDOW_HEIGHT 266
/*
* Specification
* Parallel : ITU-R. 656/601 YUV422, RGB565, RGB888 (Up to VGA), RAW10
* Serial : MIPI CSI2 (single lane) YUV422, RGB565, RGB888 (Up to VGA), RAW10
* Resolution : 1280 (H) x 1024 (V)
* Image control : Brightness, Contrast, Saturation, Sharpness, Glamour
* Effect : Mono, Negative, Sepia, Aqua, Sketch
* FPS : 15fps [user=366900]@full[/user] resolution, 30fps [user=355664]@vga[/user], 24fps [user=3621271]@720p[/user]
* Max. pixel clock frequency : 48MHz(upto)
* Internal PLL (6MHz to 27MHz input frequency)
*/
So the 0x33F000 is the correct value, and the postview defines in SecCamera.h (not to mention the rest of the values) need to be updated with those here.
The only problem is that some of the information is wrong. The resolution stated in the comment is 1.3MP, the beginning of the file says 2.0MP, but we know (and the resolution list later in the file confirms) that it is a 3.0MP sensor. Meh.
Click to expand...
Click to collapse
I'm going to do that now
No progress @Mevordel the camera just force closes with the header changes. I think we might need to mess around with the camera driver in the kernel
Or maybe I need to allocate more memory to the camera
I am hell sure that it is not connected to the memory, as aries an crespo with 5mpx use same memory amount as we have set
Wysyłane z mojego Nexus S za pomocą Tapatalk 2
Mevordel said:
This pretty much completely confuses me... Is CONFIG_SAMSUNG_GALAXYS defined for your device? A lot of what was added looks to be support for the P1. Is that because you took some of the code from the P1?
Click to expand...
Click to collapse
What I did was to take the 3.0 p1 drivers, then modify the ifdef to comply with our devices. (config_samsung_galaxys to replace mach_aries and config_samsung_ypg1 to replace config_mach_p1) with the 2.6 drivers , bbelos had completely copied the p1 which is why we have the camera working on it. We're only doing the same thing but with some ugly manners of implementing it. (it's implementation will be different with the cm10.1 kernel.). This is how we got it working.
Also wouldn't be more easier to take your camera drivers from p1?
Envoyé depuis mon Nexus 7 avec Tapatalk
I had always thought that the issue was with the camera.aries library and not the kernel. I flashed back to my old CM9 build from a year or so ago (with the 2.6.35.7 kernel, that worked with Gingerbread and its camera) and used our camera library for 4.2.2 and I got the exact same errors with the rear camera, but the front worked fine as it did with 4.2.2
Sent from my Galaxy Nexus using xda app-developers app
JackpotClavin said:
I had always thought that the issue was with the camera.aries library and not the kernel. I flashed back to my old CM9 build from a year or so ago (with the 2.6.35.7 kernel, that worked with Gingerbread and its camera) and used our camera library for 4.2.2 and I got the exact same errors with the rear camera, but the front worked fine as it did with 4.2.2
Sent from my Galaxy Nexus using xda app-developers app
Click to expand...
Click to collapse
Hmm to get mostly your camera working, you need the camera HAL drivers to fit with the FIMC kernel drivers. So if you want to use the P1 camera HAL, you will need to update your fimc drivers in order to get it working. In your case you would only need to add ifdef CONFIG_MACH_VENTURI.
We can take pictures with Fast Burst Camera (but the quality is poor)...
flouflou said:
We can take pictures with Fast Burst Camera (but the quality is poor)...
Click to expand...
Click to collapse
Fastburst just takes a screenshot; it doesn't take actual photos
android1234567 said:
Fastburst just takes a screenshot; it doesn't take actual photos
Click to expand...
Click to collapse
I know but it's still practice...
It seems that it might be worthwhile to take a look at the code that produces the preview images... I mean that technically is our device producing images from the BFC right?
Sent from my SAMSUNG-SGH-I577 using xda app-developers app
Related
I recently got an Optimus S and am disappointed that the camera has no exposure control. It's almost a deal breaker because it's such a step down from my old Samsung m510 flip phone's camera. I have posted at length about it on androidcentral, but here is the deal:
The Optimus S has no exposure control, even though the T definitly does, and by one review, the Optimus U does too. It's not a matter of the camera app; even apps that show an exposure slider have no effect on the exposure. (Scene modes also have no effect.) Because the hardware is so similar on all these phones, I can't believe it's simply a hardware limitation - the app, camera driver, or the interface between the driver and Android's java APIs, has to control exposure somehow in software, right?
I got ahold of some other roms, from the Optimus T and the V, and tried swapping all lib files with camera in the name - libcamera, libcamera_client, libcameraservice, and liboemcamera on both phones, and additionally libOlaCameraJNI, libOlaEngine, and libOlaMaskResource on the T. Rebooting with various combinations of those resulted in a hang on boot, crashing camera apps, or no effect at all. Also tried installing CameraApp.apk from the T's rom to no effect.
Downloaded the S and U's source code from LG, ran a diff, and noticed that the Optimus U's kernel/drivers/media/video/msm folder has some differences compared the Optimus S's, including at least one file that the S doesn't have at all that seems to send different hex codes for setting exposure values. I also think the T had similar differences from the S. So I copied the msm folder over from the U to the S, compiled the S kernel from scratch, flashed it, and verified it was actually running from my new kernel, but the camera apps still had no control over the exposure.
Flashing a custom rom from the V will allow the S to boot, but doesn't give camera control. Flashing a rom from the T will make it hang while booting.
Where else can I go with this? Is there some bridge between the kernel drivers and the Android camera API (look up Camera.Parameters in the android dev site), that I'm missing? What actually goes between a call to getMinExposureCompensation() and the kernel to find out what capabilities the camera has? Again, I don't see how the Optimus S hardware would simply not support exposure adjustments when other Optimus phones do.
Thanks!
Found Camera.java in frameworks/base/core/java/android/hardware from Google's source code. It says "This class is a client for the Camera service, which manages the actual camera hardware." Then I looked for the camera service, which I found at frameworks/base/services/camera/libcameraservice . But this is in Google's code, not LG's device-specific code, which leads me to believe that this stuff is the same across every phone. So I'm still trying to figure out where in the software exposure control happens.
Bump. Tried boggling around more folders and config files between various kernels from different versions of this phone. Am now thinking about using the ndk and modifying the original camera app. Will I be able to use it to access the hardware directly in native code and send exposure adjustments to the camera?
The file kernel/drivers/media/video/msm/isx005.c (for a Sony camera chip - how do I know if that's what's actually in my phone?) contains the following code:
It looks like the other files in kernel/drivers/media/video/msm allow have functions along the lines of [chipname]_write_exp_gain(uint16_t gain, uint32_t line).
Code:
static int32_t isx005_set_brightness(int8_t brightness)
{
int32_t rc = 0;
switch (brightness) {
case 0:
rc = isx005_i2c_write(isx005_client->addr,
0x0060, 0x80, BYTE_LEN);
if (rc < 0)
return rc;
rc = isx005_i2c_write(isx005_client->addr,
0x0061, 0x50, BYTE_LEN);
if (rc < 0)
return rc;
break;
case 1:
rc = isx005_i2c_write(isx005_client->addr,
0x0060, 0x80, BYTE_LEN);
if (rc < 0)
return rc;
rc = isx005_i2c_write(isx005_client->addr,
0x0061, 0x60, BYTE_LEN);
if (rc < 0)
return rc;
break;
case 2:
...etc.
It still seems that auto exposure control wouldn't happen in the camera firmware. Maybe I'm wrong?
edit: from the looks of these files, it seems like it's done in firmware. Still, would I be able to call these exposure functions from an application built using ndk?
Another edit: from kernel/arch/arm/configs/thunderc-sprint-perf_defconfig:
Code:
#
# Qualcomm MSM Camera And Video
#
CONFIG_MSM_CAMERA=y
# CONFIG_MSM_CAMERA_DEBUG is not set
#
# Camera Sensor Selection
#
# CONFIG_MT9T013 is not set
CONFIG_ISX005=y
CONFIG_ISX005_ROTATION_180=y
# CONFIG_MT9D112 is not set
# CONFIG_MT9P012 is not set
# etc, etc, etc - no other camera drivers enabled
Hello i have found some info because i noticed we have only 352mb of ram and arent we suppose to have 384 mb or is the triple buffer config eating some ram of the device.
I did found this info and some pmem adsp stuff but didnt see any logic formula with those and think those are device dependent. But is this true and can we can salvaging about 5MB of ram causing by over allocated FB size in kernels?
And ive read this as follow.
optimum setting for 480x854 displays is ---->
864 x 480 x 4 x 3 = 4976640 (4FB000) for triple buffer...
And
864 x 480 x 4 x 2 = 3317760 (32A000) for standard / double buffer
yes, 864 not 854 (it must be a multiply of 4096)
Edit. it can also be defined as formula.
#ifdef CONFIG_FB_MSM_TRIPLE_BUFFER
#define MSM_FB_SIZE (864 * 480 * 4 * 3) /* 4bpp * 3 Pages */
#define MSM_FB_NUM 3
#else
#define MSM_FB_SIZE (864 * 480 * 4 * 2) /* 4bpp * 2 Pages */
#define MSM_FB_NUM 2
#endif
And i also saw that ive compared some kernel sources and found that the modedb.c in our kernel misses our screen dimensions but not sure if its in any special use to fps or refresh timing i am not sure but i thought i should suggest/ask and maybe its helpfull after all. And few typos but not sure if its important to tell because you developers are super awsome and are busy enough with important stuff already and i dont wanna feel like an attack/ambush towards you guys like look some typos and stuff. But i hope i dont come over that way. Just want to help as much as i can since i am to dumb to maintain a git aswell haha.
Greets from testalot.
Yeah i am able to test crazy stuff if needed. Even tryed htc and samsung kernels with x10i combined ramdisk and init.rc adjusted and with links to the other devices them .rc files.
But not booting ofcourse but just wanted to give it a shot.. (^-^)
Sent from my X10i using xda app-developers app
As the title suggests, I'm curious as to a way to increase the DPI for the camera app to increase the quality of photos taken (when zooming in on a crop of a photo). I remember from my Note 3 that there used to be a way to change the quality of the photo (best, better, etc.) which was a way of changing the DPI for the photo taken.
Even if there's a way to do it with root (say by modifying the build.prop file), any advice would be great!
As an alternative, is there a camera app that allows for you to change the DPI and fully utlize the camera hardware? I used to use Camera Zoom FX (Premium) but it didn't play nicely with some of the phones (namely Motorola) that I have used that app on.
Thanks for the tips, help, guideance, etc.!
Not sure what you mean, you can set up to 20mp in the settings. Thats even more than the rgb sensor is capable of. I guess this upscales the rgb sensors color info to the 20mp picture the monochrome sensor is taking. I cant think of anything that Would utilize the hardware more
rob.allen78 said:
As the title suggests, I'm curious as to a way to increase the DPI for the camera app to increase the quality of photos taken (when zooming in on a crop of a photo). I remember from my Note 3 that there used to be a way to change the quality of the photo (best, better, etc.) which was a way of changing the DPI for the photo taken.
Even if there's a way to do it with root (say by modifying the build.prop file), any advice would be great!
As an alternative, is there a camera app that allows for you to change the DPI and fully utlize the camera hardware? I used to use Camera Zoom FX (Premium) but it didn't play nicely with some of the phones (namely Motorola) that I have used that app on.
Thanks for the tips, help, guideance, etc.!
Click to expand...
Click to collapse
highest quality you can do is raw in pro mode. you can later decide in what quality you compress it to jpeg
0alfred0 said:
Not sure what you mean, you can set up to 20mp in the settings. Thats even more than the rgb sensor is capable of. I guess this upscales the rgb sensors color info to the 20mp picture the monochrome sensor is taking. I cant think of anything that Would utilize the hardware more
Click to expand...
Click to collapse
I saw the 20MP option but that's not what I'm referring to Some camera apps or phone makers allow for you to change the quality of the picture taken in the form of changing the DPI. The higher the number, the higher the quality of the picture when looking at a 100% crop of a photo (but also the file size tends to be larger too). I know it's not common, but it is there for some camera/OEMs.
rob.allen78 said:
I saw the 20MP option but that's not what I'm referring to Some camera apps or phone makers allow for you to change the quality of the picture taken in the form of changing the DPI. The higher the number, the higher the quality of the picture when looking at a 100% crop of a photo (but also the file size tends to be larger too). I know it's not common, but it is there for some camera/OEMs.
Click to expand...
Click to collapse
I dont quite understand what that means though from a technical viewpoint. I am not an expert but i roughly know how cameras work and what parts they are made of (keywords: sensor/pixel size, sensor resolution, bayer matrix, etc.). I never came across something called DPI. I also do not know what should be happening when increasing this DPI.
Maybe you can enlighten me. Although this does not seem to be a feature for the Mate 10 i am very much interested in learning about cameras, especially in mobile devices.
0alfred0 said:
I dont quite understand what that means though from a technical viewpoint. I am not an expert but i roughly know how cameras work and what parts they are made of (keywords: sensor/pixel size, sensor resolution, bayer matrix, etc.). I never came across something called DPI. I also do not know what should be happening when increasing this DPI.
Maybe you can enlighten me. Although this does not seem to be a feature for the Mate 10 i am very much interested in learning about cameras, especially in mobile devices.
Click to expand...
Click to collapse
I had to research this a bit myself so that I could properly convey what I was originally asking for
This article from Snap Shop eCommerce helped quite a bit:
A Simple Introduction to DPI
(apparently, it's only useful if I intend on printing any of the photos taken from the camera itself)
I had a note 2 and a note 4 until just recently. I know the setting your talking about. Its got nothing to do with DPI - its more a compression setting/sharpening setting affects how big the filesize is from your camera as it affects how much each photo is compressed (was listed as "quality" modes? from memory)
Yep that's my understanding too - it's basically like 'fine' or 'superfine' settings on point n shoot cameras - dictates how much the JPG file is compressed. FWIW my Note 4 on Marshmallow seems to have dropped the setting, along with most other phones in the last few years. You just get the default compression for photos and bitrate for videos. As @madman_cro noted, you can make sure you're getting 100% of what the sensor is capable of by shooting RAW and doing the JPG processing yourself. Gotta love it when they remove settings so as not to confuse the average user....
I got a note 4 infront of me and went looking for the setting as well and couldnt find it either your right it must of got lost in a update hahahhaha (my boy has my note2 somewhere) but yeah its exactly what your saying with the fine/superfine etc more a compression setting than anything else
iv had lot's of phones(with custom and stock rom) and while I've never seen dpi settings it may have benefit for printing. as from what iv read now that you got me interested 72 is apparently enough for our screens and our phone delivers 92 so we are ok. il try to convert raw to higher dpi later and try it in phone while zoomed in but i doubt il see the difference cause its basicly the same image
Usual DPI is 72 at jpg photo at real cameras, if you shot in RAW usual DPI is 300, i think at mirrorless is even less.
better/higher DPI is because of post processing , higher dpi more details. Just simple, if you want better phots shot in RAW .
RAW or not makes no difference - the dpi stays the same,.
The DPI of a printed photo can be affected by the resolution the photo was taken at and the size of the printout (think about it...dots per inch.....or pixels per inch on photos really...DPI is more a printer thing. RAW has nothing to do with the amount of pixels/resolution - and therefore doesnt affect DPI whatsoever as its still exactly the same amount of pixels+ resolution involved whether its in RAW format or not...... All RAW means is that the photo was outputted without any editing by the camera first - its a unmolested original image with no processing which allows for a human to do all the editing later and perhaps a better job of it)
Take a 1 megapixel photo and print that photo on A4 paper, now take a 20megapixel photo and print it on a4 paper. The higher resolution image is going to have a higher DPI on the printout than the lower resolution image does, and would be noticeable as chances are the 1megapixel had such a low dpi at the printout size the image was stretched to fit. Take a 20megapixel RAW image, and a 20megapixel normal image - DPI is exactly with both as it has nothing to do with RAW.
What it all comes down to....Stay on the highest setting you can for resolution, and you have the best chance of getting a good printout later on and being compatible with bigger printouts while still keeping clarity (higher resolution photos can be printed larger without loss of quality)
I wouldnt try and make a poster from a 2 megapixel photo for instance - as it just doesnt have enough resolution to keep a good DPI **when the image is printed** The earlier question by the OP has been answered - it wasnt a DPI setting on her note at all its a compression setting (eg fine/superfine) nothing to do with DPI and has no effect on it either.
Thats kinda it in a nutshell and dumbed down a bit to explain it easier (Im gunna get nit picked to death on technicalities of terms perhaps but im trying to keep it simple)
Hey everyone!
First and Foremost, DO A NANDROID BACKUP!!!!! I am not responsible for any mistakes that you make or if anything happens to your phone.
for thoes who want to test non compression settings and are rooted :
you can flash in magisk and that allows to set jpeg 100%
It's only work with stock camera . It's has no effect in gcam or ....
Changelog:
V1-
-set JPEG quality to 100%
-Increase 1080 and 4k bit rate
-Set audio to channel 2 (stereo)
-Increase audio bit rate
-Increase photos details
V2-
-Some changes for better vibrance and saturation
V3-
-Increase video quality
-Increase audio quality
-Increase photos details
V4-
- Larger Image Buffer
- Larger colour information flow from colour sensor in blend matrix
- Better overall handling of ISO exposure settings
- Better low light performance
- Less noise in low ISO
- More aggressive handling of high ISO aliasing
- Extra frame of bracketing for HDR modes
Enjoy
What does it contain?
Yes, some explanation and info would be welcome haha.
EDIT : guys, don't flash until we have more info.
look at the README:
Changelog:
Code:
v1 - Initial Release
v2 - Fixed the earpiece not working throughout the system
v3 - Fixed Earpiece not switching from multimedia to calls
v4 - Fixed bluetooth audio issue
v5 - Fixed right channel not playing through main speaker
v6 - Fixed latency issue between earpiece and main speaker
The rest seems legit, so it doesn't seem to be a scam, however, it would be good to know exactly what it does. Also, since you used as a model the stereo speaker mod from @acervenky , it would be nice to give him some credit.
Samples
Gcam - stock camera - camera tweak
More sharp and WB super accurate
Works as a module and easy to uninstall?
Just delete from magisk model
https://forum.xda-developers.com/newreply.php?do=newreply&p=78280377
Apart from JPEG quality, which was set to 100% by you, these files have no impact on photos, processing or whitebalance.
They control video.
Also, OnePlus' stock camera and for example GCam are already using 95% JPEG quality.
There is no noticeable difference between 95 and 100%. All this does is needlessly increasing filesize.
Providing downsized samples through the forum is also not saying anything.
The "difference" which can be seen in your samples is not caused by the change you did to the files.
You just took a bad photo from what I can see (bad focus / handshake?!).
Also keep in mind that stock camera sometimes does not apply postprocessing when using it right after GCam.
Clear recents first if you compare them.
If I missed something, please provide thorough information to what you've actually changed.
No disrespect, but in terms of photo-quality this is a placebo-tweak.
V2
Samples:
Gcam - stock - camera tweak
AcmE85 said:
https://forum.xda-developers.com/newreply.php?do=newreply&p=78280377
Apart from JPEG quality, which was set to 100% by you, these files have no impact on photos, processing or whitebalance.
They control video.
Also, OnePlus' stock camera and for example GCam are already using 95% JPEG quality.
There is no noticeable difference between 95 and 100%. All this does is needlessly increasing filesize.
Providing downsized samples through the forum is also not saying anything.
The "difference" which can be seen in your samples is not caused by the change you did to the files.
You just took a bad photo from what I can see (bad focus / handshake?!).
Also keep in mind that stock camera sometimes does not apply postprocessing when using it right after GCam.
Clear recents first if you compare them.
If I missed something, please provide thorough information to what you've actually changed.
No disrespect, but in terms of photo-quality this is a placebo-tweak.
Click to expand...
Click to collapse
Just try it you will see the changes
Nice, thank's you for this mod ?
V3
Flash part 1 and part 2
javad79 said:
Samples:
Gcam - stock - camera tweak
Click to expand...
Click to collapse
Image 1 and 3 are screenshots ?
Photo seems actually nice on camera tweaked but your presentation and samples look weird... what's your mod actually modifying to improve quality??
Looking at the files I agree with the earlier comment, looks like your touching video encoding/decoding... don't see anything related to picture in there...
Gugus38 said:
Image 1 and 3 are screenshots ?
Photo seems actually nice on camera tweaked but your presentation and samples look weird... what's your mod actually modifying to improve quality??
Looking at the files I agree with the earlier comment, looks like your touching video encoding/decoding... don't see anything related to picture in there...
Click to expand...
Click to collapse
In V3 I make changed in Media profile to change jpeg quality and increase audio quality and force it to record stereo and increase video quality by changing bit rate
In part 2 I add some tweak
I belief with this mod you can get better results than stock
Camera or gcam
V3 increase gcam quality too
I'm so busy now and couldn't test or send good samples
If you have any ideas to increase quality just say it
Stock-gcam-tweake
Upload to imgur or any other site that doesn't compress the photos. Thx
http://imgur.com/gallery/I5EnS2W
I am a little confused . What file should I install?
javad79 said:
V3
Flash part 1 and part 2
Click to expand...
Click to collapse
Falsh first one after that second one
With A11, we were able to get the display to always render in native 4K with the adb wm trick.
Code:
wm size 1644x3840
wm density 630
would return
Code:
Physical size: 1096x2560
Override size: 1644x3840
and have the display render in native 4K across the entire OS.
With A12, the trick seems to do nothing now, setting the size back to 1096x2560 and returning no override size value. We're locked out of that beautiful 4K outside of a select few whitelisted apps (like Google Photos). Even the homescreen isn't rendered in 4K! What's the point, then?
I rooted and tried to do some deeper digging around of my own: perhaps there's a whitelist xml? A setting in build.prop? Something? Anything? And much to my disappointment, I could not find anything of substance (of course, not being a developer myself and knowing jack **** is also another major factor...)
So, anyone wanna take a dive in with me and help unlock this beautiful display's potential in A12 once and for all?
Bro get rid of Stock ROM asap. I have always on 4K on Evo X 12.1 ROM
BlazingKahn35 said:
Bro get rid of Stock ROM asap. I have always on 4K on Evo X 12.1 ROM
Click to expand...
Click to collapse
Where to find that rom ?
Pandemic said:
Where to find that rom ?
Click to expand...
Click to collapse
21.3 GB folder on MEGA
17 files and 16 subfolders
mega.nz
BlazingKahn35 said:
21.3 GB folder on MEGA
17 files and 16 subfolders
mega.nz
Click to expand...
Click to collapse
Oke and what is the changelog of evo x 12.1 and bowto install abd maybe you can open a new thread with that rom ?
Pandemic said:
Oke and what is the changelog of evo x 12.1 and bowto install abd maybe you can open a new thread with that rom ?
Click to expand...
Click to collapse
It has automated BAT installer inside no changelog I do not own the ROM
BlazingKahn35 said:
It has automated BAT installer inside no changelog I do not own the ROM
Click to expand...
Click to collapse
Aaah oke thanks m8
BlazingKahn35 said:
It has automated BAT installer inside no changelog I do not own the ROM
Click to expand...
Click to collapse
You have to be on latest A11
Pandemic said:
Aaah oke thanks m8
Click to expand...
Click to collapse
Ik had het via Telegram ook gestuurd trouwens en als je vragen hebt beste via telegram anders.
BlazingKahn35 said:
You have to be on latest A11
Click to expand...
Click to collapse
[ROM][11][UNOFFICIAL] Evolution X 5.9.4 for Xperia 1 III
Evolution X 5.9.4 for Xperia 1 III [pdx215] /* * Your warranty is void. Or vaild, probably? * * I am not responsible for bricked devices, dead SD cards, Ebolation X, * thermonuclear war, or the current economic crisis caused by you following *...
forum.xda-developers.com
largo2 said:
[ROM][11][UNOFFICIAL] Evolution X 5.9.4 for Xperia 1 III
Evolution X 5.9.4 for Xperia 1 III [pdx215] /* * Your warranty is void. Or vaild, probably? * * I am not responsible for bricked devices, dead SD cards, Ebolation X, * thermonuclear war, or the current economic crisis caused by you following *...
forum.xda-developers.com
Click to expand...
Click to collapse
That's the 11 version.
BlazingKahn35 said:
That's the 11 version.
Click to expand...
Click to collapse
Yes
Hello,
I still don't understand anything about this. The screen is 4k, meaning all content is upscalled to 4k (without upscaling, you would have the image taking 1/4 of the screen with big black border all around). Now about app's, if the graphic rendering just create FHD number of pixel, how changing ROM/phone setting would do anything about that, except upscaling it, exactly the same way it does natively?
Hildr said:
Hello,
I still don't understand anything about this. The screen is 4k, meaning all content is upscalled to 4k (without upscaling, you would have the image taking 1/4 of the screen with big black border all around). Now about app's, if the graphic rendering just create FHD number of pixel, how changing ROM/phone setting would do anything about that, except upscaling it, exactly the same way it does natively?
Click to expand...
Click to collapse
I think it's the same of Kodi or other app interface on 4K tv. Some of those up render UI (and some app every content) in 1080P and then the TV/display make the upscale. Optimized app will create a 4k image/video natively (with more load on CPU/GPU but better quality)
Always 4k mode will force pretty much every app to render the image in 4K.
This is the same of the issue ps5 have on 1440P display. usually 1080P image upscaled /adapted from the display to 4k lead to a lower quality image, where 4k rendered image downscaled to 1440P offer a better quality image (it's the same of DSR that is a way to obtain better image without activating antialiasing that always ruin a little the image)
So basically, it's only about UI? Because games assets, video quality and everything that would actually gain from an increased resolution wouldn't change.
When I put my old adobe indesign CS5 that is not meant for QHD/4K screen, forcing it to do so just make a lot of issue with misplaced/unreadable text,which is understandable since the high resolution wasn't taken into account when designing the UI. But well, I do not know enough about designing android app, maybe there is a magic tool in the app itself that does the job, but then, why wouldn't Sony activate it from the start? Could be like the 120Hz toggle with a warning rendering natively at 4k would drain more battery.
High end TV's have now really good algorithm to upscale. Of course you wouldn't have the native detail of a 4K, but a FHD content on the 4k would still appear sharper than on a FHD screen. but yeah, lower quality than native 4k or higher, of course.
Hildr said:
So basically, it's only about UI? Because games assets, video quality and everything that would actually gain from an increased resolution wouldn't change.
When I put my old adobe indesign CS5 that is not meant for QHD/4K screen, forcing it to do so just make a lot of issue with misplaced/unreadable text,which is understandable since the high resolution wasn't taken into account when designing the UI. But well, I do not know enough about designing android app, maybe there is a magic tool in the app itself that does the job, but then, why wouldn't Sony activate it from the start? Could be like the 120Hz toggle with a warning rendering natively at 4k would drain more battery.
High end TV's have now really good algorithm to upscale. Of course you wouldn't have the native detail of a 4K, but a FHD content on the 4k would still appear sharper than on a FHD screen. but yeah, lower quality than native 4k or higher, of course.
Click to expand...
Click to collapse
IIRC it just runs (and displays) at a reduced resolution until you open some whitelisted apps. Screenshots are "upscaled" to native res to hide that the res is actually lower. At least this is how it was in A11.
BlazingKahn35 said:
21.3 GB folder on MEGA
17 files and 16 subfolders
mega.nz
Click to expand...
Click to collapse
Is there like a thread on this somewhere? Or someone who manages this (you?). As someone else mentioned the linked thread is for the A11 version only. I was waiting for an "adequate" A12 ROM.
UsernameNotRecognized said:
IIRC it just runs (and displays) at a reduced resolution until you open some whitelisted apps. Screenshots are "upscaled" to native res to hide that the res is actually lower. At least this is how it was in A11.
Click to expand...
Click to collapse
If you have two pixels rendered, and display them on a screen with 8 pixels available, without upscaling, you'll get 2 pixels floating in the middle of 6 black pixels.
That's what happened in old CRT screen that didn't do the upscaling by themselves, setting a 480p content on a 720p screen would return big black bar all around the content.
The content on the xperia is rendered at various resolution depending on the max possible by the apps, then upscaled to fill the 4k screen, the same way it's done for all 4k tv or screen, so you don't have your content in a post stamp in the middle of a black screen. That's why your screenshot are 4k, not because they were upscaled afterward, what would even be the point of upscaling the screenshot to begin with?
Well, now that I read again the first post, in the morning with a fresh brain, I understand that the phone return a hardware display size lower than 4K for a multiple apps that would be able to render in 4K natively, rather than being upscaled. And that's what you are trying to change.
I understand now. I'm just not sure at this lvl of dpi the human sight is able to differentiate native 4K from upscaled 4K (doesn't mean the 4k is useless, upscaled 4k is still better than qhd display, especially for amoled). But whatever, that's just my personal pov. Hope you get it working then!