I received the +NVIDIA​ Shield Android TV!

Ordered on black Friday (160€) with the cheapest free shipping, it got here earlier than I expected.
The device itself is a beauty. It impresses.

I don't have a TV at the moment so it's plugged on a 1920×1200 monitor (supports HDCP) via a HDMI to DVI connector.

On first boot, for the initial setup it configured the output to 1920×1200 (in RGB limited tho) which was fine. It applies an update as soon as it can and is stuck on 640×480 since it rebooted, HDMI settings doesn't allow to change it, shoot.
Maybe something can be hacked until I get a TV.

Its super convenient that there's two Audio Outputs beside the HDMI one that's not connected to anything at the moment.

First output: on the controller. And wow, there's a capable DAC & HP amp in this thing already! Very good surprise, it sounds great.
It's native to the system and I wonder if it's actually streaming in a compressed format or in lossless PCM. I'll measure later. In case it's compressed it's pretty well done.
The output level is sufficient to drive the 300 ohms Sennheiser HD 650 (albeit not super loud for quiet content, but for music it's fine).
The HP amp output impedance appears to be high so the amount of bass is reduced on some headphones.

Second output: on the remote. This one appears as a Bluetooth audio device to the system so it probably streams as SBC.
Unfortunately my unit seems defective. There's a loud permanent icky noise on the left channel that makes it unusable. It persisted after the accessory firmware upgrade so I guess I'll have to request a replacement. Boo.

I got this device to study the possibility to write a color correction driver on this platform.
Either fully hardware using the display controller capabilities – if any or using the (very powerful) GPU.
I expect the GPU and compositor to not be able to access DRM protected surfaces like what Netflix app likely uses, just like on the Nexus 7 2013.
I'll let you know if I get any result, who knows 😊

#supercurioBlog #development #nvidia #shield #TV

Source post on Google+

New self-hosted Git repository service

+Sourcegraph​ looks like an excellent alternative to +GitHub​​​​​, that you can install on your own server.

I particularly like the IDE-like features making exploring the code so much easier.

It's source code released under "fair source license" is an original approach as well.
It is not exactly "open source" but "hackable source" instead, still much better than the commonplace proprietary.

Discussion on Hacker News: https://news.ycombinator.com/item?id=10621751

#supercurioBlog #development



README.md at b1af2ab4761618930f6f7e44eb775e08fac3f38e – sourcegraph – Sourcegraph
Sourcegraph: the intelligent, hackable code host for teams. Sourcegraph is a self-hosted Git repository service with Code Intelligence. It runs on your own server or cloud and installs in 5 minutes. Sourcegraph gives your team the power to build better software by offering: …

Source post on Google+

Android source becomes faster to build

Building Android from its gigabytes of source code take a little bit of time.
And yes this is an euphemism, as we are talking about roughly 2 hours for a reasonably powerful quad core desktop CPU.

Of course when working with this gigantic project, you learn quickly how to build only what's necessary and its dependencies.

Still it's very good news that AOSP is switching from an optimized use of the venerable "make" tool to a duo of better optimized replacements named Kati and Ninja.
https://github.com/google/kati/blob/master/README.md
https://martine.github.io/ninja/

It's only the beginning since there's an effort to rework the build files design and WebView chromium now comes pre-built (which alone divides the full build time by almost two).

#supercurioBlog #development



Re: ANN: AOSP builds with ninja
Publié le 28/10/15 13:47 (4 messages)

Source post on Google+

Compiling Android Marshmallow #AOSP for the +Nexus​​​​ 10, awesome!

I needed just that for display calibration driver development purposes.

Thanks you very much +Dmitry Grinberg​​​​ 😃

#supercurioBlog #development



Android M on Nexus 10 – Dmitry Grinberg
How to build Android Marshmallow on Nexus 10. The story thus far… Many were very sad when google chose not to update Nexus 10 to Android 6.0 Marshmallow. This simple guide will show you how to build Android 6.0 Marshamllow for Nexus 10. And for the lazy, I also have a pre-built AOSP …

Source post on Google+

Here's the results of the current state of my display calibration algorithm on the early batch Nexus 5 I sent back and its refurbished replacement

Following up on https://plus.google.com/+supercurioFrancoisSimond/posts/cgKUgJEPTtc

On both, a 12-bit RGB LUT is loaded in hardware, but as you can see on the curves in these graphs, the panel being only 8-bit, there's some banding going on.
I started working on another driver approach that allows to avoid this 8-bit limitation and permits extremely precise correction.

The target for both is D65 white point (as seen by the sensor for simplification), gamma 2.2 curve with a fine-tuned near-black response to avoid clipping or visual artifacts in shadows and near black, also preserving the color balance as much as possible near black.

The replacement Nexus 5 stays better even when both are calibrated thanks to its higher native brightness, slightly higher contrast ratio, and better consistency in its RGB channels which requires less correction.
Although beside the brightness difference which is appreciable, they look the same.

On both, the grayscale Delta E stays below 1 which is a very good accuracy despite the current 8-bit per channel driver hardware limitation.

Subjectively, it also looks pretty darn good 🙂

Other info:

Maximum brightness – significant difference
original: 381 cd/m², replacement 474 cd/m²

Contrast ratio
original: 862:1, replacement: 891:1

On both, HCFR calculates an average gamma value of 2.18 without black point compensation and 2.21 with.

#supercurioBlog #calibration #display #color #development #measurements

              

In Album Display Measurements: my calibration algorithm on first batch Nexus vs refurbished replacement

Source post on Google+

There's a new revision of the popular X-Rite i1 Display Pro colorimeter out here, and the latest ArgyllCMS release is not able to drive this sensor fully yet

+Vincent Sergère is a proud owner of one and can't use it quite yet for what it's intended for now.

Hoping this message will help ArgyllCMS's author!

#supercurioBlog #development #color #calibration



[argyllcms] Error with new i1 Display Pro revision – argyllcms – FreeLists
[argyllcms] Error with new i1 Display Pro revision. From: François Simond ; To: argyllcms@xxxxxxxxxxxxx; Date: Fri, 9 Oct 2015 02:29:27 +0200. Hi Graeme and the list! I’m assisting a friend with his brand new X-Rite i1 DisplayPro, which has a new revision and firmware.

Source post on Google+

This is a 3D visualization of Nexus 10 display color response compared to a reference Gamma 2.2, Rec.709 color space

Nexus 10 display gamut is small, so it doesn't cover the whole cube.
Due to the nature of its the blue primary, some colors would be outside the cube so I clipped them in this graph.

It's also the demo of a new tool that will help me greatly visualize measurement, calibration and correction data 🙂

#supercurioBlog #color #display #measurements #development

    

In Album 2015-05-16

Source post on Google+

Experimenting with tri-dimensional interpolation methods for sparse data:

This one is not fit for the job it seems, especially since the input data will often be only 6x6x6.
I'm probably gonna need a more linear than cubic interpolator here.

That's Apache Commons Math TricubicInterpolator, comparing 64x64x64 reference output with interpolated input from 2x2x2 to 16x16x16 sizes.

#supercurioBlog #color #development

              

In Album 2015-05-13

Source post on Google+

I started implementing an Android system driver using the GPU for color correction and calibration

I already hit some limitations here and there (being well known by game developers) but am confident in the possibility to find solutions to get satisfying performance and results on all OpenGL ES 3.0 devices and most GL ES 2.0 ones as well.

And here's something to show you!
In my last post, I mentioned how exciting it was to not be limited to 8-bit per channel precision, which is a tough compromise when correcting displays because it means you introduce banding.
Yesterday's post: https://plus.google.com/+supercurioFrancoisSimond/posts/Dv7JzLAP5ev

In these graphs, there's a Nexus 5 running the driver in development which naively divides RGB values per 10 which makes the output much darker.
At 100% brightness: it hits 3 cd/m², for a contrast ratio as low as 10:1.

See for yourself the result of changing colors on 8-bit, vs what can be done by creating those intermediary tones that the display hardware, a 8-bit panel cannot produce.

Image 1 and 3: 8-bit
Image 2 and 4: same 8-bit, same content but but simulating the intermediary colors using GPU post-processing.

I didn't expect such extraordinary results, but it's real 🙂

#supercurioBlog #calibration #display #color #development

   

In Album Better than 8-bit per channel precision

Source post on Google+