Camera and Video Analysis

I still need to upload the videos so you'll have to wait for those, and if you haven't figured it out by now I'm really not the best photographer in the world...not even close! But I did run around inside and outside for a bit snapping pictures with both tablets.

The cameras are identical in the 8.4 and 10.1 Galaxy Pro, so while the galleries below contain images taken with both tablets there's really no difference to speak of (other than perhaps the location of the camera lenses and the potential to accidentally get upside-down photos from the 8.4 if you're not careful).

For video, both the front and rear cameras record at 1080p30 with a bitrate of ~17Mbps; the rear-facing camera has a slightly higher quality, but either one will work for basic video needs. Pictures are a different story, with the front-facing camera supporting up to 1920x1080 with an f/2.4 aperture and the rear-facing camera supporting up to 3264x1836, also with an f/2.4 aperture. Compression artifacts are clearly evident with both cameras, but the rear-facing does offer much better overall quality.

Low-light performance is nothing special as far as I could tell; a mostly dark room will present problems, dimly lit photos will be very grainy, and even indoor photos in general are merely okay. Outdoors the camera does better, but that's typical of any camera.

Overall, the cameras do a serviceable job at taking photos and videos. I find tablet cameras to be a bit unwieldy personally, but at least the Samsung Galaxy Pro line can provide decent photos that will rival inexpensive point-and-shoot cameras.

Battery Life and Storage Performance Closing Thoughts
Comments Locked

125 Comments

View All Comments

  • SilthDraeth - Saturday, March 22, 2014 - link

    On my note phone if I want to take a screenshot, I hold the power button and the Samsung Home button. Give that a try. Or, on my wife's note 10.1 first edition, it has a dedicated screenshot softkey that appears where your normal android home keys, etc appear.
  • FwFred - Sunday, March 23, 2014 - link

    LOL... 'Pro'. Surface Pro 2 just fell off the chair laughing.
  • garret_merrill - Friday, October 3, 2014 - link

    Really good tablets, although I would seriously consider the Note Pro series too (highly ranked by a number of sources, see http://www.consumertop.com/best-tablets/). But either way, the Samsung tables deliver fantastic quality.
  • Brian Z - Saturday, March 22, 2014 - link

    Antutu? Really... Maybe somebody kidnapped Anand and Brian. Frigging Antutu
  • grahaman27 - Saturday, March 22, 2014 - link

    Better than just posting the browser speed tests for CPU, and draw final thoughts from that, which they have gotten in a habit of doing.
  • JarredWalton - Sunday, March 23, 2014 - link

    What's wrong with running one more benchmark and listing results for it? Sheesh... most of the time people complain about not having enough data, and now someone is upset for me running AnTuTu. Yes, I know companies have "cheated" on it in the past, but the latest revision seems about as valid in its reported scores as any of the other benchmarks. Now if it wouldn't crash half the time, that would be great. :-\
  • Egg - Sunday, March 23, 2014 - link

    You do realize that Brian has, for all intents and purposes, publicly cursed AnTuTu and mocked the journalists who used it?
  • JarredWalton - Sunday, March 23, 2014 - link

    The big problem is people that *only* (or primarily) use AnTuTu and rely on it as a major source of performance data. I'm not comparing AnTuTu scores with tons of devices; what I've done is provide Samsung Galaxy Tab Pro 8.4 vs. 10.1 scores, mostly to show what happens when the CPU in the 10.1 hits 1.8-1.9 GHz. It's not "cheating" to do that either -- it's just that the JavaScript tests mostly don't go above 1.2-1.3GHz for whatever reason. Octane and many other benchmarks hit higher clocks, but Sunspider and Kraken specifically do not. It's probably an architectural+governor thing, where the active threads bounce around the cores of the Exynos enough that they don't trigger higher clocks.

    Don't worry -- we're not suddenly changing stances on Geekbench, AnTuTu, etc. but given the odd clocks I was seeing with the 10.1 I wanted to check a few more data points. Hopefully that clarifies things? It was Brian after all that used AnTuTu to test for cheating (among other things).
  • Wilco1 - Sunday, March 23, 2014 - link

    The reason for the CPU clock staying low is because the subtests in Sunspider and AnTuTu only take a few milliseconds (Anand showed this in graphs a while back). That means there is not enough time to boost the frequency to the maximum (this takes some time). Longer running benchmarks like Geekbench are fine. I wouldn't be surprised if the governor will soon start to recognize these microbenchmarks by their repeated bursty behaviour rather than by their name...

    Of course the AnTuTu and Javascript benchmarks suffer from many other issues, such as not using geomean to calculate the average (making it easy to cheat by speeding up just one subtest) and using tiny unrepresentative micro benchmarks far simpler than even Dhrystone.

    Also it would be nice to see a bit more detail about the first fully working big/little octa core with GTS enabled. Previously AnandTech has been quite negative about the power consumption of Cortex-A15, and now it looks the 5420 beats Krait on power efficiency while having identical performance...
  • virtual void - Monday, March 24, 2014 - link

    You cannot disregard the result produced by something just because the load generated by the benchmark comes in very short burst, that is the _typical_ workload faced by these kind of devices.

    The result in Geekbench give you some hint how the device would handle HPC-workloads, it give you very limited information about how well it handles mobile apps. Another problem with Geekbench is that it runs almost entirely out of L1$. 97% of the memory accesses where reported as L1-hits on a Sandy Bridge CPU (32kB L1D$). Not even mobile apps has such a small working set.

    big.LITTLE is always at a disadvantage vs one single core in bursty workloads as the frequency transition latency is relatively high when switching CPU-cores. Low P-state switching time probably explains why BayTrail "feels" a lot faster than what the benchmarks like Geekbench suggest. BayTrail has a P-state latency of 10µs while ARM SoCs (without big.LITTLE) seem to lie between 0.1ms - 1ms (according to the Linux device-tree information).

Log in

Don't have an account? Sign up now