Lava Xolo X900 Review - The First Intel Medfield Phone
by Brian Klug on April 25, 2012 6:00 AM ESTCamera is the other big axis of improvement with Medfield, as Intel has included a SiliconHive ISP with full support for up to 24 MP rear facing cameras and a 2 MP secondary camera. Intel acquired SiliconHive a while ago, and it has integrated their IP prominently inside the platform.
In addition all the features you need to support a smartphone camera are here, including AE, AWB, AF, lens shading and distortion correction, stabilization, and fixed pattern/dark noise subtraction. Intel is also quite proud of its burst functionality which enables up to 10 full size 8 MP images to be captured at up to 15 FPS.
I did some digging and found what CMOSes are being used in the Xolo X900 smartphone. The front facing camera is an Aptina mt9m114 1.3 MP 1/6“ CMOS with 1.9µm square pixels, and the rear facing camera is an Aptina mt9e013 8 MP 1/3.2” CMOS with 1.4µm pixels (3264 x 2448). The 8 MP rear facing system appears to possibly be from LiteOn. The optical system onboard is F/2.4 with 4.4mm focal length. The result is a thoroughly modern camera system that is up to par with what’s shipping in other devices right now. Interestingly enough, I can tell from poking around that Intel has tested the Medfield platform with a 14MP module as well.
The camera UI on the X900 is by far the most comprehensive of any smartphone I’ve encountered so far. The still shooting mode includes customization options for the burst mode and FPS, image capture size, compression level, and bracket modes in the top tab. Below that are scene modes (Auto, Sports, Portrait, Landscape, etc), focus modes (Auto, Infinity, Macro, Touch to focus), white balance (Auto, Incandescent, Daylight, etc), exposure, flash, color filters (None, Sepia, BW, Negative), ISO (100, 200, 400, 800), exposure time (1s to 1/500s), and auto exposure metering modes, phew. What’s really unique however are toggles under the happy face icon for advanced features like GDC (geometric distortion correction), XNR (extra noise reduction for low light), ANR (another noise reduction routine). These are usually things present in other ISPs, but I’ve never seen the option to play with them in any smartphone camera UI before. There are also some RAW options which, based on their labeling, I would assume allow you to save pre-Bayer demosaicing RAW data and YUV data, but I’m not sure where this data is stored after capture. Resetting the camera to defaults interestingly enough turns GDC, XNR, and ANR off, so it is in this mode that I captured sample images.
Burst mode works well, as does the camera UI. Images captured in burst mode are prefixed with BST instead of IMG when they’re stored, so you can tell the two apart later on the desktop. 8 MP images captured on SuperFine end up being just under 2 MB after JPEG compression.
To get to the bottom of still image quality, we turned to our regular set of evaluation tools, consisting of both photos taken in a fixed smartphone lightbox test scene with the lights on and off, with test charts (GMB color checker card, ISO12233, and distortion), and at our smartphone bench locations. I took these after resetting the camera to defaults, which again curiously disables GDC, XNR, and ANR. The result is some very strange higher order distortion in the chart (the chart is indeed flat and normal to the camera), but good spatial resolution in the ISO chart, I can see up to around 15 lp/ih in the vertical and 14 in the horizontal. White balance is a bit weird on the chart, but in the lightbox the white balance is pretty good. The X900 also illuminates the scene for focusing before taking the photo in the dark, which is something some smartphone OEMs are still not doing.
I’m pretty pleased with camera quality, it isn’t as good as some other smartphones that are out right now, but it’s very good. I suspect this is more a reflection of the optics (eg heavy distortion without geometrical correction) than ISP. I actually come away pretty impressed with all the options that have been made available, it’s obvious that lots of time and energy went into that part.
Video
The video capture UI unsurprisingly offers some of the same configuration options as the still shooting mode. Capture resolutions from QVGA to 1080p are offered, along with various MMS compatible settings like we’re used to seeing. The menu here also offers the ability to disable electronic video stabilization (DVS) and noise reduction (NR) which is awesome, especially since many find electronic video stabilization somewhat disconcerting. I disabled it for the test video since this results in the same behavior I saw with the Galaxy Nexus before Google ostensibly disabled it on the rear camera (but left it enabled on the front one). Anyhow, I’m grateful that the options are here, as the smartphone camera UI standard seems to be trending toward Apple’s minimalist tendency rather than exposing real options, but I digress.
To evaluate video capture quality on the X900, I took videos at the standard bench location at around the same time. The Medfield platform uses Imagination’s VDE285 video encoder. 1080p30 video recorded on the X900 is encoded at 15.0 Mbps H.264 Baseline with 1 reference frame. 720p30 video from the rear camera is encoded at around 8 Mbps with the same parameters, but interestingly enough front facing 720p30 video is encoded at 12Mbps. All three include 320 kbps AAC stereo audio.
Baseline H.264 is about par, but not the high profile that we’ve seen being done on other platforms like Exynos 4xxx or OMAP 4. Thankfully the baseline bitrate is good enough to produce good quality results, but again turning the encode parameters up a bit would enable better results with the same bitrate.
As we always do, I’ve uploaded the bench videos to YouTube and also made them available for direct download if you want to look at them without the transcode. Some small interesting points are how the videos are saved with a .3gp extension instead of the more common .mp4 (haven’t seen .3gp in a while, even if it’s acceptable), and also the 1080p video field of view is much narrower than the 720p field of view (clearly a center crop is being taken). Those notes aside, I have no issues with the 1080p video quality that’s produced, it looks good and has continuous auto focus. The 720p video has some weird decimation artifacts from downscaling, but nothing too bad, and 1080p maximum is usually what I scrutinize anyways.
Facebook
Twitter
RSS
106 Comments
View All Comments
kyuu - Wednesday, April 25, 2012 - link
I dunno what review you all were reading, but I didn't see average performance. I saw it pretty much beating everything else save the HTC One S/X with only a single-core and running an old version of Android. Wth ICS, it'd probably be at the top easily.Sure, ARM isn't sitting still, but is Intel. I have no desire to see Intel overtake the market, but I can easily see Intel being the performance king by a good margin in the mobile SoC market when they release their next SoC.
Also, for people saying cost is a factor... do you have any source to back up the claim that Intel's SoC is significantly more costly? All I see are assumptions.
kyuu - Wednesday, April 25, 2012 - link
That's "neither is Intel" in the second paragraph, first sentence.UpSpin - Thursday, April 26, 2012 - link
SunSpider and Browsermark results are that good because of software tweaks done by Intel. Intel tweaked a lot in software, thus I doubt that ICS will improve anything further.Linpack single threaded, that's the most important benchmark to compare raw processing power without software tweaks. It shows that Medifield is faster than ARM A9, a good sign, but slower than Krait and thus all soon to get released A15 cores, a bad sign.
Linpack multi threaded shows that Medfield has not the slightest chance vs. Krait and ARM A15, most of them will be dual core SoCs, but even if they get produced in single core varients they will be faster (Linpack single threaded). Medifield also gets beaten by Quad Core A9 chips (all new high end smartphones pack either a Quad Core A9, or dual Core krait/A15). Medfield is at best, as fast as a dual core A9 (raw processing power).
Then take a look at the GPU: Poor performance for todays standards. Slower than the SGSII, slightly faster than the Galaxy Nexus, which has a slow GPU, too.
Power consumption: poor to average. (sadly we don't have numbers for Krait or Tegra 3 (HTC One X/S)
The SoC is not bad at all, but its release date is one year too late. This year is the year of Krait and A15, which beat Medfield in single threaded applications and are at least dual cores, so more than twice as fast. The integrated GPU is pretty weak, too, especially if you consider that this years ARM SoCs have a much better GPU.
Additionally x86, the advantage is huge software tweaks thanks to Intel, the disadvantage, custom skins/apps/features made by third party manufacturers won't run that easily.
Exophase - Friday, April 27, 2012 - link
Intel doesn't tweak Sunspider or Browsermark. But Javascript JIT performance is probably much better on x86 than ARM right now because it got a ton of attention on PCs from all major browser vendors, starting with the release of Chrome. And there's at least one major ARM improvement (EABI hardfloat) that's in V8 but didn't make it into official Android yet.Browsermark is only partially Javascript, but the other part (HTML5 rendering) is really lame too. Run it and you'll see what I mean, I hope.
Linpack is also a lousy benchmark. Any serious vector FP code on a phone (like matrix stuff for a game) would use SIMD with compiler intrinsics or ASM, and probably single precision over double precision. But even as a Dalvik double precision floating point test it sucks because it's not tiled and therefore heavily bandwidth limited.
Basically, most of the benchmarks used are awful.
clockerspiel - Wednesday, April 25, 2012 - link
The cell phone industry desparately needs a "flagship" representative for the Android ecosystem - and this ain't it!jjj - Wednesday, April 25, 2012 - link
You can't normalize battery life unless you factor in the screen size since the screen uses a lot of power and the handset's volume is directly related to the screen size and battery size.By normalizing you are making things worse than better.If you can't measure the power consumption for just the SoC you might as well just provide the system's battery life since,in the end, that's what matters anyway.
It is what it is,you can't take out the screen or the RAM or the NAND but that's no reason to make things worse with tests that distort the reality instead of helping.
menting - Wednesday, April 25, 2012 - link
uhh, it's not measuring the power consumption for the SoC, it's measuring the whole phone's power usage. So in this case, normalizing IS a valid way to go about this.plamengv - Wednesday, April 25, 2012 - link
It is beyond me why Intel will market x86 CPU with OS that has nothing to do with x86. The people who want Android will always go with the better looking and cheaper device. Something that this device is not. The other with knowledge will go for iPhone because there is no other alternative. Windows Phone is from professional point of view worse than Windows Mobile 6.5 and lacks lot of features. Intel had to bet on Windows 7 turning the smartphones into UMPC. Imagine Viliv S5 shrinked to Galaxy Note but running Windows 7! Well maybe Haswell and 22nm will finally make it.menting - Wednesday, April 25, 2012 - link
android was built from Linux..tell me where Linux has nothing to do with x86. And with future android versions including x86 compiles by default., x86 or not isn't an issue.The X900 is a reference design, who says other companies can't put a different external case on it? And where's proof that it will be more expensive?
superPC - Thursday, April 26, 2012 - link
why windows 7? windows 8 would be a lot better suited for something similar with this phone (with compatible GPU).