<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Recent changes to requested features</title><link>https://sourceforge.net/p/sk-blade/wiki/requested%2520features/</link><description>Recent changes to requested features</description><atom:link href="https://sourceforge.net/p/sk-blade/wiki/requested%20features/feed" rel="self"/><language>en</language><lastBuildDate>Wed, 17 Oct 2012 21:49:30 -0000</lastBuildDate><atom:link href="https://sourceforge.net/p/sk-blade/wiki/requested%20features/feed" rel="self" type="application/rss+xml"/><item><title>WikiPage requested features modified by Ender Tekin</title><link>https://sourceforge.net/p/sk-blade/wiki/requested%2520features/</link><description>Requested Features and Other Improvements
-----------------------------------------
Here is a list of features that we would like to add/implement. Please feel free to contribute code to tackle some of these issues.

###Key Features:
* Decoders for symbologies [UPC-E](http://en.wikipedia.org/wiki/Universal_Product_Code#UPC-E) and [EAN-13](http://en.wikipedia.org/wiki/Universal_Product_Code#EAN).
* Multi-resolution localization: 
    *The current localization parameters works best for QVGA resolution, and to provide real-time feedback on a mobile device, VGA resolution videos are subsampled to QVGA for localization purposes (decoding is still performed at VGA resolution, and is much faster).
    *Localization is performed assuming a longer (e.g. UPC-A barcode), to reduce the rate of false positives (such as parallel lines of text, etc.), since we cannot assume a visually impaired user is pointing the camera accurately at a barcode. To detect shorter barcodes, such as UPC-E, it may be necessary to go back to full resolution for counting edges (maybe sacrifice some speed).
* Screenreader compatibility: The clients currently access text-to-speech directly to provide speech feedback. While the desktop client also provides the output as text in a shell window that a screenreader should pick up, the same is not true of DroidBLaDE. It needs to check for screenreader availability, and if one is available, dump the output on a view that the screenreader may then capture and play back at the user's preferred settings.
* iOS client: An iOS version of DroidBLaDE would serve more visually impaired users.
* Windows client: Should be rather straightforward other than figuring out direct audio card access to provide real-time audio feedback.
* Desktop clients should not need OpenCV: OpenCV is primarily used for input/output, which can be accomplished using other available and smaller libraries, such as ffmpeg.
* Ability to add your own barcodes: Should be simple to add a private database that the user can add to, and is searched before going online. It may be a good idea to add looked up products to a separate database (like caching) to increase the speed of product identification (and not rely on a continuous data connection) for products that the users may commonly be using BLaDE to identify.

</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ender Tekin</dc:creator><pubDate>Wed, 17 Oct 2012 21:49:30 -0000</pubDate><guid>https://sourceforge.net40b77e6c75a9369d96d09384687c74608564d021</guid></item></channel></rss>