The Epic 4G has a pair of cameras: a 5MP flash assisted camera on the back of the device and a front facing VGA camera on the front. Samsung’s camera app is a nicely trimmed down version of what we’ve seen on many Android phones. You still get the ability to adjust things like white balance, metering mode and exposure compensation, but you can also hide all of that so all you see is a viewfinder and a capture button.

The Camera app, detailed mode

The Camera app, simple mode

The app launches in an average amount of time. I recorded 3.03 seconds to get from the icon to being able to line up my first shot. There’s a measurable lag between when you take a shot and when it’s actually captured, which can result in blurred photos if your subject is only stationary for a short period of time.

The Camera app repurposes the physical buttons on the Epic 4G. You can lock the camera app by hitting the power/lock button, doing so will render all other buttons on the phone inactive (e.g. home/back keys won’t work, useful if you’re recording video that you don’t want interrupted). The volume rocker serves as zoom in/out buttons as well.

You have two options to actually trigger the camera: you can use the button the screen, or the physical trigger on the camera itself. Both work well.

Picture quality out of the rear facing camera is great for web-sized images, but at full resolution you see the shortcomings of the sensor/software combo. Brian has most of the comparable smartphones so all I was able to do is showcase the Epic 4G vs. the Nexus One and iPhone 4.

White balance isn’t too bad. The Epic 4G tends towards more reddish tones than blue/green but it’s at least more predictable than the iPhone 4. The biggest issue really is image sharpness. At web resolutions it’s fine, but blown up to full size you see how soft the picture really is. You lose a lot of detail.

Apple iPhone 4 - Click to Enlarge

Samsung Epic 4G - Click to Enlarge

Google Nexus One - Click to Enlarge

I’d say that most modern smartphone cameras are fine for sharing pictures on Facebook but if you want to be able to pick out details you’ll need to look for another phone or carry a point and shoot with you.

The Epic, like many Android phones, has issues dealing with light shining through trees. You get an overblown halo effect, rather than an accurate depiction of the scene.

The rear camera is capable of recording 720p video and it can record video with the flash on, a feature that’s surprisingly absent from a number of flash enabled smartphones. Video quality here is reasonably good. The softness problem is less of an issue at 720p it seems.

Battery Life GPS Issues


View All Comments

  • Ethaniel - Monday, September 6, 2010 - link

    I have also noticed that all Android phones out there do some kind of "breakdancing". You think it has something to do with Android, but I think it has something to do with Java. Now, Java devs will probably want to eat my brain after this... but Java sucks. Big time. Making Android's UI based on Java was a bad, bad, really bad move. About four three time slower than C++, it demands more memory... completely inadequate for a mobile environment. Reply
  • meatless - Monday, September 6, 2010 - link

    It's sad, the prevalence of Java FUD to this day. It's also bad to blame Java (the syntax), as you are unnecessarily conflating the Dalvik VM with desktop VMs such as Sun's.

    C++ is fast, sure, but there is a lot more to designing a platform than speed, and the Dalvik VM is more than fast enough. iOS's Obj-C implementation is also not C++ fast, but who complains?
  • taltamir - Tuesday, September 7, 2010 - link

    1. both Javas are shit
    2. There is more to a platform then speed... but when you are designing a platform starved for processing power and that needs to sip electricity then it makes a huge difference.
  • Penti - Tuesday, September 7, 2010 - link

    Most of the platform are actually C/C++ libraries and programs, where you glue your app in isn't that relevant. You need a framework for any mobile phone platform, but the resources that framework glues into thats where a lot of performance comes from and it's in C/C++. It's better to have an accelerated framework running on a virtual machine then an unaccelerated C++ one. Rendering of menus and such would be slower on the last one. Besides on Symbian it's QT-framework that rules now, not some ultra customized embedded framework. Memory requirements have gone up there too, but capacity have grown even more. Besides nobody wanted to write mobile apps to some badly designed and awkward C++ framework and API. Java syntax was a good choice therefor. Reply
  • taltamir - Monday, September 13, 2010 - link

    the fact that there are more considerations than just programming language when it comes to power and speed are obvious, as is that you could make a java app thats faster than a C++ app.
    Neither make java a good choice.

    BTW, I didn't personally comment about the issue of jerkiness, I was going on a tangent as a reply to what meatless said (specifically the socalled "java FUD")
  • zizagoo - Monday, September 6, 2010 - link

    It's an Android problem. The cause of the "jerkiness" is that unlike iOS/WebOS/WP7, Android doesn't have a gpu accelerated ui. They supposedly did this because the G1 wouldn't support it at the time.

    Gingerbread, which is supposedly showcased next month, should fix this.
  • deputc26 - Monday, September 6, 2010 - link

    Thankyou! this is exactly it, give the man a medal. I don't know why Anandtech never mentions this. It should be ubiquitous knowledge in the android community. Reply
  • meatless - Monday, September 6, 2010 - link

    Also, the 3-4X speed difference on non-mobile platforms is greatly exaggerated. I always find a fun and FUD-free site. Reply
  • Iksy - Tuesday, September 7, 2010 - link

    Greatly exagerated? That site shows a 2.3x speed difference and it's comparring against Sun's fastest most optimizing version against g++. The unoptimized version is over 20x slower, you'll find it near the bottom of the list for compares. I do find it interesting that while they're satisfied with using an open source C (gnu) compiler, they do not include the open source java interpreter. They also do not include the Intel C compiler, even though they easily could and include the Intel Fortran compiler.

    In other words, is still in the ball park so say Java is 3-4x slower than the equivalent c++ code.
  • dvinnen - Tuesday, September 7, 2010 - link

    Wait, so the Java syntax is what is slowing down Android? Because it doesn't run Java, it runs Dalvik.

    I would also like to see evidence that C++ is 4 times faster. Not saying Java is faster but it is fast enough. I say that as a Java developer who doesn't like the language and would rather use slower languages like Python

Log in

Don't have an account? Sign up now