Archive for the 'Apple' Category

Since the iPhone’s release, there has been much criticism of the built in 2.1MP camera. Certainly, there is room for improvement.

Personally, I don’t really understand most of the criticism. Cell phone cameras suck. If you want a real camera, get a real camera. Even a $150 pocket point and shoot will outperform any cell phone camera by a long shot.

So what happens when a professional artist with an unparalleled intimate knowledge of light gets a hold of an iPhone and decides to take some pictures?

What you see at the left is what happens.

The renowned watercolor artist Paul Jackson has an iPhone and he noticed some interesting characteristics of the iPhone’s camera’s implementation. Namely, it scans when it takes the photo and, thus, you can achieve interesting effects if you move the camera just right. Combined with his mastery of all that is light, he set out to see what he could do with the camera.

Some very cool images resulted. Paul says “I just love the shots I’ve been getting from my iphone camera. You can bet it will affect how I paint things!”

Paul’s paintings are simply stunning. It is hard to believe that an image like this is a watercolor. And Perfect Curves is a great example of Paul’s mastery of painting light.

Truly a great artist!

Paul was recently invited, as one of only three american artists, to exhibit at the First Invitational Exhibition of Contemporary International Watermedia Masters in China during the Olympics.

He is spending some time traveling through China and is documenting his experience on his weblog. It is a fun read and full of interesting observations & insights.

I look forward to seeing how Paul’s future work is influenced by the strong imagery of China!

A couple of days ago as Ben and I were biking into work, we stopped at an intersection and chatted with one of the folk who maintains the stoplights in the Cupertino / San Jose / Sunnyvale area.

He was in the process of changing out some of the lamps in the cross walk signs, eliminating at least one incandescent lamp and replacing an LED element with a newer model.

I took a moment to examine the LED element that he had removed and he gave it to me. SWEET!

It is somewhere around 60+ reddish-orange LEDs arranged on a printed circuit board in the form of the standard “don’t walk” hand. It is backed by a power supply such that it can be plugged into a standard 120v outlet.

And it is bright. Seriously, blindingly, bright.

I figured it would also make a neat light source for photography and decided to use it as the sole source of illumination for a self portrait. I put the camera on a tripod, used a remote switch to control the shutter, and aimed the LEDs at my head from a slightly down and off-to-the-left position.

Interesting shot. I dig it.

That is pretty much the natural color of the image. I did very little post-processing beyond cropping the image.

The one processing parameters that I did tweak that had a major impact on the resulting image, was to use Aperture’s RAW 1.0 processor instead of the 2.0 processor.

Much to my surprise, the difference between the two is huge!

Normally, I use the 2.0 processor and don’t think much about it. It does a great job, to these unprofessional eyes.

However, it appears that photos in the extremes of range are not necessarily best processed by the 2.0 pipeline.

Specifically: the only difference between the image on the right and the image above is the use of the 2.0 (right) vs. 1.0 (above) RAW processing pipeline. All other adjustments are the same.

That is a significant difference!

Certainly an eye opener and I will be re-evaulating certain images in light of this.

A bug? Hardly. Converting a RAW image to something that can be rendered on screen requires a relatively complex bit of math that is specifically designed to yield reasonable results given a wide range of reasonable inputs.

This is not a very reasonable image. It is lit by an intense light source comprised of relatively narrow bands of color; mostly orangish red.

I wonder what other RAW pipelines might do with this image? I dropped the original RAQ (w/sidecar) in a zip file on a server, if curious.

I played with the image a bit with both the 2.0 and the 1.0 pipeline. I couldn’t post-process the 2.0 image to bring out the level of detail/features found in the 1.0 image. Caveat: I barely know what I’m doing.

Honestly, I’m not sure which image is “less correct”. I like the 1.0 image a lot better in that I like the range of oranges that seem to be utterly missing in the 2.0 image.

My general impression of RAW pipelines is that there is a tremendous amount of math behind the RAW conversion process, but there is also a whole bunch of tuning for aesthetics. Camera sensors simply do not have the dynamic range of the human eye and, thus, RAW conversion is partially about compensating for the limitations of the sensors.

This morning, my software update queue was full of goodies.

Notably: iTunes 7.7, iPhone 2.0, and an Apple TV software update! And the App Store is live!

After the updates, the first App I downloaded was the Apple Remote.

Flat out brilliance.

Much like pairing the Apple TV with iTunes, you enter a 4 digit pin number displayed on your iPhone (or iPod touch) on the Apple TV.

Once paired, the user interface is very similar to the iPod UI. Playlists, artists, songs, etc… select what you want to play… displays art work, yada yada.

And in well fell swoop, every other remote (there are 5, if you include two Apple IR Remotes) was obsoleted.

Having bi-directional, fully stateful, communication between the remote and the media playback device is a gigantic game changer. It means that the remote can actually meaningfully tell you what is going on and and can provide UI pertinent to the context implied therein.

That is, you can touch your music, scrub a track with your finger, flick through a playlist and otherwise get your fingers right into your media playback.

You can even update ratings. For me, being able to update ratings is a huge feature. I have smart playlists that put together random selections of tracks over a certain rating, in a certain genre, that I haven’t heard in a while. It creates a set of personalized radio stations out of my music collection. And now it’ll be even more effective because I’ll be rating many more tracks much more quickly!

This changes the game in my living room. Completely. My media center’s remote is now more powerful than any computer I bought in the 1990s. And every one of my friends who has a similar device can now be a DJ.

It isn’t perfect. At the moment, it doesn’t appear that you can play rental material from the remote interface and you can’t create on-the-go playlists. Nor can you set ratings when controlling an Apple TV (but that is an Apple TV limitation).

Sure, as one commenter pointed out, there are other products that offer this style of remote control.

But I don’t want an expensive, dedicated, limited capability, complex remote with a shoddy user interface. I want the power of a computer to control my media playback. In my hand. Only I don’t want to know it is a computer — I want it to just work. With a high quality user experience and seamless network integration.

You people have dirty minds! The !Adult smart playlist merely filters out all songs for which the word adult appears in the comments. For example, Nine Inch Nail’s Closer has adult in the comments and will never play when that playlist is selected.

Hey! Today is 5/19.

Five years ago today, I was sitting in Apple’s employee orientation with a big glass o’ the kool-id in front of me.

Still having fun and making cool stuff.

With the recent release of the MacBook Air, there have, of course, been a flurry of reviews and, more relevant to this particular blog post, armchair quarterback style conjecturing as the relevance of the Air’s design within the current marketplace.

Not surprisingly, many of the reviews or commentaries mention The Apple Cube, pictured at left (photo courtesy of wikipedia).

At Daring Fireball, Gruber’s article said in a footnote:

Arguably, the main problem with the G4 Cube had nothing to do with its technical specs, price, or aesthetic appeal, but rather that its case was overly prone to cracking and/or unsightly injection mold lines. I.e., the Cube’s fatal flaw was in the design and engineering of its case.

Close, but not quite. Near the end of the cube’s manufacturing lifecycle, Cubes were on closeout and my company picked up 10 or so to use as general purpose workstations. None of them had noticeable cracking or mold lines.

However, the very design of the cube was fatally flawed.

In particular, the cube sacrificed function in the name of form.

To be blunt: Gorgeous to look at, absolute pain in the ass to live with.

The design was such that anything requiring a cable change was inconvenient. You had to physically tilt the machine over, often all the way onto its side, connect/disconnect the cables, and then very carefully re-route all the cables through the little gap in the back.

The top wasn’t much better. The top featured both the slot for the optical drive and the power button. Unless you paid careful attention, it was damned easy to brush the power button when dropping in or removing a disc.

Worse, the top of the machine was a magnet for dirt, hair and cats. Hair would fall across the optical drive slot and then get sucked right into the drive when you inserted a disc.

And, yes, cats. My friend had a cube at his home. The cats would love to sit on top of the nice, warm, flat cube. Which would both fill it with cat hair and turn it off… then on… then off… then on… then off for as long as the cuts stuck around. He finally had to put one of those pigeon guard kind of strip of nail things on top of the cube to keep the cats from corrupting his filesystem!
(People seem to think I actually take the cat thing as a serious criticism or design flaw. Please. It was funny, that is almost all. Certainly, if the cube had been marketed like the iMac, it would have been a consideration — not a big one, but a consideration none the less.)

The cube was certainly a gorgeous piece of engineering. As a piece of art, it deserved all the awards it received.

However, as a computing device, it really sucked.

Update (responding to comments) on the full post…

Read the rest of this entry »

When analyzing an Objective-C application with Dtrace, one big challenge is how to introspect any objective-c objects that are passed as parameters into the various trace points.

While you can use the Objective-C provider (documented on the dtrace man page) to trace particular methods of specific classes, it doesn’t really help for actually introspecting an instance or class.

By “introspecting”, I mean “printing out the damned class name”, for example.

Full monty on the click through.

Read the rest of this entry »

Jim Correia asked on cocoa-dev:

Can you offer any advice for the times when I must write my own accessor, but want it to have similar behaviors to the autogenerated accessor? In particular, I’m thinking about the default atomic behavior. Is this simply wrapping the work in a @synchronized(self) block? Something else?

First, some context. Jim is referring to Objective-C 2.0’s properties and, more specifically, to the behavior of methods automatically synthesized by the compiler.

By default, synthesized accessors are atomic. Atomic does not mean thread safe.

Read the rest of this entry »

Update: CocoaHacks was quite a bit of fun. Not only did I demonstrate the rather silly little hack, but I ran it fully garbage collected. With one simple change (that should be in the next release), the MacFUSE framework works just fine with Garbage Collection enabled!

The best compliment came from Amit Singh; something along the lines of “That is absolutely the strangest filesystem I have seen.”

In any case, my little hack repository has been updated to be GC only. retain/release/autorelease/dealloc are dead to me (in this project, anyway).

If you want to build MacFUSE with GC enabled, simply set Objective-C Garbage Collection to “Supported” in Xcode in the MacFUSE framework project’s build settings.

At left, is a screenshot of the Finder browsing the Objective-C classes active in the runtime of a little Cocoa app that I wrote this evening.

The little app is called RuntimeFS and it contains a simple bit of code that traipses through the Objective-C runtime and collects information about the Objective-C classes encountered. This information is then barfed up by the elegantly simple delegate like API required by MacFuse to create a filesystem.

Let me restate that: MacFuse kicks ass. The Objective-C API is trivially easy to use. Trivially easy. I implemented this little hack in less than two hours, not having looked at the MacFuse API before. Nor did I read the docs; just looked at this example and one header file. I have implemented filesystems in a couple of different languages. Filesystems are hard. Or was. Not anymore.

I dropped the source code in the “Silly” directory of my public SVN repository.

Because, really, this is quite a silly hack. And hack it is — it doesn’t crash, but that is about all the quality assurance analysis I have done.

Free as in “MIT License” free. Have fun. I’m accepting patches, of course.

Future Stuff

If I were to go anywhere with this, the first thing I would do would be to move the subclasses into a subdirectory and then add other subdirectories to contain additional data.

Specifically, I would add directories like -1- Instance Variables, -2- Class Methods, -3- Instance Methods, -4- Subclasses, -5- Documentation (or something), etc…

The naming convention serves two purposes. First, it sorts nice like. Secondly, the names are invalid as class names and, thus, it makes handling the metadata vs. class directories trivially easy while also eliminating potential namespace conflicts.

In Leopard, Apple added a new tool to the developer tool suite called Instruments. It is a timeline based debugging and performance analysis tool. With a full suite of tools to analyze all kinds of dimensions of performance, correlating all data onto a timeline that can be inspected and navigated at will. And it remembers prior runs so you can compare results before and after changes.

And it fully consumes dtrace.

Clicking through the screenshot at right will show a run of Instruments with a single analysis instrument active.

I created a custom instrument that encapsulates the dtrace script I discussed in Objective-C: Using dtrace to trace messages-to-nil.

I ran the resulting instrument against TextEdit.

What can’t be conveyed by that screenshot is exactly how “live” the data can be examined. You can click and drag on the timeline to select a subset of the run, details of the selected instrument are shown in the table in bottom right, and any given row can be selected to show the backtrace active at the time the sample was taken.

I didn’t want to clutter up the screenshot with lots of data and, thus, didn’t demonstrate the awesomeness that is being able to relate data across multiple instruments, correlated by time.

That’ll be in the next Mac OS X / Software related post.

Click on through for an explanation with screenshots as to exactly how to convert the dtrace script to an instrument.

Read the rest of this entry »

Update: There are [at least] two different Objective-C messagers. objc_msgSend() and objc_msgSend_stret(). All of what is written here applies to both however objc_msgSend_stret() is the problematic one when it comes to messages to nil; it is the one used to return structures and, thus, the one that does not necessarily guarantee a zero return.

In my last post on the subject, Adrian Milliner posted a short dtrace script that would log the backtrace for all invocations of objc_msgSend where the first paramater — the target — was nil.

The script is as follows:

pid$1::objc_msgSend:entry
/arg0==0/
{
  ustack();
}

Once saved to a file (in this case objc-nil-trace.d, the trace can be applied to any running Cocoa process via:

sudo dtrace -s objc-nil-trace.d <pid>

The <pid> argument should, obviously, be the process ID of the process to be traced.

It works well enough and is certainly faster than a conditional breakpoint in GDB (likely, orders of magnitude faster), but it is far from a complete solution.

Read the rest of this entry »