xiphmont

Color Calibrating the W701 under Linux (...and probably the W700, W510, etc too...)

"Whaaaat?" you say, "dispcal works just fine with the W701's built-in calibrator under Linux." Well, it should...

Problem is, the BIOS shuts off the LCD when you close the lid. I've not found a user-exposed LCD or backlight control in Linux, sysfs or otherwise, that does a gosh-darned thing when the lid is closed. I'm not aware of anyone else who's found one either. If someone out there knows of an existing software interface, please let me know!

Until I find the 'correct' software solution, there's an easy hack to make it work:

The W701's lid sensor is on the status led board to the right of the suspend indicator. A stainless steel ruler placed between the hinges blocks the magnet in the base, preventing the lid switch from turning off the LCD. TADA! Dispcal et. al. can do their magic.

(Aluminum and austenitic stainless steel won't work. A magnet has to stick to it. Fortunately the cheapy stainless rulers sold by e.g. Staples and Michaels fit the bill nicely.)


xiphmont

This is the wrong tool, but it feels so right

The little handheld spectrometer I've been using for LED and color matching work, aside from being something of a toy, is intended for lighting applications, that is, for very bright light (e.g., it's rated to be pointed directly into the sun) with a wide field of view. Screen evaluation requires low light sensitivity in a narrow field.

Sometimes two pounds of optical glass is easier and cheaper* than the 'right' tool.

*$19 for two 3" condenser lenses from Anchor Optics. Anchor is awesome.


xiphmont

Design to double precision...



...measure with ruler, mark with Sharpie, cut with utility knife, assemble using foamboard and hot glue.


xiphmont

The most recent project hits a Yak-shaving milestone...

There are so many posts that need to come out of this one...

I ordered a whole bunch of Chinese LED conversion kits. I tried lots of ways to mod them to work on Thinkpads, all of which worked... though many turn out not to work well enough, so don't use the mods on those pages for now :-(



Dissatisfied with all offerings, I designed and have been testing my own LED driver boards....



The LED strips that came with the Chinese kits all had terrible color rendering (low temperature, greenish, or both) on the spiffy AFFS screens the X61T is known for.



...so that's sucked me into the world of spectrometers, reverse engineering the protocols to use them on Linux (oh, yeah, I need to publish that), binning leds by hand with a makeshift integration chamber...



...and then of course all the software needed to take the SPD data from the assembled system and interpret the color data, then plot it, which I just finished today!



That contrast measurement is too low and I know why, the sensor is too close and unbaffled, so it's picking up IPS glow. Time for measurement jig rev 2....


xiphmont

libvpx 1.4.0 ("Indian Runner Duck") officially released

Johann Koenig just posted that the long awaited libvpx 1.4.0 is officially released.

"Much like the Indian Runner Duck, the theme of this release is less bugs, less bloat and more speed...."


xiphmont

Today's WTF Moment: A Competing HEVC Licensing Pool

Had this happened next week, I'd have thought it was an April Fools' joke.

Out of nowhere, a new patent licensing group just announced it has formed a second, competing patent pool for HEVC that is independent of MPEG LA. And they apparently haven't decided what their pricing will be... maybe they'll have a fee structure ready in a few months.

Video on the Net (and let's be clear-- video's future is the Net) already suffers endless technology licensing problems. And the industry's solution is apparently even more licensing.

In case you've been living in a cave, Google has been trying to establish VP9 as a royalty- and strings-free alternative (new version release candidate just out this week!), and NetVC, our own next-next-generation royalty-free video codec, was just conditionally approved as an IETF working group on Tuesday and we'll be submitting our Daala codec as an input to the standardization process. The biggest practical question surrounding both efforts is 'how can you possibly keep up with the MPEG behemoth'?

Apparently all we have to do is stand back and let the dominant players commit suicide while they dance around Schroedinger's Cash Box.


xiphmont

NetVC BoF and a roundup of things IETF

In case folks hadn't heard the good news from IETF92 in Dallas, hums from the NetVC BoF indicated consensus for forming a NetVC working group. It's now up to the IESG to formally approve or nack formation. Should the working group be formally approved, we'll obviously submit Daala as one of the inputs to the development and standardization process.

The articles above are a good summary if a bit overly Daala-centric. It's unlikely that the final codec will be 'Daala', much as the IETF work on Opus drew from our codec CELT, but also drew from other contributors, most notably the SILK codec from Skype. We hope and expect to see substantial input from other participants (such as Cisco and Google).

As a parting mention, any IETF followers or insiders who haven't yet seen ietfmemes are missing their recommended daily allowance of realtime insider process backchannel snark :-)


xiphmont

Daala Blog-Like Update: Bug or feature? [or, the law of Unintentionally Intentional Behaviors]

Codec development is often an exercise in tracking down examples of "that's funny... why is it doing that?" The usual hope is that unexpected behaviors spring from a simple bug, and finding bugs is like finding free performance. Fix the bug, and things usually work better.

Often, though, hunting down the 'bug' is a frustrating exercise in finding that the code is not misbehaving at all; it's functioning exactly as designed. Then the question becomes a thornier issue of determining if the design is broken, and if so, how to fix it. If it's fixable. And the fix is worth it.

[continue reading at Xiph.Org....]

Tags: ,

xiphmont

Relocated to Mountain View

For the next few months, I'm spending most of my time in Mountain View at the main Mozilla office in order to be closer to most of the rest of the Daala team. For now the plan is to be here through middle of June.

This isn't a permanent move, at least I'm not currently planning it to be. I intend to return to Somerville in the middle of June. But for now, I'm local to the other codec and FOSS hackers out in Silly Valley!

xiphmont

A Fabulous Daala Holiday Update

Before we get into the update itself, yes, the level of magenta in that banner image got away from me just a bit. Then it was just begging for inappropriate abuse of a font...

Ahem.

Hey everyone! I just posted a Daala update that mostly has to do with still image performance improvements (yes, still image in a video codec. Go read it to find out why!). The update includes metric plots showing our improvement on objective metrics over the past year and relative to other codecs. Since objective metrics are only of limited use, there's also side-by-side interactive image comparisons against jpeg, vp8, vp9, x264 and x265.

The update text (and demo code) was originally for a July update, as still image work was mostly in the beginning of the year. That update get held up and hadn't been released officially, though it had been discovered by and discussed at forums like doom9. I regenerated the metrics and image runs to use latest versions of all the codecs involved (only Daala and x265 improved) for this official better-late-than-never progress report!
Tags: ,

You are viewing xiphmont