Camera Compression - HTC EVO 3D

Has anyone posted a mod to disable the jpg compression algorithm on the stock EVO 3D app? My 5mp pictures are stored around 500-700 kB. My pictures look good on my phone, but horrible when blow up to monitor size. I've seen references to jpg compression on other devices, but nothing shows up in a search for the EVO 3D.

---

Mine shown like that when is in really dark conditions but the rest of the pictures show more then 1mb
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Sent from my PG86100 using Tapatalk

---

jgalan14 said:
Mine shown like that when is in really dark conditions but the rest of the pictures show more then 1mb
Click to expand...
Click to collapse
That would indicate some level of compression. A higher density of one's or zero's allows for greater compression. At 2560x1440x24 bits per pixel ~ 11 MB. So, if my image is 500 kB, the image is compressed to 4.5% of the raw image size. Obviously we are losing quality. This seems to be the standard medium compression (Q=25). I just wish we'd have the option to set the level.

---

i think the camera.apk on our phone is specific to HTC, Sense 3.0 and the EVO 3D as it has to have support for the 2d/3d modes.
without looking at the camera.apk file, my guess would be, in order to modify that type of setting, the apk file would probably need to be decompile and somebody will have to search thru the decompiled pieces to locate the compression information/setting.
unless the camera.apk reads a setting file from its /data/data directory in order to set the compression level, which i doubt, decompiling, modifying and recompiling is the only method which comes to mind ...
sorry, its not a very positive or easy solution...

---

joeykrim said:
i think the camera.apk on our phone is specific to HTC, Sense 3.0 and the EVO 3D as it has to have support for the 2d/3d modes.
without looking at the camera.apk file, my guess would, in order to modify that type of setting, the apk file would probably need to be decompile and somebody will have to search thru the decompiled pieces to locate the compression information/setting.
unless the camera.apk reads a setting file from its /data/data directory in order to set the compression level, which i doubt, decompiling, modifying and recompiling is the only method which comes to mind ...
sorry, its not a very positive or easy solution...
Click to expand...
Click to collapse
The sounds like a lot of work, I'll stick with the current settings, thanks for the info
Sent from my PG86100 using Tapatalk

---

joeykrim said:
i think the camera.apk on our phone is specific to HTC, Sense 3.0 and the EVO 3D as it has to have support for the 2d/3d modes.
without looking at the camera.apk file, my guess would be, in order to modify that type of setting, the apk file would probably need to be decompile and somebody will have to search thru the decompiled pieces to locate the compression information/setting.
unless the camera.apk reads a setting file from its /data/data directory in order to set the compression level, which i doubt, decompiling, modifying and recompiling is the only method which comes to mind ...
sorry, its not a very positive or easy solution...
Click to expand...
Click to collapse
I don't really care about fixing 3D mode. Maybe we could compile the 2D camera app from AOSP?
Jason

---

jason62082 said:
I don't really care about fixing 3D mode. Maybe we could compile the 2D camera app from AOSP?
Jason
Click to expand...
Click to collapse
definitely, thats compiled all the time in cm7. hopefully soon cm7 will be fully functional on evo 3d.
by way of AOSP camera.apk, here are the files:
http://android.git.kernel.org/?p=platform/packages/apps/Camera.git;a=tree
believe it or not, grepping for the phrase compress returned a few very helpful lines:
http://android.git.kernel.org/?p=pl...Camera.git&a=search&h=HEAD&st=grep&s=compress
the line which stands out to me the most:
source.compress(CompressFormat.JPEG, 75, outputStream);
it is very possible, if the adjustment options for compression were properly added to the settings in the camera.apk and pushed to cm7, they would probably accept it.
if you wanted to compile for yourself, now that we have root and nand unlock, thats also possible!
the only potential issue i'm not 100% sure about would be camera drivers for the kernel and the AOSP version of camera.apk working properly with ours ....

---

I would think the compression issue is definitely on the right track, my HTC Hero took excellent pictures compared to the 2D pictures of my EVO 3D in 2D, obviously you would not think they would downgrade hardware in a phone meant for this and I a year and half newer. I was quite disapointed when I compared the quality after getting the phone, thought the EVO was better because the screen is 3x better than the Hero but when you put them on a computer no contest the EVO is worse. They're both 5mp but the EVO 3D turns out 2mp quality...fail! Hopefully we can decompress and supercharge this camera.

---

+1 on trying to get this resolved!

---

joeykrim said:
the line which stands out to me the most:
source.compress(CompressFormat.JPEG, 75, outputStream);
Click to expand...
Click to collapse
I was able to compile the AOSP source and make these changes (increasing the compression to 99), but no dice. I tested the with and without this change and it didn't make a lick of difference.
Also, I tried to compile the CM source, but I must not have some of the source. I get compile errors looking for methods that don't exist.

---

jason62082 said:
I was able to compile the AOSP source and make these changes (increasing the compression to 99), but no dice. I tested the with and without this change and it didn't make a lick of difference.
Also, I tried to compile the CM source, but I must not have some of the source. I get compile errors looking for methods that don't exist.
Click to expand...
Click to collapse
This sucks...not only do we only have a 5M camera where 8M are standard, its not even a good one at that. I dont know about others, but I dont take 3D pics and would much rather have a descent 2D camera

---

Found somethimg interesting...crappy the other day. Go to camera settings and you'll see that in 16.9 wide mode, 2 spaces up where it sais 5mp it has 2560x1440 pixels=3.686 Mp...WTF, but put it in 4x3 mode the 5mp line then show 2560x1920 pixels= 4.915 Mp. When you go to Wide screen you robbed and nocked down to a 3.6 Mpixel camera, thats Bulls#!t. Which means in 3D your using 2 widescreens for an effective rate of 7.3 Mpixel...not even combined 10Mp like i originaly thought.

---

stealth919 said:
Found somethimg interesting...crappy the other day. Go to camera settings and you'll see that in 16.9 wide mode, 2 spaces up where it sais 5mp it has 2560x1440 pixels=3.686 Mp...WTF, but put it in 4x3 mode the 5mp line then show 2560x1920 pixels= 4.915 Mp. When you go to Wide screen you robbed and nocked down to a 3.6 Mpixel camera, thats Bulls#!t. Which means in 3D your using 2 widescreens for an effective rate of 7.3 Mpixel...not even combined 10Mp like i originaly thought.
Click to expand...
Click to collapse
I don't see that issue, but I flashed the 2.3.4 htc camera (can't remember the thread off hand, but I think it's the 1 discussing the green hue fixed). I just saw it's in 16:9 and 5MP.

---

Oh mine still shows 5mp but if you look at the small print for thactual pixel it drops the count in widescreen mode, trying to sneek one by us. And this was the same on my camera before and after the update. Guessing the phone couldn't handle a true combined 10mp in 3D mode and they had to keep it under 8 or something. Atleast the green hue is gone.

---

Actually the 3d photos are 2mp
Sent from my HTC EVO 3D X515m using XDA App

---

jason62082 said:
I was able to compile the AOSP source and make these changes (increasing the compression to 99), but no dice. I tested the with and without this change and it didn't make a lick of difference.
Also, I tried to compile the CM source, but I must not have some of the source. I get compile errors looking for methods that don't exist.
Click to expand...
Click to collapse
interesting! im glad you were able to get aosp camera.apk to compile!
originally, i didn't trace that line back any further, but i remember seeing it imported a bitmap compression package in the headers. now you've sparked my curiousity so i've researched it below. if you want the short answer, skip to the bottom for summary.
long technical answer: doing some more googling i found the bitmap compress method call documented on the android java dev site for Bitmap and quoted below:
boolean = compress(Bitmap.CompressFormat format, int quality, OutputStream stream)
Write a compressed version of the bitmap to the specified outputstream.
Click to expand...
Click to collapse
Clicking on the word, compress, links to more details around that specific method call and quoted below says:
public boolean compress (Bitmap.CompressFormat format, int quality, OutputStream stream)
Since: API Level 1 Write a compressed version of the bitmap to the specified outputstream. If this returns true, the bitmap can be reconstructed by passing a corresponding inputstream to BitmapFactory.decodeStream(). Note: not all Formats support all bitmap configs directly, so it is possible that the returned bitmap from BitmapFactory could be in a different bitdepth, and/or may have lost per-pixel alpha (e.g. JPEG only supports opaque pixels).
Parameters
format The format of the compressed image
quality Hint to the compressor, 0-100. 0 meaning compress for small size, 100 meaning compress for max quality. Some formats, like PNG which is lossless, will ignore the quality setting
stream The outputstream to write the compressed data.
Returns
true if successfully compressed to the specified stream.
Click to expand...
Click to collapse
summary: it appears the compress call does just that, it compresses the image and the only variable we can change is the "quality" of the compression. i think it might be worthwhile to just bypass this compress call. if we don't want the image compressed, why even call compress? i would suggest it is worth compiling the aosp Camera.apk and bypassing the compress call.
hope that helps provide some more insight!

---

I don't know much about programming, but I don't see why skipping the compress call is a good idea. I'm all for keeping jpg format and I've always been under the impression that is a compression. 75 for quality is a bit low which is what it's set to, right? Why not just put it to 100 and maximize the quality?

---

joeykrim said:
summary: it appears the compress call does just that, it compresses the image and the only variable we can change is the "quality" of the compression. i think it might be worthwhile to just bypass this compress call. if we don't want the image compressed, why even call compress? i would suggest it is worth compiling the aosp Camera.apk and bypassing the compress call.
hope that helps provide some more insight!
Click to expand...
Click to collapse
I commented out that line and saw no change. It compiled without any problems. I'm not even sure that piece of code is even being called. Could it be that the camera hardware itself is compressing the image? I'm a little new to Android debugging, but is there a way to step through the code with Eclipse? That might be the only way to figure out what's going on.

---

gk1984 said:
I don't know much about programming, but I don't see why skipping the compress call is a good idea. I'm all for keeping jpg format and I've always been under the impression that is a compression. 75 for quality is a bit low which is what it's set to, right? Why not just put it to 100 and maximize the quality?
Click to expand...
Click to collapse
at this point, we are more analyzing the AOSP code and looking to understand how the current AOSP functions/methods are coded and how they operate. also looking to understand the impact different calls/methods have on the size and quality of the images.
i think its too early to determine what is ideal or optimal w/o knowing the impact each setting and method call has on the final image.
we're also hoping the htc camera apk is using code/methods/packages similar to the AOSP to make the end result easier to port over. HTC might have completely recoded everything and AOSP might be completely unreleated. i haven't seen any post with decompiled htc camera code yet so for starters we're working with the open source code android gave us.
jason62082 said:
I commented out that line and saw no change. It compiled without any problems. I'm not even sure that piece of code is even being called. Could it be that the camera hardware itself is compressing the image? I'm a little new to Android debugging, but is there a way to step through the code with Eclipse? That might be the only way to figure out what's going on.
Click to expand...
Click to collapse
the camera hardware itself *could* be compressing the image .. the only other place I would know to look would be at the camera drivers in the kernel source code.
Easiest method I use for Android App Debugging is to throw an output in logcat.
on the next line (so we know its inside the same call), right after the source.compress method call, add Log.d(LOG_TAG, "Source.compress called"); LOG_TAG is usually defined as a static string in most android apps so all logcat output is the same throughout the app. if its not defined in the camera app, you can replace with whatever string you want.
this will also require an android.util package and Eclipse should give a prompt.
keep us updated! appreciate all the compiling/testing you're doing!

---

I may have something
Okay, so I think I figured out where the jpg compression happens. In the driver source there's a driver for a Zoran chip. Zoran makes a camera/video processing chip that takes in an image, does something, then sends it back. See www.linuxmedialabs.com/Downloads/LSI/ZR36067.PDF. In \drivers\media\video\zoran\zoran_card.c there is an interesting line:
Code:
zr->jpg_settings.jpg_comp.quality = 50; /* default compression factor 8 */
I'm thinking this is how the compression is initialized. If we set the value to 100, we might be able to increase the quality. Now, how do we get this cooked into a ROM. Can someone help me with this?
EDIT: I don't think the Zoran code is used at all if I look through the shooter configs IDK, It looks like it may be done by the Gemini code.