The source code for the Tesseract OCR for iPhone project has been published. It’s really simple – more of a skeleton, proof-of-concept project than anything else. Still, though, it’s neat to have nearly point-and-shoot text conversion in your pocket.

The project page is: Pocket OCR

The source code is available at github: http://github.com/rcarlsen/Pocket-OCR

There is certainly a lot of improvement to be made. Automatic color correction. Page layout recognition. Perspective correction…the list could go on. The code is there, so…fork away!

(the thumbnail is a bit tongue-in-cheek…but honest. good conversion requires a good source image: well-lit, macro, focused and tightly cropped seems best)

In preparation of submitting Pinwheel to the App Store I’ve gone and released a beta version via ad hoc distribution. Seems like it should be a straightforward prospect, however the various device provisioning, code signing profiles and entitlements made it a bit of a process for a first-timer.

iTunes also seems to be entirely unhelpful when something goes wrong with the “unknown error” message. What could it be? Code sign error? Unprovisioned device? Incorrect OS target? Mismatch in the app and mobileprovision file? It’s all a mystery in the iTunes universe.

Despite the inconvenience involved with having to generate a new ad hoc mobileprovision profile each time I add a new beta tester device, requiring a recompile of the beta app, it’s nice to finally get an app out to other non-development devices.

The ad hoc distribution process is documented well (enough) on Apple’s dev portal and on several other blogs, but my real stumbling block was navigating the Xcode interface to ensure that the proper code signing profile was being included in the binary (hint, look at the verbose build output for “embedded.mobileprovision” and ensure that the mobileprovision ID matches the correct version.)

I’ve also been getting trouble with Xcode not building using the correct provisioning, despite updating the target info and cleaning out the build folder. A restart of the program usually gets it sorted.

The next step will be to set up a Distribution build for the App Store submission. We’ll see how that goes in the end…

i’m having a time of it tracking down a resource allocation bloat culprit in an iPhone app i’m working on. i’ve narrowed it down to when i’m rapidly updating the center property of a UIImageView. a snippet from the Instruments application is below:

there are hundreds (if not thousands) of these messages, and the object allocation graph trends steadily upwards. when i disable the portion of the method which updates the center property the allocations stop and the memory usage goes flat. this also only occurs on the device…the simulator does not exhibit this behavior.

i’m using UIImageView directly, without subclassing, and it contains data from a small PNG file. i’ve patched up several other leaks successfully today, and really wanted to nail this one too.

[Also available at ITPedia. Watch video of the BarCampNYC4 presentation.]

This is an overview of getting set up using openFrameworks for iPhone development.

What is openFrameworks?

openFrameworks is a “a C++ library for creative coding”. It shares a similar philosophy with Processing (as a library for Java). The intended audience “are folks using computers for creative, artistic expression, and who would like low level access to the data inside of media in order manipulate, analyze or explore.”

There are good resources for reading more about it below, under the Resources heading. This article assumes basic knowledge of programming and of the Xcode development environment. You can simply follow along and launch the demo app, but you should really read the resources to understand the structure of a typical openFrameworks-based application.

Why?

iPhone native application development is typically done in Objective-C. Not pressing the merits and detractions of Obj-C, but it’s *another* language to learn. If you have code / experience working in C++ then you can use oF to migrate those programs to the iPhone somewhat painlessly. Arguably easier to begin working with – espeically if you’re coming from experience with Processing.

Why not?

However, if you already develop in Objective-C, then maybe you don’t need to use oF. OpenFrameworks is not as well documented as Objective-C (even though Apple’s docs are as dense as the proverbial stereo instructions joke). Certain applications are not as suitable (lots of hierarchal views) It’s very easy to overwhelm the iPhone if porting desktop oF code over.

Ultimately, however, this eliminates 90% of Obj-C. Still need to use Obj-C (or Obj-C++) to use iPhone interface widgets. Don’t worry about it right now. (more…)

As an in-class exercise for Spatial Media we were asked to develop a program which would identify coins in a series of supplied images and tally up their total value. In one hour.

Since time was limited, I decided to use pixel count as a rough estimate of each coin’s size. This works very reliably with the sample set of images, but that’s likely because the images consist of duplicated coins and are on a solid white background. Several additional methods wold likely need to be implemented to deal with actual situations. (Code below) (more…)

I’ve had a few days to test the libraries I cobbled together for using openFrameworks with iPhone and also received positive reports from some folks who tried out the Makefiles I provided to them, so here they are for anyone who’s willing to try them out. -please make these instructions better if you see fit- (more…)

While the Arduino IDE (Integrated Development Environment) is relatively simple way to program the Arduino hardware, I found myself getting frustrated by it’s limited features after spending time using Xcode and Eclipse. There are some simple tutorials available online which demonstrate how to set up Xcode for programming the Arduino, however these didn’t “just work” for me, and were targeting arduino-0.10.

I made a few (simple in hindsight) changes to the project which has worked well for me so far. (more…)

(i was going for a fisher-price approach with the title…)

regardless, i’ve finally gotten around to iPhone development. my developer account was approved last week, and apple happily took my $99 in exchange for slightly greater access to their website and a application code signing certificate. in preparation, i’ve been reading the requisite docs on objective-c, cocoa and iphone application programming. also, working on golden cheetah got me comfortable (sort of) coding in xcode. (more…)

super annoying…Qt advertises that you can make an xcode project file using qmake to enable native development on mac…i had never been able to get the golden cheetah project working in this way, even after following what little documentation i could find. each time i’d run “qmake -spec macx-xcode” would result in a non-parseable xcodeproj file. to date i’ve just been coding and compiling with a simple text editor.

justin had done some initial troubleshooting, eventually filing a bug report with trolltech. he determined that the QMAKE_CXXFLAGS = -DGC_BUILD_DATE=”`date +’\”%a_%b_%d,_%Y\”‘`” was causing the issue. commenting out the offending line to get a valid xcode project and having to create another define in a source file.

a dev from trolltech got back to justin confirming the bug and offering a workaround by manually adding the directive in the xcode target’s build settings. they also mentioned that a fix would be coming in a future version of qmake, but gave nothing specific. i spent most of the afternoon trying to follow this workaround to no avail. it was very frustrating. i looked at the project file that qmake created and something looked odd with how special characters in the qmake_cxxflags key were escaped with slashes. too many it seemed.

finally, i came across a forum post where someone was trying to set a define macro to have a string value – jsut what we are trying to do. the solution is somewhat a hack, a bandaid for a shortcoming of qmake… triple-escape the outside quotation marks. looks like: -DGC_BUILD_DATE=\\\”`date +’\”%a_%b_%d,_%Y\”‘`\\\”

it compiles fine on the linux (ubuntu) test box, manually on mac os x (using qmake/make) and also creates a valid (parseable) xcode project file, but it won’t compile in xcode. i still have to disable these lines in src.pro and add them in by manually later. for the time being, i’m planning to develop in xcode, and build test versions without the build date/version number and then compile beta/release versions by hand, which works fine.

for reference, here are the lines i’m referring to in src.pro:

QMAKE_CXXFLAGS += -DGC_BUILD_DATE=\\\"`date +'\"%a_%b_%d,_%Y\"'`\\\"
QMAKE_CXXFLAGS += -DGC_SVN_VERSION=\\\"`svnversion . | cut -f '2' -d ':'`\\\"
QMAKE_CXXFLAGS += -DGC_MAJOR_VER=1
QMAKE_CXXFLAGS += -DGC_MINOR_VER=0

the top two lines are string values; the bottom two values are integers. also note, this has been reported to not work in win32, but i haven’t tested it myself. after we get the mac/linux builds going i’ll get back to the win build.

oops. school’s out and i’ve completely ignored documentation. looking to correct that, please accept the following communiqué:

the winter show went very well – it seemed that cloud reader was well received. most of the favorable comments were split among two categories…those which really liked the performative aspect of the project and could envision it large on a wall….and those who reacted strongly to the intimate aspect of seeing it running on the iPhone screen.

since the project was originally designed for the small screen in ITP’s 2×2 class, the comments were enough to encourage me to finally get around to iPhone application development. i’ve looked over various objective-c, cocoa and iphone docs over the past year, but never really made a commitment to actually learn or apply it. now i’m driven, and have come to love square braces

separately and coincidentally, sean from golden cheetah decided to extend justin and i write access to the svn codebase and the website. he’s been quite busy and gc development has stalled for it. although i’ve been busy with school, between the three of us we should be able keep abreast of patches and implement new features.

i’m trying to be cautious with the project…i don’t want to do something that will expose me as a (programming) fraud! justin and i were able to get it working happily in xcode…although the QMAKE_CXXFLAGS += -DGC_BUILD_DATE=”`date +’\”%a_%b_%d,_%Y\”‘`” compiler directive in src.pro was causing qmake to create non-parseable xcodeproj files…i think it may have to do with escaping special characters. justin sent a bug report to Qt…hopefully we’ll hear something at some point…for the time-being i’ve commented out the line in the .pro file and added a conditional define in MainWindow.cpp.

so, tinkering with the golden cheetah code has be getting me comfortable with code that isn’t java and i think i’ll be well on my way to get to with with cloud reader for iphone…come on apple and approve my developer application!