I am trying to make sure that the classification, training process and the model is hidden while used in browser. I have found that wasm is kind of binary format for web browser to execute. Can I use wasm?
Is there a way in tensorflow or in js to hide my training or classification algorithm and pre-trained model?
Is there any other framework supporting it?
There is currently not yet a good way to simultaneously run your TFJS model in a users' browser, and also keep your model secret. If model privacy is a design constraint, you will need to either do some sever-side computation, or invent some other solution.
https://github.com/tensorflow/tfjs/issues/239
An update for those who still wonder about this issue: Tensorflow.js now utilizes WebAssembly under the hood. As noted above, this does not mean your code is inaccessible. Cloistered, obfuscated & unfriendly yes, yet the determined user can still capture, de-compile, & analyze that code. Granted, few users have both the capability & motivation to do so, but it's a big world out there...
I'm currently building a texture classifier in the c++ api of opencv. I was looking to use this to recognise textures and ideally help a parot ar drone 2.0 to navigate to a specific texture. I have found the documentation on node copter and it's opencv bindings. I wasn't sure about whether this would require me to re write my program in javascript?
If there is some sort of interface then is it feasible to run my program in the background, pull images from the parrot analyse them and send back control commands to the parrot?
I have been working with opencv for about 3 months and have some basic understanding of node.
Thanks in advance!
There are lots of ways to interface with a Parot AR drone. NodeCopter is one option, but there are others. ROS has good AR drone bindings I've used which would give you tons of flexibility at the expense of some complexity.
You might also consider building your C++ program into a stand-alone option and calling it from Node.js. You could also interface with the AR Drone API directly.
It's not too hard to write a program to control an AR.Drone with some sort of OpenCV-based tracking. Javascript would probably be my suggestion as the easiest way to do that, but as #abarry alluded, you could do it with any language that has bindings for the AR.Drone communications protocol and OpenCV.
The easiest thing would be to have a single program that controls the drone, and processes images with OpenCV. You don't need to run anything in the background.
copterface is a Node.js application that uses node-ar-drone and node-opencv to recognize faces and steer the drone toward them. It might be a good starting point for your application.
Just to give an example in another language, turboshrimp-tracker is a Clojure application that shows you live video from the drone, lets you select a region of the video containing an object, and then tracks that object using OpenCV. It doesn't actually steer the drone toward the tracked object, but that would be pretty easy to add.
I am new to computer programming and have some experience programming with python. I am thinking of developing a program that does physics simulations (projectiles, circular motion, damped simple harmonic motion systems etc.) as a hobby project. I would like to write the program that it could be run by a non-technical user(my fellow students) on a variety of platforms (mac, windows etc.) without any setup and python doesn’t seem to be a good option for building such a program so I am looking for an alternative. JavaScript has caught my attention, as it seems to be quite powerful on modern browsers, especially in conjunction with HTML5. I would like to know whether it is suitable to use JavaScript for this type application, and some information as to where I should start (I have no JavaScript knowledge)
Thanks in advance!
Yes I did have a look at the similar threads on the site but I want write something by myself than using a 3rd party library (other than for the frontend, if possible) :)
What is actually your question? :)
Can you write a physics simulation in Python?
Yes, of course.
Can you write a physics simulation in Javascript?
Yup.
Will it be useful?
Yes, probably.
Will it be efficient?
Not as efficient as an implementation with C, to be sure. But for small-scale simulations should you should have quite enough power with current JIT javascript interpreters. Tens or hundreds of objects on 30fps looks like a safe approximation, I think.
Can you make use of modern HTML when writing a physics simulation in JS?
The simulation and the display are two different things, but yes, if you want to make a graphics frontend to your simulation, the modern features of HTML and CSS could be certainly useful. But if you write it in any other language, you still have nice choices for visualization.
How to learn JavaScript?
There's plenty of tutorials online, but I don't know any particular one to recommend; perhaps anyone else can fill for me here.
As mentioned by Kos languages that are as High Level as Python or Javascript might constrain you. But later on you can still move critical parts to C-Code. (-> Regular shared Library or even Browser-Plugin)
For JavaScript I recommend you the Mozilla tutorials: https://developer.mozilla.org/en/javascript
Check out the "JavaScript Guide" in particular and keep in mind that not every Browser supports JavaScript 1.7. By the way, you should also checkout jQuery. Actually it might be easier to start right off with jQuery because you need some highlevel library anyways.
By the way: You might also want to check out Processing. (www.processing.org) It might be perfect for you as you are new to programming and it has a lot of awesome vizualization features. It basically a simplified Java with a very easy to use library. You can checkout the pre-installed examples and start playing around. Be sure to check the Reference on the website / the forum if you are stuck with problems. Processing runs on the JVM and is therefore cross plattform.
I recommend Processing very much because you can directly see results and in any case it might be interesting for Prototyping even if you think of using another language in the future to suit your needs.
Actually there is even a JavaScript version of Processing though I never used it...
EDIT: If you plan to choose JavaScript, you should use Firefox in combination with Firebug. It makes life easier when debugging...
I am planning to build a web application highly based on Google Maps API. I am considering either using the Javascript version, or the Flash version. I would like to create an interface which will be quite rich. Should I go for JS version of the API or Flash one? Also I do not plan to purchase Flex Builder, so ideally I would like to use some free Flex SDK that supports ActionScript. What would you recommend? Is it more reasonable to use JS or maybe better use the Flash Version. What are the limitations, pros and cons?
The advantages of Flash:
Fully cross-browser/cross-platform.
Write once, run everywhere (except
iPhone & iPad).
Virtually same syntax
as Javascript, only with class-based
OOP, strong data-typing, etc.
Very fast UI effects (high frame-rate, etc.), much faster than JS/HTML5, way less CPU usage
Disadvantages:
Steve Jobs hates it.
Hey, I've built apps using both the Flash and the JavaScript version of the Google maps API. I find that there's not too much difference between the actual API itself. However, I find that creating apps with the Flash/Flex version is much easier because you get a real component based environment to build your app. In my opinion this leads to much cleaner code and maintainable applications whereas the JavaScript applications tend to get messy.
I do not know how it is to develop Flex apps without the FlashBuilder but I guess it's doable. In the end it's a good investment.
Go for Flex....
Fully cross-browser/cross-platform.
You can find a lot of articles and support.
Coding wise its strict and neat compared to JavaScript which is loosely typed language.
You can find a lot of custom components and third party API's which can bring more rich look and feel as well as high usability.
With the increased power of JavaScript frameworks like YUI, JQuery, and Prototype, and debugging tools like Firebug, doing an application entirely in browser-side JavaScript looks like a great way to make simple applications like puzzle games and specialized calculators.
Is there any downside to this other than exposing your source code? How should you handle data storage for this kind of program?
Edit: yes, Gears and cookies can be used for local storage, but you can't easily get access to files and other objects the user already has around. You also can't save data to a file for a user without having them invoke some browser feature like printing to PDF or saving page as a file.
I've written several application in JS including a spreadsheet.
Upside:
great language
short code-run-review cycle
DOM manipulation is great for UI design
clients on every computer (and phone)
Downside:
differences between browsers (especially IE)
code base scalability (with no intrinsic support for namespaces and classes)
no good debuggers (especially, again, for IE)
performance (even though great progress has been made with FireFox and Safari)
You need to write some server code as well.
Bottom line: Go for it. I did.
Another option for developing simple desktop like applications or games in JavaScript is Adobe AIR. You can build your app code in either HTML + JavaScript or using Flash/Flex or a combination of both. It has the advantage of being cross-platform (actually cross-platform, Linux, OS X, and Windows. Not just Windows and OS X).
Heck, it may be the only time in your career as a developer that you can write a web page and ONLY target ONE browser.
SproutCore is a wholly JavaScript-hosted application framework, borrowing concepts particularly from Cocoa (such as KVO) and Ruby on Rails (such as using a CLI generator for your models, views and controllers). It includes Prototype, but builds plenty of stuff such as sophisticated controls on top of that. Its Photos demo is arguably impressive (especially in Safari 3.1).
Greg already pointed you to Gears; in addition, HTML 5 will come with a standardized means of local storage. Safari 3.1 ships with an implementation where you have a per-site SQLite database with user-settable size maximums, as well as a built-in database browser with SQL querying. Unfortunately, it will be a long time until we can expect broad browser support. Until then, Gears is indeed an alternative (but not for Safari… yet!). For simpler storage, there is of course always cookies.
The downside to this would be that you are at the mercy of them having js enabled. I'm not sure that this is a big deal now. Virtually every browser supports js and has it enabled by default.
Of course the other downside would be performance. You are again at the mercy of the client handling all the intensive work. This also may not be that big of a deal, and would be dependent on the type of app you are building.
I've never used Gears, but it looks like it is worth a shot. The backup plan would be to run some server side script through ajax that dumps your data somewhere.
Not completely client side, but oh well.
Nihilogic (not my site) does a lot of stuff with Javascript. They even have several games that they've made in Javascript.
I've also seen a neat roguelike game made in Javascript. Unfortunately, I can't remember what it was called...
If you want to write a standalone JavaScript application, look at XULrunner. It's what Firefox is built on, but it is also built so that you can distribute it as an application runtime. You will write some of the interface in JavaScript and use JavaScript for your code.
Gears might provide the client-side persistent data storage you need. There isn't a terribly good way of not exposing your source code, though. You could obfuscate it but that only helps somewhat.
I've done simple apps like this for stuff like a Sudoku solver.
You might run into performance issues given that you're completely at the mercy of the client's Javascript interpreter. Gears would be a nice way of data storage, but I don't think it has penetrated the market that much. You could just use cookies if you're not fussy about that kind of thing.
I'm with ScottKoon here, Adobe AIR is great. I've really only made one really nice (imho) widget thus far, but I did so using jQuery and Prototype.js, which floored in such wonderful ways because I didn't have to learn a whole new event model. Adobe AIR is really sweet, the memory foot print isn't too bad, upgrading to a new version is built into AIR so it's almost automatic, and best of all it's cross-platform...they even have an alpha-version for Linux, but it works pretty well already on my Eee.
Standalone games in GWT:
http://gpokr.com/
http://kdice.com/
In regard to saving files from a javascript application:
I am really excited about the possibilities of client-side applications. Flash 10 introduced the ability to create files for save right in the browser. I thought it was super cool, so I built a javascript+flash component to wrap the saving feature. Right now it only works for creating text based files (vcard, ical, xml, html, css, etc.)
Downloadify Home Page
Source Code & Documentation on Github
See It In Use at Starter for jQuery
I am looking to add support for non-text files soon, but this is a start.
My RSS feeds have served me well- I found that Javascript roguelike!
It's called The Tombs of Asciiroth.
Given that you're going to be writing some server code anyway, it makes sense to keep storage on the server for a lot of domains (address books, poker scores, gui configuration, etc.,.) For anything the size of what you'll get in Webkit or Gears, you can probably also keep it on your server.
The advantage of keeping it on your server is two-fold:
You can integrate it fairly simply as a Model layer in a typical MVC framework, and,
Users get a consistent view without being tied to their browser/PC, or in a less-than-ideal environment (Internet Cafés).
The server code for handling this can also be fairly trivial, particularly if it's written with this task in mind, so it's not a huge cognitive burden.
Go with qooxdoo. They recently realsed 1.0, although most users of it say it was ripe for 1.0 at least two versions ago.
I compared qooxdoo with YUI and ext, and I think qooxdoo is the way to go for programmers - YUI isn't that polished as qooxdoo, from a programmer's point of view and ext has a not so friendly licensing model.
A few of the strong points (for me) of qooxdoo are:
extremely clean code
the nicest OO programming model I've seen among Javascript frameworks
an extremely rich UI widget library
It also features a test runner for unit tests, an API doc generator and reader, a logging facility, and several useful features for debugging, grouped under something called Inspector.
The only downside is that there aren't readymade themes (something like skins) for qooxdoo. But creating your own theme is quite easy.