If you want to cross-compile OpenCV from source code, you can do by next steps.

1. Building OpenCV 2.1 requiers CMake. You can easily install it by using MacPorts, or follow the installation instructions at the CMake website.

   % sudo port install cmake
   

2. Clone this project from github, then move into the project directory

   % git clone git://github.com/gonzojive/iphone_opencv_test.git
   % cd iphone_opencv_test
   

3. Download the source code for OpenCV from Sourceforge. Save OpenCV-2.1.0.tar.bz2 into the project root.
4. Use the provided Makefile:

   % make
   

This will extract the downloaded archive, apply a patch to the OpenCV code, generate appropriate cmakefile suport using the opencv_cmake.sh script, and finally make the static libraries for simulator and device.  The libraries will be in the opencv_{device,simulator} directories, and may be linked in XCode etc.

I would ideally like to use a $30 webcam to scan books and other products with off-the-shelf open-source software, for use in some inventory management software.  They do make specialized barcode scanner hardware for this purpose, but the computer vision enthusiast in me sees no reason why we should not have a good webcam solution in 2010.

Software that could not recognize these images:

• zxing
• zbar

Software I did not try:

• ruby code that uses Horenetseye

What’s missing from open-source barcode software: science

It seems like the libraries out there now do not use large quantities of data to test out the algorithms and incrementally improve them.  I am talking about a dataset typical in a supervised learning project with thousands of example images with corresponding labels.  In this case, it would be helpful to have two different classes of examples in a dataset.  For each image, it would be helpful to have

1. the pixel coordinates of the corners of the barcode image
2. the barcode value

With this sort of data, we could begin to compare the performance of the barcode libraries out there.  A fairly large dataset could be generated synthetically, or one could be created relatively easily from real-world data as well.  See this thread about using a tex library to generate EAN-13 barcodes.

I don’t have any brilliant insights about how to accomplish great results, but one thing I have noticed is that no library seems to make use of the english characters printed at the bottom of EAN barcodes.  This could probably be used in conjunction with the barcode data to further improve results, since OCR software is super accurate these days.

An update is coming soon that will move the GPS-to-district magic onto the phone itself, so your phone will not need the internet to get in touch with congress.

In the future we would like to make the application more interactive and interesting to play with.  Right now it’s just a dinky slideshow with charts and bullet points about single-payer health care and world health stats.  But it’s not the greatest.  Let us know if you would like to produce some content (like a video or code stuff).  A single-payer advocate and graphic designer would be awesome for redoing the graphics.   floatopian@floatopia.org

Other ideas would be to…

• show how much money could be saved if we cut the private insurance bureaucracy.  administration consumes 31% of all health care costs–show how that money could be used better by letting people go on a “health care shopping spree”
• video that describes single-payer in 90 seconds or so.  think of the video of Robert Reich explaining the public option in 70 seconds.  Somebody in congress or outside of congress should do this anyway, and we would like to put it in the app.
• Insurance Industry roulette.  spin the wheel to decide whether you will go bankrupt due to medical expenses, whether your insurance company will pay for your surgery, or whether you will be covered at all due to a preexisting condition.
• comparison of other health care proposals with single-payer
• arguments  against and/or misconceptions of single payer

The app was mostly designed for those who like single-payer already, so they can call congress about it.  It is also intended to get some facts out, like how we spend 2x more on health care than nearly every other developed country.

etc.

Hope you all enjoy the app.

Update: Spread the word on Apple’s censorship!

Tweet this story!

PALO ALTO, CA –Apple, Inc. has censored  an iPhone application promoting health insurance reform in the United States.

iSinglePayer, an iPhone application that advocates for single-payer health care reform was rejected from the App Store by Apple because it is “politically charged.”  The application displays charts and bullet points about single-payer health care systems, and it allows users to call members of congress.  iSinglePayer even calculates your local congressperson using GPS, and displays the amount of money donated to each congressperson from the health sector.

Rejection From the App Store

The application was submitted on August 21 and rejected on September 26, more than five weeks after it was submitted.  Most applications take 10-14 days to approve.  The rejection was made over the phone by a representative from Apple.  The representative explained that the application was “politically charged” and was rejected for this reason.

Apple rejected the iSinglePayer application because it is "politically charged"

Apple informed Floatopian (which is pretty much just me) that iSinglePayer was rejected in part because it was the product of a lone developer.  There are applications developed for particular political candidates, like the official Obama application, but since those have the official support of a politician they are acceptable.   When a single developer wants to voice his opinions, Apple censors it.  Unless, of course, you can pawn your propaganda app off as news…

auspices

Apple allows certain propaganda on the App Store.

Single-Payer Health Care

The United States currently spends more than twice what other industrialized countries spend on health care per capita. In 2007, the United States spent $7290 per person on health care while the United Kingdom spent $2992 (41% of the U.S. expenditure) according to the OECD.  Despite the high cost, the U.S. health system performs poorly in comparison and does not insure everybody.

Many other developed nations insure every citizen with single-payer health insurance, while the United States has over 45 million uninsured and tens of millions underinsured.

62% of all 1.5 million bankruptcies in 2009 will be medical bankruptcies, and 75% of those will occur despite medical insurance[1]. Some of those with insurance were too sick to continue to work, and thus lost insurance. High co-pays and deductibles bankrupted other patients. None of these problems affect single-payer systems where insurance is provided by taxes even in the case of job loss.

Despite widespread support among physicians, nurses, economists, public health officials, and public opinion polls, single-payer health insurance reform has not been a major part of the health care debate. Senator Max Baucus, chairman of the Senate Finance Committee, excluded single-payer advocates from a round-table discussion among dozens of health experts, including many industry representatives.

The rejection of iSinglePayer from the App Store is but the latest blow to supporters of single-payer health reform.

Contact

Contact Red from Floatopian at floatopian@floatopia.org.

I don’t know who to contact at Apple.  We got a call from a nice guy named Richard who seems to work in developer relations–try (408) – 862 – 9516.  A more general apple number is (408) – 996 – 1010.  You can also try the media help line at (408) 974-2042

Update: Help Get Us a Sponsor

If you are part of a large health reform advocacy group, we would love to partner with you to see if that will get the app published.  Even better would be a member of congress, which would really put Apple on the hot seat.  We just want to publish this thing before it is irrelevant!

Also, we forgot to mention that the app was free to download and has no ads.

Update II: iSinglePayer available in the App Store

Thanks everyone for raising this issue publicly.  Over the weekend Apple approved iSinglePayer and it is now available for download in the Healthcare and Fitness section of the App Store.  I am glad that the app got through, and I hope that Apple will not be rejecting any more applications because they are politically charged.  Thanks again, all!

Click here to download the app for free

In the five weeks since we first submitted we improved the app to not use the network at all.  A new, faster version will be coming out soon.

Update III: Apple strikes criticism from the app description

Apple called me again this and told me to alter the description text in the app store.  They said to remove anything that mentions the approval process.  Thus, you will no longer see the following in the app description:

*** Apple lets iSinglePayer on the App Store after a wave of bad press! ***

Apple originally rejected iSinglePayer because it was “politically charged.”  Five days of bad press later, iSinglePayer has hit the App Store.  Thanks to singlepayercentral.com for helping get the app approved, and Wired, Engadget, DailyKos, and many others for reporting the story.  Now this little iPhone app can make it into your back pocket.

Not a big deal, but yes, we live in a corporate democracy now.

Common Lisp is finally on the iPhone!  After waaaaay too much time in C and Makefile world, I have gotten ECL to cross-compile for the ARM processor and iPhone OS.  The whole process required some changes to the ECL code itself, the ECL make process, and changes to the garbage collector.

To get ECL cross-compiling was a challenge for someone without much experience building C libraries and dealing with platform dependencies.

I made a script that should make this process easy at least 1000 times less painful than my experience.  Just get ECL from the Floatopian repository and build it with a simple script:

git clone http://floatopian.com/~reddaly/ecl/ecl/.git/

cd ecl

sh make-iphone

The library files should be installed in install_iPhoneOS/lib/.  If they are not, then something probably went wrong during the installation process.  The build script is pretty dumb, so it will keep going even if individual steps encounter errors.  So if you get problems look for the error highest up in the output.

THIS VERSION OF ECL does not have any extra bells and whistles.  It is built without threads, bignum support, and ASDF.  If you add any of these features, let me or the ECL list know so we can all share the wealth.

Some notes on ASDF:

> However, I still don’t have all the bells and whisltes working correctly.
> My current problem is getting ASDF to properly compile into ECL.  I cannot
> get ECL to build, even for the i386 Darwin non-cross-compiled version of
> ECL, when I have ASDF enabled and the –disable-shared flag set in the
> configuration script.  [...]

–disable-shared means you cannot compile code and load it. That is
why ASDF is not building. My question now is, does you iPhone have a C
compiler? If not then you will have to install a fake version of
COMPILE-FILE and COMPILE and try to teach ASDF to use it. It might be
a nice addition to ECL for environments without a C compiler but, as I
said, it is fake: there will be no compilation going on.

Some notes on cross-compiling GMP: http://gmplib.org/list-archives/gmp-bugs/2008-April/000997.html

Finally, I would like to get SLIME working on the iPhone to bring the advantages of REPL development to the iPhone.  If you get that working, let me know.

SUMMARY OF CHANGES:

• Ported Boehm garbage collector to iPhone.  I believe I ported everything necessary to get it to work in a threaded environment, but threading is currently broken so the GC part may not be functional.  Look at the changes to gcconfig.h
• various fixes to ensure that the build and host ECLs use the same exact built-in symbol table. (The build ECL is the one with the i386 architecture that you use to cross-compile the ARMV6 architecture host ECL)  ECL uses a tool called DPP to compile lispish C to something gcc can understand.  If the build and host ECLs are not compiled with the same settings, then the symbol tables do not line up and you get strange runtime bugs.  I changed a bunch of C #defines so to make sure the same symbol sets were used.
• fixed some problems assumptions that precluded cross-compilation and non-GMP builds

If you are here just to cross-compile OpenCV, please visit this new post instead.  The older post is a little more detailed, error-prone, pedantic, and maybe out of date.

Original post:

Cross-compiling is one of the many joys of iPhone development.  Generally cross compiling is as easy as calling a `configure’ script with the correct parameters:

In our case for putting OpenCV on the iPhone, we used the following command:


# build arm version
echo "Building iPhoneOS arm version of the OpenCV framework"
echo "============================================="
if test -d ../build_iphoneos; then cd ../build_iphoneos; fi
./configure \
--host="arm-apple-darwin9" --target=arm-apple-darwin9 \
--without-python --without-gtk --without-swig --disable-app \
--enable-static \
--disable-shared \
CC=/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.0 \
CPP=/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/cpp \
CXXCPP=/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/cpp \
CXX=/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.0\
AR=/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/ar \
RANLIB=/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/ranlib \
NM=/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/nm \
CFLAGS="-arch armv6 -pipe -std=c99 -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -Wreturn-type -Wunused-variable -fmessage-length=0 -fvisibility=hidden -miphoneos-version-min=2.0 -gdwarf-2 -mthumb -miphoneos-version-min=2.0 -I/Library/iPhone/include -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS2.2.sdk" \
LDFLAGS="-arch armv6 -pipe -std=c99 -gdwarf-2 -mthumb -I/Library/iPhone/include -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS2.0.sdk" \
CXXFLAGS="-arch armv6 -pipe -std=c99 -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -Wreturn-type -Wunused-variable -fmessage-length=0 -fvisibility=hidden -miphoneos-version-min=2.0 -gdwarf-2 -mthumb -miphoneos-version-min=2.0 -I/Library/iPhone/include -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS2.2.sdk"

the CC, CPP, CXX, CXXCPP, AR, RANLIB, and NM arguments specify the executable files in charge of (CC) compiling C, (CPP) preprocessing C, (CXX & CXXCPP) the same for C++, (AR, RANLIB, NM) library related minutae.  A lot of the CFLAGS LDFLAGS CXXFLAGS are redundant or unnecessary, but they work so why not?

The host= and target= options control cross-compilation.  You really only need to set HOST, which is the machine type on which the compiled code will run.  In our case it is arm-apple-darwin9 which is the machine type of the iPhone.  We gathered a lot of these arguments by building something in XCode and looking at the exact arguments to the C compiler. (You can observe those in the same window as the error messages.)

The C family of programming languages has dumbed down our lives a great deal lately.  Cross-compiling is an even dumber phenomenon than the ins and outs of normal iPhone programming.  Hopefully this post will help bring the joys of cross-compiling into your own living room.  If you find this helpful, please comment on what library you have successfully put on the phone.  If anyone wants OpenCV, let us know.

The most important lesson from Rails(tm) is simplicity. Rails showed it is possible to learn a platform, and indeed a whole programming language, in a few days, and soon thereafter to pump out a full working web site. Rails did not, unfortunately, solve all of our problems.

But Rails et al. have not solved the major problems of web programming. These include:

• annoying designing and testing mechanisms (lots of page reloading)
• multilingual inconvenience (between server & client and on the client & itself)
• weird persistence paradigms i.e. the diseased relational database of the new millenium. (where are the object database evangelists?)
• lackluster visual tools for
  • laying out pages
  • designing widgets
  • introspecting the framework

(The above is a brief brainstorm, not a list of Fundamental Problems.)

In order to deal with the problem of multiple languages, I propose doing all the programming in one language: Lisp. Use it for the server language, and use it wherever a Javascript-like doohicky is needed on the client. The client dialect may need to be different, but all the Lisp concepts, primitives, etc. should be preserved. Parenscript was at one point converging with Lisp, but the project has chosen to be more of a Javascript-in-SEXPs than a Lisp of its own. WebLisp, a Lisp that compiles to Javascript, is a fantasy to be described in an upcoming post.

Visual tools for web programming could help out the world of web development dramatically. I have used Dreamweaver a little bit, but even after a few tutorials I haven’t been able to produce results as good as those using manual HTML/CSS editting. This is a weird state of affairs. I wish that instead of several dozen replacements for Ruby on Rails, we had an innovative framework that makes Adobe Dreamweaver obsolete.

Using more semantics and then creating tools for easily constructing “views” for certain classes of objects seems like a good direction.   But I’ll try look into visualization more and rant at length about that later…

Persistence is not the problem of a web framework. Web frameworks should deal with issues related to the high magnitude of time to transmit information from server to client, but databases are somebody else’s gig. Get yourself a killer object-oriented database solution (e.g. Elephant for Common Lisp) and have at it.

Now on to better things.