Int13 is working to redesign their website to set the focus on augmented reality games & applications.
Their first game, ARDefender is a simple yet very innovative game based on a new technology known as Vision Based Augmented Reality.
It uses the camera of the iPhone to blend the game world and the real world for a truly surprising, immersive and fun experience!
Source: http://www.int13.net
Context sensitive product visualization on mobile devices is one, next big step for augmented reality. By integrating products directly into the customer’s environment on a smartphone, the shopping experience will become even more convenient and direct. You can see the final usage setting and make a more confident buying decision. And you know what? Vanija, our Swiss partner has finally done this important step together with their customer Möbel-Pfister Ltd and created the App “Atelier Pfister” for their new Swiss Design Collection! The iPhone App, which was created together with Visualcontext Designer Alain Leclerc von Bonin, the programmers Adrian Nägeli & Reto Senn, Bitforge AG and which contains parts of metaio’s augmented reality software, lets users integrate virtual furniture into their own living environment. You take a picture with your smartphone, integrate, combine and arrange the design pieces – and when you like what you see (because it fits well) – you buy what you see. Do you like what you read?
Images: Home Screen of the app and a screenshot from the AR functionality.
|
|
|
At MAX, Adobe’s worldwide developer conference will announce with its partners their progress to bring Flash support to, between others, BlackBerry handsets. I guess iPhone will be again the black ship of the story… Anyway, an Organization of 50 companies called Open Screen Project created by Adobe to promote the evolution of richer mobile, tv, and desktop browsing experiences, by giving the welcome to BlackBerry, will achieve 19 out of 20 mobile handset top manufacturers.
Adobe is also announcing support for HTTP streaming and several new mobile-ready features, including multi-touch, gestures, accelerometer, and screen orientation.
Flash Player 10.1 is the first consistent browser-based runtime from the Open Screen Project that offers browsing of Flash-based web apps, HD video, and other content on smartphones, netbooks and other Internet-enabled devices.
Flash support is also expected for several other mobile platforms, including Google Android, Symbian, Palm webOS, and Windows Mobile. A public developer beta will be available for Windows Mobile, webOS, and desktop operating systems before the end of the year. A public developer beta for Android and Symbian should be announces early in 2010, with general availability and publicly available devices coming in the first half of 2010.
That sounds great for AR mobile development! Just to let you know that Adobe is also interested in FLARToolkit, watch this Augmented Reality presentation for MAX 2009: http://max.adobe.com/MAXar/
So it sounds like sooner than later we will be delivering FLAR experiences on mobiles -Probably using also gyro, accelerometer and GPS-.
via: http://www.readwriteweb.com/archives/author/jolie-odell.php
The nascent field of Mobile Augmented Reality (AR) is on the verge of becoming mainstream. In recent months an explosion in the development of practical AR solutions has given consumers numerous AR applications to experience and “augment” their daily lives. With this surge in AR development the potential arises for the multiplication of proprietary methods for aggregating and displaying geographic annotation and location-specific data. Mobilizy proposes creating an augmented reality mark-up language specification based on the OpenGIS® KML Encoding Standard (OGC KML) with extensions. The impetus for proposing the creation of an open Augmented Reality Markup Language (ARML) specification to The AR Consortium is to help establish and shape a long-term, sustainable framework for displaying geographic annotation and location-specific data within Augmented Reality browsers.
In addition to proposing the ARML specification to The AR Consoritum, Mobilizy will be presenting an overview of the ARML specification at the Emerging Technologies Conference @MIT, Boston, and at the Over The Air Event held at Imperial College in London. An introduction to the ARML specification is available here: http://www.openarml.org
“Mobilizy has taken a very exciting giant step forward in proposing one of the first specifications for the commercial augmented reality sector” says Robert Rice, Chairman of the AR Consortium and CEO of Neogence Enterprises. “Companies are beginning to turn away from the novelty and focus on building an industry.”
The purpose for establishing an open ARML specification is to assure all data that is created for augmentation in the physical world could be universally accessed and viewed on any augmented reality browser. ARML allows individuals and organizations to easily create and style their own AR content (e.g. points of interest) without advanced knowledge of AR, APIs or tools. The ARML specification is analogous to HTML for the Web, which is used for creating web-pages and web-sites.
Features of the proposed ARML specification 1.0 include:
Additionally all content created using the ARML specification can be also viewed on other KML based viewers such as Google Earth without any modification. For Mobilizy, proposing the ARML specification is a logical step to assure cross-platform exchange of context-aware, location-based, real time data within an AR experience.
Mobilizy understands ARML as a natural evolutionary process to open AR for the entire world. We believe that open standards and open interfaces are a key to success for Mobile AR initiatives. Mobilizy’s strategy is to build a complete AR eco-system for context-sensitive, location aware, real time data exchange in conjunction with a compliant browser that includes interfaces to social bookmarking services, search engines and directories.
Mobilizy GmbH is offering limited access to the preview version of our upcoming ARML browser. If you are interested to gain early access, or you have questions regarding the ARML specification, please contact us at: arml@mobilizy.com
San Francisco, September 18th 2009 – Today, metaio officially announced the launch date of junaio, its mobile augmented reality platform. On November 2nd, the leading company in augmented reality will release a first version exclusively for the iPhone. More features will be released soon after, including capabilities on the Android and Symbian platforms.
The world as seen through junaio
junaio will change the way we create, access and share information. By combining innovative online and mobile technologies, junaio will allow users to see location-based content through the display of a mobile device. Users can leave traces, messages or objects and visually interact with their friends or anyone else in the world. Already existing web services can be enhanced and completely new ways of interaction can be created. Whether it is social networks, multimedia content or game concepts – virtually anything can be embedded in the real world and connected to a certain place.
“The possibilities are endless, we are taking the Internet outside to the real world,”
says Thomas Alt, Chief Executive Officer of metaio.
Seeing location-based multimedia content through the display of your mobile device is only one part of the story.
“Mobile augmented reality is all about the user´s orientation. But to deliver a really useful and robust application, you have to be user oriented,”
says Peter Meier, Chief Technology Officer. metaio is defining a new dimension in mobile augmented reality through incorporation of features that will allow better usability and social interaction. junaio is the result of more than six years application development in augmented reality and months of research and usability tests for mobile applications. So get ready for the ultimate Outernet experience!
For more information and updates, please refer to: www.junaio.com
Back in November 2008, a group of Japanese coders, working largely under the radar, unveiled a project that redefined many ActionScript developers’ ideas of what the language could do. FLARToolkit, developed primarily by Tomohiko Koyama (aka Saqoosha), introduced augmented reality to the web, and to a large segment of the population as a whole.
FLARToolkit is the latest in a series of ports of ARToolkit, an augmented reality C++ library originally developed by Dr. Hirokazu Kato at the Human Interface Technology Lab at University of Washington. With the advent of ActionScript 3.0, developers like Mario Klingemann and others began experimenting with realtime image analysis techniques for Flash Player. Saqoosha picked up on this, and ported FLARToolkit from NYARToolkit, a Java/C#/Android port of ARToolkit.
FLARToolkit made its biggest initial splash at the hands of North Kingdom, the Swedish interactive agency that developed GE’s SmartGrid augmented reality campaign. Since then, a host of AR applications have made their way to the web via FLARToolkit; the majority of them are variations on the theme of 3D characters dancing on top of live video, or games. As time goes on, however, creative developers will imagine new, creative, and useful applications of the technology. With this in mind, I developed FLARManager.
FLARManager is a lightweight framework that makes building FLARToolkit augmented reality applications easier. When I first came across FLARToolkit, I was simultaneously excited and stymied — there seemed to be so much potential, but it was difficult to use and even harder to understand. Augmented reality is still a long way from maturity, and leveraging FLARToolkit on the ubiquity of Flash Player provides a great opportunity for further exploring its possibilities. FLARManager aims to provide quicker entry to the technology, to allow a focus on new forms of interaction via marker detection and augmented reality.
FLARManager comes bundled with a series of examples and tutorials. Documentation and walkthroughs can be found in the Inside FLARManager section of my blog. The tutorials move from a quickstart through simple 2D and 3D implementations of FLARManager. This article will provide a more detailed look into the process of marker detection and recognition in FLARToolkit, and how FLARManager can improve the accuracy and reliability of those processes via simple configuration changes.
Computer vision in a web context has many inherent difficulties. The main problems arise from a lack of control over the end users’ environmental conditions. Poor or uneven illumination makes software analysis of an image much trickier, and these problems affect FLARToolkit substantially. The last couple of FLARManager releases have focused on functionality that gives developers more control over marker detection and tracking by attempting to mitigate the effects of suboptimal conditions.
Before wading into FLARManager’s settings, it makes sense to begin with a high-level analysis of the process FLARToolkit uses to identify and track markers. The following is my best attempt at understanding the process. Fortunately, FLARToolkit is open source; unfortunately, the minimal comments are all in Japanese (with the exception of those that I added and tagged with ‘SOC:’), and most of the errors the toolkit throws have no information encapsulated within them. If any readers have more insight into the process, please leave comments on this article.
The first step in many computer vision applications that rely on edge detection is to threshold the source image. A binary image is made by changing pixels brighter than a threshold value to one color, and pixels darker than the threshold to another.
Thresholding separates the source image into a binary image, making analysis less computationally expensive.
FLARToolkit’s next step is to find contiguous areas in the thresholded image, speficially within the areas below the threshold (darker areas). Using BitmapData.getColorBoundsRect and BitmapData.floodFill, contiguous areas are ‘labeled’ with unique colors, used later to id the areas.
Each contiguous area of white (corresponding to dark areas of the source image) is 'labeled' with a different color.
With candidates for marker locations, FLARToolkit then proceeds to search the labeled areas for shapes that could be transformed squares (i.e. marker outlines).
Once all marker outline possibilities have been established, FLARToolkit analyzes the areas of the image within the outlines and compares the contents with the list of patterns the developer has asked FLARTookit to detect. FLARToolkit assigns a ‘confidence’ value to all of the matches; matches that are at or above the confidence level specified by the developer are reported as pattern matches.
One of the central design philosophies of FLARManager is to avoid modification to the FLARToolkit source as much as possible. By remaining loosely coupled with FLARToolkit, each project can continue development separately, and FLARManager can theoretically be implemented for other Flash marker detection engines that arrive in the future.
To this end, the opportunities for FLARManager to improve on FLARToolkit’s process are limited. However, FLARToolkit has free access to both the source image that is passed into FLARToolkit, and to the results that FLARToolkit delivers after analysis. These are the areas on which FLARManager focuses.
All of the settings discussed below can be specified either as member variables of a FLARManager instance, or as attributes of the <flarManagerSettings> node in FLARManager’s external xml configuration file. For more information about the config file, please view the documentation.
FLARToolkit uses static thresholding: the threshold value does not change from frame to frame. This causes problems when lighting is variable or dim; these are both often the case for web end-users. Based on some ideas described by Makc and Saqoosha, FLARManager now uses ‘adaptive’ or ‘automatic’ thresholding.
Adaptive thresholding is enabled by default in FLARManager. To toggle it, set adaptiveThresholding to either true or false. When adaptive thresholding is active, the threshold value used by FLARToolkit will be changed semi-randomly whenever no markers are detected. There are two values that can be adjusted to tweak the threshold changes.
The first is adaptiveThresholdingSpeed. This value determines the speed at which the threshold is adjusted every frame. Once markers become absent from the source image, the threshold begins to accelerate away from its current value. If adaptiveThresholdingSpeed is set to a low value (0.0 – 0.3), more gradual changes in the threshold result in an initial lag in marker detection, but a better retention of markers once detected. If adaptiveThresholdingSpeed is set to a higher value (> 0.5), an optimal threshold value may be reached more quickly, but the next threshold change may overshoot the next optimal value. This appears as quicker, but more unstable, marker detection.
The second value is adaptiveThresholdingBias. Rather than completely randomly selecting new threshold values, FLARManager applies this bias to the randomized values, to push the overall direction of change toward lower or higher threshold values. Values for adaptiveThresholdingBias below zero will cause the threshold to trend toward 0, while values above zero will push threshold toward 255. Lower thresholds favor darker environments; higher thresholds work best in brighter environments. adaptiveThresholdingBias defaults to -0.1, as darker environments tend to be more common for viewing web applications than oversaturated environments.
To see the results of your tinkering with adaptive thresholding, set FLARManager.thresholdSourceDisplay to true (note: this cannot be set via the xml config file, it must be set in ActionScript). This will overlay the thresholded image on the source image.
These images show the effects of changing thresholding. The image at far left has a threshold of 120, and the image at far right has a threshold of 0. Optimal threshold values vary with lighting conditions; adaptiveThresholding is designed to automatically seek out the optimal threshold value for every FLARManager application.
The labeling process can be very CPU-intensive, as it has to scour the entire thresholded image for dark areas. In fact, FLARLabeling_BitmapData.labeling is the single most CPU-intensive method in FLARToolkit, even when no markers are detected. This is particularly an issue in darker environments. One technique to mitigate this, suggested by Jeffery Bennett, is to slightly blur the source image before thresholding. This tends to increase the size and decrease the number of contiguous areas to label, resulting in higher performance.
This is where sampleBlurring comes into play. This value determines the amount of blur applied to the source image. Specifically, the BlurFilter uses 2 ^ (sampleBlurring-1) for its blurX and blurY values. (Powers of 2 perform much better than other values for BlurFilters.) Higher values result in faster performance, but because the image is more blurred, also result in worse marker detection. sampleBlurring defaults to 1. Setting to zero will turn this feature off entirely.
These images show the effects of sampleBlurring on marker detection. The image at far left has a sampleBlurring of 0; the image at far right has a sampleBlurring of 4. Notice that the total number of contiguous black areas decreases as we move to the right, but the legibility of the marker's pattern also decreases.
These images show the effects of sampleBlurring on marker detection. The image at far left has a sampleBlurring of 0; the image at far right has a sampleBlurring of 4. Notice that the total number of contiguous black areas decreases as we move to the right, but the legibility of the marker’s pattern also decreases.
Due primarily to inaccurate camera calibration, FLARToolkit has a lot of variability in its reporting of marker outline locations. This seems to be unavoidable, given that the developer has no control over the end user’s camera model, or even settings (e.g. focus and zoom). One remaining option for correcting the resulting jitter is to smooth the results.
FLARManager applies smoothing by averaging detected markers’ positions across a number of frames. This is smoothing. Higher values average across a greater number of frames, resulting in smoother motion and less jitter, but also in less responsiveness. smoothing defaults to 3 frames, which is just enough to remove jitter, but not so much that responsiveness of moving markers is significantly diminished.
FLARManager also provides an interface that allows developers to write and plug in their own smoothing algorithms. Custom smoothing algorithms can be written up as a class that implements the IFLARMatrixSmoother interface, and applied in a given FLARManager application by setting FLARManager.smoother to an instance of that class (this cannot be done via the config xml file; it must be set in ActionScript).
As described in the [labeling] section above, sampleBlurring has an impact on pattern matching: higher values result in faster FLARToolkit performance, but also in poorer marker detection.
Maintaining reliable tracking of a marker once it’s first acquired is not a part of FLARToolkit’s core process, but it’s worth mentioning here that FLARManager has a feature designed to address this. Developers can specify a delay between the time that FLARToolkit loses a marker and the time that FLARManager dispatches a MARKER_REMOVED event, by using markerRemovalDelay. If a marker with the same pattern reappears near the same location it disappeared from, within markerRemovalDelay frames, the MARKER_REMOVED event wil not be dispatched.
Unfortunately, this is an imperfect workaround for an imperfect system. Increasing markerRemovalDelay pretty quickly results in a breakdown of the illusion of augmented reality, as the objects drawn at the marker’s location get left behind when the marker moves quickly. As such, I don’t recommend setting markerRemovalDelay much higher than the default of 1 frame, but some applications may be able to make more use of this than others.
There are a number of improvements still to be done on these features, as well as a slate of additional features to come. One of the trickiest things about working with computer vision is bridging the differences between tracked objects as the computer sees them and as the developer would like to see them. This is FLARManager’s primary role: to round out results generated by FLARToolkit, and provide simple and flexible access to them.
Every new feature that makes its way into FLARManager will continue to be adjustable via the external configuration file and in ActionScript. Since end-user environments in webcam applications vary so much, a core design philosophy of FLARManager is to remain as customizable as possible.
Article borrowed from: http://www.insideria.comA nice CNN article.
(CNN) — Blair MacIntyre imagines a world where tiny clouds of information — Facebook statuses, business cards, Twitter posts — float above all of our heads.
“Augmented reality” can combine live video with data and information from the Internet. In some ways, it’s not that far from reality.
Advancements in mobile phone technology have cleared the way for a coming wave of “augmented reality” applications that merge the physical world with information compiled about people and places on the Internet.
“When the technology gets there, this stuff could be amazingly useful and mildly terrifying in some ways”
Said MacIntyre, an associate professor at the Georgia Institute of Technology who has taught classes in augmented reality for a decade.
The idea of pairing digital information with our real, 3-D environments is not especially new — think robot-human vision in the “Terminator” movies. MacIntyre even plodded about college campuses in the 1990s wearing a 40-pound backpack and nerdy goggles, trying to make something similar happen.
But as mobile phones become better equipped with GPS systems, which use satellites to locate the phones; compasses, which tell the direction the phone faces; and accelerometers, which relay the device’s tilt; the once-lofty idea of augmented reality is being put into the hands of consumers.
In the Netherlands last month, a company called SPRXmobile released a mobile browser, Layar, that lets people see pieces of this new info-reality through their phone screens.
A Layar user sets his or her phone to video mode, aims it around and sees all kinds of information pop up on the screen: blinking dots on apartments that are for sale, the values of those units, pull-down reviews of the bar up on the corner or details about sales at a nearby retail store. Watch a video demo of the app
This makes information easier to find and helps people make better sense of the physical world around them, said Maarten Lens-FitzGerald, co-founder of Layar.
Layar, which bills itself as the first mobile browser that features augmented reality, is only available in the Netherlands and only on certain phones, including Google’s Android, T-Mobile’s G1 and the HTC Magic. But Lens-FitzGerald said the company plans to announce a global expansion plan on August 17 and will develop an app for the iPhone if Apple changes policies that obstruct developers from creating such applications on that device.
A range of other “AR” apps are in development or are on the market. One, called Nearest Tube, highlights subway routes in New York and London. Wikitude is an app that aims to show people encyclopedic information about nearby landmarks. Like Wikipedia, users can add information to the service. The idea could usher in an era of cell-phone tour guides.
But there are doubts about augmented technology on phones.
Lens-FitzGerald, of Layar, is concerned that augmented reality is being over-hyped and may create unrealistic expectations from consumers.
“It’s a cool technology, but yeah, we need to see how much [funding and visibility] our companies will get,” he said. “It’s getting a lot of press now without being proven, but do we make money, are we going to make people happy with it? We don’t know. We’re just starting.”
He added: “It’s like the first TV. We need to build an audience.”
MacIntyre, of Georgia Tech, said the technology behind today’s augmented reality apps is crude. Mobile phone GPS isn’t nearly accurate enough to make sure a Twitter post is tagged to a person, for instance, rather than the lamp post that’s 50 feet away.
Furthermore, the idea behind the information-reality mesh on mobile phones is off-base, he said.
“I don’t see them answering a problem that needs to be solved,” added MacIntyre, who believes two-dimensional maps can be used to display information much more easily with current technology.
More functional problems exist as well. People don’t necessarily want to walk around the world holding cell-phone screens in front of their faces. And the world’s information has to be tagged geographically to make sense in an augmented-reality setting.
But MacIntyre does see a bright future for augmented reality.
Within a year, mobile phone applications will become much more functional, he said, and in the foreseeable future, augmented reality will move off of phone screens and onto futuristic sunglasses, whose wearers will see blips of information about everything around them, he said.
If that happens, the “Terminator” vision will have truly arrived.
Source: CNN By John D. Sutter
Loading ...