Mac Daddy World

We just finished some marathon coding and are happy to announce iPhoneDrive. In a nutshell, it lets you use your iPhone for file storage by providing an easy file browser interface. Version 1.0 is very functional considering that it was written in about one week. The demo version works just like the paid version but only for a 7 day period.

It supports drag and drop to and from the iPhone. It also supports transfer of entire folders. This makes it easy to move large directories back and forth between your Mac and your iPhone. Since the iPhone uses USB 2.0, the transfer speed is very fast. Now you can put those spare gigabytes to good use. Backup your important files! Your hard disk could fail at any moment! Do it now!

Here’s a screenshot:

Reinventing the Wheel

You can see we used an NSBrowser for the file browser. If you’ve ever tried to use one of these you’d know that they’re not very useful out of the box. Drag and drop has to be implemented manually, and the updating of cell data is very flaky, requiring many work-arounds. Also, they don’t do many of the things that you’d come to expect from the Finder’s column view mode.

All said and done, the interface came out pretty good. I just wish Apple would update NSBrowser to support more of the things found in the Finder column view. Obviously the Finder isn’t implemented using NSBrowser (it’s not even Cocoa for that matter), but it would be nice to have things like elipsification, marquee selecting, and drag and drop in there without having to reinvent the wheel.

We welcome any feedback about iPhoneDrive. Leave a comment here or use the feedback form on the main Ecamm website.

The iApps like iChat and Photo Booth only request a 640×480 or smaller image from the iSight. Therefore it can be troublesome to find a way to test the full capabilities of the new 1.3 MP iSight. That’s why we wrote our own little test program.

Today we cleaned it up and are posting it here so new-MacBook-Pro-having visitors can try it out see the new and improved image for themselves.

The app requests and displays a video stream from the camera at 1280×1024. If you’re on an older iSight it will still stretch the VGA image out to be this size but it won’t look very good. The app will report the frame actual size from the ImageDescription at the top.

There’s also a snapshot button so you can take your own picture and make your friends jealous of your fancy new laptop. Sorry: no Photo Booth effects yet!

If you get to try it, leave a comment and let me know how it works for you.
The Test App (68 k)

Tech Talk Follows:

The app does Hi-Lite™ a potential reason why Apple might not be yelling from the rooftops about the new camera: You can see right away how slow it is to stream the full sized video. Why? It’s more than four times more data than VGA. The Sequence Grabber was designed decades ago and wasn’t designed to handle more than NTSC/PAL sizes. Until the Sequence Grabber is revamped, it’s a little too slow to run such a large stream.

1,280 x 1,024 = 1,310,720 pixels
It’s 4:2:2 compressed YUV data, so that’s 2 bytes per pixel or 2,621,440, or 2.5 megabytes per raw frame.
So for full 30 fps video, this translates to about 75 megabytes per second or 600 Mbps.
Now keep in mind the camera controller allows for a compressed MJPEG mode which cuts the required USB bandwidth signifcantly. (You’d never fit that over USB 2.0 without compression.)

But even if it is being compressed on-camera, it’s then being decompressed in the driver and passed to QuickTime in YUV. That’s a lot of data to push through the poor Sequence Grabber pipes. Technically, you should be able to request MJPEG data from the sequence grabber, but the default seems to be YUV. I haven’t tried requesting other compression types as I don’t actually have one of these new machines in front of me.*

More details about the new camera:

The original iSight didn’t advertise itself as a UVC device (It was Vendor Specific).
The new one does advertise as UVC, so you can easily use USB Prober to decode the device descriptor:
According to the descriptor the camera supports the following frame formats:

MJPEG 640×480 @ up to 60fps
MJPEG 720×480 @ up to 60fps
MJPEG 800×600 @ up to 30fps
MJPEG 1024×576 @ up to 30fps
MJPEG 1024×768 @ up to 30fps
MJPEG 1280×960 @ up to 30fps
MJPEG 1280×1024 @ up to 30fps
Uncompressed 640×480 @ up to 30 fps
Uncompressed 352×288 @ up to 30 fps
Uncompressed 160×120 @ up to 30 fps
Uncompressed 704×576 @ up to 25 fps
Uncompressed 720×480 @ up to 25 fps

Maybe another SequenceGrabber savvy engineer out there with the new MBP could experiment and see what you get back from VDGetCompressionTypes. Can we request MJPEG data through the pipes?

*Another thanks to Dave for running some tests for me on his MBP. Dave is a web designer and has a website that I’ll plug.

or… Built-in iSight The Next Generation 

At WWDC, Glen had the unenviable task of hitting the compatibility lab and testing the upcoming release of iGlasses on as many computers as he could.  When checking out the new 2.2 and 2.4 GHz MacBook Pros, he noticed something interesting about the built-in iSight:

It’s a whole new camera.  Really!

First, looking at System Profiler:

It has a new USB PID.  What I’ll henceforth have to refer to as the original built-in iSight, had the USB Product ID: 0×8501 and reports its manufacturer as Micron. The new built-in iSight has the Product ID of 0×8502 and reports manufacturer of Apple Inc.   

Now the cool part:  It’s a 1.3 megapixel sensor!  I wrote a simple test application to capture a frame of video using an SGDataProc and save it to the Desktop.  On my older 2.33 GHz MB Pro with the original built-in iSight, what I get is a VGA (640×480) image.  This is the maximum size of the original camera, which I know for sure uses a VGA sensor.

Then, braving the 95 degree the heat, we got on our bikes and cruised down to the Cambridge Apple Store.  After fighting our way through the crowds of people asking if they can pre-order an iPhone, we commandeered some MB Pros.  The same test program produced a nice, big 1.3 MP (1280×1024) image. 

UPDATE: Test app available here.

Other differences:

The new camera supports all of the VDSetBrightness, VDSetContrast, etc. calls. The old camera only supported Saturation and Sharpness.  This causes an odd bug in iGlasses which we’ll have to fix very soon.

Whereas the original camera was uyvy (’2vuy’ in QuickTime), the new camera’s data is yuyv compressed. (that’s YUY2 for you Windows users or ‘yuvs’ in QuickTime parlance.) It’s the same as the previous 4:2:2 format except the 16-bit words are byte swapped. This doesn’t cause a problem for iGlasses which knows how to deal with both data types as this is the YUV format used by our iMage USB Webcam.

Interesting:

- I haven’t verified this yet, but I’m going to guess that 10.4.10 (which includes a new 2.0 version of the UVC driver) is required to get the larger sized image.  This would explain why nobody noticed this last month when they were first released.

- I’m guessing they’re still using a Micron sensor.  A few sources have indicated that the iPhone will also use a Micron sensor for its camera.  The phone is supposed to have a 2 MP camera. 

- iChat and other iApps don’t take advantage of the larger image size.  If we stretched our iChat preview window up to around 1280 wide (the aspect ratio is not 4:3 in iChat 3), it was clear that we were looking at a VGA image scaled up.  iChat and other such apps are probably calling SGSetChannelBounds with 320×240 or 640×480 because that’s the size they use for conferences, whereas I’m specifying a really large size (1600×1200).

- Thanks to Dave for letting me mess around with his new laptop this afternoon. 

Just a heads up if you depend on your Logitech webcam microphone. Wednesday’s awkwardly named 10.4.10 update breaks the USB microphone support for the latest family of Logitech cameras (Fusion, Ultra Vision, Notebooks Pro, Pro 5000). They simply no longer show up as an audio device. Older QuickCams such as the STX and the original Notebooks Pro are not affected. We hope this will be fixed shortly, as Apple actually sells the Fusion on Apple Store.

Safari 3 on Windows is old news by now, but I still have this nagging feeling.

Apple has had iTunes on Windows for years, but iTunes is a Carbon app, and doesn’t contain any Cocoa, AppKit, or Objective-C. (A quick analysis with otool will show this.)
I’m not saying that getting iTunes ported to the PC was easy, but it’s not exciting because we don’t write Carbon apps anymore.

Now enter Safari for Windows… Safari is written from the ground up in Cocoa. A quick analysis of Safari will show you that it contains over 200 Obj-C classes and about 4000 Obj-C methods. Its controllers (logic) and views (the UI) are built entirely in Objective-C using AppKit.

Why is this an important fact?

I’m a huge fan of Cocoa and coding using AppKit: I find it makes coding fast and efficient. The only downside? Without a huge nasty porting effort, your code is permanently stuck on the Mac. All of your NSMutableDictionary, all of your NSWorkspace, all of your NSLock, all of your NS-anything. Today, it’s just not leaving your Mac. It’s stuck.

I’d really like to port CardRaider to Windows, but it makes such heavy use of Objective-C and AppKit, that it just seems like a nasty task.

Now enter Safari on Windows. Cursory examinations of the Safari 3 Windows binaries shows no evidence of an Objective-C runtime or any AppKit.dll. So let’s assume for a moment that they didn’t just port the Cocoa and AppKit libraries…
So did Apple really rewrite all 200 Obj-C classes in Safari in C++ or C# and change them to not use Cocoa? Are they somehow going to maintain two codebases, one written entirely in Obj-C based on AppKit, and one in another language and based some other library? Maybe they did… they seem to have done that with WebKit and WebCore….

Or, more likely, do they have some kind of secret button (some kind of tool, script, or compiler modification) that takes Safari’s 200 .m files and makes Windows code.

I’m not trying to trivialize their porting effort, because I’m sure it wasn’t an easy task. I’m just looking at the implications of maintaining two mostly identical versions of Safari 3, one written in Objective-C using Cocoa, and the other not allowed to use those things.

Did they really port this manually? I don’t think so.
otool -ov /Applications/Safari.app/Contents/MacOS/Safari | grep -c Module
202
otool -ov /Applications/Safari.app/Contents/MacOS/Safari | grep -c method_name
4097
otool -tV /Applications/Safari.app/Contents/MacOS/Safari | grep -c _objc_msgSend
20319

I hope for their sakes that it’s somehow automated, and if it is…

Apple: Share the technology!
Give developers the secret button to easily make their Cocoa apps into Windows apps!

Can you think of anything that could do more to encourage Mac development than allowing that code to also be useful for Windows?

But maybe they really did port it line by line, class by class.
If you look at the Windows branch of WebKit/WebCore, all the .m files have become .cpp files and the AppKit calls have become CoreFoundation calls. And it shows no sign of having been automated.
And a lot of the code has clearly been manually ported to Windows code. For example looking at a randomly selected class/routine:

The once graceful:
-[WebIconDatabase iconForURL:withSize:cache:]

has become:
HRESULT WebIconDatabase::iconForURL(BSTR url, LPSIZE size, BOOL cache, OLE_HANDLE* bitmap)


with the underlying NSWorkspace, NSImage, NSMutableDictionary, etc. calls now turned into dirty Windows CreateDIBSection code.