So I’ve finally figured out what bothers me about 3-D entertainment (and no, it’s not that all of it sucks post-Captain Eo … although that is true….).  It’s focus.  In 2-D photography and cinematography, depth-of-field creates a sense of depth, naturally, by having the foreground in focus and the background gradually more and more out-of-focus as it recedes.  But it’s a bit of a trick; we can look directly at part of the out-of-focus image, and it stays out-of-focus.  Unfortunately, this is not how our eyes actually work in real life.  In real life, our eye automatically re-focus on everything we look at, meaning when we look at a scene, in a certain sense, everything appears in-focus.  Our sense of three-dimensionality comes from being physically present in the 3-D environment, and the depth perception of using two eyes to look at it. But when we focus on what’s in the foreground, we do actually lose focus on the background.

3-D movies mess with those independent senses; if there is shallow depth-of-field, we can look at part of the image and it stays out of focus, but still feels 3-D because of depth cues caused by the high-tech magic of the imagery.  If there is deep focus, we don’t have that screwyness, but we’re limited to the odd camera lenses  (often wide-angle) that produce deep focus, or very peculiar lighting to cater to the more stringent aperture requirements.  Either way, that stops looking natural after a few hours.  Citizen Kane is all peculiar photography, but you can’t watch everything shot that way.

In short, I guess you can count me among those who really thinks 3-D  “looks cool” to the eye because it’s so UNnatural.  So it’s novel, yes, and impressive, perhaps, but I’ve never thought it made anything look better.

Comments(0)

Dear Interwebs,

Is this possible?  I’d like to create a mouse-deformable elastic SVG image.  In other words, the user can click anywhere inside the image and drag the mouse around, and in response the object(s) underneath the cursor would be stretched in the direction of mouse movement, as if they were rubber sheets.  The clincher is elasticity — I’d like the distorted objects to animate back to their original shape on mouseUp or loss of focus.

I’ve been reading up on SVG animation docs last night and this morning, but I haven’t found any actual examples that come close to what I’m talking about.  Most of the tutorial sites deal with primitives (and justifiably so, of course), and this concept clearly involves  different stuff … restoring original positions of the nodes, etc.  Got any help?

Thx!

Comments(0)

Are you a satisfied OpenStreetMap user? You should be; OSM has user-generated and user-maintained data, and provides a service equal to that proprietary software companies have been charging exorbitant rates for … based solely on the scarcity of the free, public information at the service’s core.

Which got me to thinking about real-time traffic data.  The situation is exactly like the pre-OSM map situation: the “data” is public and free, and consumers have to pay to see it because there is no free alternative.  Ripe for change.

It’s a complicated subject, but in broad strokes there are two major ways to determine traffic information: listen to public Traffic Message Channel (TMC) information on the radio, and aggregate individual user motion culled from participating GPS devices on-the-road.

TMC is a form of Radio Data System (RDS) broadcast and is a published standard. RDS is a sideband of FM radio, and is also used to broadcast song titles by participating FM stations, emergency alerts, and a few other information types. The trouble is that so few devices pay attention to the RDS channel — only a handful of car radios do, and expensive in-vehicle navigation systems do, and that is about it. So the free RDS-TMC data is flowing right past all of us, doing no good.

Making use of it means getting it into the computer, and that seems to have some prerequisites: first, an FM tuner; second, that FM tuner must provide raw access to the antenna, not something hardware-converted directly into a stereo audio stream; third, something to decode the RDS-TMC data stream itself; and fourth, a database to look up the highly-abbreviated hexadecimal TMC messages and convert them into useful stuff like place names.

As near as I can tell, there is exactly one GPL software package capable of reading RDS: srdsd. Unfortunately, it is built to be hooked up to external tuning equipment, perhaps because the authors are as interested in RDS encoding as decoding. There are a few hardware adapters out there specific to RDS, bluetooth and USB, but they are all from one company, GNS, and naturally there are not free drivers. So the big question is how many FM tuners in Linux boxes can actually receive RDS signals?

Scratch that; a better question is how many FM tuners in cell phones can receive RDS signals? Supposedly many can, and suposedly many GPS devices are also capable of RDS decoding, but so far I have not turned up a definitive list.  Apparently some HTC devices can, because there is a shareware project to support them. The Dash Express and TomTom dashtop devices have RDS-TMC built-in or available as add-ons.

Anyway, to sum up, here is what I think would be required to build a crowd-sourced free traffic data source: daemons running on mobile (or desktop) devices that receive RDS-TMC data from nearby FM transmissions, and report what they hear to the central database. Of course, each device can utilize the local data for its own routing purposes; the aggregation would benefit users who don’t have a device and assist in route planning by showing a broader picture. The good news is that “real time” data here is far slower than with GPS tracking; on the scale of one update every few minutes, let’s say. Stationary devices could participate, too, since relaying the information is helpful to everyone even if you yourself are not on the move.

Unfortunately, I have no idea how many FM or GPS devices are out there that can pick up RDS-TMC, so I can’t even begin to speculate on what the coverage would be like. It would require each device owner to run specialized (albeit unobtrusive) software on their device. The other big option would be to have GPS-capable devices simply phone in their position and speed (anonymously, hopefully), then aggregate that.  Far more devices could participate, no RDS-TMC drivers or decoding needed, but it would still involve widespread participation to provide meaningful traffic updates.

Any thoughts?

Comments(0)

I’m busy. And like everyone and his brother (although not my brother), I’ve read David Allen’s Getting Things Done (GTD) and thought about how his organizational theories might line up with the way I work.  If you’re uninitiated, GTD is a collection of methods and tidbits that Allen says are better for keeping your projects organized and your head clear than the old-fashioned alternatives.  It has quite a following, and I like a fair number of the informational nuggets inside.

The trouble is implementing GTD in software — there are a zillion and a half software solutions, all of which are single-purpose, incompatible with each other, and walled data gardens.  Most are not even cross-platform, nor do they support networked backends, meaning you must keep duplicate copies of your info and worry about syncing it. I’ve learned to dislike such solutions for personal data — I want my personal wiki to be available to me wherever I am, I want my addressbook available on every device where I might need to call, email, or send an IM, etc.  So I don’t want my GTD projects sealed in a single-purpose app on one computer.

I have found a GTD Web app that I like quite a bit: Tracks.  It is free software (of course), it is simple in its interface, and it provides output data in a lot of useful formats — including iCalendar feeds. I can access and update Tracks from desktop Linux, Mac, Blackberry, Maemo, and Symbian platforms — all of which I use regularly. The only trouble is that it produces read-only feeds, meaning it does not integrate into any of the available calendaring apps. That would be too easy.

But more importantly, looking at Tracks got me thinking about how to represent GTD information in a standard format. Since it is essentially calendar scheduling and to-do management on roids, the best fit of any RFC’ed standard is VTODO.  Lots of calendaring apps already support VTODO, although in most it takes a back seat to VCALENDAR.

The question is how to represent GTD’s unique ideas in VTODO. As a refresher, the important concepts in GTD are that you track “next actions” — single-step to-dos that are more easily managed and attacked than large-scale projects.   But you also keep track of projects as a whole, and you sort your next actions by context — at home, in the garage, calls to make, emails to send, etc.

Though individual VTODO tasks are a natural fit for next actions, how to map projects and contexts is not as clear.  VTODO has 33 defined properties (although two of them are mutually exclusive, if I read correctly).  Some are basic (description), some are calendar-like (duration), some computery (geolocation), some Exchange-like but potentially useful (attendees).

The “categories” property seems to be the only real option for GTD incorporation — but is it better used as a “project” field or as a “context” field? Whichever you choose, the other field will have to be represented some other way, perhaps as an iCalendar calendar. That is because VTODO items must belong to an iCalendar; they cannot be separate. Thus you cannot just have a single calendar for all of your GTD items. You could have one calendar for each context, and within it use VTODO “categories” for each project, or you could have one calendar for each project, and use the VTODO category to denote the context associated with the action. Which is better?

At first glance, it seems like one calendar per context is better; contexts are less transient than projects, and if you wanted to make certain contexts available only on certain devices, the calendar subscription method makes that possible.  What doesn’t work so well is that most calendaring apps don’t pay much attention to “categories” support — predefined categories are always trite alternatives like “work” and “birthdays,” you cannot create new categories from within the task manager, you cannot vary display colors on the basis of category, and so on. You are also supposed to be able to assign multiple categories to a VTODO task, but that is also unsupported in the client apps I have tried — Thunderbird, Chandler, Evolution, probably some more….

In fact, as I am typing this entry right now, I’ve discovered that I cannot open and edit existing tasks in Thunderbird/Lightning.  I can right-click and access menus for progress, priority, and calendar, but progress and priority are grayed out.  I certainly can’t change the due date, location, or status.

I guess the ultimate question is why are there so many single-purpose GTD silo apps out there, while our existing calendar applications need so much work on task support. Am I missing something? Is there a killer task-supporting calendar out there?

Comments(0)

Way, way back in aught 7, I wrote this rarely-read piece about the trials of converting the legacy PhotoCD (.pcd) format into something useful on a modern day computing machine.  The principle problem was that since no new files were being produced in .pcd format, the knowledge of how to correctly decode them was slowly beginning to atrophy, even though the spec was open and the source code to tools like ImageMagick was open as well.

Just last week, I received an email from Ted Felix, the PhotoCD decoding ninja who did all of the groundwork for the applications I mentioned in the original article. Since the piece has gone into read-only archive mode following the transfer of Linux.com from SourceForge to the Linux Foundation, I’m posting the info Ted sent to me here, instead.

The news is the launch of a new command-line tool called pcdtojpeg. Pcdtojpeg appears to use Ted’s luminance look-up-table (LUT), which correctly converts from .pcd’s weird PhotoYCC color model to standard sRGB without blasting out the highlights. I haven’t used it yet to report on any other fancy features, but it’s good to see work in this area continue.  I only wish it were pcdtotiff….

Comments(0)