cloud goes social

Thanks to Karl (see previous post comments and update) the XCode project has now the possibility to work on the images uncompressed. We (me and Karl) wanted to see the difference for ImageMagick to work with a compressed format (JPEG, for instance) and with an uncompressed format (raw data).

I’ve added to the project a simple benchmark, consisting in running the MagickWand creation, filtering and destruction a given number of times (customizable in the beginning of the source file, for instance 10), calculating how long it takes each time and in total.

The results are impressive, and can be better exaplined by looking at this simple graph:

Benchmarks running on the simulator and on the device (click to see better!)

As you can see working with uncompressed data achieves 3x faster results on the iPhone device, with a mean running time of 0.85 seconds to run an ordered posterize filter on an image of size 320×460 (the size of the iPhone screen). Similar results are also on the Simulator achieving 3.7x faster filtering for the same image.

The end line is trivial, working with uncompressed data, while being less easy (but as you can see from the project code not extreme) or intuitive yields much faster results!

You can download a better looking graph and the IM_test project as usual.

For any comment don’t hesitate to write, as you’ve seen I try to pick up my comments as much as I can (even on holiday!)

Thanks goes again to Karl who’s has the idea of working with raw images, and provided with the code to achieve so.

ciop ciop

UPDATE: iOS4.3 and Xcode4

PLEASE READ THE UPDATE

UPDATE! (30.08.09)
Thanks to Jon Kean (see comments) the downloadable project now shows how to use images with unusual number of bits per component. As usual look at the defines at the top to check the functionality you want.

UPDATE! (14.07.09)
Thanks to Karl (see comments) the downloadable project now shows different ways of integrating ImageMagick with Objective-C UIImages offering both compressed methods, using JPEG compression as an example, and raw-data methods. Look at the define at the top to change which method the program will be using.

Many of you have asked me if I could post an Xcode project example to use the libraries and ImageMagick, and so, here it is.

The code is self-describing so I didn’t comment it much, it’s just a few functions call. All it does in this case is loading an image from an UIImage (Objective-C) into a format that ImageMagick (C) understands and can manipulate. Then it applies an ImageMagick filter (OrderedPosterize), which uses a configuration file (thresholds.xml).

Everything is working fine, and you have the complete set of libraries, headers and configuration files, and a configured XCode project right at hand.

All downloadable from here

If you still have any problem, don’t hesitate to contact me!

ciop ciop

UPDATE: iOS4.3 and Xcode4

PLEASE READ THE UPDATE

I’ve been busy working on an iPhone project using ImageMagick the last month, and one thing has kept on bugging me: Some functionality just wasn’t working!!!

In particular I discovered that ImageMagick uses some XML configuration files for some of its internal operations. You can find the whole reading about them on ImageMagick site.

After fiddling, deciding to not care, re-deciding that I WANTED THE FUNCTIONALITY here’s the solution (as usual in steps):

1. The Files that need to be copied over are stored, if you use my script to compile ImageMagick under the installation directory:
   ~/Desktop/tmp_target/imagemagick/lib/ImageMagick-6.5.3/config
~/Desktop/tmp_target/imagemagick/share/ImageMagick-6.5.3/config
2. XCode needs to import such files, so that they can be copied over to the destination application. In particular add them to the Resources directory with the usual method for adding files:
   Right click on the Resources folder -> Add -> Existing Files…
   and select all the .xml files in the two folders above.
3. The Code somewhere, like in a function that gets called only once (viewDidLoad, for instance), this may vary depending on your program, add the two following lines:

   NSString * path = [[NSBundle mainBundle] resourcePath];
   setenv("MAGICK_CONFIGURE_PATH", [path UTF8String], 1);
   

Done, now ImageMagick knows where to look for the needed configuration files and will work like a breeze for you.

YES! It was this easy. But not to discover, trust me! :P

UPDATE: iOS4.3 and Xcode4

PLEASE READ THE UPDATE

I’m working on some iPhone applications, which need some image filtering. For now, I won’t say more! Stay tuned for the news when it comes out!

Long story short, I soon found the need (ant the challenge was a good one) to get ImageMagick static libraries so that I can use it on the iPhone. Not only that, but with jpeg and png support. That’s what I need.

After a fast search through the net, I couldn’t find a single _GOOD_ post on how to do that. Just some bits and bytes – Nothing complete.

I soon set on a mission to get ImageMagick to work on the iPhone, as a library. And here’s the result of my quest (around 1 day of search, trials and errors, and at last some light!)

Setting

I’m running MacOSX 10.5.7, with the latest MacPorts installed. If you don’t, get it! I have many ports installed, the ones I “think” are important are:

• jpeg
• libpng

Also, I’m testing everything with the latest beta of the iPhoneOS 3.0 – It should be working also for 2.2.1 and the final 3.0 when it comes out.

The Script

I now provide you with a shell script that should do the whole trick of creating the static libraries needed in Xcode for iPhone development.

Just download it, give it run permission (chmod +x ./compile_im.sh), and launch it. It will ask for your password because it needs to copy a file that is not owned by you, the user.

Before complaining that it’s not working, open it, and look at the required directory structure for it to work.
In particular you will need:

• a Desktop folder named cross_compile
• ImageMagick source: ImageMagick
• jpeg source: jpeg

– to which I’ve added the MacPorts patches

• libpng source: libpng
• Untar ImageMagick source and place it into ~/Desktop/cross_compile/i_m
• Untar/Unzip jpeg/libpng source and place it into: ~/Desktop/cross_compile/i_m/IMDelegates/jpeg-6b and ~/Desktop/cross_compile/i_m/IMDelegates/libpng-1.2.37

Now you can run the script :)

Result

The result will be stored under: ~/Desktop/tmp_target. In particular you can find all the header files needed while developing your application under: ~/Desktop/tmp_target/im_libs/includes (divided by library). While all the static libraries are inside ~/Desktop/tmp_target/im_libs/:

• libjpeg.a
• libpng.a
• libMagickCore.a
• libMagickWand.a

Please note that the script joins both the i386 and the arm build inside one single .a static library to ease up developing (for testing both on the Simulator and on the device itself. When finishing up the application you may want to put only the arm library to make the overall application lighter.

XCode configuration

Step 1

To work with your libraries you need to put some easy adjustments to your Project in XCode. I’ve found that the best thing to do, especially in a shared environment with multiple developers, to just put everything inside the XCode project. To do so do:

• Project->Add To Project->Select all the .a libraries->Click ‘ADD’
• Project->Add To Project->Select the folders inside the ~/Desktop/tmp_target/im_libs/include->Click ‘ADD’

Step 2

Click on Project->Edit Project Settings and edit (in the Build:

• Other Linker Flags: -lMagickCore -lMagickWand -lz -lbz2 -ljpeg -lpng
• Header Search Paths: $(SRCROOT) – make it Recursive
• Library Search Paths: $(SRCROOT) – make it Recursive
• On the lower left click on the small-wheel and select: Add User-Defined Setting
• Key: OTHER_CFLAGS
• Value: -Dmacinsoth=1

This should be enough to make you start.

For the Lazy

If you’re lazy, don’t manage or for whatever other reason you can just download the whole compiled package

Last note

In case the script doesn’t work, you have questions/suggestions/support please don’t hesitate to contact me, and in case you need help with the script please send me the FULL output in a file.
./compile_im.sh > file_to_send.txt

The Problem

I’m an Apple fan, and user, and developer. As such I have an iPhone and I use it, and I develop for it. Well, I try.

When I say: “I try” I don’t mean that I don’t have the skills necessary to develop an iPhone application, I mean that despite the application I’ve developed (with a friend) works, has been checked against memory leaks, is snappy and, I believe, useful, well, despite all that, Apple rejects it.

Now, since I don’t doubt my developer skills, and since Apple of course couldn’t find anything done badly in the application, the question is: why does the application gets rejected?

The Intro

First of all, µMonitor is a simple application with some views, populated with some tables that shows (N.B. SHOWS, you cannot [up to now] add torrents to download, just monitor [as the name implies] the status of your µTorrent instance), by connecting through the µTorrent web API, the torrents that you’re downloading/seeding/whatnot on your µTorrent instance running somewhere over the net. It’s very simple, the webui of µTorrent hasn’t been developed to be shown on a small-screen device therefore the native application shows the same results just in a more iPhone-like ui/experience. There are optimized version of the web-ui for smaller-screened devices (link, link), but why not having a native application? Exactly! That’s why I’ve developed one!

The issue

The application has been submitted to Apple for revision the 13th of January 2009:

µMonitor submitted the 13th of January 2009

A few days later the dreaded e-mail arrives:

from : devprograms@apple.com
to: …
date Fri, Jan 16, 2009 at 4:17 AM
subject: µMonitor: Application Submission Feedback

Please include the line below in follow-up emails for this request.
Follow-up: <0ed out>
Dear Claudio,
Your application, µMonitor, is requiring unexpected additional time for review. We apologize for the delay, and will update you with further status as soon as we are able.

Thank you for your patience.

Regards,
iPhone Developer Program

After a while, a long while, the rejection email:

from: iPhone Developer Program
to: …
date: Mon, May 18, 2009 at 3:56 AM
subject: µMonitor 1.0: Application Submission Feedback

Please include the line below in follow-up emails for this request.
Follow-up: …
Dear Claudio,
Thank you for submitting µMonitor to the App Store. We’ve reviewed µMonitor and determined that we cannot post this version of your application to the App Store at this time because this category of applications is often used for the purpose of infringing third party rights. We have chosen to not publish this type of application to the App Store.

If you believe you can make the necessary modifications to bring your application in compliance with iPhone Software License Agreement, we encourage you to do so and resubmit it for review.

Regards,
iPhone Developer Program

Astonishment

• How’s it possible that it took them 4 months to come to this conclusion?
• What difference is there between Safari, which through the web-ui allows for full-interaction with µTorrent enabling much more than µMonitor provides, and µMonitor itself which just shows the current torrents?
  
  

  On the left the µMonitor interface, and on the right the built-in Safari interface

• As a generalization: since Internet might be used for “infringing third party rights” why is it enabled on the iPhone?
• What kind of “necessary modifications” could I apport to the application to make it suit this weird Apple constraints?

Rant

I’m really dazzled by the decision, and even more by the motivation, given by Apple about µMonitor, and here’s my rant-post.

What can I do? What can we do, torrent users? I will review any suggestion. For now, I’m astonished.

I just started a new project. It’s a Cscope Bundle for the super-mega-fantastic-awesome MacOSX editor TextMate.

The code is hosted over at github where the bundle can be downloaded.

The main webpage for the project is right here: Cscope for TextMate.

Of course comments are greatly welcomed with suggestions, bug fixes and requests. I will try to keep up with the project and coding to make it always more useful!

Recently in the Advanced Operating System course, at ETH (Systems) I’ve struggled upon the TIME protocol (not NTP). The problem was simple: get a TIME protocol server that could respond to the SLUG2 (friendly called by me and my project partner SLUT) when ‘she’ was needing a reply (for some randomness, apparently).

Since MacOSX doesn’t provide any such thing, I settled on the task and here’s the result:

Server side:

#!/usr/bin/env python

import time
from socket import *

def server(host="", port=37):
	sock = socket (AF_INET, SOCK_DGRAM)
	sock.bind ((host, port))

	print "listening on port %s (%s)" % (port, `host`)
	while 1:
		# Block waiting for packet.
		data, address = sock.recvfrom(256)
		print "Client sent:", data
		print "Client at:", address
		# Got a packet, reply to address packet came from.
		sock.sendto(time.time(),address)

if __name__ == "__main__":
	server("", 37)

Client side (just to test that the server is actually working)

#!/usr/bin/env python

import socket
port=37
clisocket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
while 1:
	data = raw_input("Type something: ")
	if data:
		clisocket.sendto(data, ("127.0.0.1", port))
		# Block waiting for reply.
		data, address = clisocket.recvfrom(256)
		print "Server sent time:", data
	else:
		break

clisocket.close()

This code (and any other that might be present on this blog) should be taken with a good grain of salt. It seems to do what it’s supposed to do. So if you’re in an emergency, trying to find a TIME protocol server to make it answer your client needs, here it is. Fiddle with it as much as you want. And don’t hesitate to comment with good and bad news about it.

The code and the issue have been tested on MacOSX 10.5.6

ciop ciop